Hello world 🌏

Bugun sizlar bilan begonalardan qancha oylik olishini so'rash odob-axloqini o'rganamiz. Kettik!

Birinchi qoida: Hech qachon begonalarni qancha oylik olishini so'ramang!
Ikkinchi qoida: Birinchi qoidani ko'ring.

Nega begonalardan oyligini so'rab bo'lmaydi?

Qisqa javob: Odamlar oyliklariga qarab baholanishni xoxlashmaydi.

Uzun javob: Ikkita notanish odamlarni bir-biriga beradigan ilk savollari juda muhim hisoblanadi. Bir-ikki savoldan keyin oylikni so'rash bu juda katta red sign 🛑 Oylik so'rash degani siz o'sha odamni qancha oylik olishiga qarab muomala qilmoqchisiz.

Shaxsan mendan so'rashsa, o'sha joyda men va o'sha odam o'rtasidagi aloqa tugadi.

#Karyera #Career #SWECareer #CareerTips #Dasturlash #Programming #SoftwareEngineering #IT

Kelinglar tepadagi savolni sal o'zgartiramiz. Qanday qilib tanishlardan oyligini so'rasa bo'ladi?

Do'stlar va tanishlardan oyligini so'rasa bo'ladi. Lekin o'shanda ham aniq bir sabab bilan so'rash kerak va har doim "range"da so'rash kerak.

Masalan: "Salom Sardorbek. Men sizni kompaniyangizga ishga topshirmoqchi edim. Iloji bo'lsa meni darajamdagilarga qancha atrofida oylik berishini aytib berolasimi?"

Aytgancha, agar kompaniyalar qancha oylik berishini bilmoqchi bo'lsangiz levels.fyi va shunga o'xshash websitelardan foydalansangiz bo'ladi.

#Karyera #Career #SWECareer #CareerTips #Dasturlash #Programming #SoftwareEngineering #IT

Sherali Obidov aytib bergan bir voqea esga tushib ketdi.

Bir kuni taxida Sherali akadan bir odam oyligi so'rabdi. Sherali aka "500-600 olaman" desa, u odam "ha to'g'ri uzi shunaqa programistlar 500-600 ming so'm olishadi" deganmish 🤣

#StoryTime #DasturchiHikoyalari #Germany #Uzbekistan #Dasturlash #Programming #SoftwareEngineering #IT

#Coding #ComputerScience #CS #ProblemSolving #Dasturlash #Programming #SoftwareEngineering #IT #Memes #ProgrammingMemes

Opam Angular o'rganishni boshladi 😎

O'zim Angular 1.x versiyasidan ishlashni boshlaganman. Boshida men uchun Angular magicdek edi. Two-way data binding 🤯

— Biz proyektda test yozmaymiz.
— Nega?
— Chunki bizda bunga vaqt yo’q.
— Nega?
— Chunki shundoq ham ishimiz ko’p va katta bosimda ishlaymiz.
— Nega?
— Chunki ishimiz juda sekin siljidi.
— Nega?
— Chunki proyektdagi kodni o’zgartirish qiyin va havfli bo'lib qolgan.
— Nega?
— Chunki biz proyektda test yozmaymiz.

Source: Hassan Rezk Habib

#Coding #ComputerScience #CS #ProblemSolving #Dasturlash #Programming #SoftwareEngineering #IT

Hello world 🌍

Bugun sizlar bilan bus factor xaqida gaplashamiz. Bus factor bu avtobusni sizning proyektingizga tasiri. Tushunmadingizmi? 😛 Xop, aniqroq tushuntiraman 🙂

Sizni proyektingiz to’xtab qolishi uchun avtobus sizni komandangizdan nechta odamni urib yuborishi kerak? — shu narsa bus factor deyiladi. Albatta, avtobus urib yuborishi shart emas (bu xazil sifatida aytiladi). Ishdan birdaniga ketib qolsa, kasal bo’lib qolsa, to’yi bo'lib qolsa va hokazo. Juda sodda qilib tushuntirganda, agar juda ko’p narsa bir odamga bog’liq bo'lsa (business logic, code release, code review, DB migrations, va hokazo) bu kichik bus factor degani.

Bus factor qancha kichik bo’lsa shuncha yomon. Ideal xolatda sizni proyektingiz to'xtab qolishi uchun butun komandangiz avtobusda chorvoqqa ketayotib… 🙊

Xop, qanday qilib bus factorni kamaytirsa bo’ladi?
— dokumentatisiya
— TDD: unit, integration, va end-to-end testing
— Avtomatizatsiya: CI/CD pipelines
— Knowledge transfer sessiyalar
— Sog’lom kod reviewlar

Bu haqida ko’proq o’rganing: Medium

Bir paytlar Google Mapsda 5-10ta review yozgan edim. Onda-sonda shunday emaillar kelib turadi. Bu safar uzimni reviewimni o’qib kulibman 😅

FAANGga qaysi yo’nalish yaxshi?

Shu savolni mendan tez-tez so’rab turishadi. Men uchun bu savol sal g’alati tuyiladi. Har safar shu savolni eshitganimda ichimda bir narsa o’ladi.

Chunki hamma dasturlash yo’nalishi bilan FAANGga kirsa bo’ladi. Bunday kompaniyalar shunchalik kattaligidan deyarli hamma yo’nalish bo’yicha talantlarni ishga oladi. Men hozirgacha Googleda quyidagi xildagi dasturchilarni ko’rdim va hammalari muvaffaqiyatli ishlashyapti:
— Frontend Engineer
— Backend Engineer
— Embedded Engineer
— Gaming Engineer
— Security Engineer
— Android Engineer
— iOS Engineer
— QA Engineer
— QA Automation Engineer
— Site Reliability Engineer
— va hokazo

Yaxshiroq va foydaliroq savol: “XXX Engineer bo’lib qanday FAANGga ishga kirsa bo’ladi?”

Tushunaman nega yosh dasturchilar shu savolni berishadi. Befoyda narsa o’rganib yurmayin deb qo’rqishadi. Qo’rqmang, hamma bilimlarni o’rni bor va dasturlash soxasi ichida ekansiz bilimlaringiz befoydaga chiqib qolmaydi.

Qisqasi, lyubaya yo’nalish xarasha 🙂

#Google #Googler #FAANG #FAANGPrep #Interviews #InterviewPrep #ProblemSolving #Dasturlash #Programming #SoftwareEngineering #IT

Hello world 🌍

Kelinglar bugun Acceptance Criteria haqida gaplashamiz. Nega bugun? Chunki bugun shu mavzuga oid bir foydali artikl o’qidim 😁 Tushunishni eng yaxshi yo’li tushuntirish deganlaridek, bugun sizlarga Acceptance Criteria bo’yicha oz-moz bilimimni ulashaman. Kettik!

<1-qism>

Acceptance Criteria o’zi nima?

Acceptance Criteria bu bir featureni yakunlash uchun shartlar. U oddiy technical bilimga ega bo’lmagan odam uchun ham tushinarli tilda yoziladi va technical dunyo (Software Engineer, QA) va non-technical dunyoni (Project Manager, Project/Product Owner) bog’lab turadi. Shuning uchun ham Acceptance Criteria Software Developmentda muhim ro’l o’ynaydi.

Yaxshi Acceptance Criteria yangi featurelarni osonlik va o’z vaqtida yetkazib berishga yordam beradi. Yomon Acceptance Criteria esa yangi featurelarni yetkazib berishda qiyinchiliklar, xatoliklar, tushunmovchiliklar, kechikishlar va asab buzarchilikarga olib boradi.

Acceptance Criteria qanday yoziladi?

Acceptance criteria asosan Given.. When.. Then strukturasida yoziladi. “Talk is cheap, show me the code” deganlaridek, kelinglar bir-ikkita misollar keltiramiz.

Example A: Login with email and password.
Given: that user has already signed up
And: their account is active
When: they input their email and password correctly
And: click Login button
Then: they should be authenticated
And: navigated to the home page

Example B: Add product to cart without being logged in.
Given: that user is not logged in
And: is in product detail page
When: they click “Add to cart” button
Then: the button text changes to “Added to cart”
And: the button is disabled

Acceptance Criteria bilan oddiy feature descriptionni farqi nimada?

Formatdan tashqari boshqa katta farqi yo’q. Acceptance Criteria feature descriptionga qaraganda ancha batafsil bo’ladi.

</1-qism>

2-qism >>

<< 1-qism

<2-qism>

Software Engineerlar yaxshi Acceptance Criteria yozishni bilishlari kerakmi?

Ha, professional dasturchilar yaxshi Acceptance Criteria yoza olishi kerak.

Feature requestlar biznes tarafdan kelgani uchun asosan Acceptance Criteriani Product Owner va Project Managerlar yozishadi. Lekin sog’lom komandalarda Software Engineerlar ham bu jarayonda aktiv qatnashishadi. Shu orqali ko’p detallar oldindan kelishib olinadi va tushinmovchiliklarni oldi olinadi.

Bu jarayonda Software Engineerlar qatnashishi uchun yana bir sabab bor. Bu Test-Driven Development (TDD). Agar komanda TDD qilsa, Acceptance Criteriadagi har bir shart keyinchalik unit test yoki end-to-end testga tarjima qilinadi. Shu sababli Acceptance Criteriada dasturchilar qatnashishsa testlar yozish ossonlashadi.

Qanday qilib Acceptance Criteria yozish skillarini kuchaytirsa bo’ladi?

Albatta, ko’proq Acceptance Criteria yozishda qatnashish orqali. Tepadagi linkda ham bir talay maslahatlar berilgan — o’qib chiqing.

<2-qism/>

Sizni kompaniyangizda Acceptance Criteria yozish qanday o’tadi? Software Engineerlar ham qatnashishadimi?

Tepadagi postlarni bitta artiklga solib qo’ydim: https://vovopap.com/2023/02/25/acceptance-criteria-haqida.html

Sizni setupingiz 🖥️ qanday? Ulashamiz, kettik!

Men boshlab beraman:
- MacBook Pro Intel (personal)
- MacBook Pro M1 (work)
- 27inch Monitor
- 2 laptop stands
- Wide dining table
- Logitech MX Master 3 Mouse
- Logitech MX Keys with palm rest
- Airpods 2
- Pixel Airbuds Pro
- Autonomous Ergo chair
- Trash can
- and fresh air

#Coding #ComputerScience #CS #ProblemSolving #Dasturlash #Programming #SoftwareEngineering #IT

Ba'zi insonlar boshqalarni desk setupini ko'rib, o'zini sharoitidan xafa bo'lishi mumkin.
Lekin muhimi progress. Ba'zilar $5k lik setup bilan juda oz progress qilayotgan bo'lishi mumkin. Ba'zilar eng oddiy setup bilan ham ancha steady progress qilayotgan bo'lishi mumkin.

Karyerada va umuman olganda hayotda o’sish uchun eng muhim jihatlardan biri bu “Being Likable”. Yani yoqimli inson bo’lish. Yani siz bilan gaplashish, siz bilan ishlash, siz bilan muhokamalar qilish oson va yoqimli.

Shu paytgacha intervyularda biz hohlagan narsalarni hammasini bilmasa ham yoqimli inson bo’lsa, o’sha insonni o’tkazib yuborganmiz. Va teskarisi, hamma narsani bilsada, yoqimsiz inson bo’lsa, o’ylab o’tirmasdan yiqitganman.

Esimda bor Super Dispatchga bitta bola kelgandi. Savollarimizga juda zo’r javob bergan. Lekin juda ham yoqimsiz gaplar gapirgan. “Men sizlar ishlatadigan texnologiyalarni 5 yil oldin ham zo’r bilar edim. Yorvoraman. Nechi pul oylik berasizlar?” ga o’xshagan gaplarni qilgan. Bizga to’g’ri kelmaysiz deb jo’natvorgan edik.

Yoqimli bo’ling 🙃

Elon Muskni o'ng qo'li bilan uchrashdik 😎 Dilmuroddan dasxat olish esdan chiqibdi afsus 😅

Python o’rganyapman 👀

#Coding #ComputerScience #CS #ProblemSolving #Dasturlash #Programming #SoftwareEngineering #IT #Memes #ProgrammingMemes

Nega readable kod yozish kerak?

Chunki kod 1 marta yoziladi va ming marta o’qiladi. Deylik unreadable kod yozgani 5 minut vaqt ketadi va uni o’qib tushungani 5 minut ketadi. Va readable kod yozgani 30 minut vaqt ketadi va uni o’qib tushunishga 1 minut ketadi.

Kelinglar kodni 1 marta yozib va uni 1000 marta o’qishga qancha vaqt ketishini hisoblab ko’ramiz:
Unreadable: 1 x 5 + 1000 x 5 = 5005 minut
Readable: 1 x 30 + 1000 x 1 = 1030 minut

Readable kod yozish bu long-term thinking!

#Coding #ComputerScience #CS #ProblemSolving #Dasturlash #Programming #SoftwareEngineering #IT