My FAQ List

Code ကောင်းကောင်းရေးချင်တာ ဒါပေမယ့် အလုပ်က အချိန်အဲ့လောက်မပေးဘူး

ကျွန်တော့်အမြင်တော့ shit code တွေရေးထားလည်း billion dollar app ထုတ်လို့ရပါတယ် SWE တစ်ယောက်အနေနဲ့ နှာခေါင်းရှုံ့စရာဖြစ်ပေမယ့် business perspective အရ product မြန်မြန်ထုတ်ပြီး မြန်မြန်ထိုးဖောက် ငွေမြန်မြန်ဝင်ချင်တာ သဘာဝပါဘဲ code ဘယ်လောက်ကောင်းအောင်ရေးထားထား enduser က ချက်ချင်းသတိပြုမိလောက်တဲ့ကိစ္စမဟုတ်တဲ့အတွက် no one cares ပါ။ ဒါက code တွေစုတ်ပြတ်နေအောင် ရေးရမယ်လို့ဆိုတာမဟုတ်ဘဲ code တွေရှုပ်ပွနေတာ code smell ဖြစ်နေတာကို business management ဘက်က ပြသနာလို့မမြင်ဘူးလို့ ပြောချင်တာပါ

အဲ့တော့ အလုပ်က အချိန်မပေးဘူးဆိုတဲ့နေရာမှာ နှစ်မျိုးဖြစ်နိုင်တယ် ကိုယ်ကိုတိုင်ရဲ့ ကျွမ်းကျင်မှုလိုအပ်ချက်အရ development time ပိုလိုတာ ဒါမှမဟုတ် upper level management က အချိန်နည်းနည်းပဲပေးပြီး အတင်းတွန်းထိုးလုပ်ခိုင်းတာ ပထမတစ်မျိုးကတော့ ကိုယ်နဲ့ဆိုင်တာဖြစ်တဲ့အတွက် code snippet တွေထုတ်ထားမလား တစ်ခုခု stuck ဖြစ်သွားရင် ဘယ်သူ့ဆီက အကူအညီတောင်းလို့ရမလဲ စသဖြင့် ကိုယ့်ဘာသာပြုပြင်ယူရတယ် ဒုတိယတစ်မျိုးဆိုရင်တော့ techincal challenges တွေကို uppler level management သိအောင် ပြောဖို့လိုတယ် client ဆိုတာ နည်းပညာမသိလို့ ကိုယ့်ကို ပိုက်ဆံပုံပေးပြီး development လုပ်ခိုင်းတဲ့သူဖြစ်တယ် ဘယ် client မဆို မြန်မြန်ပြီးချင်ကြတာချည်းပဲ ဒါပေမယ့် engineer တစ်ယောက်အနေနဲ့ ကိုယ့်ရဲ့ tecnhical perspective အရ မသင့်တော်ဘူးလို့ထင်ရင် best optimal advise ကို ပေးရမှာသည် ကိုယ့်တာဝန်ပါ။ အဲ့လို အကြံပေးဖို့လည်း ပိုက်ဆံပေးထားတာဖြစ်တယ်။ ဒီနေရာမှာ best optimal လို့ပြောတာက လမ်းထိပ်ကကြက်ကြော်ဆိုင်ကို KFC scale လောက်ရှိတဲ့ advise ပေးလို့မရဘူး သူ့အိုးနဲ့သူဆန် တန်တာကိုပဲ ပေးရမယ် ရသမျှအကုန်ရိတ်မယ်လုပ်လို့မရဘူး အဲ့လို ကိုယ့်ဘက်က ဒီလိုကတော့ အချိန်ကနည်းလွန်းတယ် ဘယ်အပိုင်းတွေမှာ လိုသွားနိုင်တယ် ဘယ်လိုလုပ်ရင်တော့ နှစ်ဉီးနှစ်ဖက်ပြေလည်နိုင်မယ် စတဲ့ solution ကို ကိုယ့်ကုမ္ပဏီကဖြစ်စေ တစ်ဖက် client ကဖြစ်စေ လက်မခံဘူးဆိုရင်တော့ so be it ပါပဲ မခံစားပါနဲ့ engineer တွေက ကိုယ့် expertise အရ best optimal solution ကိုသာ propose လို့ရပြီး policy making လုပ်တာက management level ကလုပ်တာပါ အဲ့တာရဲ့ consequences ကလည်း သူတို့ပဲခံရတာပါ ခုနကပြောသလို code တွေရှုပ်နေလည်း တစ်ခြား factor တွေအရ အဆင်ပြေနေရင် justify လုပ်လို့ရပါတယ် အရာရာကို engineering အမြင်တစ်ခုတည်းကနေ ကြည့်ပြီးခံစားလို့မရဘူးလို့ပြောတာပါ

မကြာခဏ deadline တွေမမီဘူး ညမအိပ်ဘဲကျုံးနေရတယ်ဒါ

ဆိုရင်တော့ ကိုယ့် team က ဘယ်လို model နဲ့သွားနေသလဲဆိုတာ ပြန်သုံးသပ်ဖို့လိုမယ် waterfall လား scrum လား kanban လား lean model လား scrum, kanban lean စတာတွေက agile ကနေဆင်းသက်လာတာဖြစ်တဲ့အတွက် agile ရဲ့ value တွေရှိပြီးသားဖြစ်တယ် agile ဆိုရင်တော့ ခုနက အချိန်ပေးတာနည်းတယ်ဆိုတဲ့ပြသနာက ကိုယ့်ဘက်ကပြသနာရှိနေတာဖြစ်ဖို့ သေချာသလောက်ရှိတယ် agile မှာ feature တစ်ခုရဲ့ manday ကိုသတ်မှတ်တာသည် engineer က သတ်မှတ်ရတာဖြစ်တယ် product backlog ကနေ feature တွေကိုယူပြီး sprint စခွဲတဲ့ sprint planning အဆင့်မှာတည်းက ဘယ် feature ကို ဘယ်သူယူမယ် ဘယ်လောက်ကြာမယ်ဆိုတာ သတ်မှတ်ရတာဖြစ်တယ် ကိုယ် promise လုပ်ထားတဲ့ target date ကို deliver မလုပ်နိုင်တာကတော့ ဘာကြောင့်ညာကြောင့်ဆိုတာထက် ကိုယ့်ဘက်ကပြသနာဖြစ်နေတာ ဖြစ်ဖို့များတယ် အဲ့တော့ ကိုယ်ပြီးဖို့သေချာတဲ့အချိန်ကို ပြောဖို့လိုတယ် ဘာကြောင့်အဲ့လောက်ကြာတယ်ဆိုတာကိုလည်း ခိုင်ခိုင်လုံလုံရှင်းပြနိုင်ရမယ် အဲ့တာအပေါ်မူတည်ပြီး ဒီ task ကို ကိုယ်ယူသင့် မယူသင့်က team က ဆုံးဖြတ်သွားမှာဖြစ်တယ် တစ်ကယ်လို့ traditional way နဲ့သွားတယ်ဆိုရင်တော့ အပေါ်ကပြောသလို management ကလူတွေနဲ့ ပွင့်ပွင့်လင်းလင်းဆွေးနွေးဖို့လိုမယ် timeline ကိုဝင်အောင် ဘာလုပ်လို့ရမလဲ resource ထပ်ထည့်ရင် ပိုမြန်မလား ဒါက သူတို့ကို ပွင့်ပွင့်လင်းလင်းထိတွေ့ဆက်ဆံဖို့လိုကိုလိုလိမ့်မယ် တစ်ခါတလေ task တစ်ခုနဲ့ တစ်ခုက တစ်ခုပြီးမှ နောက်တစ်ခုလုပ်လို့ရမယ်ဆိုပြီး ဖြစ်နေတာမျိုးရှိတယ် ဒီလိုဆိုရင်တော့ parallel ရောသွားလို့ရမလား မရဘူးဆိုရင်တော့ resource ထပ်ထည့်လည်း အကျိုးမထူးဘူး အချိန်တိုးရင်တိုး မတိုးရင် action item တစ်ချို့ကိုလျှော့ပစ်မှပဲ ရလိမ့်မယ် အဲ့တာတွေအကုန်လုံးကို အပြုသဘောဆောင်ပြီး ဆွေးနွေးလို့မရဘူး အကုန်ဟင့်အင်းဘဲဆိုရင်တော့ မစဉ်းစားနဲ့ အဲ့ကုမ္ပဏီက လစ်သာလစ်လိုက်တော့ ညဘက်တွေပါ ကျုံးရတယ်ဆိုတာ healthy ဖြစ်တဲ့ work culture တော့မဟုတ်ဘူး

ရုံးက တစ်ခြား language တွေလုပ်ခိုင်းတယ် အဲ့လို language တွေအများကြီးလုပ်သင့်လား

ဒါကတော့ ကိုယ်ဘယ်လို position မျိုးနဲ့ဝင်တာလည်းဆိုတာအပေါ် မူတည်မယ် ဉပမာ ကိုယ်က android developer အနေနဲ့ဝင်တာကို web လုပ်ခိုင်းတယ်ဆိုရင်တော့ ဒါ ရုံးဘက်က မှားတာပဲ တစ်ကယ်လို့ သူတို့အနေနဲ့ အဲ့လိုလုပ်ခိုင်းဖို့အစီအစဉ်ရှိတယ်ဆိုရင်လည်း interview တဲ့အဆင့်မှာတည်းက acknowledge လုပ်ပြီး အဆင်ပြေမပြေ ကြိုမေးထားဖို့လိုမယ် ဒါမှလည်း candidate ဘက်က လစာညှိတဲ့အခါ ပိုစဉ်းစားလို့ရမှာ တစ်ခါတလေကျ ကိုယ်က mobile developer အနေနဲ့ဝင်တယ် team lead, tech lead အနေနဲ့ ဒါမှမဟုတ် associate engineer, principle engineer အနေနဲ့ဝင်တယ် ဒီလိုဆိုရင်တော့ ခုနကလို တစ်ခြား language ဒါမှမဟုတ် တစ်ခြား field of study တွေကို အနည်းနဲ့အများ research လုပ်ရဖို့ ရှိတယ် ဒါက တဖြည်းဖြည်း စီနီယာဖြစ်လာတာနဲ့အမျှ ကိုယ်ကျွမ်းကျင်တဲ့ language တစ်ခုအပြင် တစ်ခြား ကျွမ်းကျွမ်းကျင်ကျင်မဟုတ်ပေမယ့် လုပ်ခိုင်းရင် ဒီလိုဘဲလျှောက်ရှာပြီး လုပ်နိုင်တယ်ဆိုတဲ့ဟာလေးတွေ ရှိလာစမြဲပဲ ဉပမာ ကျွန်တော် iOS ရေးတယ် ဒါပေမယ့် android နည်းနည်းရတယ် android ကို professional ရေးတဲ့သူလောက် ကျွန်တော့် code က ကောင်းချင်မှကောင်းမယ် live data တွေ coroutine တွေ data binding တွေ နောက် retrofit တို့ dagger hilt တို့လို library တွေ သုံးနိုင်ချင်မှသုံးနိုင်မယ် ဒါပေမယ့် ကိုယ်သိသလောက်နဲ့လည်း fully functional ဖြစ်တဲ့ app တစ်ခုထွက်အောင်တော့ လိုက်ရှာဖတ်ပြီး ရေးနိုင်တယ် ဒီလိုမျိုးပေါ့ အဲ့တော့ programming language တစ်ခုခုကိုအဆွဲထားတာကလည်း မကောင်းတဲ့အကျင့်တစ်ခုပဲ ဉပမာ Swift Developer, Kotlin Developer ဒါမျိုးကျ language အပေါ် တအားမီခိုလွန်းသွားတယ် သူများနိုင်ငံမှာ ဘယ်လိုလာလည်းဆိုတော့ Software Engineer (iOS), Software Developer (JS) ဒီလိုသွားတယ် SWE တစ်ယောက်အနေနဲ့ သိသင့်တာအကုန်သိတယ် တစ်ခြား language လည်း လိုအပ်ရင် adapt လုပ်နိုင်တယ် ဒါပေမယ့် သူကျွမ်းကျင်တာကတော့ ဘယ် field ပါပေါ့ အခုမှစလုပ်တဲ့သူတွေကိုတော့ အများကြီးမလုပ်စေချင်ဘူး ဒါပေမယ့် mid-senior, senior ဖြစ်လာပြီဆိုရင် ငါဒီတစ်ခုပဲသိတယ် ဒီတစ်ခုပဲလုပ်မယ် လုပ်လို့မရတော့ဘူး ကိုယ်ကျွမ်းကျင်တာ တစ်ခုရှိမယ် နောက်ကိုယ့် team ကလိုလာရင် တစ်ခြားဟာလည်း ပေါ့ပေါ့ပါးပါး adapt လုပ်နိုင်မယ် လုပ်နိုင်တဲ့ capacity လည်းရှိတယ်ဆိုရင် ပိုကောင်းတယ်

အခုကုမ္ပဏီက ပေးတဲ့လစာတအားနည်းတယ် ကိုယ့်အရည်အချင်းနဲ့ မတန်ဘူးလို့ခံစားရတယ်

ဒါကတော့ ကိုယ်ကိုတိုင်က ဒီလောက်ပဲတန်တာလည်း ဖြစ်နိုင်သလို ကုမ္ပဏီဘက်က တမင်ကျစ်ပြီး မပေးတာလည်း ဖြစ်နိုင်တယ်။ ဒီအတွက် ကျွန်တော်အကြံပေးချင်တာက ရိုးရိုးရှင်းရှင်းလေးပါပဲ။ မတန်ဘူးထင်ရင် တန်ရာတန်ကြေးလို့ ကိုယ်ထင်တာကိုတောင်း မပေးရင် ကိုယ်တောင်းသလောက်ပေးနိုင်တဲ့ကုမ္ပဏီကိုပြောင်း မပြောင်းနိုင်သေးဘူးဆိုရင်တော့ ငြိမ်ငြိမ်လေးနေလိုက် ကိုယ်ကလည်းမပြောင်းနိုင်သေးဘဲနဲ့ ဘုကလန့်တိုက်နေရင်တော့ team formation, solidity ကိုပါ ထိခိုက်လာနိုင်တယ် အဲ့ကျ ကိုယ့်နောက်ကြောင်းရာဇဝင်အတွက်လည်း မကောင်းဘူး ငွေရေးကြေးရေးက အင်မတန်ထိလွယ်ရှလွယ်ဖြစ်တဲ့ကိစ္စဖြစ်တယ် ပေါက်ကရ code တွေရေးတဲ့လူထက် သူရောက်တဲ့ team က ကွဲတာပဲ ပျက်တာပဲဆို အဲ့တာကိုယ့်အတွက်မကောင်းဘူး အဲ့လိုလူမျိုးက ပိုကြောက်ဖို့ကောင်းတယ် ကျွန်တော်ဆိုလည်း အဲ့လိုလူမျိုး ဘယ်လောက်တော်တော် ခန့်မှာမဟုတ်ဘူး တစ်ချို့ကျ ဘာမှမတတ်ခင်တုန်းက ကုမ္ပဏီက train ပေးရပြီး တတ်လည်းတတ်သွားရော လစာပိုများတဲ့ဆီသွားတယ် ဒီလိုမျိုးလည်း မကောင်းပြောချင်ကြတယ် အမှန်တော့ ဒါလည်း နှစ်ဉီးနှစ်ဖက် မျှော်လင့်ထားရမယ့်ကိစ္စဖြစ်တယ် မတတ်တဲ့သူကို train ပေးမယ်ဆိုပြီးခန့်တာလည်း ကိုယ့်ရွေးချယ်မှု တတ်သွားတဲ့အချိန် တစ်ခြားမရောက်အောင် ငွေနဲ့ထိန်းမလား ရာထူးပေးထိန်းမလား ဒါမှမဟုတ် အစတည်းက ဘယ်နှစ်နှစ်လုပ်ရမယ် မဟုတ်ရင်လျှော်ရမယ်ဆိုပြီး စာချုပ်နဲ့ထိန်းမလား ဒါလည်း ကိုယ့်ရွေးချယ်မှု တစ်ဖက်ကလည်း သူ့အဆင့်နဲ့ သူနဲ့ပိုထိုက်တန်တဲ့နေရာကိုသွားတာဖြစ်တဲ့အတွက် သူ့ကို အပြစ်ပြောလို့ လုံးဝမရဘူး ဘယ်သူမဆို ပိုသာတယ်ထင်တဲ့ဆီသွားမှာပဲ ရေကြည်ရာမြက်နုရာပဲ အဲ့တာကို တစ်ခြား emotion တွေ personal တွေနဲ့ ရောထွေးလိုက်လို့မရဘူး မဟုတ်ရင် drammatic story တွေအများကြီး ဖြစ်လာလိမ့်မယ်

ကိုယ့်ကိုယ်ကို senior engineer တစ်ယောက်ဖြစ်လာပြီလား လိုသေးလားဆိုတာ ဘယ်လိုသိနိုင်မလဲ

အဲ့မေးခွန်းကိုဖြေဖို့က factor သုံးခုအပေါ်မူတည်တယ် ပထမတစ်ခုက ကိုယ့် org/company မှာ ကိုယ့် code line ဘယ်နှစ်ကြောင်မှာ file ဘယ်နှစ် file မှာ ကိုယ့်ရဲ့ code တွေရှိနေလဲ ကိုယ်ဘယ်လောက် contribute လုပ်ပြီးပြီလည်းဆိုတာနဲ့ဆိုင်မယ် codebase ရဲ့ နေရာတော်တော်များများမှာ ကိုယ့် contribution ရှိနေပြီဆိုရင် skill အရမဟုတ်တောင် လက်ရှိ codebase အရ ကိုယ့်ရဲ့ experience အပေါ်မူတည်ပြီး စီနီယာဖြစ်လာပြီလို့ ပြောလို့ရတယ် ဒုတိယတစ်ခုက team ရဲ့ techincal decision တွေမှာ ကိုယ့်ရဲ့ advise က ဘယ်လောက် impact ဖြစ်စေသလဲဆိုတာနဲ့ တိုင်းလို့ရတယ် ကိုယ်က development process တစ်ခုလုံးကို techincal challenges တွေကို foresee မလုပ်နိုင်သေးပဲ သူများလုပ်ခိုင်းတာကိုပဲ လုပ်နိုင်တဲ့အဆင့်ပဲဆိုရင် ဒါ senior မဖြစ်သေးဘူးလို့ ယူဆလို့ရတယ် နောက်ဆုံးတစ်ခုက ကိုယ်က team ရဲ့ technical problem တွေအတွက် goto person ဖြစ်နေပြီလားဆိုတာနဲ့ တိုင်းလို့ရတယ် ဉပမာ ပြသနာတစ်ခုခုတက်တယ် ကိုယ့်ဆီလာမေးတယ် ကိုယ်ကလည်းရှင်းပေးနိုင်တယ် တစ်ခုခုပြသနာတက်လာရင် သူ့ဆီသွားမေး သူသိတယ်ဆိုတာမျိုး အဲ့လို goto person ဖြစ်လာရင် senior level ရောက်လာပြီလို့ ပြောလို့ရတယ် ကိုယ့်ရဲ့ colleagues တွေကို ဘယ်လောက် assist လုပ်ပေးနိုင်သလဲ ဘယ်လောက် educate လုပ်နိုင်သလဲ ဒီဟာအပေါ် မူတည်တယ် senior level, lead level တွေက ကိုယ်သိနေတာတစ်ခုတည်းနဲ့ မပြီးဘူး team တစ်ခုလုံးကို ကိုယ့်ရဲ့ knowledge ကိုအသုံးပြုပြီး obstacle တွေကို take down လုပ်နိုင်အောင် support လုပ်ပေးနိုင်ဖို့လည်း လိုတယ်

လက်ရှိအလုပ်က ဘာမှမသင်ပေးဘူး

ဘယ် company ကမှ အလုပ်ထဲရောက်မှ သင်ပေးမှာမဟုတ်ဘူး training ပေးပြီးခန့်တဲ့ကုမ္ပဏီဆိုရင်တော့ တစ်မျိုးပေါ့ ဒါပေမယ့် သင်ကိုသင်ပေးရမယ်လို့တော့ မမျှော်လင့်သင့်ဘူး ဘယ်သူမဆို ခန့်လိုက်တာနဲ့ တန်းသုံးချင်ကြတာချည်းပဲ အဲ့တာနဲ့ ကိုယ့်အတွက် improve ဖြစ်ဖို့ chance မရှိရဘူးလားဆိုတော့ အဲ့လိုလည်းမဟုတ်ဘူး ကိုယ်ကိုယ်ကို improve ဖို့က သူများရေးထားတဲ့ code တွေလိုက်ဖတ် သုံးထားတဲ့ library တွေကြည့် ဘာကြောင့်ဒီလိုရေးသလဲ မေးခွန်းထုတ် ကိုယ့်ဘာသာအဖြေရှာ ဒီလို self-study ပဲလုပ်သွားရမှာ အလုပ်က သင်တန်းမဟုတ်တဲ့အတွက် ခင်ဗျား skill တက်ဖို့ မတက်ဖို့သည် သူတို့နဲ့မဆိုင်ဘူး ခင်ဗျား learn လုပ်တာပြီးဖို့လည်း အချိန်ပေးဖို့တာဝန် သူတို့မှာမရှိဘူး အလုပ်လုပ်ရင်းနဲ့ပဲ ကိုယ်လိုတာကို ဖြည့်သွားရမှာဖြစ်တယ် ဘယ် senior ကမှလည်း သင်တန်းမှာစာသင်သလို သင်ပေးဖို့တာဝန်မရှိဘူး တစ်ချို့က စီနီယာတွေလက်တွဲမခေါ်ဘူးဆိုတာက တစ်ချို့ ကိုယ်ဘယ်လိုမှမသိတော့တဲ့ဟာတွေကို ဖြေရှင်းပေးဖို့ learning resource ညွှန်းပေးတာလောက်ကိုပဲ လက်တွဲခေါ်တယ်ပြောတာ ကလေးစာသင်သလို အရိပ်တကြည့်ကြည့်နဲ့ train ပေးဖို့တော့ မျှော်လင့်လို့မရဘူး on board process နဲ့ လက်ရှိ codebase ကို walkthrough လုပ်ပေးပြီးရင် ဒီအတိုင်းလက်ထဲထည့်ပေးလိုက်မှာပဲ မရှင်းရင်မေးလို့ရတယ် မသိရင် ဘယ်ဟာနမူနာကြည့်လို့ရမလဲလောက်တော့ ပြောပြပေးကြမှာချည်းပဲ ဒါပေမယ့် တစ်ခါကနှစ်ခါ သုံးခါ တလွဲတွေချည်းလုပ်လာရင်လည်း ဆဲသင့်ဆဲကြမှာပဲ တစ်ခုတော့ရှိတာပေါ့ ကိုယ်လုပ်နေရတဲ့အလုပ်တွေက tedious ဖြစ်တယ် အမြဲဒါပဲလုပ်နေရတယ် no room for improvement လို့မြင်ရင်တော့လည်း အလုပ်ပြောင်းသင့်ပြောင်းပေါ့