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

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

ဒါက တကယ့် tech debt ပါပဲ။ dev ညံ့လို့ ရေးထားခဲ့တာ မဟုတ်ပါဘူး။ တစ်ချိန်တုန်းကတော့ မလွှဲမရှောင်သာတဲ့ ဆုံးဖြတ်ချက်တစ်ခုရဲ့ အကြွေး (debt) တွေ တင်ကျန်ခဲ့တာ။ ဒီပိုစ်မှာ စာအုပ်ကြီးထဲက theory တွေ လျှောက်ပြောမှာ မဟုတ်ပါဘူး။ လက်တွေ့ ကြုံခဲ့ရတဲ့ အမှားတွေနဲ့ team ထဲမှာ trust မပျက်အောင်၊ ကိုယ်တိုင်လည်း ခေါင်းမကိုက်ရအောင် ဘယ်လို manage ဖြစ်အောင် ထိန်းကျောင်းမလဲဆိုတာ အေးဆေး စကားပြောကြတာပေါ့။

Tech Debt ဆိုတာ တကယ်တော့ ဘာလဲ

၁၉၉၂ တုန်းက Ward Cunningham ဆိုတဲ့ engineer က ဒီ metaphor ကို စသုံးခဲ့တာ။ Idea က ရိုးရှင်းတယ်။ "Code မြန်မြန် ship ဖြစ်ဖို့ shortcut တွေ သုံးလိုက်တိုင်းဟာ ဘဏ်က ငွေချေးလိုက်သလိုပဲ။ အရေးကြုံရင် ချေးတာ ပြဿနာမရှိပေမဲ့ အနှေးနဲ့အမြန် အတိုး (interest) တော့ ပြန်ပေးရလိမ့်မယ်။"

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

အဲဒီအတိုးတွေက ဘာတွေလဲဆိုတာ ကျွန်တော် ခန့်မှန်းခြေနဲ့ လျှောက်ပြောနေတာ မဟုတ်ဘူး။ လေ့လာမှုတွေအရ developer တွေဟာ သူတို့ code ရေးရမယ့်အချိန်ရဲ့ ၂၀% ကျော်ကို ဒီ tech debt တွေ လိုက်ရှင်းရင်းနဲ့တင် ကုန်နေကြတာ။ ပိုဆိုးတာက အဲဒီရှိနေတဲ့ အကြွေးဟောင်းတွေကြောင့်ပဲ နောက်ထပ် code အသစ်တွေ ထပ်ထည့်တဲ့အခါမှာပါ အကြွေးအသစ်တွေ ထပ်ယူမိဖို့ ဖိအားဖြစ်လာတတ်တာမျိုးပါ။

Stripe ရဲ့ survey တစ်ခုအရဆိုရင်လည်း developer တစ်ယောက်ဟာ တစ်ပတ်ကို ၁၇ နာရီထက်မနည်း refactoring နဲ့ debugging လို maintenance အလုပ်တွေမှာ အချိန်ကုန်နေပြီး၊ အဲဒီထဲက ၄ နာရီလောက်က bad code ကြောင့် သက်သက်အချိန်ဖြုန်းလိုက်ရတာပါ။ တစ်ကမ္ဘာလုံးအတိုင်းအတာနဲ့ဆိုရင် lost productivity က တစ်နှစ်ကို ဒေါ်လာ ဘီလီယံ ၃၀၀ နီးပါးလောက်အထိ ဆုံးရှုံးမှု ရှိတယ်လို့ ခန့်မှန်းကြတယ်။

Intentional vs. Unintentional Tech Debt

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

၁။ Intentional Tech Debt (တမင်ယူတဲ့ အကြွေး) — ဒါက strategic ဆုံးဖြတ်ချက်မျိုးပေါ့။ ဥပမာ — နောက်အပတ် Investor Demo ရှိလို့ "လောလောဆယ် ship လိုက်ဦး၊ test တွေ၊ refactor တွေ နောက်မှ ပြန်လုပ်မယ်" ဆိုတာမျိုး။ MVP ထုတ်တုန်းက "အလုပ်လုပ်ရင် ပြီးရော" ဆိုပြီး ဆောက်ခဲ့တာမျိုးပါ။ ပြန်ဆပ်ဖို့ plan ရှိရင် ဒါက ပညာရှိစွာ ယူတဲ့အကြွေးပဲ ဖြစ်ပြီး Business အတွက် ပေးဆပ်လိုက်တဲ့ အဖိုးအခတစ်ခုပါ။

၂။ Unintentional Tech Debt (မသိဘဲ တင်လာတဲ့ အကြွေး) — ဒါကတော့ တကယ့် ဂျောက်ထဲကျမယ့် အမျိုးအစားပဲ။ Requirement လွဲပြီး ရေးမိတာ၊ ကိုယ် Junior ဘဝက structure မကောင်းဘဲ ရေးခဲ့တာ၊ သုံးထားတဲ့ library က မကြာခင် dead တော့မှာကို ကြိုမသိခဲ့တာမျိုးပေါ့။ architectural debt က အဆိုးဆုံးပဲ — ကိုယ်တိုင်တောင် မရိပ်မိဘဲ ဆယ်စုနှစ်တစ်ခုမက codebase အောက်မှာ တိတ်တဆိတ် ကြီးထွားနေတတ်တယ်။

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

အကြွေးကို ပစ်ထားရင် ကြုံရမယ့် သံသရာဆိုး (Vicious Cycle)

tech debt ကို ကြာရှည်လျစ်လျူရှုထားရင် တဖြည်းဖြည်းချင်းနဲ့ မသိမသာ နစ်မြုပ်သွားတတ်ပါတယ်။

  • Velocity ကျမယ်: အရင်က ၁ ပတ်နဲ့ပြီးတဲ့ feature က အခု ၃ ပတ် ကြာလာမယ်။ Chainguard ရဲ့ ၂၀၂၆ report အရ engineer တွေဟာ တစ်ပတ်လုံးမှာ code အသစ်ရေးဖို့နဲ့ feature အသစ်ထုတ်ဖို့အတွက် ၁၆% ပဲ အချိန်ပေးနိုင်တော့တာ တွေ့ရတယ်။ ၉၃% သော dev တွေက ဒါက အပျော်ဆုံးအလုပ်လို့ ပြောထားပေမဲ့ တကယ်တမ်း လမ်းရှင်းနေရတာက ပိုများနေတာပါ။

  • "ဒီ code ကို မထိနဲ့" syndrome ဝင်လာမယ်: codebase ထဲမှာ ဘယ်သူမှ ဝင်မပြင်ရဲတဲ့ သရဲခြောက်တဲ့နေရာတွေ ပေါ်လာမယ်။ "payment module ကို သွားမထိနဲ့၊ ပျက်လိမ့်မယ်" ဆိုတာမျိုးပေါ့။ နောက်ဆုံး ကိုယ်က code ကို control မလုပ်နိုင်တော့ဘဲ code က ကိုယ့်ကို ပြန် control လုပ်သွားလိမ့်မယ်။

  • Developer Burnout ဖြစ်မယ်: နေ့တိုင်း တူညီတဲ့ bug တွေနဲ့ပဲ လုံးချာလိုက်ပြီး ဘာမှလည်း ship မဖြစ်တော့တဲ့အခါ တကယ်တော်တဲ့ engineer တွေပါ စိတ်ကုန်ပြီး ထွက်ကုန်ကြရော။ survey တွေအရ dev တွေရဲ့ ၅၁% ဟာ tech debt အရမ်းများလွန်းလို့ အလုပ်ထွက်ဖို့အထိ စဉ်းစားခဲ့ကြဖူးပြီး ၂၀% ကတော့ ဒါဟာ အလုပ်ထွက်ရတဲ့ အဓိက အကြောင်းရင်းပဲလို့ ပြောထားကြတယ်။

ဒီသံသရာရဲ့ အဆိုးဆုံးက tech debt က နည်းပညာပြဿနာတင် မဟုတ်တော့ဘဲ team ရဲ့ morale နဲ့ trust ပြဿနာ ဖြစ်လာတာပါပဲ။

တကယ်ဖြစ်ခဲ့ဖူးတဲ့ Startup ဇာတ်လမ်း

ကျွန်တော်တို့ပတ်ဝန်းကျင်က Startup တစ်ခုတုန်းက တကယ်ကြုံခဲ့ရတဲ့ war story တစ်ခုကို ပြောပြမယ်။ Enterprise client ကြီးတစ်ခုကို Demo ပြဖို့ ရက်ပိုင်းပဲ လိုတော့တဲ့အချိန်၊ checkout feature အသစ်ကို ၂ ပတ်အတွင်း အပြတ်ဆောက်ရမယ့် အခြေအနေပေါ့။ အချိန်က အရမ်းညှပ်နေတော့ dev တွေလည်း shortcut တွေ ယူကြတော့တာပဲ။

Payment status ကို handle ဖို့ proper webhook တွေ မရေးတော့ဘဲ UI ထဲကနေ HTTP polling နဲ့ ၃ စက္ကန့်တစ်ခါ လှမ်းစစ်တဲ့ နည်းလမ်းကို သုံးလိုက်တယ်။

// Anti-pattern: UI က payment status ကို ၃ စက္ကန့်တစ်ခါ poll လုပ်နေတာ
setInterval(async () => {
  const res = await fetch(`/api/checkout/${orderId}/status`);
  const { status } = await res.json();
  if (status === "paid") showSuccess();
}, 3000);

Database ထဲမှာလည်း concurrent checkout တွေအတွက် DB transaction တွေ၊ indexing တွေ သေချာမလုပ်ထားသလို၊ သက်ဆိုင်ရာ shipping rules တွေကိုလည်း controller တစ်ခုတည်းထဲမှာ hardcode တွေ အတင်းရိုက်ထည့်ပြီး အမြန် ship လိုက်ကြတယ်။ Demo ပြတော့ အောင်အောင်မြင်မြင်နဲ့ Client ရဲ့ အကြိုက် တွေ့သွားခဲ့တယ်။

ပြဿနာက ၆ လလောက်ကြာပြီး Marketing က Flash Sale အကြီးစားတစ်ခု လုပ်တဲ့နေ့မှာ စတာပဲ။ Concurrent user ထောင်ချီပြီး checkout ကို တစ်ပြိုင်တည်း နှိပ်လိုက်တဲ့အချိန်မှာ ဟို UI polling က ကိုယ့် server ကိုယ် DDoS လုပ်သလို ဖြစ်သွားပြီး connection pool ဗုန်းခနဲ ကျသွားရော။

ပြီးတော့ DB index မရှိတာနဲ့ row locking ပြဿနာတွေကြောင့် user ဆီက ပိုက်ဆံသာ ဖြတ်သွားတယ်၊ system ထဲမှာ order status က update မဖြစ်ဘဲ data တွေ အကုန် ဇာတ်ရှုပ်ကုန်တယ်။ အဲဒီ error ကြီးကို လိုက်ရှင်းဖို့ code ဖွင့်ကြည့်တော့လည်း logic တွေက ရောထွေးပွစာဖြစ်နေလို့ hotfix ထုတ်ဖို့ နေနေသာသာ တစ်ကြောင်းပြင်ရင် တစ်နေရာလိုက်ပျက်နေတာနဲ့ ရက်သတ္တပတ်တော်တော်ကြာအောင် ညဘက်ကြီး အိပ်ရေးပျက်ပြီး လိုက်ပြင်ဆင်နေရတာကြောင့် engineer ၂ ယောက် ချက်ချင်းကြီး အလုပ်ထွက်သွားတော့တာပဲ။

သင်ခန်းစာက — debt ယူတာ မဆိုးပါဘူး။ ယူပြီးရင် track မလုပ်ဘဲ၊ ပြန်ဆပ်မယ့် plan မရှိဘဲ ပစ်ထားတာကမှ တကယ့်ပြဿနာပါ။ "ဒီကောင်ကို ဇန်နဝါရီမတိုင်ခင် refactor လုပ်မယ်" ဆိုပြီး ticket လေးတစ်ခု ဖွင့်ထားလိုက်ရင် ဇာတ်လမ်းက တစ်မျိုး ဖြစ်သွားနိုင်တယ်။

Business နဲ့ Engineering ကြား ညှိနှိုင်းရခြင်း

Senior Engineer တစ်ယောက် ဖြစ်လာရင် code ရေးတာထက် ဒါက ပိုအရေးကြီးလာတယ်။ tech debt အကြောင်းကို non-tech သမားတွေ (Founders, PMs) နားလည်အောင် ဘယ်လို ဆက်သွယ်မလဲဆိုတာ။ သူတို့က code ဘယ်လောက်လှလဲဆိုတာထက် Speed, Cost, Risk တွေကိုပဲ ပိုစိတ်ဝင်စားကြတာ။ "codebase က messy ဖြစ်လို့ refactor ချင်တယ်" သွားပြောရင် engineer တွေ အပိုအလုပ်ရှာတယ်လို့ပဲ မြင်မယ်။

McKinsey ရဲ့ report တစ်ခုထဲမှာ ဖတ်ဖူးတာက tech debt ဟာ ကုမ္ပဏီတစ်ခုလုံးရဲ့ နည်းပညာပိုင်ဆိုင်မှုရဲ့ ၂၀% ကနေ ၄၀% အထိ ရှိနေတတ်ပြီး product အသစ်ထုတ်ဖို့ သုံးမယ့် budget ရဲ့ ၁၀% ကနေ ၂၀% အထိက ဒီအကြွေးဆပ်ဖို့အတွက်ပဲ လမ်းကြောင်းလွှဲသုံးစွဲနေရတာပါ။ ဒါကြောင့် သူတို့ကို ရှင်းပြတဲ့အခါ ရှင်းလင်းတဲ့ ကိန်းဂဏန်းတွေနဲ့ ချပြဖို့ လိုအပ်ပါတယ်။

Don't — "ဒီ codebase က messy ဖြစ်နေတယ်၊ ကျွန်တော်တို့ refactor ဖို့ လိုတယ်။" (Business အတွက် ဘာမှ အဓိပ္ပာယ်မရှိဘူး)

Do — "အခု feature တစ်ခုထည့်ဖို့ ၂ ပတ် ကြာနေပါတယ်။ ဒီ module ကို ၁ ပတ်လောက် ပေးပြီး refactor လိုက်ရင်၊ နောက်ပိုင်း feature တိုင်းကို ၄ ရက်တည်းနဲ့ ပြီးအောင် ship နိုင်ပါမယ်။" (ဒါက သူတို့နားလည်တဲ့ စကား — Time-to-market နဲ့ ROI)

ဒီနေရာမှာ သုံးလို့ရတဲ့ နည်းလမ်းလေးတွေက —

  • အချိန်/ငွေနဲ့ တွက်ပြ: McKinsey ရဲ့ လေ့လာမှုအရ debt ကို စနစ်တကျ manage လုပ်နိုင်တဲ့ ကုမ္ပဏီတွေဟာ revenue growth ၂၀% ပိုများတာ တွေ့ရတယ်။ ဒါကို ထောက်ပြပြီး "ဒီ debt ကြောင့် engineer တစ်ယောက်ဟာ တစ်ပတ်ကို တစ်ရက်စာ အချိန်ဖြုန်းနေရတယ်။ team ထဲမှာ လူ ၅ ယောက်ရှိရင် တစ်လကို လူတစ်ယောက်ရဲ့ နှစ်ပတ်စာ အလုပ်ချိန်လောက် အလကား ဆုံးရှုံးနေရတာနဲ့ တူတူပဲ" လို့ ပြောကြည့်ပါ။
  • Risk နဲ့ ပြ: "ဒီအတိုင်း ဆက်သွားရင် လာမယ့် Promotion ကာလကျရင် checkout စနစ်ကြီး ကျသွားနိုင်ခြေ အရမ်းများနေပြီ" လို့ ပွင့်ပွင့်လင်းလင်း ပြောတာမျိုး။
  • Analogy သုံး: "အိမ်ရဲ့ foundation (အုတ်မြစ်) လိုပဲ။ အပေါ်ထပ် ဆက်ဆောက်ချင်ရင် foundation အရင်ခိုင်ဖို့ လိုတယ်။"

Senior dev တစ်ယောက်ရဲ့ အလုပ်က ကိုယ်တိုင် ဆုံးဖြတ်ချက် ချက်ချင်းချပစ်လိုက်ဖို့ မဟုတ်ပါဘူး။ Option တွေနဲ့ ဖြစ်လာမယ့် consequence တွေကို ရှင်းရှင်းပြပြီး business ကို ကောင်းကောင်း ဆုံးဖြတ်နိုင်အောင် ကူညီပေးဖို့ပါ။ Trust ဆိုတာကတော့ တစ်ရက်၊ နှစ်ရက်နဲ့ ဆောက်လို့ရတာမျိုး မဟုတ်ဘူး။ ကိုယ်ပေးတဲ့ estimate မှန်ပြီး ပုံမှန် ship နိုင်တဲ့ track record ရှိမှ stakeholder တွေက ယုံကြည်လာမှာပါ။

ဒါဆို လက်တွေ့မှာ ဘယ်လို Manage လုပ်ကြမလဲ

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

၁။ Sprint တိုင်းရဲ့ ၁၅% ကနေ ၂၀% ကို ဖယ်ထားပါ

အောင်မြင်တဲ့ ကုမ္ပဏီတော်တော်များများဟာ သူတို့ရဲ့ sprint capacity ရဲ့ ၁၅% ကနေ ၂၀% ကို refactoring နဲ့ test ရေးဖို့ သီးသန့် ဖယ်ထားလေ့ရှိပါတယ်။ ဒါက တော်တော်လေး အဆင်ပြေတဲ့ ပုံစံတစ်ခုပဲ။ စမ်းသုံးကြည့်လို့ရတဲ့ pattern တစ်ခုက feature sprint နှစ်ခုပြီးတိုင်း refactoring sprint တစ်ခု ညှပ်ဆောက်တဲ့ "pit stop" ပုံစံမျိုးပဲ ဖြစ်ပါတယ်။

၂။ Boy Scout Rule (ကင်းထောက်စည်းမျဉ်း)

"မင်းရောက်သွားတဲ့ နေရာကို လာတုန်းကထက် ပိုသန့်ရှင်းအောင် ထားခဲ့ပါ။" feature တစ်ခုအတွက် function တစ်ခုခုကို ဝင်ပြင်ရပြီဆိုရင် လာတုန်းကထက် နည်းနည်းလေး ပိုသန့်သွားအောင် ပြင်ပေးပြီးမှ ပြန်ထွက်ခဲ့။ Variable name ကို ပိုနားလည်လွယ်အောင် ပြောင်းတာ၊ code အပိုတွေ ဖြတ်ခဲ့တာမျိုးပေါ့။ ဒါကို code review ထဲမှာပါ ကျင့်သုံးလို့ ရတယ်။

၃။ Debt ကို မြင်သာအောင် Track လုပ်ပါ

ခေါင်းထဲမှာပဲ ထားတဲ့အကြွေးက ဘယ်တော့မှ မဆပ်ဖြစ်ဘူး။ refactor လုပ်ရမယ့်အရာတွေကို ticket ဖွင့်ထားပါ။ အသက်ကြီးတဲ့ code အဟောင်းတွေကို လိုက်ပြင်နေမယ့်အစား ပြောင်းလဲမှု ခဏခဏလုပ်ရတဲ့ high-friction နေရာတွေကို priority ပေးပြီး 80/20 rule နဲ့ ရှင်းပါ။ အန္တရာယ် အချက်ပြစံတစ်ခုအနေနဲ့ Tech Debt Ratio ၂၀% ကျော်လာရင် စနစ်တစ်ခုလုံး အခြေအနေဆိုးနေပြီလို့ သတ်မှတ်ပြီး ၅% အောက်မှာ ထားဖို့ ကြိုးစားတာ ကောင်းပါတယ်။

၄။ Debt တွေ့တိုင်း လိုက်မရှင်းပါနဲ့

ဘယ်တော့မှ ပြန်မထိတော့မယ့်၊ အလိုလို ငြိမ်ပြီး အလုပ်လုပ်နေတဲ့ code အဟောင်းဆိုရင် ကြည့်ရဆိုးနေပစေဦး၊ priority အောက်ဆုံးမှာ ထားပါ။ ခဏခဏ ဝင်ပြင်နေရတဲ့၊ feature အသစ်ထည့်ဖို့ ပိတ်ဆို့နေတဲ့ code မျိုးကိုပဲ အရင်ဆပ်ပါ။ ROI အမြင့်ဆုံးဖြစ်မယ့် debt ကိုပဲ ရွေးဆပ်ပါ။ McKinsey ရဲ့ အဆိုအရ အကြွေးကို သေသေချာချာ စီမံနိုင်ရင် engineer တွေဟာ လုပ်ငန်းရဲ့ core goals တွေအတွက် ၅၀% အထိ အချိန်ပိုပေးနိုင်လာမှာ ဖြစ်ပါတယ်။

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

ကိုယ်တိုင် Burnout မဖြစ်သွားအောင် တစ်ခါတည်း အကုန်အပြတ်ရှင်းမယ်ဆိုပြီး သွားမလုပ်ပါနဲ့။ sprint တိုင်းမှာ boy scout rule နဲ့ ဖြည်းဖြည်းချင်းပဲ သွားပါ။ Blame game တွေ လျှောက်လုပ်မနေဘဲ stakeholder တွေ နားလည်မယ့် terms မျိုးနဲ့ ပွင့်ပွင့်လင်းလင်း စကားပြောပါ။

တကယ်တော်တဲ့ Engineer ဆိုတာ code ကို အမြဲ Perfect ဖြစ်အောင် ရေးနိုင်တဲ့သူ မဟုတ်ဘူး။ ဘယ်အချိန်မှာ အကြွေးယူသင့်ပြီး ဘယ်အချိန်မှာ ပြန်ဆပ်ရမလဲဆိုတဲ့ trade-off ကို တွက်ချက်နိုင်ပြီး team နဲ့ business တစ်ခုလုံး သဘောပေါက်အောင် လမ်းညွှန်ပြနိုင်တဲ့သူကို ခေါ်တာပါ။