Software Development နဲ့ပတ်သက်လို့ ကျောင်းမှာမသင်ခဲ့ရတာလေးတစ်ချို့
ကွန်ပျူတာသိပ္ပံကျောင်းသားတစ်ယောက်အနေနဲ့ Software Engineering ဆိုတာကို ဘာသာရပ်တစ်ခုအနေနဲ့ သင်ရပါတယ်။ စဥ်းစားကြည့်ပါ။ ဘဝမှာ ခင်ဗျားရေးဖူးတဲ့ အခက်ခဲဆုံး ပရိုဂရမ်က doubly linked list implementation လောက်ပဲရှိသေးမယ်။ ဒါပေမဲ့ ခင်ဗျားကို ဆော့ဖ်ဝဲကို ဘယ်လိုအဖွဲ့အစည်းတွေနဲ့ရေးကြတယ်။ Process တွေက ဘယ်လို၊ အဆင့်အဆင့်တွေ ဘယ်လိုရှိတယ်။ လူတွေအများကြီးကို ဘယ်လို manage လုပ်ရတယ်။ Stakeholder တွေနဲ့ ဘယ်လိို ဆွေးနွေးရတယ်ဆိုတာတွေ ပြောလည်း မျက်စိထဲမြင်မှာမဟုတ်ဘူး။ ပရိုဂရမ်တွေနဲ့ ကုတ်တွေနဲ့ ဘယ်လိုဆက်စပ်နေပါတယ်ဆိုတာတောင် ကောင်းကောင်းမြင်သေးတာမဟုတ်ဘူးကိုး။
ကျွန်တော်ဒီနေ့ရေးချင်တဲ့ အကြောင်းအရာကတော့ ကျောင်းတုံးက ဒါမှမဟုတ် ကျောင်းပြီးကာစတုံးက ဒါတွေသိခဲ့ရင်ကောင်းမှာလို့ ပြန်တွေးမိတဲ့ software engineering နဲ့ပတ်သက်တဲ့ အသိလေးတစ်ချို့ပါပဲ။
Waterfall is old-school. Agile is now state-of-the-art.
ပထမဆုံးပြောချင်တဲ့ ကိစ္စကတော့ Software Development Life Cycle (SDLC) တွေပါ။ ကျောင်းမှာတုန်းကဆို Waterfall process model ရော Agile Development Methodologies တွေအကြောင်းရော သင်ခဲ့ရပါတယ်။ နှစ်ခုလုံးမှာ သူ့အားသာချက်အားနည်းချက်ရှိတယ်ဆိုပြီး သင်ခဲ့ရတော့ ဘယ်ဟာက လက်တွေ့ပိုကျတယ် ဘယ်ဟာကိုပို အလေးထားပြီးလေ့လာသင့်သလဲဆိုတာ ခွဲခြားမသိခဲ့ပါဘူး။
နောက်ပိုင်း အလုပ်ခွင်ထဲရောက်လာတဲ့အခါ Agile methodoglies တွေက အရမ်းကိုတွင်ကျယ်နေပြီး Waterfall ကို သိပ်မသုံးကြတော့တာကြုံရပါတယ်။ ဘာလို့ Agile ကိုပိုသုံးကြလဲဆိုတော့ Waterfall Process နဲ့ရေးတဲ့ ဆော့ဖ်ဝဲတွေက အချိန်သိပ်ကြာပါတယ်။ နောက်ပိုင်းဆော့ဖ်ဝဲက နေရာတကာမှာ သုံးလာကြတယ်။ အရင်က ဆော့ဖ်ဝဲတစ်ခုကို ရေးချင်ရင် တစ်နှစ်နှစ်နှစ်ကနေ လေးငါးခြောက်နှစ်လောက်ထိိကြာပါတယ်။ ပြီးရင် အဲ့ဒီ ဆော့ဖ်ဝဲကို package လုပ်ပြီး ရောင်းကြ ဖြန့်ချီကျ သုံးကြရတယ်။ အဲ့တော့ ဆော့ဖ်ဝဲကို update လုပ်ချင်ရင်လည်း အချိန်သိပ်ကြာတဲ့ အတွက် စကတည်းက specification တွေကို ဖြစ်နိုင်သမျှကြိုစဥ်းစားကြတယ်။ အဲ့တော့ အချိန်တွေပိုကြာတယ်။ အဲ့လိုနဲ့ သံသရာလည်ပါတယ်။
ဒါပေမဲ့ အင်တာနက်ဆော့ဖ်ဝဲတွေ ခေတ်စားလာတဲ့ အချိန်မှာ ဆော့ဖ်ဝဲကလည်းပြောင်းလာတယ်။ ဥပမာ web based software တွေအတွက် functionality အသစ်ထည့်ရတာသိပ်မခက်ခဲဘူး။ ဆော့ဖ်ဝဲက ကိုယ့်ဆာဗာမှာပဲ run တာကိုး။ အဲ့တော့ စကတည်းက အကုန်လျှောက်ထည့်ရေးစရာမလိုဘူး။ ကိုယ့်ဆော့်ဝဲရဲ့ အရေးအကြီးဆုံးလို့ ထင်ရတဲ့ functionality တွေကို အချိန်တိုတိုနဲ့ အရင်ပြီးအောင်ရေးလိုက်တယ်။ ပြီးမှ ပြင်စရာလိုရင်ပြင်တယ်။ အဲ့တော့ ဆော့ဖ်ဝဲတွေက အရင်လို မဟုတ်ပဲ မြန်မြန်နဲ့များများ ဖြစ်လာတယ်။ လူတွေအများကြီးသုံးတဲ့ ဆော့ဖ်ဝဲတစ်ခုကို အရင်လို လူရာချီတဲ့ team တွေ process တွေမပါပဲ ရေးနိုင်လာကြပြီ။ NASA လိုမျိုး budget ကြီးကြီးနဲ့ အမှားမခံနိုင်တဲ့ ဆော့်ဖ်ဝဲတွေရေးရတဲ့ agency တွေတောင်မှာ agile methodoglies တွေကို အသုံးချနေကြပါပြီ။
အဲ့ဒါကြောင့် SDLC အများကြီးကို နှိုင်းယှဉ်နေတာထက် တကယ်အလုပ်ဖြစ်တဲ့ SDLC တစ်ခုကိုနားလည်အောင်လုပ်ပြီး လက်တွေ့အသုံးချတဲ့အခါ ရင်းနှီးနေအောင်လုပ်ထားရင် ပိုကောင်းပါလိမ့်မယ်။
Agile process တွေအကြောင်းစလေ့လာကြည့်ပါ။ ဥပမာ SCRUM process
Most software is grown. Not invented.
နောက်တစ်ချက်ကတော့ တကယ့်လက်တွေ့လုပ်ငန်းခွင်တွေမှာ ဆော့ဖ်ဝဲတွေဟာ အချိန်တစ်ခုပေးပြီး ဖြည်းဖြည်းချင်းတည်ဆောက်ယူကြရတယ်ဆိုတဲ့ ကိစ္စပါ။ ကျောင်းမှာတုံးက ဆော့ဖ်ဝဲဆိုတာ requirement တွေ specify လုပ်ပြီး implementation လုပ်၊ ပြီးရင် user တွေကိုရောင်း ကိစ္စပြတ်ပြီလို့ထင်ခဲ့ပါတယ်။ ပထမဆုံး requirment specification ကောင်းအောင်လုပ်ခဲ့ရင် implementation မှာ လန်ပြန်ထွက်အောင်ရေးခဲ့ရင် ဆော့ဖ်ဝဲကောင်းကောင်း ထွက်လာမှာပဲလို့ သမားရိုးကျ ထင်ခဲ့ဖူးပါတယ်။ ဒါပေမဲ့ တကယ့်တကယ်တမ်းတော့ အောင်မြင်လူကြိုက်များနေတဲ့ ဆော့ဖ်ဝဲတွေအကုန်လုံးနီးပါးက စကထည်းက feature တွေအကုန်ပါနေတာမဟုတ်ပဲ user တွေရဲ့ feedback ကိုအသုံးချပြီး တစ်ဖြည်းဖြည်းတည်ဆောက်ယူခဲ့ကြရတာ များပါတယ်။ အဲ့တော့ ဆော့ဖ်ဝဲဆိုတာ တည်ဆောက်တတ်ရုံတင်မဟုတ်ပဲ ရေရှည်ထိန်းသိမ်းနိုင်အောင် လုပ်ဖို့ သိပ်အရေးကြီးတယ်ဆိုတာ နားလည်ဖို့လိုပါတယ်။
ဆော့ဖ်ဝဲကို ရေရှည်ထိန်းသိမ်းနိုင်အောင် ဘယ်လိုရေးရလဲဆိုတဲ့ နည်းစနစ်တွေ သီအိုရီတွေကို ကျောင်းမှာမသင်ခဲ့ရသလောက်ပါပဲ။ ဆော့ဖ်ဝဲကို အလုပ်ဖြစ်အောင်ရေးနည်းကိုတောင် မနည်းသင်နေကြရတာဆိုတော့ ကျောင်းတွေရဲ့ အပြစ်တော့လည်းမဟုတ်ပါဘူး။ ဒါပေမဲ့ ဒီနည်းစနစ်တွေ သီအိုရီတွေက တကယ်အောင်မြင်တဲ့ ဆော့ဖ်ဝဲတွေရေးလာရတဲ့အခါ မရှိမဖြစ်လိုလာကြပါတယ်။ အတွေ့အကြုံကနေသင်ယူလာကြရပါတယ်။ တကယ်တော့ ကိုယ့်အရှေ့က အလုပ်လုပ်ခဲ့တဲ့သူတွေ ရေးထားတဲ့ စာအုပ်တွေ၊ blog post တွေ၊ conference talk တွေမှာ အဲ့ဒီနည်းစနစ်တွေ ရှာဖွေလေ့လာလို့ရပါတယ်။ ရှာရကောင်းမှန်းသိဖို့လိုပါတယ်။ မဟုတ်ရင် ချွေးဇောတွေပျံ စိတ်တွေညစ်ပြီးမှ ဒီလိုလုပ်ရပါလား ဒီနည်းတွေရှိပါလားဆိုတာ ပြန်ရှာဖွေတွေ့ရတဲ့အခါ အချိန်တွေကုန် လူပင်ပန်းပါတယ်။
Actionable advice အနေနဲ့ကတော့ ဒီစာအုပ်တွေ ရှာဖတ်ပါလို့ ညွှန်းချင်ပါတယ်။ maintainable software ဘယ်လိုရေးရမလဲဆိုတာကို အသေးစိတ်
Software development is not just about coding. Creating software is (mostly) a social process.
နောက်တစ်ခုအနေနဲ့ ထပ်ပြောချင်တာက ဆော့ဖ်ဝဲတစ်ခုရေးဖို့ ကုတ်ရေးရုံနဲ့ မပြီးဘူးဆိုတဲ့ ကိစ္စပါ။ ကျွန်တော်တို့ career အစ ဆော့ဖ်ဝဲရေးတတ်ကာစ ကိုယ့်ဘာသာကိုယ် ပရောဂျက်သေးသေးလေးတွေရေးကြရင် အခက်ခဲဆုံးအပိုင်း coding ပါပဲ။ ဘာလို့လဲဆိုတော့ ကိုယ်မှမရေးဘူးသေးတာကိုး။ အဲ့လိုနဲ့ လေ့လာရင်း လျှောက်လုပ်ရင်း အလုပ်ဖြစ်အောင်ရေးတတ်လာတယ်။ အဲ့တော့ အခက်ဆုံးအပိုင်းက coding ပဲ၊ implementation ဘယ်လိုလုပ်ရလဲဆိုတာသိရင် ဆော့ဖ်ဝဲရေးလို့ရပြီလို့ထင်တတ်ပါတယ်။
တကယ်တော့ ကိုယ်က အတွေ့အကြုံမရှိသေးတာရယ်၊ ကိုယ်ရေးဖို့ ကြိုးစားတဲ့ ပရောဂျက်မျိုးကလဲ သိပ် ရှုပ်ရှုပ်ထွေးထွေး လုပ်ရလေ့မရှိတာရယ်ကြောင့် ဖြစ်ပါတယ်။ တကယ့်လုပ်ငန်းခွင်ဝင်တဲ့အခါအခါကျတော့ software တစ်ခုတည်ဆောက် ထိန်းသိမ်းဖို့ အတွက် developer တွေတင်မကပဲ လူပေါင်းစုံ အဖက်ဖက်က ဝိုင်းပြီး ပံ့ပိုးကြရပါတယ်။ Project တွေအကုန်လုံးက team project တွေဖြစ်လာပါတယ်။ အဲဒီအခါ communication skill တွေ တစ်ဖက်လူကို ကိုယ်ပြောတာနားလည်အောင် ပြောတတ်ဖို့ သူပြောတာကို နားလည်တတ်ဖို့၊ စာနဲ့ရေးပြီးဆက်သွယ်ရရင်လည်း ရှင်းရှင်းလင်းရေးတတ်ဖို့၊ နောက်လူမှုဆက်ဆံရေးမှာ အဆင်ပြေပြေဆက်ဆံတတ်ဖို့စတဲ့ soft skill တွေလိုလာပါတယ်။ အထူးသဖြင့် ငါပြောတာမှန်တယ်၊ ငါ့အထင်မြင်က ပိုအရေးကြီးတယ် ဆိုပြီး ငါတကောကော မကောတတ်ဖို့လိုပါတယ်။
အဲ့တာကြောင့် အလုပ်ခွင်ဝင်တဲ့အခါ ကုတ်ရေးတဲ့အခက်အခဲတွေတင်မဟုတ်ပဲ တစ်ခြားလူမှုဆက်ဆံရေး အခက်အခဲတွေပါရှိမယ်လို့မျှော်လင့်ထားပါ။ ကိုယ့်ဖက်သူ့ဖက်ကြည့်ပေးပါ။ ကုတ်ပဲရေးဖို့ တွေးမနေပဲ ကိုယ့်အထက်လူကြီးတွေ ဘယ်လိုစကားပြောသလဲ၊ ဘယ်လို အလုပ်လုပ်သလဲ သင်ယူပါ။ ကိုယ့်ကို ဒီ feature တစ်ခုရေးခိုင်းရင်း ဒါရေးပြီးရင်ပြီးတာပဲလို့ မတွေးပဲ ဒါကိုဘာလို့ ရေးခိုင်းတာလဲ။ ဘယ်သူကသုံးချင်တာလဲ ဘာအကျိုးကျေးဇူးရနိုင်လို့လဲ စသဖြင့် မေးခွန်းတွေထုတ်ပါ။ စူးစမ်းပါလို့ပြောချင်ပါတယ်။
Actionable advice အနေနဲ့ကတော့ ဒီ talk လေးတစ်ခုကို နားထောင်ကြည့်ဖို့ ညွှန်းချင်ပါတယ်။
Code is read more often than it is written.
ဒီတစ်ချက်ကတော့ ကုတ်နဲ့ အဓိက သက်ဆိုင်ပါတယ်။ ကုတ်ရေးပြီဆိုရင် ကိုယ်ရေးချင်တဲ့ specification တစ်ခုကို ပြီးအောင်တည်ဆောက်ကြရတယ်။ ပြီးသွားလို့ ကိုယ်ဖြစ်စေချင်တဲ့ အတိုင်းအလုပ်လုပ်သွားရင် ပြီးပြီလို့ထင်တတ်ကြတယ်။ တကယ်တော့ အဲ့ကုတ်က နောက်တစ်ကြိမ်အပြောင်းအလဲလုပ်ရဖို့၊ ဒါမှမဟုတ် တစ်ခြားကုတ်အပိုင်းအစတစ်ခုနဲ့ ချိတ်ဆက်ရဖို့ chance များပါတယ်။ အဲ့ချိန်ကျရင် အဲ့ကုတ်ကိုကိုယ်ပြန်ကြည့်ရပါတယ်။ နောက်ကိုယ်က တစ်ခြား developer တွေနဲ့ အလုပ်လုပ်တဲ့အခါ သူများရေးထားတဲ့ကုတ်ကို ကြည့်ရဖတ်ရတာတွေ လုပ်ရပါတယ်။ တကယ့်အလုပ်ခွင်မှာ သေချာပြန်စဉ်းစားကြည့်ရင် ကုတ်ကို ဖတ်နေရတာက ရေးရတာထက်ပိုများပါတယ်။ အဲ့တော့ ကုတ်ဖတ်တတ်တဲ့ အကျင့် လုပ်ထားဖို့လိုပါတယ်။ သူများကုတ်ကို ဖတ်တဲ့အခါ အရေးကြီးတဲ့ information တွေကို ကုတ်ကနေ ခွဲခြားတတ်ဖို့ အလေ့အကျင့်လုပ်ထားပါ။ ကိုယ်ရေးနေတဲ့ programming language ကို ကိုယ်ကောင်းကောင်းနားလည်ရင် သူများကုတ်က ဘာinput တွေယူလဲ ဘာ type တွေသုံးထားလဲ ဘာ output တွေရှိလဲ conditional branch တွေဘယ်လောက်တောင်ခွဲပြီးရှိနေလဲ စသဖြင့် ကုတ်ရဲ့ ရည်ရွယ်ချက်နဲ့ အလုပ်လုပ်ဆောင်ပုံ အချက်အလက် တွေကို နားလည်နိုင်ပါတယ်။ အဲ့လိုပဲ ကိုယ်ရေးတဲ့ကုတ်ကို လည်း တစ်ခြားလူတွေ နားလည်အောင်ရေးဖို့ နည်းလမ်းတွေ သင်ယူပါ။ ပရိုဂရမ်တစ်ပုဒ်ကို တူညီတဲ့ ရလဒ်ထွက်အောင် နည်းလမ်းမျိုးစုံနဲ့ ရေးနိုင်ပါတယ်။ တစ်ချို့နည်းလမ်းတွေက ပိုနားလည်ရလွယ်ပြီး ပိုပြင်ရလွယ်ပါတယ်။ အဲ့လို နည်းစနစ်တွေကို သင်ယူပါ။ ဒီအကြောင်းအရာနဲ့ ပတ်သက်လို့ အောက်မှာ ပရော်ဖက်ဆာကြီး Donald Knuth ရဲ့ quote တစ်ခုကို ပြန်ရှယ်ပေးထားပါတယ်။
“Programs are meant to be read by humans and only incidentally for computers to execute.”
― Donald Knuth
Actionable advice အနေနဲ့ကတော့ အထက်ကညွှန်းခဲ့တဲ့ Clean Code စာအုပ်ကိုပဲ ဖတ်ကြည့်ပါ။ အဲ့ဒီ့ထဲမှာ ခုမှကုတ်စရေးတဲ့သူရော စီနီယာတွေအတွက်ရော ဖတ်ရလွယ်တဲ့ကုတ် ဘယ်လိုရေးရမလဲဆိုတဲ့ လက်တွေ့အသုံးကျတဲ့ လမ်းညွှန်ချက်တွေပါပါတယ်။
There are many levels of programmers.
နောက်ဆုံးတစ်ချက်အနေနဲ့ကတော့ စီနီယာ၊ ဂျူနီယာကိစ္စပါ။ ကုတ်ကို အလုပ်ဖြစ်အောင်ရေးတတ်လာတဲ့အခါကျရင် ကိုယ့်ကိုယ်ကို ယုံကြည်မှုလွန်ကဲတတ်ကြပါတယ်။ ဘာရေးရေး ငါရေးတတ်ပြီလို့ထင်တတ်ကြပါတယ်။ ဆော့ဖ်ဝဲတစ်ခုမှာ အစိတ်အပိုင်းတွေအများကြီးပါပါတယ်။ မမြင်ရတဲ့ complexity တွေရှိပါတယ်။ ခုခေတ်မှာ software tooling တွေ framework တွေက သိပ်ကောင်းလာတော့ နားလည်လွယ်တဲ့ beginner တွေအတွက် စစချင်းမှာ အချိန်သိပ်မကြာပဲ အလုပ်ဖြစ်အောင်ရေးဖို့ ခပ်မြန်မြန်တတ်နိုင်ပါတယ်။ အဲ့တော့ ကိုယ်နဲ့တူတူ ဒါမျိုးကုတ်ပဲရေးနေတဲ့ စီနီယာတွေနဲ့ ခြေရာတိုင်းတတ်ကြပါတယ်။
ဒါပေမဲ့ အရှေ့လူတွေဖြေရှင်းပေးထားတဲ့ ready-made solution နဲ့မကိုက်တဲ့ ပြသနာနဲ့ မကိုက်တဲ့ ပြသနာတွေကြုံလာတဲ့အခါ အဲ့လိုပြသနာတွေကို ဖြေရှင်းဖို့ အလုပ်ဖြစ်ရုံမဟုတ်ပဲ ဒီလိုလုပ်ရင် ဒါကကောင်းပြီး ဒါတော့ မကောင်းဘူးဆိုတဲ့ judgement တွေလိုလာတတ်ပါတယ်။ အဲ့ဒီအခါမျိုးကျရင် အဲ့လို unfamiliar problem တွေကို ဖြေရှင်းဖူးတဲ့ အတွေ့အကြုံရှိ ပရိုဂရမ်မာတွေက မြန်မြန်ဆန်ဆန်နဲ့ မှန်မှန်ကန်ကန် ဖြေရှင်းနိုင်ကြပါတယ်။ အဲ့ဒီလိုဖြစ်တဲ့အခါ ခံယူချက်မမှန်ရင် လုပ်ခိုင်းတဲ့လူက ညစ်တွန်းတွန်းပြီး မဖြစ်နိုင်တာတွေလာခိုင်းနေတယ်လို့တွေးပြီး ကိုယ့် သင်ယူမှုပိတ်ပင်သွားတတ်ပါတယ်။
တောင်တစ်တောင်ထက် မြင့်တဲ့နောက်ထပ်တောင်တစ်တောင်က အမြဲတမ်းရှိတယ်ဆိုတဲ့ စကားအတိုင်းပါပဲ။ ကိုယ့်ထက်အတွေ့အကြုံရှိတဲ့သူတွေ နဲ့ အတူတူလုပ်ရတဲ့အခါ သူတို့ဆီက သင်ယူစရာရှိတာသင်ယူပါ။ မေးခွန်းတွေမေးပါ။ သူတို့ပြောတာမှားတယ်ထင်ရင် ပွင့်ပွင့်လင်းလင်း ယဉ်ယဉ်ကျေးကျေးပြောပြပါ။ များသောအားဖြင့် ကိုယ်ထင်တာက မှားနေတတ်တယ်။ ကိုယ်ယူဆထားတဲ့ အချက်တစ်ခုခုကလွဲနေတတ်တာမျိုး ကိုယ်မသိတဲ့ တစ်ချက်ချက်ကို သူတို့က စဉ်းစားမိနေတာမျိုးဖြစ်တတ်တယ်။ အဲ့ဒီအခါ ကိုယ့်မှာ ပညာရပါတယ်။ ကိုယ်ကမှန်နေရင်လည်း ကိုယ့် knowledge ကို solid ဖြစ်စေပါတယ်။
Google မှာ ဆော့ဖ်ဝဲ အင်ဂျင်နီယာအဖြစ်လုပ်လုပ်နေတဲ့သူတွေကို level အဆင့်ဆင့်သတ်မှတ်ထားပါတယ်။ Level ၈ ဆင့် ၉ ဆင့်လောက်ရှိပါတယ်။ အကုန်လုံးက ဆော့ဖ်ဝဲ အင်ဂျင်နီယာတွေပါပဲ။ ပြောချင်တာကတော့ technical skill level တွေက ကိုယ်ထင်တာထားတာ အဆင့်ဆင့်ပိုရှိတယ်ဆိုတာပါ။ ကျောင်းမှာတုံးက ကုတ်ရေးတယ်ဆိုတာ ဆော့ဖ်ဝဲ SDLC ထဲက implementation အဆင့်ပဲ low level ပဲ။ တကယ်အဆင့်ပိုမြင့်ချင်ရင် project manager လုပ်ရတာပဲလို့ တစ်ထစ်ချ မှတ်ယူထားစရာမလိုပါဘူး။ management ပိုင်းက လမ်းဆုံးမဟုတ်ပါဘူး။ ပိုမြင့်တဲ့ technology တွေ architecture တွေ၊ နည်းပညာတွေကို တည်ဆောက်နေတဲ့ world class company တွေမှာ veteran engineer တွေအတွက်အလုပ်တွေရှိပါတယ်။ အဲ့တာကြောင့် ကိုယ်က နည်းပညာတစ်ခုကို သုံးတတ်ပြီဆိုရင် သုံးတတ်ရုံနဲ့ မကျေနပ်ပါနဲ့။ အသစ်သစ်တွေထပ်လေ့လာပါ။ ကိုယ်နားလည်ထားတဲ့ abstraction layer အောက်ကနောက်တစ်ဆင့်ကို နားလည်အောင်အားထုတ်ပါလို့ တိုက်တွန်းချင်ပါတယ်။ ကိုယ့်အတွက်ပိုတော်အောင်လုပ်ရမဲ့ အခွင့်အလမ်းတွေ အမြဲရှိပါတယ်။ ကိုယ်က ကိုယ့်ဘာသာကိုယ် ပိတ်မပစ်ဖို့ပဲလိုပါတယ်။
Actionable advice အနေနဲ့ကတော့ ဒီ video talk လေးနားထောင်ကြည့်ပါ။ ဂျူနီယာ developer တစ်ယောက်အနေနဲ့ ဘယ်လိုတွေးပြီး ဘယ်လိုလေ့လာသင်ယူရမလဲ။ ကိုယ့်ကိုယ်ကိုယ် ဘယ်လို level up လုပ်ရမလဲဆိုတဲ့ practical advice တွေပါပါတယ်။ ပြီးတော့ Pragmatic Programmer စာအုပ်ကို ဖတ်ကြည့်ပါ။ တကယ်လက်တွေ့ အသုံးကျတဲ့ advice တွေပါပါတယ်။