Content

The Dunning-Kruger Effect

Dunning-Krugger Effect ဆိုတာက ဖြစ်ရပ်ဆန်းတစ်ခု။ ဘယ်လိုဖြစ်ရပ်ဆန်းလဲဆိုရင်

တချို့လူတွေက နဲနဲပဲသိပြီး သူတို့ကိုသူတို့ ယုံကြည်ချက်တွေအများကြီးရှိကြတယ်။ အဲ့လိုပဲ တချို့ကြတော့ ခုဏကလူတွေထက်ပိုပြီး သိကြတယ်။ ဒါပေမဲ့ သူတို့လောက် ယုံကြည်ချက်တွေမရှိကြဘူး။ Graph ကိုကြည့်ရင် သိသာပါတယ်။ စဆရကတွေက အသိဉာဏ်မှာနဲတယ်။ ဒါပေမဲ့ ယုံကြည်ချက်မှာများတယ်။

Dunning-Kruger တို့ research တွေအရ ဘာကြောင့်လဲဆိုတော့ သူတို့တွေက Topic ၁ ခုအပေါ်မှာ သေသေချာချာမသိပဲ အပေါ်ယံလေးပဲသိတယ်။ ဥပမာ Topic ၁ ခုအပေါ်မှာ ပြား ၈၀ ဖိုးလောက်သိတယ်။ ပြီးတော့ သူတို့ထင်တာက ဒီ Topic က ၁ ကျပ်ဖိုးလောက်ပဲ ရှိတယ်ထင်ကြတယ်။ အဲ့တော့ သူတို့ကို သူတို့ ၈၀% တောင်သိပြီဆိုပြီး အထင်ကြီးပြီး ဆရာကြီးတွေလို့ထင်ကြတယ်။

သူတို့မသိတာက အဲ့ Topic က ၁ သိန်းဖိုးလောက် လေ့လာလို့ရတယ်ဆိုတာကို။ ဘာကြောင့်လဲဆိုတော့ သူတို့သေသေချာချာ မလေ့လာရသေးလို့။ ပိုလေ့လာလေ ကိုယ်မသိသေးတာတွေ အများကြီးရှိသေးတယ်ဆိုတာသိလာလေ။ ဒီလိုသိလာလေ မိမိကိုယ်မိမိ ယုံကြည်ချက်အားနည်းလာလေ။ အသိဉာဏ်အရတက်လာတယ်။ ဒါပေမဲ့ ယုံကြည်ချက်က အရင်ကျလာတယ်။ သူတို့က ၁၀၀၀ ဖိုးလောက်သိတယ် (ဟို ပြား ၈၀ ဖိုးသိတဲ့လူထက်စာရင် ပိုများတယ်)။ ဒါပေမဲ့ သူတို့သိတာက နောက်ထပ် ၉၉၀၀၀ ဖိုးလောက်သိဖို့လိုသေးတယ်ဆိုတာ။

ဆက်လေ့လာတော့မှ အောက်ဆုံးနေရာကနေ တဖြေးဖြေးယုံကြည်ချက်တက်လာပြီး တကယ်သိလာလေပါ။

ဒီ​ Dunning-Gruger Effect က Software Engineering မှာလည်း သက်ရောက်မှုရှိတယ်။ များသောအားဖြင့် Software Engineering မှာ လူ(၃) မျိုးကို အဓိက တွေ့ရတယ်။

၁။ အသင်လွယ် အတက်လွယ် ပြီး အစွမ်းပြချင်တဲ့ တက်ကြွတဲ့ ကြက်ဖ လေးတွေ။

၂။​ ဘယ်ကစမ်းစမ်း ညာကစမ်းစမ်း အကုန်သိ အကုန်တက်တယ်ဆိုတဲ့ ဆရာကြီးတွေ။ ဒီလူတွေက ဘာမေးမေး ဖြေနိုင်ပြီး သူတို့ကိုယ် သူတို့လည်း အကုန်သိ အကုန်တက်လို့ ထင်နေကြတယ်။

၃။ တော်တော်များများကို သိပေမယ့် မေးလိုက်ရင် ချက်ခြင်းမဖြေနိုင်ပဲ အင်း တကယ်လို့ / ဖြစ်ကောင်းဖြစ်နိုင်တယ် ဆိုပြီး တွေးတွေးဆဆ လေးလေးပင်ပင်ကြီး ဖြေတဲ့ ဆရာသမားတွေ။

ဒီလူ (၃) မျိုးက ဘယ်သူတွေလဲ? ပြောရရင် ကျွန်တော်တို့ Software Engineering မှာ ဖြတ်သန်းရမယ့် အဆင့်ဆင့်ပါပဲ။

Coding (verb) / Coder (noun)

ကျွန်တော်တို့ အကုန်လုံးလိုလို ဒီအဆင့်က စကြတာများတယ်။ Coding ကို သင်ရမှာ စိတ်လှုပ်ရှားတယ်။​ Hello World လို့ ကွန်ပျူတာမှာ ပေါ်လာတာနဲ့ ထမင်းမေ့ ဟင်းမေ့ အခြေအနေပေါ့။ နောက်တော့ အပြင်က ပြဿနာတွေကို ကွန်ပျူတာ ပရိုဂရမ်ရေးပြီး ရှင်းဖို့ ကြံတော့တာပဲ။ Cookbooks တွေ Youtube က Tutorial Video တွေ ကြည့်ပြီး လိုက်လုပ်မယ်။ Stackoverflow / Github နဲ့ အခြား ပလက်ဖောင်းတွေက ကုတ်တွေကို ကူးပြီး ကြုံလာတဲ့ error တွေကို ရှင်းမယ်။ နာရီပိုင်း / တစ်ရက်နှစ်ရက်အတွင်း Error တွေရှင်းပြီး ပရောဂျက် ( Proof of Concept - POC ) ထွက်လာတဲ့အခါ အတော်လေး ကျေနပ်ပိတီ ဂွမ်းဆီထိ ခံစားရပါရဲ့။ ဒီအချိန်မှာ we love coding တွေ ဘာတွေဖြစ်နေပြီး ဘယ်ပြဿနာမဆို coding နဲ့ ရှင်းမယ်ဆိုတာမျိုး ဖြစ်နေပြီ။

အကျင့်စရိုက်လက္ခဏာများ

• POC (Proof of Concept) တွေကို ခပ်မြန်မြန် ရေးနိုင်ပြီ။
• Requirement တွေ ရှင်းရှင်းလင်းလင်းမသိလည်း လက်ခံတယ်။ Requirement ပြင်ရင် အသစ်ကစပြီး ပြန်ရေးနိုင်တယ်။
• error အသစ်တွေကိုပဲ ရှင်းဖို့ အာသီသရှိတယ်၊ ရှင်းပြီးသား error အဟောင်းတွေကို improve ဖြစ်အောင် မလုပ်ချင်ဘူး။
• ဘယ်ပရောဂျက်မဆို ရေးနိုင်မယ်လို့ ယုံကြည်ချက်ရှိတယ်။ မြန်မြန်လည်း ပြီးမယ်ထင်တယ်။

Developing (verb) / Developer (noun)

ဘာလာလာကုတ်နိုင်တယ်ဆိုတဲ့ အဆင့်ကို ရောက်ပြီး သိပ်မကြာခင်မှာပဲ ကိုယ့်ကို စာသင်ပေးတဲ့လူတွေနဲ့ စတွေ့ဖို့ အကြောင်းဖန်လာတယ်။ သူတို့က ဘာသင်ပေးလဲဆိုရင် ဘယ်လိုပိုပြီး အဆင့်အတန်းရှိရှိ ကုတ်ရတယ်ဆိုတာမျိုး။ တစ်ခါတစ်လေလည်း သူတို့ အဖွဲ့အစည်းတွေမှာ ဘယ်လို ကုတ်ကြတယ်ဆိုတာမျိုး။ ဒီမှာ ကိုယ်ကုတ်နေတဲ့ ပုံစံချည်းက အဆင့်မရှိမှန်းသိပြီး ရှက်တက်လာတယ်။ ရှိလို့ရှိမှန်းတောင်မသိတဲ့ Coding Standards တို့ ဘာတို့ စပြီးကြားဖူးလာတယ်။ နောက်တော့ ရှေ့က စီနီယာတွေက မရှိမဖြစ်လို့ပြောတဲ့ ကိစ္စတွေကို မရှိမဖြစ်လို့ယုံလာတက်ပြီ။ ဒီမှာ ပရောဂျက်စတဲ့အခါ Industry Best Practises တွေ၊ Architecture Pattern တွေကို မျက်လုံးစုံမှိတ်ပြီး သုံးလာပြီ။

အကျင့်စရိုက်လက္ခဏာများ

• POC (Proof of Concept) ရေးဖို့ကို အချိန်တွေ ယူလာပြီ။ ဘယ် Architecture ဘယ် Pattern နဲ့မှ အိုကေမယ် မအိုကေဘူးနဲ့ ရှုပ်ရှက်ခက်လာပြီ။
• Solution တစ်ခုရေးတဲ့အခါ အပ်နဲ့ထွင်းရမှာကို ပုဆိန်နဲ့ ခုတ်ပြီး ပုဆိန်နဲ့ခုတ်ရမယ့် ကိစ္စတွေကို ခဲတံချွန်ဓားနဲ့ ခုတ်တာမျိုးတွေ လုပ်လာပြီ။ ( over-engineer / under-enginner solutions )
• Requirement ရှင်းရှင်းလင်းလင်းမရှိရင် ရေးလို့မရဘူးတို့ဘာတို့နဲ့ ဇီဇာကြောင်လာပြီ။
• Error တစ်ခု ပြဿနာတစ်ခုကိုပဲ ဖြေရှင်းနည်း အမျိုးမျိုးထုတ်ပြီး ဘယ်ဟာက ဘယ်အပိုင်းမှာ ပိုကောင်းတယ်တွေ ဘာတွေ လုပ်နေပြီ။ sorting ဆိုရင်တောင် ဘယ် sorting algorithm က ဘယ်လိုအခြေအနေမှာ ပိုမြန်တယ်တို့ ဘာတို့။

Engineering (verb) / Engineer (noun)

ပြဿနာပေါင်းသောင်းခြောက်ထောင်အတွက် Solution တွေရေးပြီး Production မှာ စသုံးတဲ့အခါ ကိုယ့်ရဲ့ အားနည်းချက်တွေကို ကိုယ်ပြန်မြင်လာတယ်။ ဘယ်နေရာကတော့ အခု အလုပ်လုပ်နေပေမယ့် ဘယ်လိုအချိန်ကြရင် ကွဲမယ်ဆိုတာမျိုးတွေ မကြာခန တွေ့တွေ့လာတယ်။ ဒီ​ Flaw တွေကို ရေးတုန်းက မတွေ့ခဲ့ပဲ ဘာလို့အခုမှ တွေ့တာလဲ? ကိုယ်မျက်စိစုံမှိတ်ပြီး လူအထင်ကြီးပြီးရောဆို သုံးခဲ့တဲ့ Best Practises တွေ Golden Rules တွေက တကယ်လည်း အလုပ်မဖြစ်ဘူးလားလို့ တွေးမိလာပြီ။ ရှုပ်ထွေးလာတယ်၊ စာတွေပိုဖတ်ဖြစ်လာတယ်။ ပိုရှုပ်လာတယ်၊ ပိုဖက်တယ်။ နောက်ဆုံးတော့ သိလိုက်ပြီ။ အော် Best Practise ဆိုတာတွေကလည်း သူတို့သတ်မှတ်ထားတဲ့ ပြဿနာ / အခြေအနေတွေအတွက်ပဲ ကောင်းတာမျိုး။ ပြဿနာဆိုတာတွေက Unique ဖြစ်နေတာဆိုတော့ ကိုယ့်ပြဿနာကို အတိအကျ ရှင်းပေးနိုင်မယ်လို့ ကံသေကံမ မပြောနိုင်။ ဒီတော့ Industry မှာ ဘာတွေပြောင်းလဲနေပြီလဲ ဆိုတာမျိုး မျက်စိဒေါက်ထောက် ကြည့်ဖြစ်လာတယ်။ industry အတွင် းမှာ အဖွဲ့ဖွဲ့ကွဲနေပြီး ဟိုဘက် ဒီဘက် အပြန်အလှန် စကားရည်လုပွဲလိုမျိုး အချေအတင် ဆွေးနွေးနေကြတာကိုလည်း စိတ်ဝင်စားလာပြီ။ အပြင််မှာ ပြဿနာတွေ တက်နေသလို ကိုယ့်စိတ်ထဲမှာလည်း ပြဿနာတက်နေပြီ။ ကိုယ်သင်ယူထားတဲ့ Knowledge အချင်းချင်းလည်း မတည့်ကြတော့ဘူး။ ဒီမှာ “Why” ဆိုပြီး စမေးတက်လာပြီ။ ကိုယ်သိထားသမျှ ကိုယ်မှန်တယ်ထင်ထားသမျှကို စပြီး မေးခွန်းပြန်ထုတ်လာပြီ။ ငါဘာလို့ ဒါကို one and only အဖြေလို့ ထင်နေခဲ့တာလဲ? တစ်ခြားဟာရော မရှိဘူးလား? idea အသစ်တွေ solution အသစ်တွေ စပြီး လုပ်ဖြစ်လာပြီ။

အကျင့်စရိုက်လက္ခဏာများ

• POC ကို Coder တွေနဲ့အပြိုင် အမြန်ရေးနိုင်လာပြီ။
• ကိုယ့်ရဲ့ Knowledge နဲ့ Skill ကို စမ်းဖို့အတွက် ပိုပြီးရှုပ်တဲ့ ပြဿနာတွေကို ရှာလာတယ်။
• Requirement အသစ်တွေ တက်လာပြီဆိုရင် ရှုထောင့်ပေါင်းစုံက သုံးသပ်ပြီး တစ်ခါတစ်လေဆိုရင် Requirement ကိုပါ ကိုယ့်ဘာသာကိုယ် ပြန်ပြင်ခိုင်းတာမျိုးတွေ လုပ်လာပြီ။

The Dunning-Kruger peak

ကျွန်တော်တို့ တစ်ခုခုကို လေ့လာတဲ့အခါ ဒီ အဆင့်ကို ရောက်လာတက်တယ်။

ငါ အကုန်လုံးကို သိပြီ။ ငါထပ်သိစရာ မရှိတော့ဘူး။ ဘာလာလာ ဒေါင်းတယ်။

ဒါမျိုး အတွေးတွေ နေ့စဉ်နဲ့အမျှ တွေးမိနေရင် ဒီလူ ငပိန်းတောင်ထိပ် ကို ရောက်နေပြီလို့ ပြောလို့ရတယ်။

များသောအားဖြင့် တစ်နေ့တစ်နေ့ ဖန်တရာတေနေတဲ့ အလုပ်ကို လုပ်ရတဲ့သူတွေမှာ အဖြစ်များမယ်။

ဒီအဖွဲ့ထဲမှာ ဒီလူတွေနဲ့ ဒီ Tech Stack သုံးပြီး ဘာမှ Innovation မပါတဲ့ CRUD Module တွေပဲ လုပ်နေရရင် ဒီ ငပိန်းတောင်ထိပ်ကို ရောက်လာမှာ မြေကြီးလက်ခက် မလွဲပါပဲ။

Organization တွေ အနေနဲ့ကလည်း innovation တွေလုပ်ပြီး risk ယူဖို့က ခက်တယ်။ ဒီတော့ သူ့စီမှာ လုပ်နေတဲ့သူတွေအဖို့လည်း တိုးတက်ကြီးပွားဖို့ရာ ခက်မယ်။

နိဂုံးချူပ်

Health Care, Finicial နဲ့ Ecommerce မတူညီတဲ့ နယ်ပယ်တွေမှာ အလုပ်လုပ်ရင်း သိလာတာက နယ်ပယ်အသစ်တစ်ခုမှာ စပြီးအလုပ်လုပ်ရတိုင်း သိပ်မကြာဘူး ဒီတောင်ထိပ်ကို ရောက်လာတာပဲ။ တစ်ယောက်ယောက်က ဒီ Dunning-Kruger graph အကြောင်းပြောတာ ကြားမှ သတိပြန်ကပ်ရတယ်။ သြ လိုသေးပါလားပေါ့။ ဒီငပိန်းတောင်ထိပ်က ပြန်ဆင်းဖို့ဆိုရင် “Why” လို့သာ ခပ်နာနာမေး။ ဒါဆို အဆင်ပြေသွားလိမ့်မယ်။ မသိလို့ဆိုပြီး စိတ်ဓာတ်တွေ လှိမ့်ပိန့်ကျပြီးတော့တော့ မနေနဲ့ပေါ့။ ဖြည်းဖြည်းမှန်မှန် လေ့လာရင်း Enjoy the path. welcome from Lifelong Learning Club.

Ref;

https://medium.com/geekculture/dunning-kruger-effect-and-journey-of-a-software-engineer-a35f2ff18f1a https://www.linkedin.com/pulse/dunning-kruger-effect-aung-pye-tun/#

ဒီတော့ ကိုယ့်အခွင့်အလမ်း ကိုယ်ရှာမယ်ဆိုရင်

ဘာမှ ကောင်းကောင်းမသိပဲနဲ့ confident တွေ so high နေတာ မဖြစ်နိုင်ပါဘူးလို့ တွေးရင် မင်းလည်း အခု အဲ့ထိပ်ကို ရောက်နေတာ ဖြစ်ကောင်းဖြစ်မယ်။ ကိုယ့်ရဲ့ လုပ်ဖောင်ကိုင်ဘက်တွေ mentor တွေနဲ့ ပြန်ပြီး စကားေပြာကြည့်ဖို့လိုနေပြီ။

proof of concept (POC) keen - အာသီသ

ဒါကို Dunning-Kruger Effect လို့ခေါ်ပါတယ်။

ပညာတစ်ခုမှာ နည်းနည်းပဲ တက်တဲ့သူတွေက ကိုယ့်ကိုယ်ကိုယုံကြည်မှုတွေ so high ပြီး မိုးမမြင်လေမမြင်ဖြစ်နေတက်။ ပညာရပ်တစ်ခုဟာ ၁ က နေ ၁၀၀ အထိ ရှိတယ်ဆိုကြပါစို့။ အဲ့ဒီမှာ ၁ လောက်တက်တဲ့ သူဟာ သူအကုန်သိပြီလို့ ထင်တယ်။ နောက်မှာ လေ့လာစရာ ၁၀၀ အထိ ရှိသေးတယ်ဆိုတာ မသိလို့။

သူတို့ထက် ပိုပြီးတက်တဲ့သူတွေကတော့

Outline

Dunning-Kruger Effect ဆိုတာဘာလဲ?

Software Development မှာ တွေ့ရတဲ့ လူ (၃)​မျိုး

ဘယ်လို သိနိုင်မလဲ

ဘယ်လို ဖြေရှင်းမလဲ?

What? Why? How?

Let’s start with a brief definition

The Dunning-Kruger effect is the phenomenon whereby people with little knowledge tend to overestimate their abilities, precisely because they ignore how much knowledge is necessary to master them.

Let’s visualise this now …