Software Developer

အောင်မြင်တဲ့ Developer တွေရဲ့ အမူအကျင့် ငါးရပ်

Perl Programming Language ရဲ့ မူလဖန်တီးရှင် လာရီဝေါက ပြောဖူးတယ်။ 

စကေး စွန်းကြမ်းတဲ့ ဒီဗလုပ်ပါတွေတိုင်း ထူးခြားတဲ့ ပါရမီ သုံးခုရှိတယ်၊ အဲဒါတွေက (၁) အပျင်းကြီးတာ (၂) စိတ်မရှည်တာ (၃) ဖင်ခေါင်းကျယ်တာတဲ့။

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

သူတို့ဟာ စိတ်မရှည်ဘူး၊ အဲဒါကြောင့် အစကတည်းက ပြည့်စုံအောင် တည်ဆောက်ကြတယ်။ ယူဆာတွေ အရစ်မခံဘူး။

သူတို့ဟာ ဖင်ခေါင်းကျယ်ကြတယ်၊ အဲဒီအတွက် သူတစ်ပါးတွေ အပစ်ပြောစရာ၊ ဝေဖန်စရာမလိုအောင် ကုဒ်တွေကို ရေးကြတယ်။

အောင်မြင်တဲ့ ဒီဗလုပ်ပါ ဖြစ်ဖို့ စကေး စွန်းကြမ်းတဲ့ ဒီဗလုပ်ပါ ဖြစ်ကို ဖြစ်ရမယ်လို့ မဆိုလိုပါဘူး။ (ဒါပေမယ့် တဖြည်းဖြည်းနဲ့ ကြမ်းလာဖို့တော့ လိုပါတယ်။)

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

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

အောင်မြင်မှုအကြောင်း ပြောရမယ်ဆိုရင်တော့ တစ်ယောက်နဲ့ တစ်ယောက် အမြင်တူမှာ မဟုတ်ပါဘူး။ အဲဒီအပြင် ဘဝမှာ ဖြစ်ပေါ်လာတဲ့ စိန်ခေါ်မှုတွေကို ဘယ်လိုအမူအကျင့်တွေနဲ့ တုန့်ပြန်လဲဆိုတဲ့ အပေါ်မှာလဲ အောင်မြင်မှုက တည်မှီနေပါတယ်။ အလိုအလျှောက် တုန့်ပြန် လုပ်ဆောင် လေ့ရှိတဲ့ အမူအကျင့်တွေဟာ အောင်မြင်မှု ရှုံးနိမ့်မှုတွေအပေါ်မှာ ၄၀% လောက် သက်ရောက်မှုရှိတယ်လို့ Duke University က သုတေသနတွေ့ရှိချက်တွေအရ သိရပါတယ်။ 

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

(၁) ကျွမ်းကျင်ပိုင်နိုင်မှုနှင့် ပညာရှင်ဆန်ဆန် အလုပ်လုပ်ခြင်း

စတိ(ဗ်)မာရာဘိုလီက ပြောဖူးပါတယ်။ 

မှန်ကန်တဲ့အလုပ်နဲ့ ခက်ခဲ့တဲ့ အလုပ်တွေဟာ အမြဲတမ်း တူနေတတ်တာ တစ်ခုရှိပါတယ်။ အဲဒါကတော့ ကျွမ်းကျင်ပိုင်နိုင်ဖို့နဲ့ ပညာရှင်ဆန်ဆန် အလုပ်လုပ်ဖို့ လိုအပ်ချင်းပါပဲ။

Professionalism (ပညာရှင်ဆန်ဆန် အလုပ်လုပ်ခြင်း) ဆိုတာ ဒါမိုကလီးရဲ့ ဓားလိုပါပဲ။ လက်တစ်ဖက်မှာ ကိုင်ထားမယ်ဆိုရင် ယုံကြည်မှုနဲ့ ဂုဏ်သိက္ခာကို ကိုယ်စားပြုပြီး တစ်ဖက်မှာ ကိုင်ထားရင်တော့ တာဝန်ယူမှုနဲ့ တာဝန်ခံမှုကို ကိုယ်စားပြုပါတယ်။ ပညာရှင်ဆန်ဆန် အလုပ်လုပ်မယ့်သူအနေနဲ့ ဒါမိုကလီးရဲ့ ဓားကို ဟိုဖက်လက်၊ ဒီဖက်လက် ပြောင်းကိုင်ပြီး အလုပ်လုပ်ရလေ့ရှိပါတယ်။ တာဝန်ယူ တာဝန်မခံပဲ ယုံကြည်မှု ရလာမှာ မဟုတ်သလို ဂုဏ်သိက္ခာဆိုတာလဲ ရှိလာမှာမဟုတ်ပါဘူး။ 

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

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

တကယ်တော့ Professionalism (ပညာရှင်ဆန်ဆန်အလုပ်လုပ်ခြင်း)မှာ တာဝန်ခံတတ်ခြင်းက အဓိကကျပါတယ်။ Developer တစ်ယောက်အနေနဲ့ အချိန်တိုင်းမှန်မနေနိုင်ပါဘူး။ ဒါပေမယ့် ကိုယ့်ကြောင့်ဖြစ်လာတဲ့ အမှားတွေကိုလဲ ခေါင်းရှောင်လေ့မရှိပါဘူး။

(၂) တူညီတဲ့အမှားကို နောက်တစ်ကြိမ် ထပ်မမှားခြင်း

အမစ် ကလန်သရီက ပြောဖူးပါတယ်။

တောင်းပန်မှုတစ်ခုရဲ့နောက်မှာ ဆင်ခြေရယ် ဆင်လက်ရယ် ပါလာပြီဆိုတဲ့ အဓိပ္ပါယ်ဟာ သူတို့အနေနဲ့ နောက်တစ်ကြိမ် တူညီတဲ့ အမှားကိုထပ်မှားဦးမယ်။ အဲဒီအတွက်ပဲ ထပ်ပြီး တောင်းပန်ရဦးမယ်လို့ ဆိုလိုပါတယ်။

သေချာပါတယ်။ ကျွန်တော်တို့ အားလုံး ကျွန်တော်တို့ ရေးလိုက်တဲ့ Software တွေကို ကောင်းကောင်း အလုပ်လုပ် စေချင်ကြပါတယ်။ ကိုယ်ရေးလိုက်တာလေး တစ်ခု မှန်မှန်ကန်ကန် အောင်အောင်မြင်မြင်နဲ့ အလုပ်လုပ်သွားတဲ့အချိန် ခံစားရတဲ့ ပီတိကို လူတိုင်းခံစားလိုပါတယ်။ ဒါပေမယ့် အဲဒီလို Software ကို မှန်မှန်ကန်ကန် ဖြစ်စေချင်တယ်ဆိုတာ ကိုယ်တစ်ယောက်တည်း မဟုတ်ပါဘူး။ ကျွန်တော်တို့ရဲ့ Customer တွေနဲ့ သုံးမယ့် ဝန်ထမ်းတွေလဲ ဖြစ်စေချင်နေကြပါတယ်။ ရှင်းပါတယ်၊ အဲဒါကြောင့်လဲ ပိုက်ဆံတွေ အကုန်ခံပြီး ခင်ဗျားတို့ဆီ အပ်ထားတာပေါ့။

ဒါပေမယ့် Software တိုင်းဟာ Perfect မဖြစ်ပါဘူး။ Software တွေတိုင်း ကြိုတင်မခန့်မှန်းနိုင်တဲ့ အမှားအယွင်းတွေ ရှိနေပါတယ်။

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

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

(၃) ကံကိုယုံပြီး ဆူးပုံမနင်းပါနဲ့

ကျွန်တော်တို့ နည်းပညာနယ်မှာ Garbage in, Garbage out ဆိုတာ ရှိပါတယ်။ အမှိုက်ထည့်ရင် အမှိုက်ပဲ ပြန်ထွက်မှာပါ။ ကံကိုယုံပြီး ဆူးပုံနင်းရင် သေချာပေါက် ဆူးဆူးမှာပါပဲ။ Developer တွေမှာ ကံကောင်းတယ်ဆိုတာ မရှိပါဘူး။ သူ့အလိုလို ဖြစ်လာတယ်ဆိုတာလဲ မရှိပါဘူး။

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

ဒါပေမယ့် အဲဒီလို အပြန်ပြန်အလှန်လှ စစ်ဖို့အတွက်ဆိုတာ အချိန်လိုပါတယ်။ နောက်ကနေ မီးပူထိုးနေတဲ့ အလုပ်တွေဆိုရင် အကြိမ်ကြိမ် ပြန်စစ်ဖို့ အခက်အခဲ ရှိနိုင်ပါတယ်။ အဲဒီအတွက် Automatic Testing တွေ သုံးဖို့လိုပါတယ်။ Test Driven Development (TDD)တွေ သုံးဖို့လိုပါတယ်။ အဲဒါတွေက အစပိုင်းမှာ လုပ်ရတာ အလုပ်ပိုတယ် ဆိုပေမယ့် ရေရှည်မှာတော့ အလုပ်ကို အများကြီး အထောက်အပံ့ပေးပါတယ်။ 

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

တကယ့် ဂျွတ်တဲ့ Developer တွေဆိုတာ ဘယ်လို ရေးမလဲဆိုတာကိုလဲ သိသလို ဘယ်လို စစ်မလဲဆိုတာကို ပိုသိနေတဲ့သူတွေ ဖြစ်ပါတယ်။

စစ်ဆေးရလွယ်ကူအောင် ရေးနိုင်ခြင်းဆိုတာ ကုဒ်ရေးတဲ့သူတွေအတွက် စိန်ခေါ်မှု တစ်ခုဖြစ်ပါတယ်။ Developer တစ်ယောက်ဟာ ပြန်စစ်ရင် ဘယ်လို စစ်ရမှန်းတော့ မသိဘူး၊ ဒါပေမယ့် အလုပ်ဖြစ်အောင် ရေးတတ်တယ်။ နောက်တစ်ယောက်ကတော့ အစိတ်အပိုင်းတိုင်း အစိတ်အပိုင်းတိုင်းကို စစ်လို့ရအောင် ရေးပြီး အလုပ်ဖြစ်တဲ့ကုဒ်တွေ ရေးနိုင်တယ်ဆိုပါစို့။ ဒီနှစ်ယောက်ရဲ့ အရည်အချင်းဟာ အင်မတန်ကွာခြားတတ်ပါတယ်။ Testable Code တွေ ဖြစ်စေဖို့ Design Pattern တွေအထိ သိထားဖို့ လိုအပ်ပါတယ်။ အဲဒီအပြင် အလုပ်အတွေ့အကြုံ ဘယ်လောက်ရှိလဲအပေါ် မူတည်နေပါတယ်။ 

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

အလုပ်ဖြစ်အောင်လဲ လုပ်နိုင်ရမယ်။ စစ်ဆေးရအလွယ်ဆုံးဖြစ်အောင်လဲ ရေးနိုင်တယ်ဆိုရင်တော့ Developer တစ်ယောက်အတွက် အတိုင်းထက်အလွန်ပါပဲ။

(၄) ပြောင်းလွယ်ပြင်လွယ်ရှိတဲ့ ကုဒ်တွေ ဖန်တီးလေ့ရှိခြင်း

ဆီရီဟုစဘက်က ပြောဖူးပါတယ်။

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

ကျွန်တော်တို့ ကုဒ်ရေးတဲ့အခါ Framework တွေကို သုံးကြပါတယ်။ အဲဒီ Framework တွေဆိုတာ ပြောင်းလွယ်ပြင်လွယ်ရှိခြင်းနဲ့ လွတ်လပ်ခြင်းတွေအပေါ် အခြေခံရပါတယ်။ Laravel နဲ့ POS တန်းသုံးလို့မရပါဘူး။ ဒါပေမယ့် Laravel နဲ့ POS ရေးလို့ရပါတယ်။ အဲဒီလိုပဲ HR Software လဲ ရေးလို့ရပါတယ်။ တစ်ခြား အဆုံးမရှိတဲ့ Application တွေ ဖန်တီးလို့ရပါတယ်။ 

အဲဒီလိုပါပဲ ကျွန်တော်တို့ ကုဒ်တွေရေးတဲ့အခါ ဘယ်ဟာကတော့ဖြင့် ဒီ Application အတွက်ပဲ၊ ဘယ်ဟာကတော့ဖြင့် နောက်ပြန်သုံးလို့ရတယ်ဆိုတာမျိုးတွေ စဉ်းစားပြီး ဖန်တီးဖို့ လိုပါတယ်။ အဲဒီလို ပြန်သုံးလို့ရတဲ့ အစိတ်အပိုင်းတွေဟာ လွတ်လပ်ခြင်းနဲ့ ပြောင်းလွယ်ပြင်လွယ်ရှိခြင်းကို ကိုယ်စားပြုပါတယ်။ 

ကျွန်တော်တို့ Developer တွေအနေနဲ့ ပထမ Project မှာ ကုဒ်ရေးတာ တစ်နှစ်ကြာရင် နောက် Project မှာ ခြောက်လ၊ နောက် Project မှာ သုံးလ၊ နောက် Project မှာ တစ်လလောက်နဲ့ ပြီးဖို့ လိုပါတယ်။ အဲဒီလို ဖြစ်ဖို့ဆိုရင် ကိုယ်ရေးတဲ့ ကုဒ်တွေကို လွတ်လပ်အောင်၊ ပြောင်းလွယ်ပြင်လွယ်အောင် စဉ်းစားရေးသားမှသာ ဖြစ်နိုင်ပါတယ်။ 

ကိုယ်ရေးလိုက်တဲ့ ကုဒ်တွေကို အလုပ်ဖြစ်သွားတာ၊ ပြန်စစ်လို့ ရတာလောက်နဲ့ ရပ်မထားပါနဲ့။ ကောင်းသထက်ကောင်းအောင် ပြန်ပြင်ပါ။ ပြောင်းလွယ်ပြင်လွယ် ဖြစ်အောင် ဖန်တီးပါ။ ဒါဆိုရင် တစ်ပေါက်တည်း ရတဲ့ Developer မျိုး မဟုတ်တော့ပဲ ဘာလာလာဒေါင်းနိုင်တဲ့ Developer ဖြစ်လာမှာ ဖြစ်ပါတယ်။

(၅) အမြဲတမ်း သင်ယူပါ

ကျွန်တော်တို့ Developer တွေအတွက် နည်းပညာတွေဆိုတာ အချိန်နဲ့အမျှ ပြောင်းလဲနေပါတယ်။ Developer ဟာ သင်ယူဖို့ ဝန်မလေးသူ ဖြစ်ဖို့ လိုပါတယ်။ အဆက်မပြတ် သင်ယူလိုသူ ဖြစ်ဖို့ လိုပါတယ်။ သင်ယူတာကို ရပ်လိုက်တာနဲ့ ခေတ်ပေါ် နည်းပညာတွေနဲ့ အဆက်ပြတ်သွားပြီး ကိုယ်ရေးတာတွေဟာ ကြာလေ ဒိတ်အောက်လေ ဖြစ်သွားပါလိမ့်မယ်။ 

ကျွန်တော်တို့ Developer တွေဟာ Self-education (ဘယ်သူမှ မတိုက်တွန်းရပဲ ကိုယ်တိုင် သင်ယူခြင်း) အလေ့အကျင့်နဲ့ တစ်သားတည်း ကျနေဖို့ လိုပါတယ်။ အဲဒီအတွက် မောင်းနှင်အားလိုပါတယ်။ အဲဒီမောင်းနှင်အားကို မဖြစ်မနေ လေ့ကျင့်ပေးဖို့ လိုပါတယ်။

Developer တွေအနေနဲ့ အစပိုင်းမှာ ရှေ့ကလူတွေဆီက ပုံတူကူးချပြီး မှီခိုတတ်ပါတယ်။ အဲဒီလို မှီခိုလိုက်မယ်ဆိုတာနဲ့ သူမရှိတာနဲ့ တိုင်ပတ်ပါလိမ့်မယ်။ Developer တွေအနေနဲ့ အစပိုင်းမှာ မှီခိုတာ ပြဿနာ မဟုတ်ပေမယ့် ကြာလာတာနဲ့အမျှ Independent (အမှီအခိုကင်းမဲ့မှု) ဖြစ်လာဖို့ လိုပါတယ်။ အဲဒါမှသာ Interdependent (အပြန်အလှန် ပူးပေါင်းဆောင်ရွက်နိုင်စွမ်) ဆိုတာ ရလာမှာ ဖြစ်ပါတယ်။ အဲဒီလို အဆင့်ဆင့် တိုးတက်သွားဖို့ အဓိက အကျဆုံး အလေ့အကျင့်ကတော့ အဆက်မပြတ် ကိုယ်တိုင် လေ့လာသင်ယူနေခြင်းပါပဲ။

နောက် Developer ပေါက်စတွေ အနေနဲ့ ဖြစ်လေ့ဖြစ်ထ ရှိတာတစ်ခုက သူတို့ကို ဘယ်သူမှ သင်မပေးဘူးဆိုပြီး ပြောကြတာပါ။ လက်တွေ့လုပ်ငန်းခွင်ဆိုတာ အပြန်အလှန်သင်ပေးဖို့ အချိန်မရတဲ့နေရာ ဖြစ်ပါတယ်။ Project Deadline တွေနဲ့ လုပ်ကြရတဲ့အတွက် ပြန်သင်ပေးဖို့ဆိုတာ မလွယ်ပါဘူး။ ဖြစ်သင့်တာက Self-education အင်ဂျင်ကို နဂိုကတည်းက လည်လာအောင် လုပ်ပြီးမှ လုပ်ငန်းခွင် ဝင်သင့်ပါတယ်။ အစအဆုံး မြင်ရမှာ ကူးရမှ သိတာမျိုး မဖြစ်သင့်ပဲ အရိပ်ပြ အကောင်မြင်နိုင်စွမ်း ရှိတဲ့အထိ ကြိုတင် လေ့ကျင့်ထားသင့်ပါတယ်။ အဲဒီလို လေ့ကျင့်ပြီးမှသာ လုပ်ငန်းခွင် ဝင်သင့်ပါတယ်။

ကိုယ့်ဘဝ တိုးတက်မှုဟာ ကိုယ်နဲ့သာ ဆိုင်ပါတယ်။ ဟိုသင်တန်း တက်ချင်တာ စပွန်ဆာ မပေးလို့၊ ဟိုပွဲ တက်ချင်တာ တနင်္ဂနွေနေ့ကြီး ဖြစ်နေလို့၊ အလုပ်မှာ ဘာစာအုပ်မှ မရှိလို့ စသည်ဖြင့် ငြီးတွားနေမယ်ဆိုရင် အလုပ်ဖြစ်မှာ မဟုတ်ပါဘူး။ 

နာရီလေးဆယ်ကို အလုပ်အတွက် အချိန်ပေးပြီးတိုင်း နာရီ ၂၀ ကို သင်ယူဖို့အတွက် အချိန်ပေးပါလို့ အဆိုရှိပါတယ်။ နွားခြေရာခွက်လေးထဲမှာ နေပြီး ပျော်နေမယ်ဆိုရင်တော့ ကြာလာတာနဲ့အမျှ သင်ယူလိုစိတ်တွေလဲ ပျောက်လာပါလိမ့်မယ်။

Ravi Shankar Rajan ရေးသားသော 5 Powerful Habits of Successful Developers ကို မှီငြမ်း ရေးသားခြင်း ဖြစ်ပါသည်။