Seniority darajalari

Men roadmap'larni qayta ishlab chiqish ustida ishlayapman — ularni kuzatib borish osonroq bo'lishi va yangi dasturchilarni cho'chitib yubormasligi uchun ko'nikmalarni seniority darajalariga qarab ajratyapman. Roadmap'lar faqat texnik bilimlar haqida bo'lgani uchun, bu masalaga yana bir bor to'xtalib, turli seniority role'lari haqida nima deb o'ylashim bo'yicha maqola yozish yaxshi fikr bo'ladi, deb o'yladim.

Men ko'plab tashkilotlar dasturchilarning seniority darajasini belgilashda ish tajribasi yillariga keragidan ortiq ahamiyat berishini ko'rganman. "Junior" deb atalgan, lekin Senior Developer'lar ishini bajarayotgan dasturchilarni ham, "Senior" deb atalishga ham munosib bo'lmagan "Lead" dasturchilarni ham ko'rganman. Dasturchining seniority darajasini faqat uning yoshi, ish tajribasi yillari yoki egallagan texnik bilimi bilan belgilab bo'lmaydi. Bu yerda boshqa omillar ham rol o'ynaydi — ularning ishga bo'lgan qarashi, hamkasblari bilan qanday muloqot qilishi va muammolarga qanday yondashishi. Quyida har bir seniority darajasi uchun ana shu uchta asosiy omilni batafsil muhokama qilamiz.

Turli seniority unvonlari

Turli tashkilotlarda seniority unvonlari turlicha bo'lishi mumkin, lekin ular asosan uch toifaga bo'linadi:

• Junior Developer
• Mid Level Developer
• Senior Developer

Junior Developer

Junior developer'lar odatda endigina o'qishni bitirgan bo'ladi va ularning sohada umuman tajribasi yo'q yoki juda kam bo'ladi. Ularning nafaqat kod yozish ko'nikmalari zaif, balki Junior developer'ni darhol fosh qiladigan yana bir nechta jihatlar ham bor:

• Ularning asosiy shiori — yechimga qanday erishilganiga unchalik e'tibor bermay, "ishlaydigan qilish". Ular uchun ishlaydigan dastur va yaxshi dastur bir xil narsa.
• Biror narsaga erishish uchun ularga odatda juda aniq va tuzilgan ko'rsatmalar kerak bo'ladi. Ular tunnel vision'dan aziyat chekadi, jamoaning samarali a'zosi bo'lishi uchun nazorat va doimiy yo'l-yo'riq talab qiladi.
• Junior dasturchilarning ko'pchiligi shunchaki o'z role'iga mos kelishga harakat qiladi va biror joyda tiqilib qolganda, hech bo'lmasa o'zi urinib ko'rish o'rniga ishni senior dasturchiga qoldirib ketishi mumkin.
• Ular kompaniyaning biznes tomonini bilmaydi, management/sales/marketing va boshqalar qanday fikrlashini tushunmaydi hamda biznes domenini bilib olish qancha qayta ishlash, behuda sarflangan kuch va oxirgi foydalanuvchining noroziligini oldini olishi mumkinligini anglamaydi.
• Over-engineering — jiddiy muammo, u ko'pincha mo'rtlik va bug'larga olib keladi.
• Ularga muammo berilganda, ular ko'pincha faqat joriy muammoni, ya'ni asosiy muammoni emas, balki uning alomatlarini tuzatishga harakat qiladi.
• Ularda "Somebody Else's Problem" xulq-atvorini sezishingiz mumkin.
• Dunning–Kruger effekti tufayli ular nimani yoki qanchalik ko'p narsani bilmasligini bilmaydi.
• Ular tashabbus ko'rsatmaydi va notanish codebase ustida ishlashdan qo'rqishi mumkin.
• Ular jamoaviy muhokamalarda qatnashmaydi.

Jamoada Junior developer bo'lish yomon narsa emas; siz endigina ish boshlayotganingiz uchun sizdan hamma narsani bilishingiz kutilmaydi. Biroq o'rganish, tajriba orttirish, "Junior" unvonida qotib qolmaslik va o'zingizni rivojlantirish — sizning mas'uliyatingiz. Quyida Junior developer'larga seniority zinapoyasidan yuqoriga ko'tarilishda yordam beradigan bir nechta maslahatlar keltirilgan:

• Har qanday muammoni yetarlicha uzoq ishlasangiz hal qilish mumkin. Agar Stack Overflow'da yoki GitHub'dagi issue'da javob bo'lmasa, taslim bo'lmang. Lead'ingizga "Bu mening qo'limdan kelmaydi" deyishdan ko'ra "Men tiqilib qoldim, lekin X, Y va Z'ni sinab ko'rdim. Biror yo'l-yo'riq bera olasizmi?" deyish ancha yaxshi.
• Ko'p kod o'qing — faqat o'zingiz ishlayotgan loyihalardagi kodni emas, balki reference/freymvork source code'ini, open-source kodni ham. Hamkasb dasturchilardan, balki Reddit'da ham, o'zingiz tanlagan til/vositalar uchun yaxshi open-source misollar haqida so'rang.
• Shaxsiy side-project'lar qiling, ularni odamlar bilan baham ko'ring, open-source hamjamiyatiga hissa qo'shing. Yordam so'rab odamlarga murojaat qiling. Hamjamiyatdan qancha qo'llab-quvvatlash olishingiz mumkinligidan hayron qolasiz. Taxminan 6 yil oldin GitHub'dagi birinchi open-source loyiham hali ham yodimda: u Google'ning Geocoding API'sidan berilgan manzil bo'yicha ma'lumotlarni olib keladigan kichik PHP script (kutubxona) edi. Codebase juda tartibsiz edi, unda hech qanday test, linter yoki sniffer, hech qanday CI yo'q edi, chunki o'sha paytda men bularning hech biri haqida bilmasdim. Qanday qilib ekanini bilmayman, lekin bir mehribon inson loyihani qandaydir yo'l bilan topib, uni fork qildi, refactoring qildi, "zamonaviylashtirdi", linting, code sniffing va CI qo'shdi hamda pull request ochdi. Bu bitta pull request menga shunchalik ko'p narsani o'rgatdiki, ularni o'zim hech qachon bunchalik tez o'rganmagan bo'lardim, chunki men hali kollejda o'qir, kichik xizmat ko'rsatish kompaniyasida ishlar va nima to'g'ri, nima noto'g'ri ekanini bilmay, kichik veb-saytlarni yolg'iz o'zim qilardim. GitHub'dagi bu bitta PR mening open-source bilan ilk tanishuvim bo'ldi va men hamma narsam uchun undan qarzdorman.
• "Somebody Else's Problem Field" deb ataladigan xulq-atvordan qoching.
• Hal qilish uchun muammo berilganda, alomatlarni tuzatish o'rniga uning root cause'ini aniqlashga va o'shani tuzatishga harakat qiling. Va yodda tuting: muammoni qayta yuzaga keltira olmaslik u hal qilinganini anglatmaydi. U nega yuzaga kelganini va nega endi yuzaga kelmayotganini tushunganingizda hal qilingan hisoblanadi.
• Sizdan oldin yozilgan kodni hurmat qiling. Codebase'dagi arxitektura yoki dizayn qarorlari haqida fikr bildirganda kechirimli bo'ling. Kod ko'pincha layoqatsizlikdan boshqa sabablarga ko'ra xunuk va g'alati bo'lishini tushuning. Legacy code bilan yashashni va u bilan muvaffaqiyatli ishlashni o'rganish — ajoyib ko'nikma. Hech qachon kimnidir ahmoq deb o'ylamang. Buning o'rniga, bu aqlli, yaxshi niyatli va tajribali odamlar hozir ahmoqona ko'rinayotgan qarorga qanday kelganini aniqlang. Meros qilib olingan legacy code'ga shikoyat qiluvchi emas, balki "imkoniyat tafakkuri" bilan yondashing.
• Biror narsani bilmaslik normal holat. Narsalarni oldindan bilmaganingiz uchun uyalishingiz shart emas. Ahmoqona savollar bo'lmaydi — samarali ishlashingizga imkon beradigan darajada xohlagancha savol bering.
• Egallab turgan lavozimingiz sizni cheklab qo'yishiga yo'l qo'ymang. O'zingizni rivojlantirish ustida ishlashda davom eting.
• Uy vazifangizni bajaring. Oldinda nima kutayotganini taxmin qiling. Jamoaviy muhokamalarda ishtirok eting. Hatto noto'g'ri bo'lsangiz ham, nimadir o'rganasiz.
• O'zingiz ishlayotgan domen haqida o'rganing. Mahsulotni oxirgi foydalanuvchi sifatida boshidan oxirigacha tushuning. Taxminlarga tayanmang, shubha tug'ilganda savol bering va narsalarga aniqlik kiriting.
• Samarali muloqot qilishni o'rganing — soft skill'lar muhim. Yaxshi email yozishni, ishingizni taqdim etishni, savollaringizni o'ylangan tarzda shakllantirishni o'rganing.
• Senior dasturchilar bilan birga o'tiring, ular qanday ishlashini kuzating, o'zingizga mentor toping. Hech kim hamma narsani biladigan odamni yoqtirmaydi. Ego'ingizni jilovlang va tajribali odamlardan saboq olishga yetarlicha kamtar bo'ling.
• "Ekspert"larning maslahatiga ko'r-ko'rona ergashmang, ularga biroz shubha bilan qarang.
• Agar sizdan biror ish uchun estimate berish so'ralsa, asosli baho berish uchun barcha tafsilotlarga ega bo'lmaguningizcha javob bermang. Agar bunga majbur bo'lsangiz, vazifa "bajarildi" deb belgilanishi uchun nima qilish kerakligi haqida qanchalik kam bilishingizga qarab, uni 2 baravar yoki undan ham ko'proq oshirib ayting.
• Debugger'dan foydalanishni o'rganishga vaqt ajrating. Debugger'lar yangi, hujjatlashtirilmagan yoki yomon hujjatlashtirilgan codebase'da harakatlanishda yoki g'alati muammolarni debug qilishda juda foydali.
• "Mening kompyuterimda ishlayapti" deyishdan saqlaning — ha, men buni ko'p eshitganman.
• Har qanday yetarli emaslik hissi yoki imposter syndrome'ni o'zingizni oldinga undash, ko'nikma va bilimlaringizni oshirish uchun energiyaga aylantirishga harakat qiling.

Mid Level Developers

Junior developer'lardan keyingi daraja — Mid Level developer'lar. Ular texnik jihatdan Junior developer'lardan kuchliroq va minimal nazorat bilan ishlay oladi. Senior darajasiga sakrash uchun ularda hali hal qilinishi kerak bo'lgan ba'zi muammolar bor.

O'rta darajadagi dasturchilar Junior developer'ga qaraganda malakaliroq. Ular o'zlarining eski codebase'idagi kamchiliklarni ko'ra boshlaydi. Ular bilim orttiradi, lekin navbatdagi tuzoqqa tushib qoladi, ya'ni narsalarni "to'g'ri yo'l bilan" qilishga urinib, ishni chalkashtirib yuboradi: masalan, shoshilinch abstraction'lar, Design Pattern'lardan haddan tashqari yoki keraksiz foydalanish — ular Junior developer'larga qaraganda yechimni tezroq taqdim eta olishi mumkin, lekin bu yechim uzoq muddatda sizni boshqa bir chuqur chalkashlikka olib kirishi mumkin. Nazoratsiz qolsa, ular "narsalarni to'g'ri qilish"ga urinib, ishning bajarilishini kechiktirishi mumkin. Ular qachon tradeoff qilish kerakligini bilmaydi va hali ham qachon dogmatik, qachon pragmatik bo'lish kerakligini bilmaydi. Ular o'z yechimiga osongina bog'lanib qolishi, uzoqni ko'ra olmasligi va feedback'ni qabul qila olmasligi mumkin.

Mid-level dasturchilar juda ko'p uchraydi. Ko'pchilik tashkilotlar ularni noto'g'ri ravishda "Senior Developer" deb ataydi. Biroq Senior Developer bo'lishi uchun ularga yana mentorlik kerak. Keyingi bo'limda senior dasturchining mas'uliyatlari va qanday qilib senior dasturchi bo'lishingiz mumkinligi tasvirlangan.

Senior Developers

Senior developer'lar — Mid-level developer'lardan keyingi daraja. Ular hech qanday nazoratsiz va kelajakda hech qanday muammo tug'dirmasdan ishni o'zlari bajara oladigan odamlardir. Ular yetukroq, o'tmishda ham yaxshi, ham yomon dasturlarni yetkazib berib tajriba orttirgan va bundan saboq olgan — ular qanday qilib pragmatik bo'lishni biladi. Quyida odatda Senior Developer'dan kutiladigan narsalar ro'yxati keltirilgan:

• O'tmishdagi tajribalari, qilgan xatolari, haddan tashqari murakkab yoki yetarlicha o'ylanmagan dizayndagi dasturlar sababli duch kelgan muammolari tufayli ular muammolarni oldindan ko'ra oladi va codebase yoki arxitekturaning yo'nalishini belgilay oladi.
• Ularda "Shiny-Toy" sindromi yo'q. Ular ishni bajarishda pragmatik. Kerak bo'lganda tradeoff qila oladi va nima uchun shunday qilayotganini biladi. Qayerda dogmatik, qayerda pragmatik bo'lish kerakligini biladi.
• Ular soha haqida yaxshi tasavvurga ega, ko'p hollarda ish uchun eng yaxshi vosita qaysi ekanini biladi (hatto o'sha vositani bilmasa ham). Ularda talab qiladigan muammoni hal qilish uchun yangi vosita/til/paradigma va hokazolarni o'zlashtirib olish bo'yicha tug'ma qobiliyat bor.
• Ular jamoada ekanini anglaydi. Boshqalarga mentorlik qilishni o'z mas'uliyatining bir qismi deb biladi. Bu junior dasturchilar bilan pair programming qilishdan tortib hujjat yoki test yozish kabi shon-shuhratsiz vazifalarni yoki bajarilishi kerak bo'lgan boshqa har qanday ishni o'z zimmasiga olishgacha bo'lishi mumkin.
• Ular domenni chuqur tushunadi — kompaniyaning biznes tomonini biladi, management/sales/marketing va boshqalar qanday fikrlashini anglaydi hamda dasturlash jarayonida biznes domeni haqidagi bilimlaridan foyda oladi.
• Ular quruq shikoyat qilmaydi, empirik dalillarga asoslanib xulosa chiqaradi va yechim bo'yicha takliflarga ega bo'ladi.
• Ular faqat koddan ancha kengroq fikrlaydi — ularning vazifasi shunchaki kod yozish emas, balki muammolarga yechim taqdim etish ekanini biladi.
• Ular katta, aniq belgilanmagan muammolarni o'z zimmasiga olish, ularni aniqlashtirish, bo'laklarga ajratish va bu bo'laklarni bajarish qobiliyatiga ega. Senior developer katta va mavhum narsani olib, uni oxiriga yetkaza oladi. Ular bir nechta variantni o'ylab topadi, jamoa bilan muhokama qiladi va ularni amalga oshiradi.
• Ular o'zlaridan oldin yozilgan kodni hurmat qiladi. Codebase'dagi arxitektura yoki dizayn qarorlari haqida fikr bildirganda kechirimli bo'ladi. Meros qilib olingan legacy code'ga shikoyat qiluvchi emas, balki "imkoniyat tafakkuri" bilan yondashadi.
• Ular hech kimni ranjitmasdan feedback berishni biladi.

Xulosa

Barcha jamoalar ushbu seniority role'larining aralashmasidan tashkil topadi. O'z role'ingizdan qanoatlanib qolish — yomon narsa, siz har doim keyingi bosqichga chiqish uchun o'zingizni rivojlantirishga intilishingiz kerak. Ushbu maqola mening sohadagi e'tiqodlarim va kuzatuvlarimga asoslangan. Ko'plab kompaniyalar seniority darajasini belgilashda ish tajribasi yillariga ko'proq e'tibor beradi, bu esa juda yomon metrika — tajriba shunchaki yillar o'tkazish bilan orttirilmaydi. Uni sohada qancha yil o'tkazganingizdan qat'i nazar, turli xil muammolarni doimiy ravishda hal qilish orqali orttirasiz. Men sohada hech qanday tajribasi bo'lmagan yangi bitiruvchilarning tezda o'sib, Senior Engineer darajasidagi ishni qilayotganini ham, faqat yoshi va "ish tajribasi yillari" tufayli "senior" deb atalgan Senior developer'larni ham ko'rganman.

Karyerangizda yuqoriga ko'tarilish uchun sizda bo'lishi kerak bo'lgan eng muhim fazilatlar: o'rtamiyonalik bilan kifoyalanmaslik, ochiq fikrli bo'lish, kamtarlik, o'z xatolaringizdan saboq olish, qiyin muammolar ustida ishlash va shikoyat qiluvchi emas, balki imkoniyat tafakkuriga ega bo'lish.

Shu bilan ushbu post o'z nihoyasiga yetdi. Dasturchilarning seniority darajalari haqida qanday fikrdasiz? Ushbu qo'llanmani yaxshilash bo'yicha takliflaringizni bemalol yuboring. Keyingi safargacha, biz bilan qoling!