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

ဦးစွာပထမ ဘာတွေလုပ်သင့်လဲ ဆိုတာကို ပြောပြပေးပါမယ်နော်။

(၁) Study Code & Practice
Developer တစ်ယောက်ဆိုရင် Code ဆိုတဲ့စကားလုံးနဲ့ မစိမ်းပါဘူးနော်။ အသုံးပြုတဲ့ Language အလိုက်ပုံစံလေးတွေပဲ ကွဲပြားခြားနားပါတယ်။ သီအိုရီ သဘောတရားချင်းတွေက တူညီကြပါတယ်။ Code တွေကို များများလေ့လာဖို့လိုပါတယ်။ အခြေခံ စလေ့လာခါစမှာတော့ ဒီ Code က ဘာအတွက်၊ ဒါကတော့ ဟိုဟာအတွက်ဆိုပြီး လေ့လာမှတ်သားရပါတယ်။ နောက်ပြီး လေ့ကျင့်ရပါတယ်။ လေ့ကျင့်ပါများလာတော့ ပိုမိုနားလည်လာပြီး အတွေ့အကြုံတွေပါ ရလာမှာဖြစ်ပါတယ်။ အခုခေတ်မှာဆိုရင် တော်တော်လေး ကံကောင်းပါတယ်။ တကယ်လို့ ကိုယ်ရေးလိုက်တဲ့ Code က မှားနေတယ်ဆိုရင် Google ပေါ်တက်ပြီး အမှန်ကို ရှာဖွေ လေ့လာနိုင်ပါတယ်။

(၂) Documentation
မိမိတို့အလုပ်မှာဆိုရင်လည်း Documentation တွေရေးဖို့ လိုအပ်ပါတယ်။ ဘာလို့ဆို အဓိကတော့ မှတ်တမ်းပေါ့နော်။ မိမိက အဲ့ဒီအလုပ်တွေကို မှတ်တမ်းသာ မထားဘူးဆိုရင် နောက်ထပ် တစ်ယောက်ကို လွှဲပြောင်းပေးတဲ့အခါ အခက်အခဲတွေ့စေနိုင်ပါတယ်။ တိတိကျကျ အချက်အလက်တွေကို မလုပ်ထားဘူးဆိုရင် Project တွေမှာ မတိကျ၊ မရေရာသော လုပ်ဆောင်ချက်တွေနဲ့ ဖြစ်လာလိမ့်မယ်။ မှတ်တမ်းသာ ရှိနေမယ်ဆိုရင် Project ပြန်လည်ပြင်ဆင်တဲ့အပိုင်းမှာလည်း မြန်ဆန်ပါလိမ့်မယ်။ Client တွေကို Project နဲ့ ပတ်သက်ပြီး ပြောဆိုရာမှာလည်း လွယ်ကူရှင်းလင်းစွာ ပြောဆိုနိုင်ပါလိမ့်မယ်။

(၃) Start Standard Code
Code တွေကို စတင်လေ့လာတဲ့အခါမှာ ဘယ်လိုရေးရမလဲ၊ ဘာအတွက်သုံးတာလဲ စသဖြင့် အရင်လေ့လာကြပါတယ်။ ရေးပုံရေးနည်းတွေကိုလည်း လေ့လာမှတ်သားရပါတယ်။ တဖြည်းဖြည်း လေ့လာရင်းနဲ့ တခြားလူတွေရဲ့ Idea တွေနဲ့ ရေးထားတဲ့ Code အသစ်အဆန်းများကိုလည်း တွေ့လာရပါတယ်။ သူတို့ စဉ်းစားပုံ၊ စဉ်းစားနည်းတွေကိုလည်း တွေ့မြင်ရပါတယ်။ မိမိကိုယ်တိုင်လည်း Code ရေးသောအခါ ပြီးစလွယ်မရေးဘဲ စနစ်တကျ ရေးသင့်ပါတယ်။ မိမိက Code ကို Standard ကျကျ ရေးထားရင် မိမိကိုယ်တိုင် ပြန်လည်သုံးသပ်မယ်ဆိုရင်လည်း စိတ်ကျေနပ်စရာ ရမှာအမှန်ပဲ ဖြစ်ပါတယ်။ တခြားသူက ကိုယ့် Code ကို လေ့လာသောအခါ သေသေချာချာ ရှင်းရှင်းလင်းလင်းနဲ့ လေ့လာလို့လည်းရသလို၊ နားလည်ရလွယ်ကူမှာလည်း ဖြစ်ပါတယ်။ Comment တွေ ရေးသင့်တဲ့နေရာမှာ ရေးထားတော့ တခြားသူက ကိုယ့် Code ကို ပြန်ပြင်ဆင်မယ်ဆိုရင် အချိန်တွေမြန်ဆန်လာမှာ ဖြစ်ပါတယ်။

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

(၄) Review Code
Project တစ်ခုကို ရေးနေပြီဆိုရင် ကျွန်မအပါအဝင် လူတော်တော်များများဟာ အဲ့ဒီ Project ရဲ့ Output ကိုပဲ အရင်မြင်ချင်ကြတယ်။ အာရုံထဲမှာ ပြီးဖို့ပဲ အရေးကြီးနေတယ်။ မိမိတို့ရဲ့ Code ကို ပြန်လည်သုံးသပ်ခြင်းက နည်းကြပါတယ်။ Output ကိုမြင်ပြီဆိုရင် Project တစ်ခုပြီးပြီပေါ့။ နောက်ဆက်လက်လုပ်ဆောင်ရမယ့် အဖွဲ့ဝင်တွေဆီကို လွှဲပြောင်းပေးလိုက်ကြတယ်။ အဲ့တော့ ကိုယ့် Code တွေက ရှုပ်ပွနေတာလည်း ဖြစ်နိုင်သလို၊ မလိုလားအပ်တဲ့ Code တွေလည်း ပါနေနိုင်တာပေါ့။ Code တွေကလည်း ကျစ်လစ်မှုမရှိပဲ ဖြစ်နေမှာပေါ့။ Code ၁၀ ကြောင်းလောက်ပဲ ရေးရင်ရတာကို စာပိုဒ်တစ်ပိုဒ်လောက် ဖြစ်နေလိမ့်မယ်။ အဲ့လိုမျိုးတွေမဖြစ်ရအောင် မိမိရေးလိုက်သော Code ကိုပြန်ပြီး Review လုပ်ဖို့ လိုအပ်ပါတယ်။ ကိုယ့် Code ကို ဘယ်လိုချုံ့လို့ရမလဲ၊ Function တွေကို ဘယ်လိုအချိန်မျိုးမှာ သုံးသင့်လဲ၊ Common ရေးမလား စသဖြင့် သေချာပြန်သုံးသပ်သင့်ပါတယ်။ ကျွန်မဆိုရင် အရင်က Code Review လုပ်ဖို့ အလေ့အကျင့်မရှိပါဘူး။ သတိလည်းမထားမိဘူး။ အခုဆိုရင် ကိုယ့် Project ပြီးရင်တောင် Output ထွက်သွားပြီဆို ဘယ်လိုမျိုး ချုံ့လို့ရနိုင်မလဲ စဉ်းစားကြည့်တဲ့ အကျင့်လေးဖြစ်လာတယ်။ တခြားလူတွေလည်း Code လေးတွေကို Review လုပ်ဖို့ တိုက်တွန်းအကြံပြုချင်ပါတယ်။

(၅) Testing
Project တစ်ခုပြီးသွားပြီဆိုရင် အရမ်းအရေးကြီးတဲ့ အစိတ်အပိုင်းတစ်ခုက Testing ပဲဖြစ်ပါတယ်။ Testing အတွက်ဆို အချိန်သိပ်မယူ၊ မပေးဖြစ်ကြဘူး။ အမှန်တော့ သူ့အတွက် အချိန်တွေယူသင့်တယ်၊ အချိန်တွေ ပေးသင့်ပါတယ်။ Project တစ်ခုက Testing သေချာစစ်မှ အသုံးပြုသူ လက်ထဲသို့ စိတ်ချစွာ ထည့်ပေးလိုက်နိုင်မှာ ဖြစ်ပါတယ်။ Testing သေချာမလုပ်တဲ့ Project ဟာဆိုရင် အသုံးပြုသူတွေအတွက် အမှားတွေနဲ့ သက်တောင့်သက်သာ မရှိတဲ့အရာကြီးဖြစ်နေလိမ့်မယ်။ အလုပ်အတွက် အချိန်တွေလည်း မမြန်ဆန်တော့ပဲ ပိုမိုကြန့်ကြာကုန်လိမ့်မယ်။ ငွေကြေးပိုင်းဆိုင်ရာနှင့် ကိုယ်ပိုင်အချက်အလက်ပိုင်းဆိုင်ရာ Project တွေဆို စဉ်းစားကြည့်ပါလား။ စိုးရိမ်စရာကြီးနော်။ အချိန်မပေးပဲ Testing လုပ်တဲ့အခါ Error တွေကို တွေ့လာရလိမ့်မယ်။ အဲ့ဒီ Error ကိုရှင်းနေတုန်းမှာပဲ နောက်ထပ် Error တွေ ထပ်တွေ့တယ်။ Project ကလည်း ညနေပေးရတော့မယ်…အချိန်တွေကမမီတော့ဘူး။ Schedule တွေနောက်ကျမယ်။ Client တွေဆီကို စကားတွေ ပြောရတော့မယ်။ Client တွေက ကိုယ့်ကို ယုံကြည်မှု အားနည်းလာတယ်။ နောက်ထပ် Project လာဖို့ ဆိုတာ သူတို့အတွက် သိပ်မလွယ်လှတော့ဘူး။ အဲ့လိုမဖြစ်ရအောင် Project တစ်ခု လုပ်တော့မယ်ဆို Schedule ယူတဲ့နေရာမှာ Testing အတွက်ပါ သေချာထည့်တွက် စဉ်းစားသင့်ပါတယ်။

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

(၁) Copy & Paste
Copy/ Paste စကားလုံးက IT နယ်ပယ်ကသူတွေအတွက်ကော တခြားနယ်ပယ်ကလူတွေအတွက်ကော မစိမ်းလောက်ဖူးလို့တော့ ထင်ပါတယ်။ Copy/ Paste လုပ်တဲ့အခါမှာလည်း သေချာလုပ်ဖို့ လိုပါတယ်။ ကိုယ်က အွန်လိုင်းကနေ Code တွေရှာတဲ့အခါမှာလည်း သေချာနားလည်တဲ့အခါမှ Copy လုပ်သင့်ပါတယ်။ နားမလည်တဲ့အခါ Modify လုပ်ဖို့ ခက်ခဲပါလိမ့်မယ်။ နောက်တစ်ခုအနေနဲ့ကတော့ Project တစ်ခုကနေ တခြား Project ကို Code တွေ Copy လုပ်တဲ့အခါမှာလည်း အသုံးပြုတဲ့ Variable နာမည်တွေကို ဂရုစိုက်ပါ။ Project တစ်ခုမှာက နာမည်တစ်ခုသုံးပေမယ့် တခြား Project မှာတော့ သူနဲ့သက်ဆိုင်တဲ့ နာမည်ကိုသာ သုံးသင့်ပါတယ်။

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

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

(၄) Break Time/ Relax
ထိုခေါင်းစဉ်ကလည်း အထက်က ဖော်ပြခဲ့တဲ့ Health နဲ့လည်း သက်ဆိုင်ပါတယ်။ မိမိတို့ဟာ အလုပ်တွေ ဘယ်လောက်ပဲ များနေပါစေ အနားယူရမယ့်အချိန်မှာ အနားယူသင့်ပါတယ်။ အဲ့ဒီနေရာမှာ Self-management နဲ့ဆိုင်တယ်ပေါ့နော်။ အရင်က အလုပ်မှာ ၁နာရီနားတယ်ပေါ့။ အလုပ်များနေလို့ မနားတော့ဘူးဆိုတာ မဖြစ်သင့်ပါဘူး။ အလွန်ဆုံး ၁၀ မိနစ်လောက်တော့ မဖြစ်မနေ အနားယူသင့်တယ်လို့ ကျွန်မအနေနဲ့ ထင်မြင်မိပါတယ်။ အလုပ်တွေကို လုပ်နေရလို့ ပင်ပန်းပြီး ခေါင်းရှုပ်နေပြီ။ ထိုအချိန် အလုပ်ကမပြီးသေးလို့ ဆက်လုပ်နေရင်လည်း စဉ်းစားလို့မရတော့လို့ Idea မထွက်လာတဲ့အချိန်တွေလည်း ရှိမှာပဲလေ။ အဲ့လိုအချိန်မျိုးဆို ခဏနားပြီး ဦးနှောက်ကို အနားပေးပြီးမှ ဆက်လုပ်ရင် ပိုမိုကောင်းမယ်လို့ ထင်ပါတယ်။

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

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

(၇) Humble
မိမိကိုယ်ကို မိမိ နှိမ့်ချတတ်ပါစေ။ တချို့လူတွေက သူတို့တော်နေပြီဆိုရင် ပညာမာန်တက် ဂုဏ်မောက်ကြပါတယ်။ တခြားလူတွေက သူတို့လောက်မတော်ဘူးဆိုတဲ့ အတွေးအမြင်တွေ ဖြစ်လာကုန်ကြတယ်။ ထိုအမြင်တွေက အလုပ်တွေမှာ အရမ်းထိခိုက်ကြပါတယ်။ အဖွဲ့အစည်းနဲ့အလုပ်လုပ်ရတယ်ဆို Teamwork အားမကောင်းတော့ပါဘူး။ အလုပ်က အမှန်တကယ် ပြီးသင့်သလောက်မပြီး ဖြစ်လာတတ်ပါတယ်။ ကျွန်မကတော့ အဖွဲ့အစည်းရဲ့လုပ်အားဟာ တစ်ဦးတစ်ယောက်လုပ်အားထက် ပိုတော်ပြီး၊ Strong ဖြစ်ပါတယ်လို့ ထင်မြင်မိပါတယ်။

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

အထူးသတိပြုရမယ့် အချက်လေးတစ်ခုအနေနဲ့ကတော့ မိမိတို့ဟာ Code ရေးနေတဲ့လူအချင်းချင်း တစ်ဦးကိုတစ်ဦး မနှောင့်ယှက်မိစေအောင် သတိပြုပေးပါနော်။

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