Shunaqasi ham bo'lib turadi

Motivatsiya < Intizom
[chaqmoq izidan yurmang]

Shu kunlarda g‘ayratlantirish (motivatsiya) kurslari juda ko‘payib ketdi. Boshida foydali ko‘rindi. Vaqt o‘tib, hammasi yuzaga chiqa boshladi.

Biz bizga buyurilgan intizomni tark etdik. Bu Motivatorlarni ko‘payishiga olib keldi.

Motivatsiya chaqmoqqa o‘xshaydi – u birdaniga paydo bo‘ladi, ko‘p energiya beradi va hamma narsani yoritadi. Lekin u bir zumda o‘tib ketadi va ortidan yana qorong‘ulik qoladi. Intizom esa shamga o‘xshaydi – uning nuri kuchli bo‘lmasligi mumkin, lekin u tinmay yonadi. U sizni uzoq muddatli yo‘lingizda doimiy ravishda olg‘a boshlaydi. Sizga bir lahzalik porlash kerakmi yoki uzoq muddatli yorug‘lik?

“Phoenix project” kitobida yangi CTO xatolarini o‘rganish uchun mutaxassisga boradi. Fikrlar orasida shu fikr ham bor edi:

Tadqiqotlar shuni ko‘rsatdi-ki, kuniga 5 daqiqa shug‘ullanish haftada bir 3 soat shug‘ullanishdan yaxshiroq.

Nega?
Chunki intizom kichik, doimiy qadamlardan iborat. Aynan shu kichik harakatlar, kichik g‘alabalar bizga maqsadimizga yetishish uchun barqaror zamin yaratadi. G‘arbdagi ko‘plab muvaffaqiyatli insonlar aynan shu tamoyilga amal qilishadi: ular hasharlar uyushtirmaydi, ular har kuni oz-ozdan o‘z vazifalarini bajarib borishadi.

Niyatim kimnidir tanqid qilish emas.

Niyatim - esdan chiqib borayotgan intizomimizni qayta tiklashga chaqirish.

Shunday ekan, o‘zimizga bir savol beraylik: bizga bir lahzalik chaqmoq kerakmi yoki hayotimizni nurga to‘ldiruvchi doimiy sham?

03.09.2025 London
@DrAlgorith

Professional "Yo‘q" deyish

Bilarmidingiz? Rahbaringiz aslida sizdan "Yo‘q" deyishingizni kutadi.

Har bir rahbar o‘z jamoasida "labbaychi", har bir topshiriqqa "xo‘p bo‘ladi" deydigan, savol bermasdan ishga kirishib ketadigan xodimlarni yoqtiradi, - deb o‘ylashadi. Yuzaki qaraganda shunday: kamroq muhokama, tezroq ishga kirishish. Lekin bu muvaffaqiyatsizlikka olib boradi.

Kitobda qiziq gap o‘qib qoldim. Erik ismli qahramon aytgan gapi bor, bu gap har bir rahbar ish stoliga yozib qo‘yishiga arziydi:

"Albatta, siz "Yo‘q" deyishingiz mumkin. Biz sizga fikrlashingiz uchun haq to‘laymiz, shunchaki ishni bajarish uchun emas."

"Of course you can say No. We pay you to think, not to do."


Nima uchun "Ha, xo‘p bo‘ladi"chi xodimlar xavfli?

Tasavvur qiling, men jamoaga yangi bir loyiha ustida ishlashni topshirdim. Dasturchi hech qanday savol bermasdan, darhol kod yozishni boshladi. Ikki haftadan so‘ng u ishni tugatdi. Ammo keyin ma’lum bo‘ladiki:

1. Bu ish boshqa bir modul bilan ziddiyat hosil qilgan.

2. Loyihani yaratishda qo‘llanilgan yondashuv kelajakda katta "texnik qarz" (technical debt) qoldirgan.

3. Aslida, bundan ancha samaraliroq va tezroq yechim mavjud edi, lekin hech kim bu haqda o‘ylab ko‘rmagan.

Natijada nima bo‘ldi?

Vaqt, pul va eng asosiysi - jamoaning ishtiyoqi behuda sarflandi. Agar o‘sha dasturchi yoki jamoa boshida "Yo‘q, bu yondashuv to‘g‘ri emas, chunki..." deb aytganida, biz bu isrofgarchilikning oldini olgan bo‘lardik.

Qanday qilib to‘g‘ri "Yo‘q" deyish mumkin?

"Yo‘q" deyish – bu qo‘pollik yoki bo‘ysunmaslik emas. Bu – professional mas’uliyat. Muhimi, buni to‘g‘ri yetkazib bera olish.

1. "Yo‘q, chunki..." formulasidan foydalaning.
Shunchaki "yo‘q, qilolmayman" demang. Sababini aniq va raqamlarga asoslanib tushuntiring.

Salbiy: "Yo‘q, bu vazifani bugun qila olmayman."

Ijobiy: "Yo‘q, bu vazifani bugun bajara olmayman, chunki hozirda men A loyihasining muhim qismi ustida ishlayapman. Agar chalg‘isam, ertangi reliz kechikishi mumkin. Bu esa korxonamiz uchun X miqdorida zarar keltirishi ehtimoli bor."

2. Muqobil yechim taklif qiling.
Siz muammoning bir qismi emas, yechimning bir qismi ekanligingizni ko‘rsating.

Salbiy: "Bu funksiyani ikki kunda qo‘shib bo‘lmaydi."

Ijobiy: "Bu funksiyani to‘liq hajmda ikki kunda qo‘shishning imkoni yo‘q. Lekin, biz eng muhim qismini (MVP) ertaga tayyor qilib berishimiz mumkin. Yoki, agar bizga to‘rt kun vaqt berilsa, uni barcha testlardan o‘tkazib, barqaror versiyasini taqdim etamiz. Qaysi biri biz uchun hozir muhimroq?"

3. Ustuvorliklarni (prioritetlarni) aniqlashtiring.

Ba’zida rahbariyat (yoki buyurtmachi) barcha vazifalar birdek muhim deb o‘ylaydi. Sizning vazifangiz - ularga haqiqiy vaziyatni ko‘rsatish.

Savol bering: "Tushundim, bu juda muhim. Hozir men ishlayotgan A va B vazifalar bilan solishtirganda, bu yangi topshiriqning ustuvorligi qanday? Agar buni boshlasam, qaysi birini kechiktirsam bo‘ladi?"


Xulosa

Sizning ishingiz – shunchaki kod yozish, dizayn chizish yoki jadval to‘ldirish emas. Sizning ishingiz - korxonaning umumiy maqsadiga erishish uchun o‘z tajribangiz va aqlingizni ishlatishdir.

Buning ichiga xavflarni oldindan ko‘ra bilish, noto‘g‘ri qarorlarni shubha ostiga olish va yaxshiroq yo‘llarni taklif qilish ham kiradi.

Agar sizga biror vazifa berilsa, bir zum to‘xtang. O‘zingizga savol bering:
* Bu vazifaning asl maqsadi nima?
* Nima uchun aynan shu yo‘l tanlandi?
* Bundan yaxshiroq, tezroq yoki arzonroq yechim yo‘qmi?
* Bu ish kelajakda qanday muammolarga olib kelishi mumkin?

Agar javoblaringiz sizni qoniqtirmasa, o‘z fikringizni aytishdan qo‘rqmang. Asosli dalillar bilan aytilgan "Yo‘q" — bu korxonaga qilingan eng katta yaxshilikdir.

Unutmang, siz shunchaki klaviaturani bosishingiz yoki qog‘ozlarni to‘ldirishingiz uchun oylik olmaysiz. Siz tajribangiz, bilimingiz va eng muhimi - fikrlash qobiliyatingiz uchun haq olasiz.

Shunday ekan, keyingi safar topshiriq olganingizda, o‘ylang.
Agar kerak bo‘lsa, o‘z professional lug‘atingizdagi eng qudratli so‘zni ishlating: "Yo‘q, chunki..."

10.09.2025 London
@DrAlgorithm

StartUp va yoshlar

O‘zbekistonda StartUp qilayotgan yoshlar ko‘paygan. Bu juda yaxshi holat. O‘zining shaxsiy tijorati (biznesi) bo‘lishi juda zo‘r.

Yoshlarimiz tirishqoq, qiyinchilikdan qo‘rqmaydi, ishini oxiriga yetkazishga harakat qiladi. Bu xislatlar hammada ham bor emas. Bersang yeyman, bermasang o‘laman - kayfiyatidan chiqib olganimiz quvonarli holat.

Ammo bitta "Lekin"imiz bor.

StartUp qilish qoidalari va talablari bor. Buni ko‘pgina markazlar o‘rgatib kelmoqda. Masalan, StartUp Garage. Yangi boshlayotganlarga yo‘l xaritasi (Roadmap) berib, har bir bosqichni tushuntirib kelishmoqda. Bu fundamental bilim va busiz ish yurishi qiyin.

Hatto yaqinda StartUp Garage o‘zining yopiq eco-tizimini hamma uchun ochdi (Founders Community). Endi hamma tekinga a’zo bo‘lishi mumkin. StartUp asoslarini o‘rganishi, tanish-bilish orttirishi mumkin.

Meni o‘ylantirgan narsa esa, yoshlarning ish yuritishi.

O‘zini CEO deb bilgan StartUpchilar, g‘oyadan boshqa ish qilmagan. Menga ham ko‘p yozishadi. 2-3 asoschi bilan suhbat qilib koʻrdim, gaplari qiziq:

- Oka, manga CTO kerak-de.
- Nima uchun?
- Shu man o‘ylagan narsani yasab beradi. Hammasini o‘zi boshqaradi. TZ yozishdan bozorga kirishgacha qilib beradi.

Yoki:
- CTO misiz? Manga CTO kerak. Kompyuterga aloqador loyiha o‘ylaganman. Shuni qilib berish kerak.

G‘oya borligi yaxshi, g‘oya hammada bor.

Shu g‘oyani tushuntirib bera olish, uni amalga oshirish uchun qadamlarni yozib chiqish, shu qadamlarni bajarish uchun harakatni boshlash, har kuni g‘oyani loyihaga aylantirish ustida ishlash hammaning ham qo‘lidan kelmas ekan.

Hurmatli StartUp asoschilari:

- Agar StartUpʼingiz hali g‘oya shaklida bo‘lsa, iltimos, StartUp qurish asoslarini o‘rganing.

- IT mutaxassisi qilib beradi, men shuni ustida biznes qilaman, - degan fikrdan qayting.

- G‘oyamni yasayman, sarmoya (investitsiya) olaman va sotaman, - deb kichik fikrlamang.

G‘oya bormi? BIror muammoni hal qiladimi? Raqobat qila olasizmi? Ko‘lami katta emasmi? Tez bozorga kira olasizmi? O‘zi umuman bozorga kirish imkoni bormi?

kabi savollarga javob topib qo‘ying.

Nazariy asosini bilmasdan ish boshlasangiz 90/10 ning 90 tomonida bo‘lib qolasiz.

StartUp boshlaganingiz zo‘r, to‘xtamang. Parallel nazariy tomonini ham o‘rganing. Biz sizga yordam beramiz. Faqat savollar va taqdimot (pitch)ga yaxshi tayyorlaning. Vaqtni nazorat qiling.

Foydali va asosli StartUpʼlarimiz koʻpayvursin!

15.09.2025 London
@DrAlgorithm

Assalomu alaykum.
Mazza qilib Shaytanatni Juma kuni tugatdim. Oʻziyam 10 iyuldan beri oʻqibman. Aybga buyurmisizlar. Zoʻr yozilganiga koʻp ishlarim qolib ketdi. Bu kanal ham huvillab qoldi.
Miyya ochilganiga Shanba kuni oʻtirib bir project boshladim. MongoDB + EFCore da. Qiziq boʻlsa githubda boʻlishaman )

https://github.com/mirzaevaziz/modest
Ancha randalab qo'ydim

Qahva (kofe) - halolmi?

Qahva ajoyib narsa. Ishing tushmasa, maza qilib xotirjam yurasan. Lekin u bilan tanishsang va ayniqsa yaqin o‘rtoq bo‘lib qolsang, bo‘ldi, kunda bir necha bor hayoling u bilan band bo‘ladi.

Gemini bilan qahva haqida gaplashib qoldim. Qiziq narsalar bilib oldim.

O‘zimizcha "Coffee shop"ga chiqib kelaylik deymiz. Aslida Qahva chiqqan vaqtda "qahvaxona" atamasi chiqqan ekan (1500 yillar).

Ilk qahva 9 asrda Efiopiyada ixtiro qilingan ekan.

15 asrlarda Yamanda qahvani yetishtirish va sotishni boshlashgan. Bu esa Arablar diyorida qahvaning keng tarqalishiga sabab bo‘lgan. Ilk "Qahvaxona"lar ham o‘sha davrda ochilgan ekan. Bu davrlarda So‘fiylar tungi ibodatda qoim turish uchun, uhlab qolmaslik uchun iste’mol qilishgan ekan.

1511 yilda qahva Makkada harom qilinadi. 1524 yilga kelib, Usmonli sultoni Sulton Sulaymon I davrida, bosh Mufti Mehmed Ebüssuûd Efendi (al-İmadi) fatvosi bilan halol qilinadi.

16 asrda qahva Eron, Misr, Suriya va Turkiyaga tarqagan.

17 asrga kelib qahva Ovrupo davlatlarida ham keng tarqala boshlagan. Londonda 300 ta qahvaxona bo‘lgan ekan. Qiziq narsa aytaymi?

Hozirgi Co-working markazlarining vazifasini 17 asrda Qahvaxonalar bajargan ekan.

G‘oya egalari, san’at egalari, tadbirkorlar va boshqa turli soha odamlarini birlashtirish va yangi loyihalarni muhokama qilish uchun joy bo‘lgan ekan.

Ba’zi qiziq faktlar:

1. Qahva donalarini ko‘pchilik meva deb o‘ylasa kerak. Aslida esa u qahva daraxti mevasining danagi ekan.
2. "Mocha" qahvasi. Mocha so‘zi Yamandagi Moxa portning nomi bo‘lgan.
3. 1675 yilda Angliya qiroli Karl II qahvaxonalarni taqiqlagan.
4. Qahva so‘zi arabcha vino so‘zidan olingan, - deyiladi.
5. Qahvada 1,500 ta ta’m bor ekan. Vinoda esa 200 ta.

Coffee (en) <- kaffei (dk) <- kahve (tr) <- qahva (ar).

Qahvasiz o‘zingizni yaxshi his qilsangiz, ichmasdan yurganingiz ma’qul. Qahvaga o‘rgangan bo‘lsangiz, 18:00dan keyin ichmang.

Salomat bo‘ling

Rasm: Mahalladagi qahvaxonada rasmga oldim. Yozilgan yozuvi yoqdi.
- Yetarli qahva bilan dunyoni boshqarar edim.

22.09.2025 London
@DrAlgorithm

Xozirch Integration testlarini yozib bo'ldim.
Bugun bitta muammo chiqdi. Mongodbda auto transaction by default ishlamasakan. Misol db contextga 1 dan ko'p entity change qilinsa xato beryapti.
Xozircha Database.AutoTransactionBehavior = AutoTransactionBehavior.Never; qilib qo'ydim.
Yana vaqt bo'lganda shuni chuqurroq tahlil qilib ko'raman.
Tuningiz haytli bo'lsin!

This setting (Database.AutoTransactionBehavior = AutoTransactionBehavior.Never) in EF Core when working with MongoDB (or any non-transactional provider) is not just a toggle — it has important caveats. Let’s go deep into what this means, why it exists, and the potential issues you should watch out for.

⸻

🔎 What AutoTransactionBehavior Does

In EF Core (SQL providers like SQL Server, PostgreSQL, etc.):
• By default, SaveChanges wraps your operations inside a transaction if one isn’t already active.
• This ensures atomicity: either all changes succeed, or none are committed.

MongoDB is different:
• MongoDB doesn’t use EF’s transaction system natively.
• Transactions exist in MongoDB only for replica sets and sharded clusters (introduced in MongoDB 4.0), and even then EF Core providers may not fully integrate with them.
• So the EF Core MongoDB provider often disables transaction wrapping by default or allows you to set this explicitly.

⸻

⚠️ Potential Issues When Using AutoTransactionBehavior.Never

1. Loss of Atomicity
• SQL DB: if you call SaveChanges on 5 entities and the 3rd insert fails → all inserts roll back.
• MongoDB + Never: each document is sent individually; if the 3rd fails → the first 2 stay written.
👉 This leaves your DB in a partially saved state, inconsistent with your domain model.

⸻

2. Concurrency Issues
• Without a transaction, if multiple processes/threads update related documents at the same time, you can get:
• Lost updates (last writer wins).
• Race conditions (e.g., two services decrementing stock, both reading the same old value, then writing incorrect new values).
• Normally EF Core’s transaction would serialize this, but Never disables that safeguard.

⸻

3. Cross-Collection Inconsistencies
• Example: You create an Order and related OrderItems.
• With Never, if Order inserts succeed but OrderItems fail → orphaned data.
• MongoDB doesn’t enforce foreign keys, so cleanup is manual.

⸻

4. No Retry on Failure
• SQL providers + EF Core transactions can be retried as a unit if transient errors occur.
• With Never, MongoDB inserts/updates might fail in the middle, requiring you to implement your own retry + compensation logic.

⸻

5. Eventual Consistency Surprises
• If your app logic assumes that after SaveChanges the DB is in a valid, fully persisted state, that assumption is broken.
• For example:
• Service A: Saves Product and Inventory documents.
• Service B: Immediately queries both.
If Inventory failed to persist, Service B sees half-saved state.

⸻

6. Harder Unit of Work Semantics
• EF Core’s DbContext is supposed to represent a unit of work.
• With Never, SaveChanges no longer guarantees atomic unit-of-work behavior.
• That undermines the DDD principle of aggregate consistency.

⸻

7. Provider-Specific Transaction Support Gaps
• MongoDB does support multi-document transactions on replica sets/shards, but:
• Not all EF Core MongoDB providers implement them.
• If they do, you must use AutoTransactionBehavior.WhenNeeded or explicit BeginTransaction().
👉 By forcing Never, you guarantee transactions are never used, even where they are possible.

⸻

8. Debugging & Error Recovery Complexity
• Example: A batch update fails mid-way.
• With transactions, you know nothing changed → just retry.
• With Never, you must:
1. Detect which documents succeeded.
2. Roll back manually or compensate forward.
3. Handle side effects (like external events fired for already-saved docs).

⸻

✅ When is Never Safe/Useful?

You might want this if:
• Your operations are idempotent (safe to repeat).
• Each document is independent (no strong relationships).
• You rely on MongoDB’s natural eventual consistency model.
• Performance matters more than strict atomicity (skipping transactions can be faster).

⸻

🧩 Best Practices if You Must Use Never
1. Design for Idempotency
E.g., if inserting PaymentHistory, use natural/document IDs that prevent duplicates if retried.
2. Apply Outbox Pattern for event publishing so half-saved states don’t fire inconsistent domain events.
3.

Use Compensating Actions: If Order fails, delete any saved OrderItems, or mark Order as “incomplete.”
4. Limit SaveChanges Scope: Save only one aggregate root per SaveChanges call to reduce risk.
5. Enable Application-Level Transactions: Wrap SaveChanges in custom logic that ensures consistency across documents.

⸻

🔑 Bottom Line

Setting Database.AutoTransactionBehavior = AutoTransactionBehavior.Never in EF Core MongoDB:
• Removes EF’s guarantee of atomicity.
• Exposes you to partial saves, race conditions, and inconsistencies.
• Makes you responsible for implementing consistency, rollback, and retry logic manually.
• Only safe if your model and operations are naturally idempotent or single-document focused.

EPAMning Maxtumqulidagi ofisiga anchadan beri kelmaganakanman. Joylashgunimcha 15 minut ketti ))))