Haqiqiy boykot

Agar qaysidir katta kompaniya haqida yaxshi fikrda bo'lmasangiz, uni boykot qilishni eng yaxshi yo'li nima bilasizmi?

Bu uning mahsulotlarini sotib olmay qo'yish emas (bundan eng katta zararni o'zingiz ko'rasiz), unga raqobatchi kompaniya yaratib uni bozordagi o'rnini olib qo'yish.

Eplay olsangiz butun xizmatlaridan ko'ra yaxshiroq xizmatlar, mahsulotlar yarating. Eplay olmasangiz hech bo'lmaganda o'z davlatingizdagi, o'z shahringizdagi, o'z mahallangizdagi xizmat / mahsulotidan ko'ra chin ma'nodagi yaxshiroq bo'lgan alternativ mahsulot taklif qiling. Ana shunda odamlarni chiqib boykotga chaqirib, battar kambag'allashtirmaysiz. Balki yaxshiroq mahsulot berib boyitasiz.

Qo'lingizdan kelmaydimi? Hozircha kelmaydimi? Unda keladigan paytgacha o'qing, o'rganing, izlaning, harakat qiling.

O'rganish uchun eng yaxshi variant esa o'sha kompaniya o'zi. Zo'r kompaniyadan zo'rroq narsa qilishning eng yaxshi usuli tashqaridan turib "divanniy" analitika qilish emas, ichkaridan turib barcha kuchli, kuchsiz tomonini o'rganish.

Va eng asosiysi - kimnidir boykot qilish, sindirish uchun harakat qilmang. Shunchaki eng yaxshisi bo'lishga, eng yaxshi mahsulot yaratishga va ko'proq odamlar hayotini yaxshilashga harakat qiling.

Muammo "yomonlar" kuchli ekanida emas, "yaxshilar" juda ojiz ekanida!

#justthoughts

@musayev_blogi

Postni Microsoftdan taklif olishimdan 1 yil oldin yozgan ekanman. Hozir esa shu gaplarni eslashning eng yaxshi vaqti.

Gap nimadaligini esa batafsilroq "Janob Panda" kanalidan bilib olishingiz mumkin
https://www.tg-me.com/mukhammadkarim_tukhtaboev/2604

#imho

@Janob_Musayev

Startaplardagi "tirik qolish" xatoligi

Ikkinchi jahon urushi paytida o‘q yegan holda bazaga qaytgan bombardimonchi samolyotlarni tekshirib, ularning o‘q yegan joylarini mustahkamlash kerak degan tadqiqot haqida o'qigan bo'lsangiz kerak (survivorship bias).

Agar startap yoki dasturdan yuzlab negativ izohlar bilan ham minglab (yoki millionlab) odamlar foydalanyaptimi demak u o'zining eng asosiy vazifasini juda yaxshi tarzda uddalaydi. Ya'ni ular yuzlab o'q yeb ham bazaga tirik qayta olyapti.

Ulardagi xato va kamchiliklarni "mustahkamlash" orqali ulardan o'tib ketishga urinish esa huddi samalyotning eng muhim bo'lmagan qismlariga zirh qo'shishga urinishga o'xshaydi.

Muvaffaqiyatli loyihalardan kuchliroq yangi loyiha yaratish ulardagi kamchiliklarni to'g'rilashdan emas, ularning muvaffaqiyatini takrorlay olishdan boshlanadi.

#startup_life

@Janob_Musayev

O'tgan oyda EventGO da e'lon qilgan tadbirlarning uchdan birini (56 tadan 19 ta) tashkilotchilar o'zlari sayt va telegramga joylashtiribdi. Umumiy 2000 dan ortiq odam esa tadbirlarga qatnashish qiziqishini bildiribdi.

Albatta, hozircha hech qanday daromad keltirmasa ham, juda yirik loyiha bo'lmasa ham qilgan ishingdan odamlar foydalanayotganini ko'rishning o'zi kichik startupimiz uchun yoqimli holat :)

Ha aytgancha, siz ham kanalingizda ovozli chat qilsangiz yoki boshqa tadbirlaringiz bo'lsa, uni bemalol EventGOda e'lon qilsangiz bo'ladi. Bepulga!

#startup_life

@Janob_Musayev

Karyerada bo’yiga va eniga o’sish

Kecha Jahongir aka “Dasturchilar uchun menejer bo’lish lavozim oshishi emas...” deb yozibdi. Bu fikr shubhasiz yarim to’g’ri. Negaligini esa batafsil tushuntirishga harakat qilaman.


Lavozimlar narvon shaklida emas

Ko’pchilik korxonadagi lavozimlar strukturasi haqida o’ylaganda uni faqat tepaga ketgan narvon shaklda tasavvur qiladi. Lavozim oshishi uchun esa, shu narvondan pog’onama-pog’ona chiqish kerak deb hisoblanadi. Ingliz tilida “going up the career ladder” degan jumla ham bor.

Lekin aslida lavozimlar narvon shaklida tuzilmagan, ayniqsa yirik bigtech kompaniyalarda. U ko’proq piramidaga o’xshaydi. Ya’ni u yerda ham bo’yiga, ham eniga o’sish imkoniyati bor. Faqat bir jihati, o’sish davomida ular bir-biridan uzoqlashmaydi, aksincha ikkalasi ham markazga qarab yuradi.

Kompaniyaga yangi kelgan va karyerasini endi boshlagan paytingizda (men ham shu qatori) esa piramidaning eng quyi burchagiga joylashasiz. Sizda esa o’sish yoki lavozim oshishiga harakat qilishning esa ikki xil yo’li bor: eniga qarab markazga yoki tepaga.


Eniga o’sish

Jahongir aka fikri nega yarim to’g’ri ekanini allaqachon tushungan bo’lsangiz kerak. Ular ham aslida “O’sish faqat bo’yiga emas, eniga ham bo’lish mumkin” demoqchi bo’ldilar.

Eniga o’sish sizning bilimingiz, tajribangiz, muammolarni yecha olish va boshqa qattiq ko’nikmalaringiz (hard skills) orqali amalga oshadi. Dasturiy muhandislik borasida bu Software Engineer, Software Engineer II, Senior Software Engineer, Lead, Principal, Distinguished va hokazolarga bo’linib ketadi. Har xil kompaniyalarda bu har xil nomlanadi. Lekin odatda 7-8 darajadan iborat bo’ladi.

Men masalan, L1 darajadaman. L4 darajaga chiqish esa o’rtacha 5+ yil vaqt oladi. Undan uyog’i taxminan har bir daraja 5 yildan 😐

Eniga o’sishda ham aytganimdek markazga qarab yuriladi, ya’ni unda ham ko’proq odamlar bilan ishlashingizga, ko’proq narsalarga javob berishingizga, ko’proq asabingizni sarflashga majbur bo’lasiz. Faqat asosiy farqi, eniga o’sishda boshqalarni boshqarishga (rasman) javobgar bo’lmaysiz.


Menejerlik haqida ikki og’iz

Bo’yiga o’sishga o’tishdan oldin menejerlikka o’tish har doim ham bo’yiga o’sishni anglatmasligini eslatib ketish kerak. Product Manager, Program Manager, Scrum Manager kabilar menejer sifatida odamlarni emas, boshqa narsalarni boshqarasiz.

Dasturchilikdan bu kasblarga o’tish, shubhasiz, umuman boshqa yo’nalishga o’tishni anglatadi.


Bo’yiga o’sish

Bo’yiga o’sishni ortiqcha tushuntirishga hojat yo’q. Lekin uning eng asosiy 2ta shartini aytib ketish kerak:
1. Bo’yiga o’sish davomida siz, albatta, odamlarni boshqarishga javobgar bo’lib borasiz. Qanchalik o’sgan sari javob beradigan odamlaringiz ham shunchalik ko’payadi
2. Yuqoriga o’sishda markazlashish majburiy bo’ladi. Ya’ni aytganimdek lavozimlar strukutrasi piramida, to’g’ri to’rtburchak emas. Shuning uchun ham oldinroq ham faqat “tepaga” deb ketdim “tepaga qarab markazga” emas.

Bulardan esa yana ba’zi xulosalar kelib chiqadi:
1. Tepaga qarab yurganingiz sari kenglik torayib, lavozimlar ahamiyati tenglashib boradi. Masalan, CFO, CTO, CIO, COO, CMO hammasi teng va CEO ga hisob beradi. CEOda esa solishtiradigan odamning o’zi yo’q :)
2. Yuqoriga qarab yurishni tanlasangiz, oxirgacha faqat yuqoriga qarab intilish yo’li qoladi xolos


Hali aytadigan gaplar ko'pku, lekin hozircha shu yerda to'xtagan ma'qul.

Xulosa va maslahat o'rnida esa

Eniga o'sish sharti — qattiq ko'nikmalar (hard skills) kuchayishi yoki tabiiy kuchli bo'lishi. Bo'yiga o'sishda esa yumshoq ko'nikmalar (soft skills) o'rni asosiy rolda. Qaysi tomonlama iste'dodingiz va qiziqishingiz baland ekaniga qarab o'sish yo'nalishini tanlash mumkin.

#career_life #engineering_life #postbase

P.S: Keyingi postda qattiq va yumshoq ko'nikmalar haqida batafsilroq yozaman

@Janob_Musayev

O'zgarishlar = Imkoniyatlar

Seshanba kuni ertalab (Amerika vaqti bilan) Microsoft global miqyosda 3% yoki aniqrog'i 6000 nafar ishchilarini bo'shatganini e'lon qildi. Bo'shatayotganini emas, aynan bo'shatganini.

Bizda u vaqtda ish vaqti deyarli tugab kun oxiridagi stendapga qatnashishni kutib turgandik. Hali emailni ochib ko'rmasdan turib yangilikni u yerda eshitdik.

Emailimda umumiy yangiliklardan boshqa menga bog'liq hech qanday alohida xabar bo'lmasa ham, baribir keyingi soatlar oson o'tmadi. Menejerimga jamoadagilar yaxshimi deb yozganimdan keyin menejerim o'zi va yana 2-3 ta jamoadoshim bo'shatilib ketganini xabar berdi. Butun karyerasi davomida - 23 yildan beri Microsoftda ishlab kelayotgan menejerim...

Balki bu dramatik eshitilishi mumkin, lekin holat qaysidir ma'noda jang maydonida yoningdagi safdoshlaring halok bo'lishini kuzatishga o'xshar ekan. Ichida bo'lmaguncha qanchalik jiddiy ekani his qilinmaydigan holat.

Jang maydoniga o'xshashi esa hech kimda omon qolish kafolati yo'qligida. Chunki bo'shatishlarda aniq bir formula ko'rmaysiz. Shunchaki tahminiy tanlashga o'xshaydi. Agar gap tajriba yoki ishchining qilgan ishi ahamiyati haqida bo'lganida Typescript veteran dasturchisi yoki umuman butun Typescript compiler jamoasi bo'shatilib yuborilmagan bo'lardi.

Odamlarga alam qiladigani bu yangilik Microsoft chorakni rekord darajadagi foyda va foyda marjasi bilan yopib, aksiya narxi uchib bergandan keyin sodir bo'lgani. Odamlar "Hammasi yaxshi. Xavotirga o'rin yo'q" deb o'ylab turgandi.

Menejerim ishdan ketgani yagona jiddiy o'zgarish bo'lmadi. Rahabariyat hozirgi ishlayotgan loyihamizni (deyarli) to'xtatishga va e'tiborni boshqa joylarga qaratishga qaror qilibdi. Loyihada ishlayotgan (yoki qolgan) 30-40 odam esa boshqa loyihalarga o'tkazildi.

Albatta, hayotimizdagi har bir o'zgarish biz uchun imkoniyat va sinov. O'zgarishlar sabab endi to'liq Irlandiyada joylashgan yangi jamoa va menejer bilan ishlayman. Darajamga yaqin dasturchilar ko'proq. Yanada yangi narsalarni o'rganish va o'sish uchun imkoniyat ko'proq.

Bizning qishloqda ana shunaqa gaplar... )

#microsoft_life

@Janob_Musayev

2020-22-yillar oralig'ida juda ko'plab odamlar Amazon va boshqa FAANG kompaniyalardan offer olib Irlandiyaga to'g'ridan-to'g'ri relokatsiya bilan kelgan.

Lekin hozirgi vaqtdagi raqobatni hisobga olgan holda FAANG chetdagi kimgadir offer berib relokatsiya qilishi uchun x10 emas x100 engineer bo'lishi kerak, menimcha.

O'qishga kelish sizga ish kafolatini bermaydi. Ko'pincha unda ham ish beruvchi sizning ish vizangizga sponsorlik qilishi kerak bo'ladi. Lekin o'sha davlatda turgan holatingizda va o'sha davlat ta'limini olgan holda suhbatga taklif olish imkoniyatingiz ancha balandroq, eng kamida amaliyot yoki bitiruvchi o'rinlarga.

#opinion

@Janob_Musayev

Biznes va Ijtimoiy siyosat farqi

Behzod aka Hoshimov bu gaplari bilan shaharda parkovka pulli bo'lishi — bu biznes qilish vositasi emasligini eslatyapti. Ya'ni bu yerda "Qancha ko'p xarid qilsangiz, shunchalik chegirma qilib beramiz" degan qarash bo'lmasligi kerak. Aksincha, bu narsa shaharda avtomobillarni kamaytirish uchun chora. Shuning uchun ham aynan teskari qoida ishlashi to'g'ri.

Biznes va siyosat bir xil emasligi, tadbirkorlardan (har doim ham) yaxshi siyosatchilar chiqmasligi va ayniqsa ikkalasini aralashtirib tashlamaslik bo'yicha juda yaxshi eslatma bo'libdi.

Shu birgina misol orqali biznes haqida ham, ijtimoiy siyosat haqida ham ozgina narsa o'rganish mumkin. Ajoyib!

#business_life

@Janob_Musayev

Dasturchilar uchun kamdan-kam eslanadigan, lekin "suv va havodek" kerak ko'nikmalar

5 yildan ortiq turli xil ko'lamdagi kompaniya va loyihalarda dasturchi sifatida ishlab quyidagi ko'nikmalar har qanday dasturchi uchun "suv va havodek" kerak ekani, lekin juda kam tilga olinishini tushundim.

1. Dasturni debug qila olish
Ustozim Yo'ldosh aka aytgandi "Yozgan kodini debug qilishni bilmaydigan dasturchi, dasturchi emas" deb. Debugging bu shunchaki qatorlar orasiga print() qo'yib chiqish emas, balki:
— Intellij, VS Code, Chrome DevTools yoki boshqa IDElar debuggerlaridan foydalana olish
— Dasturning kirish/boshlanish qismini bilish va kerakli joylarga breakpointlar qo'ya olish
— O'zgaruvchilarni, qiymatlarni kuzatish va kod bilan qadamma-qadam yura olish
— Yuqoridagi ishlarni murakkab tizimlarda amalga oshira olish

2. Git ziddiyatlarini hal qila olish
Bir o'zingiz ishlaydigan loyihada git commit, git push, git pull qilishdan osoni yo'q. Lekin yirik loyihalarda git bilan ishlash bu darajada oddiy emas
— Avvalo gitda branchlar bilan ishlash, gitflow qanday ishlashini tushunish
— Git merge vaqtida ikkala tomon o'zgarishlarini ham buzib qo'ymasdan saqlay olish
— Merge, Rebase, Squash Commitlar nima ekani va farqlarini bilish kerak

3. Loglarni tahlil qilish va monitoring
Birorta onlayn dars yoki kurslarda loglar bilan ishlash haqida ko'rganimni eslolmayman. Jiddiy loyihalarda esa bu narsa birlamchi darajada. Buning uchun
— Log yozish, uni qayerlarga va qanday shakllarda qo'yish
— Ishlanayotgan til yoki frameworkdagi asosiy loggin kutubxonlarini bilish va ulardan foydalana olish
— Grafana, Splunk, DataDog, ElasticSearch kabi monitoring vositalaridan loglarni kuzata olishni bilish kerak

4. Turli xil formatdagi API lar va soxta (mock) API lar bilan ishlash
Ichida 4-5 ta ma'lumot bo'lgan JSON formatdagi ochiq REST API bilan ishlash hammaga yoqadi, lekin real loyihalarda quyidagilarga yuzlashishingiz aniq
— Juda yirik, qavat-qavat va yuzlab obyektlarni o'z ichiga olgan APIlar
— Ma'lumotlarning XML, YAML, JSON ko'rinishidagi strukturalari va ularning biridan ikkinchisiga o'tish yoki ularni obyektlarga aylantirish (yoki teskarisi)
— Local ish yoki testlash uchun bu API larni soxtalashtirish (mock) va asosiy mock kutubxonalar bilan ishlash

5. Tezlik va resurslar tahlili (Performance Profiling)
Yozgan dasturingizni qancha traffik, bosim va ma'lumotlar hajmiga chiday olishini oldindan testlash uchun (O'zbekistondagi IT tizimlari eng asosiy muammolaridan) quyidagilarni bilish kerak:
— Qanday qilib stress test, load test, spike test... lar o'tkishni bilish
— Serverning qayeriga ko'proq bosim tushayotganini (CPU, RAM..) aniqlash
— Tiqilishlar qayerlarda va nima uchun yuz berayotganini aniqlash va shunga mos o'zgarish qilish (muammoni faqat yangi server qo'shish bilan hal qilmaslik)

Albatta, hali endigina birinchi ishini qidirayotgan yoki boshlagan yosh dasturchi bo'lsangiz, yuqoridagilarni o'ylab o'zingizni qo'rqitish kerak emas. Ammo ma'lum vaqt o'tib, darajangizni oshirish haqida o'ylash vaqti kelganda ular bilan tanishib qo'yish zarar qilmaydi.

Yana qaysi ko'nikmalarni yuqorida eslashga munosib deb o'ylaysiz?

#engineering_life #software_engineering #hard_skills

@Janob_Musayev

FAANG dasturchilari tez ishlay olmaydi... 🤔

Bir necha kun oldin Otabek kanalidan mana bu LinkedIn postga ko'zim tushib qoldi. Unga ko'ra FAANG dasturchilari startap muhiti uchun juda sekin ishlaydi, hamma narsani over engineering qilib tashlaydi, mukammal kodsiz yasholmaydi va blah blah blah deb yozilgan.

Yuqoridagi post FAANG kompaniyalari ichidagi holat qandayligidan zig'ircha xabari yo'q odam tomonidan yozilgani shubhasiz. Asosiy nuqtalar haqida qisqacha to'xtalsam.

Hamma narsa microservis emas
FAANG kompaniyalarida hamma loyihalar ham microservislar bilan, mukammal va zamonaviy arxitekturada qurilmaydi. Aksincha, juda ko'p servislar millionlab qator kod joylashgan monolit tizimlarda yotadi. Ayniqsa, eng mashhur servislar. Masalan, Microsoftda Office va Windows kodlari, Googleda ham asosiy servislar. Ularni build va run qilish uchun butun xonalarni egallagan serverlar kecha-kunduz ishlab yotadi.

Dedlaynlar juda zich
Yangi feature yoki mahsulotni ishga tushirishga odatda keragidan 2-3 baravar kam vaqt beriladi. Ko'p holatda dedlaynlar 3-4 qavat tepadan keladi. Ya'ni dasturchilarda ham, ularning menejerlarida ham bu borada fikr berish deyarli ilojsiz. Ayniqsa, hozirgi AI poygasi vasvasasi paytida. Lekin, albatta bu vaqtning uzog'i beshdan biri kod yozish uchun ketadi. Qolganimi? Sal keyinroq

Texnik qarzlar uyum-uyum bo'lib yotadi
Kodni yozib bo'lgandan keyin uni mukammalashtirish, 95% coverage bilan unit, integration, e2e test yozish uchun yana 2-3 hafta beriladi desangiz ham adashasiz. Balki qachondir va qaysidir jamoalarda shundaydir. Lekin aytganimdek hozirgi tentak poyga vaqtida hech kim qarashni ham xohlamaydigan uyum-uyum texnik qarzlar, testlarsiz loyihalar va featurelarni yetarlicha topish mumkin. Menejmentga ularni yopishdan yangi featureni testlab ko'rish muhimroq. Huddi startaplardagidek.

Kodlar (ba'zida) mukammallikka yaqin ham emas
Yuqoridagi gaplardan keyin bunisi tushunarli bo'lsa kerak. Loyihalarga juda tez-tez yangi dasturchilar qo'shilishi va tajribalilarini ham ogohlantirishsiz bo'shatib yuborishlari ma'lum bir standardagi kod sifatini ushlab turishni ilojsiz ham qilib qo'yadi.


Nega unda FAANG kompaniyalari sekin ishlaydi?

Javob oddiy – qochib bo'lmas byurokratiya sabab. Har qanday yangi mahsulot, hatto kichik o'zgarishli feature ham xavfsizlik, maxfiylik (privacy), accessibility va qonuniy muvofiqlik (legal compliance) tekshiruvlaridan o'tishi kerak. Kod yozishga haftalar yetarli bo'lsa ham, bular uchun oylab vaqt ketadi.

Startaplardan farqli tarzda millionlab foydalanuvchisi bo'lgan kompaniyalar bu tekshiruvlarga ko'z yumib ketolmaydi. Muammo chiqqan holatda ham qonun organlari ularni "Hali yoshda" deb ayamaydi va milliardlab jarimaga tortadi va brendga jiddiy ziyon yetadi.

Yuqoridagi postda tasvirlangan hamma narsa mukammal bo'lishini xohlaydigan, over engineering qilib yuboradigan va tez ishlolmaydigan dasturchilarni esa FAANG kompaniyalarida emas, yangi va kichik startaplardan ko'proq topish mumkin. Ayniqsa, katta tajribaga ega bo'lmagan dasturchi o'zi startap boshlagan holatlardan.

Balki men bilmagan boshqa katta kompaniyalarda holat boshqacharoqdir. Bilsangiz albatta izohlarda yozib qoldiring!

Eng asosiysi esa LinkedIndagi postlarga ishonib ketavermang.

#engineering_life #FAANG #startups

@Janob_Musayev

Hozirgi holatim...

@Janob_Musayev

Xohlagan savolingizni so'rang

Keyingi bir soat davomida izohlardagi savollarga javob berishga harakat qilaman. Savollaringiz bo'lsa so'rab oling.

Tugatdik.

#ask_me_anything

@Janob_Musayev