
Biztosan megfigyelted már, hogy kétféle ember létezik a tömegben. Az egyik típus azonnal kiszúrja az ismerős arcot, még akkor is, ha százan mennek körülötte. Folyamatosan szkenneli a környezetét: arcokat, mozdulatokat az apró változásokat. Rengeteg mikrodöntést hoz minden percben, mintha egy háttérfolyamat futna benne, ami sosem áll le.
A másik típus teljesen másképp működik. Egyszerűen csak megy előre, Safe mode-ban. Nem figyeli az arcokat, nem szelektálja a környezetét, számára csak az számít, hogy eljusson A-ból B-be. Nála minden „hardcode defaults” - előre beégetett rutinok, minimális döntés.
Mindkét stratégia működőképes, de más árat fizetünk érte. Az első típus rengeteg energiát éget el a folyamatos feldolgozásra, a második viszont spórol az erőforrásokkal, de közben sok mindent nem vesz észre.
Stack Overflow a fejben: miért kezdünk 18:00 után lefagyni, és miért érdemes „hardcode-olni” az életet - előre rögzíteni, beégetni döntéseket, hogy ne kelljen minden alkalommal újra lefuttatni a scriptet?
Volt egy terved: este leülsz a saját projektedhez, kicsit tapogatod a Rustot, vagy végre befejezed azt az átkozott x.y. doksit. De a valóság viszont máshogy néz ki. Ott állsz a nyitott hűtő előtt. Ott van egy meggyes és áfonyás joghurt, bámulod őket 20 másodpercig. És nem tudsz dönteni.
Napközben az agyad microservice-architektúrát rajzolt újra, race conditiont fixelt multithread környezetben, és az ügyfél költségvetésével zsonglőrködött százezres vagy milliós összegekben. Egy egyszerű (300 forintos) döntésen viszont lefagyott.
Végül csinálsz egy szendvicset, ledőlsz a kanapéra, és fél órán át scrollozol valamit, képtelen vagy rákattintani bármire is. Úgy érzed magad, mint egy zöldség.
Hirdetés
Spoiler: nem lettél hülyébb - egyszerűen a CPU-d Thermal Throttling módba kapcsolt. Üdv a Decision Fatigue (döntési kimerültség) világában. Nézzük meg ezt architekturális szemmel, és próbáljunk rátolni egy hotfixet.
A probléma architektúrája: core resource depletion (vagyis a figyelem, az energia és a döntési képesség kimerülése)
Hogy megértsük a biológiai hardverünket, miért nem bírunk el estére az egyszerű feladatokkal sem, bele kell nézni a dokumentációba.
A pszichológiában ezt az „ego kimerülése” jelenségnek nevezik, Roy Baumeister elmélete alapján. A lényege egyszerű: az akaraterő és a döntéshozatali képesség véges erőforrás, mint egy akkumulátor töltöttsége vagy a glükózszint.
A crash neurofiziológiája
A döntésekért és az önkontrollért a prefrontális kéreg felel. Ez az agy egyik legenergiaigényesebb része - a „GPU-nk”, ami a legjobban melegszik.
Talán az ember egyik leggyengébb architekturális pontja az, hogy a tranzakció costja a prefrontális kéreg számára szinte független a feladat méretétől. Amikor A vagy B joghurt között választasz, az agynak le kell futtatnia egy nehéz scriptet:
1. Future A (meggy íz)
2. Future B (áfonya íz)
3. Inhibition: ne kapd fel az elsőt
4. Összehasonlítani, majd commitolni a döntést.
Ez egy elég aktív és nehéz munka a neuronok számára. A „Vegyek-e házat?” döntés több stresszt (kortizolt) okoz, de maga a mechanika - opciók összevetése és impulzusok gátlása - mindkét esetben ugyanúgy égeti a glükózt és a neurotranszmittereket.
• DB scalability fix: –1 credit
• Kék vagy fekete póló?: −1 kredit
• Emoji válasz chatben: −1 kredit
A rendszer nem fontosság alapján von le erőforrást, hanem pusztán attól, hogy meghívod a Make_Decision() (hozz döntést) függvényt.
Memory leak
18:00-ra több száz (ezer) mikro-döntést hoztál. Ignoráltál push értesítéseket (döntés: „nem olvasom”), tracket választottál Spotifyon, eldöntötted, hogy átteszel-e egy taskot Jirában, kitaláltad, mit válaszolj egy kollégádnak. A Daily Decision_Limit számláló 0-t mutat.
És ekkor próbálod elindítani a nehéz alkalmazást: „Rust tanulás” vagy egy „empatikus beszélgetés”.
A rendszer válasza: FATAL ERROR: INSUFFICIENT RESOURCES
A prefrontális kéreg (a belső CEO) lekapcsol hűtés miatt. Az irányítást átveszi a Safe Mode - a bazális ganglionok (ősagy). Ennek a módnak nagyon limitált a scriptkészlete:
• Eat_Sugar() - gyors glükóz / azonnali energia
• Scroll_Feed() - dopamin-shot (like, új poszt, kép, kis meglepetés, retró rádió, tik-tok, csipsz, ropi, mini izgalom-új üzenet stb )
• Sleep() - energiatakarékos mód
Nem vagy lusta, csak mentálisan dehidratált lettél. Olyan, mintha megpróbálnád a STALKER 2-t egy i3-on.
Patch: Hardcode & Cache
Mit csinálnak a top mérnökök és vállalkozók? Csökkentik a DB-hívások számát. Hardcode-olják a rutint.

Mit csinálnak a top mérnökök és vállalkozók? Csökkentik a DB-hívások számát. Hardcode-olják a rutint.
Steve Jobs fekete garbójára vagy Mark Zuckerberg szürke pólói? Sokan ezt „ízléstelenségnek” vagy furcsaságnak tartják. Valójában ez brutális optimalizáció.
„A lehető legkevesebb döntést akarom meghozni az életemben… kivéve azt, hogyan szolgáljam a közösséget a lehető legjobban” - mondta Zuckerberg.
Reggel nem futtatnak egy drága queryt: SELECT * FROM Wardrobe WHERE style matches mood...
Hanem pre-compiled asseteket használnak. Ott van az egyenruha. A döntés egyszer megszületett, és be van hardcode-olva.
Nyereség: napi 10–20 kredit, amit üzletre lehet költeni.
Ha nagy dolgokra akarod használni a CPU-t, a hétköznapokat át kell rakni „Decision” módból „Script” módba.
Mérnöki optimalizációs algoritmus
Tehát Hardcode Defaults és a Batch Processing (kötegelt feldolgozás) protokollokat használunk. Íme 4 feature, amit már holnap deployolhatsz az életedbe, hogy ne legyen fagyiverziós az estéd.
1. Kaja configból (Default Config)
Napi három ételválasztás minimum 50 kredit elégetése. Étterem, étel, vacillálás, fizetés, várakozás.
Megoldás: hardcode-olt reggeli (és ha lehet, ebéd).
Reggeli: Zabkása bogyós gyümölccsel / rántotta. Pont.
Nem állsz a hűtő előtt azzal, hogy „mihez lenne kedvem?”.
Egyszerűen lefuttatod a breakfast.sh-t.
Eredmény: zero-latency start. A fejed a nap tervezésére marad, nem a menüre.
2. „Második polc” szabály (No-SQL megközelítés)
Boltban 10 féle tészta, 6 féle ketchup. Összehasonlítani összetevőket és árakat minden alkalommal - brutál drága query az agynak.
Megoldás: egy márkát egyszer kiválasztasz, és cache-eled.
Mindig „X márka” tej. Mindig „Y márka” tészta.
Ha nincs - bármelyik alternatíva 1 másodperc alatt (fallback strategy).

3. Kapszulagardrób (Hardware standardization)
A bonyolult kombinálást igénylő cuccokat (passzol-e a nadrág a cipőhöz?) rakd /deprecated vagy /special_events mappába.
Hétköznapokra standard: „egyenruha”.
5 ugyanolyan jó póló, 2 farmer, mindenhez passzol.
Öltözés: 15 mp.
CPU Load: 0%.
4. Interrupt batch processing (Interrupt coalescing)
Minden értesítés egy interrupt, ami kiüríti az L1/L2 cache-t, és döntést igényel: „most válaszoljak vagy később?”.
Még ha nem válaszolsz, már égettél energiát az impulzusgátlásra.
Megoldás: nem olvasunk messengert realtime.
Napi 2–3 slot (pl. 12:00, 16:00, 19:00), amikor feldolgozod az egész queue-t.
Egyébként: Do Not Disturb.
Fontos SLA: hogy ne pánikoljanak a kollégák, előre lefektetett protokoll:
• Messenger = nem sürgős (async). Válasz a slotomban/idősávomban
• Telefon = „Prod down” vagy „tűz” (sync). Azt mindig felveszem.
A gyakorlat azt mutatja: a kérdések 99%-a simán vár 16:00-ig. Ha tényleg baj van, fel fognak hívni.
Konklúzió: legyél Architekt!
Az akaraterő akkumulátor. Teljesen irracionálisnak tartom ezt a töltést zokniválasztásra, ételrendelés-scrollozásra és push értesítésekre pazarolni. Ez resource leak.
Te választasz: elég az „user” módból, aki minden „sors-popupra” rákattint. (reaktívan élni és reagálni, nem irányítani)
Sokkal érdekesebb System Architectként egyszer beállítani a default configot, és hagyni, hogy a rendszer autonóm módon fusson.
Automatizáld a rutint. Hardcode-old az életet.
Azt akarod, hogy a töltöttséged 95%-a kódra, bizniszre és életre menjen el - ne arra az 5%-ra, ami túléli a háztartással való harcot.
Vagy legalább arra, hogy tudatosan nézz meg egy sorozatot, ne azért, mert a rendszer lefagyott, és nem találja a „Shutdown” gombot.




![;]](http://cdn.rios.hu/dl/s/v1.gif)

)