Engineering Notes dan repost
Davomi
3. Engineerga vazifa emas, muammo bering. Tayyor yechimni implement qilish oson, yechimni va ayniqsa yaxshi yechimni topish qiyin. Agar manager yoki team lead sifatida engineerlarga "A tildagi B frameworkda C arxitekturada web server yoz, databaseda X, Y, Z tablelar bo'lsin" shaklidagi vazifa berayotgan bo'lsangiz unda birinchidan siz engineerlardan to'liq foydalanmayapsiz, ikkinchidan siz o'ylagan yechim optimal bo'lmasligi mumkin. Yaxshisi, "bizda A muammo bor, shuni hal qilish uchun bizga B imkoniyatga ega yangi servis kerak" deb muammoni o'rtaga tashlang. Shunda bir qancha alternativ yechimlarni ko'rib, hamma tomondan analiz qilib, eng yaxshi yaxshi yechimni tanlash imkoni bo'ladi. Lekin odatda call davomida yaxshi yechim o'ylab topish ko'p vaqt va ma'lum bir sohada chuqur bilim talab qilishi mumkin. Bunday holatda bir kishiga muammoni chuqur o'rganish va potensial yechimlar ustida ishlash vazifa qilib beriladi (yechimni implement qilish emas) va keyin berilgan yechimlarni butun jamoa bilan analiz qilib, qaror qabul qilishingiz mumkin. Implement qilish shundan keyingina boshlanadi.
4. Djangochi emas, engineer bo'ling. Bugun application serverda, ertaga databaseda, indinga networkingdagi muammoni hal qilishingizga to'g'ri kelishi mumkin. Albatta ishga kirishdan oldin bularning hammasini chuqur o'rgana olmaysiz, shuning uchun "T shaped" engineer bo'lishga harakat qiling. Ya'ni bilimingiz T harfidagiga o'xshab biror tor sohada chuqur bo'lishi bilan birga boshqa ko'plab sohalardan ham ma'lum darajada xabardor bo'lishingiz siz uchun ancha foydali, shunda zarur bo'lganida boshqa bir sohani chuqurroq o'rganishingiz oson bo'ladi (ya'ni T ni π ga aylantirish oson bo'ladi). Menimcha lokal bozordagi eng katta muammolardan biri ko'p sohalarni yuzaki biladigan lekin birortasini chuqur tushunmaydigan (– shaped) yoki bir tor sohani chuqur biladigan lekin boshqa sohalarni umuman tushunmaydigan (I shaped) engineerlar. Bundan tashqari bir narsani chuqurroq o'rganib olib, keyin hamma joyga shuni tiqishtiradigan (L shaped) engineerlar ham odatda jamoaga foydadan ko'proq zarar keltiradi, ToDo app qilish uchun ham microservice quradiganlar bunga misol.
5. Qilgan har bir ishingizni va o'ylagan har bir yechimingizni yozib boring. Projectda to'g'ridan-to'g'ri sizga bog'liq narsalar minimal bo'lishi kerak, yechimlar va g'oyalar ham shular qatorida. Ertaga siz ishdan ketsangiz ham yozgan narsalaringiz turadi. Bu kelajakda boshqalarning vaqtini isrof qilmaslik uchun qilishingiz mumkin bo'lgan eng yaxshi narsalardan biri. Bundan tashqari menga o'xshab xotirangiz yomonroq bo'lsa 1 hafta oldin tugata olmagan ishingizga qaytganingizda oldingi safar nima qilganingiz/qilmoqchi bo'lganingizni yozib qo'yganingiz uchun o'zingizga o'zingiz rahmat aytasiz.
@boboshersnotes
3. Engineerga vazifa emas, muammo bering. Tayyor yechimni implement qilish oson, yechimni va ayniqsa yaxshi yechimni topish qiyin. Agar manager yoki team lead sifatida engineerlarga "A tildagi B frameworkda C arxitekturada web server yoz, databaseda X, Y, Z tablelar bo'lsin" shaklidagi vazifa berayotgan bo'lsangiz unda birinchidan siz engineerlardan to'liq foydalanmayapsiz, ikkinchidan siz o'ylagan yechim optimal bo'lmasligi mumkin. Yaxshisi, "bizda A muammo bor, shuni hal qilish uchun bizga B imkoniyatga ega yangi servis kerak" deb muammoni o'rtaga tashlang. Shunda bir qancha alternativ yechimlarni ko'rib, hamma tomondan analiz qilib, eng yaxshi yaxshi yechimni tanlash imkoni bo'ladi. Lekin odatda call davomida yaxshi yechim o'ylab topish ko'p vaqt va ma'lum bir sohada chuqur bilim talab qilishi mumkin. Bunday holatda bir kishiga muammoni chuqur o'rganish va potensial yechimlar ustida ishlash vazifa qilib beriladi (yechimni implement qilish emas) va keyin berilgan yechimlarni butun jamoa bilan analiz qilib, qaror qabul qilishingiz mumkin. Implement qilish shundan keyingina boshlanadi.
4. Djangochi emas, engineer bo'ling. Bugun application serverda, ertaga databaseda, indinga networkingdagi muammoni hal qilishingizga to'g'ri kelishi mumkin. Albatta ishga kirishdan oldin bularning hammasini chuqur o'rgana olmaysiz, shuning uchun "T shaped" engineer bo'lishga harakat qiling. Ya'ni bilimingiz T harfidagiga o'xshab biror tor sohada chuqur bo'lishi bilan birga boshqa ko'plab sohalardan ham ma'lum darajada xabardor bo'lishingiz siz uchun ancha foydali, shunda zarur bo'lganida boshqa bir sohani chuqurroq o'rganishingiz oson bo'ladi (ya'ni T ni π ga aylantirish oson bo'ladi). Menimcha lokal bozordagi eng katta muammolardan biri ko'p sohalarni yuzaki biladigan lekin birortasini chuqur tushunmaydigan (– shaped) yoki bir tor sohani chuqur biladigan lekin boshqa sohalarni umuman tushunmaydigan (I shaped) engineerlar. Bundan tashqari bir narsani chuqurroq o'rganib olib, keyin hamma joyga shuni tiqishtiradigan (L shaped) engineerlar ham odatda jamoaga foydadan ko'proq zarar keltiradi, ToDo app qilish uchun ham microservice quradiganlar bunga misol.
5. Qilgan har bir ishingizni va o'ylagan har bir yechimingizni yozib boring. Projectda to'g'ridan-to'g'ri sizga bog'liq narsalar minimal bo'lishi kerak, yechimlar va g'oyalar ham shular qatorida. Ertaga siz ishdan ketsangiz ham yozgan narsalaringiz turadi. Bu kelajakda boshqalarning vaqtini isrof qilmaslik uchun qilishingiz mumkin bo'lgan eng yaxshi narsalardan biri. Bundan tashqari menga o'xshab xotirangiz yomonroq bo'lsa 1 hafta oldin tugata olmagan ishingizga qaytganingizda oldingi safar nima qilganingiz/qilmoqchi bo'lganingizni yozib qo'yganingiz uchun o'zingizga o'zingiz rahmat aytasiz.
@boboshersnotes