2024. október 20., vasárnap

Zavaró tényezők

Egyszer voltam egy barlang-túrán, ahol a vezetőnk javaslatára próbaként kikapcsoltuk néhány percre a lámpákat és csendben ültünk, élveztük a tökéletes csendet és sötétséget. Egy pár perc múlva viszont mintha valami apró neszt hallottam volna. Vagy nem? Néhányszor láttam valami fényfoszlányt. Vagy csak én láttam? Mindenki így volt vele. A túravezető a kisérlet végén elmagyarázta, hogy nem vagyunk betegek, az agyunk hozzászokott a folyamatosan ingergazdag környezethez és keresi a szokásos ingereket, ha nem talál, akkor csinál.

Egy átlagos munkanapon az idő nagy része nem szó szerint munkával tellik. Általában nehéz akár 10-15 percet is találni amikor az ember folyamatosan dolgozhat. A leggyakoribb okok:

  1. Emberi interakciók 
    1. Valaki odajön hozzád (vagy dob egy instant message üzenetet) falamit kérdezni
    2. Meetingek - aminek a felén azt kérdezed magadtól hogy vajon miért vagy itt, de csak magadtól, mert egyébként nem akarsz senkit se megsérteni.
    3. Code review-re várunk
  2. Automatikára várni:
    1. Hogy végre elinduljon a spring boot / weblogic / salalla-halalala
    2. Lefusson a jenkins build
    3. Hogy a cuccod bedeployoljon a VM-en, kubernetesben vagy akárhol
    4. Szerintem döbbenetesen sok időt töltünk azzal hogy lassú szoftverekre várunk.

Na és a kérdés: mit adjak az agyamnak, mit rugdosson amíg ezekre a fentiekre várok?

Egy szubjetív felosztás következik, egyszerűen jó és rossz dolgokra felbontva:


A jók

Akvárium

Az akváriumot imádom, nagy dolgok nem történnek benne, a halak nem követelik a figyelmemet és igazán valószinű hogy semmiről sem maradok le, ha egy napig, egy hétig, vagy akár egy hónapig oda se nézek. Mégis sokáig lefoglal, és bármikor vissza lehet ugrani az eredeti feladatra ha jenkins végre befejezte a pöcsölést.

Hátrány: munkahelyen kizárt

Stresszlabdák

A stresszlabdák talán rövidebb ideig foglalják le az ember agyát, de 1-2 percig még oké. Aztán sajnos az ember agya elkezd csinálni valami mást.

Ördöglakatok

Bizonyos ördöglakatok nem igényelnek nagy agymunkát és ezekkel is elvan az ember egy meeting alatt, mondjuk talán 10-30 percig. Ezt viszont nem mindenki tolerálja, egyes managerek azt szeretnék látni, hogy folyamatosan csapkodom a billentyűzetet, az hogy ez valójában kontraproduktív az talán nem nyilvánvaló.

Papir és ceruza

Használható munkára, vagy csak firkálni valamit egy meeting alatt. 100% compliant, még soha senki sem szólt hogy hagyjam abba és figyeljek arra amit mondok.

Ablak

Két aktivítás közötti idő kitöltésére egy ablak is szuper, főleg ha valami szépet lát az ember. Hegyek völgyek, tavak, folyók, parkok. Ha olyan környezetre van kilátásod, csak ami zavar (pl ocsmány belső udvarok, gázos utcák, koszos házfalak), akkor az ablak felejtős.
Észrevettél valami összefüggést a kilátás és a munkahelyed minősége között? Én igen, nekem úgy tűnik hogy a gáz helyeken általában a munkakörnyezet maga is kevésbé attraktív. A rusnya architektúra rusnya viselkedésre bátorít.

Szobanövény

Kiválló, és soha nem zavar hülye kérdésekkel, nagyon alacsony a TCO is. Hátrány: Barlangban nem lesz jó, napfény kell neki. Nem nagyon foglal le, ha 5 percig néznem kellene, lehet hogy kidobnám az ablakon.

A rosszak

Sajnos minden ami, odafigyelést igényel.

  1. Internet, hiroldalak
  2. Social media
  3. Whatsapp üzenetek mindenféle csoportokban, még akkor is ha munkával kapcsolatos.
  4. Könyvek, e-könyvek - egyébként amikor van rá idő akkor zseniális, de ezzel az aktivítások közti időt betömni rémesen rossz ötlet
  5. E-learning, még egy 2-3 perces duolingo lecke is, főleg mert utánna elkezd nyafogni hogy még egy leckét csináljak.
  6. Valaki friss és véletlenszerű ötlete arra hogy mit kellene most csinálnod - keress rá egy módszert hogy elküldd a fenébe

2024. június 20., csütörtök

Csak úgy eszembejutott

Néhány évvel ezelött egy este éppen hazafelé indulni készültem, amikor benéztem az egyik irodahelyiségbe. Ott ült az egyik munkatársam, Zénó, egy szép méretes humanoid, aki elszúrt egy csillagászati méretű átutalást. Épp a sírással küszködött. Egy szót kellett volna mondanom csak ahhoz hogy felvidítsam: Xavér. Így hívták azt a munkatársat, akit Zénó olyan élvezettel basztatott, hogy az idegösszeomlást kapott és kirúgták. Ez azóta is Zénó kedvenc témája volt.

Csak annyit kellett volna mondanom, hogy "Xavér". Zénó egyből elvigyorodott volna, egyből előtodultak volna a szép emlékek, letörli könnyeit, kétkézzel megragadja a fa.... izé a billentyűzetét és odacsűr a tranzakcióknak.

Vagy esetleg annyit: "Ha nem basztattad volna halálra Xavért, most lenne aki segítsen." De ez utóbbi nem biztos hogy segített volna.

Úgyhogy nem is mondtam semmit, elmentem haza. Szép kis helyeken dolgozok néha.

2024. április 23., kedd

Szubjektív SCRUM történet

Egyre inkáb nevetség tárgyává válik a közösségi médiában a SCRUM és azt hiszem azok akik az utóbbi 10 évben ismerkedtek meg ezzel a dologgal a munkahelyükön valószináleg nem értik hogy hogy rajonghattunk valaha is érte. Gondoltam akkor megírom a történetét röviden.

2008 körül dolgoztam elösször a SCRUM-mal. Akkor éppen egy virtuális világ projekten dolgoztunk, kemény határidő volt, igyekeztünk tartani, de volt pár kihívás. Az egyik legjelentősebb kihívást a projekt vezetése jelentette: minden napra betettek nekünk 4-5 óra meetinget. Minden meetingre meghívtak mindenkit: a designereket, a rendszergazdákat, a szoftverfejlesztőket, a producereket és mindenkinek végig kellett halgatnia minden témát. Mire az ember kikeveredett a meetingekről, utánna már tényleg alig maradt idő a munkára. Vicces kis hack-eket csináltunk a dologból, pl lefoglaltunk egy munkatársammal egymás naptárjában 2 órát meetingre, amikor egymás mellett ültünk és dolgoztunk. Ha valaki jött hogy meeting kezdődne, akkor azt mondtam, hogy "bocsi most van egy meetingem Józsival", és ez teljesen igaz is volt, közben persze dolgoztunk beszélgetés helyett.
De ez félmegoldás és nyilván maradt egy nagy probléma: a projekt vezetője a meetinget tartja munkának és a munkát haszontalan időtöltésnek veszi.

És ekkor jött egy srác Londonból (ez azért fontos mert az volt a CÉG központja és tehát az ő véleménye nagyobb súlyt kapott) és bemutatta a SCRUM metodikát a csapatnak.

  • A SCRUM standup max 15 perces procedúra volt
  • Konkrétan tényleg állva csináltuk végig, nem volt betelefonálás közben email böngészés
  • Csak az kaphatott szót, aki vagy aznap, vagy előző nap tényleg csinált valamit. Ennek a betartására egy studió mikrofon vándorolt kézről kézre és aki úgy próbált beleszólni, hogy nem volt nála a mikrofon, azt úgy tettünk mintha nem hallanánk, vagy szóltunk neki hogy baj lehet az erősítőjével.
    A mikrofont mi kértük, nem nyomta oda senki nekünk ha nem kértük.
  • Mindenki ennyit mondott el: mit csináltam tegnap, mit fogok ma csinálni és mik az akadályok - azaz ma kivel kell együtt megoldani valamit
  • A feladatokra nem vártunk, a feladatokat magunkhoz vettük amikor az előző feladatot befejeztük
  • Egyszerre egy feladat. Csináld amig kész nem lesz.


Ezt az egészet fejlesztők hozták be, fejlesztők csinálták és mind nagyon élveztük, a "nem tudom hogy leszünk kész" érzést a "haladunk" érzés váltotta fel. Kivétel a projektmanagert. Rajta láttam hogy a helyét keresi, ő valószinűleg úgy érezte, valami trónfosztás-szerűség történt, valami proletár-diktatúra.
Nekem viszont szuper élmény volt, és úgy hívták: scrum.

Tekerjünk gyorsan előre 2024-be, nagycéges környezet, és nézzük mit történik egy mai SCRUM daily meetingen:

  • A projekt vezető végigmegy a csapaton és mindenki beszámol arról hogy hol tart a feladatával. Ez egy "report event". Amennyiben koordinációnak nevezzük, akkor gyakran inkáb csak a projekt vezetőjével koordinálunk, nem annyira a csapattal.
  • A feladatokat hozzánk rendelik, nem mi húzzuk be amikor készen vagyunk az előzővel
  • Ennek következtében N darab folyamatban levő feladatom van és zsonglőrködhetek velük.
  • Nem csak hogy nem állunk fel, de többnyire be se megyünk.
  • A projekt iterációk valahogy rémesen hasonlítanak kis vizesésekhez.

Valahogy az egész olyan, mintha még mindig a régi Waterfall process-t csinálnánk, csak most néhány hónapos ciklusokban.


Most gyorsan tekerjünk vissza kb 1700 évet. A kereszténységet a római birodalomban tiltották és a követőit keresztre feszítették, oroszlánokkal etették fel, gályákra küldték vagy eladták rabszolgának. Nem tűnhetett akkor túl penge ötletnek kereszténynek lenni.
Egészen addig, amíg Konstantin császár hatalomra nem jutott, ő ugyanis a birodalom hivatalos vallásává tette a kereszténységet. A birodalom kb 100 millió lakója alighanem vegyes érzelmekkel próbálta megérteni, miről is szól egyáltalán a kereszténység, hogy aki eddig Jupiternek áldozott az most kinek kellene hogy áldozzon, satöbbi. Amennyiben az ókori római vallás és a katolikus kereszténység között valaki valami hasonlóságot vélne felfedezni (ó ne, micsoda eretnek gondolat), akkor valószinűleg azt gyanítaná, hogy hát persze, ugyanarra a kultúrára ráhúzták az új vallást, már hogy ne lenne hasonló.


Na és szerintem valami ilyesmi történt a SCRUM-mal is. Nem az számít, hogy SCRUM-nak vagy minek nevezzük. Ezt valamikor a 2000-es évek elején olyan írták le, akik így szerettek dolgozni, akik nem akartak pöcsölni sok meetingen, csak gyorsan meg akarták beszélni, hogy hol járnak és merre tovább. Aztán ezt a metódust ráhuzták egy olyan kultúrára, ami viszont nem ilyen. Bár a felirat rajta az hogy "SCRUM", de nem tud lazítani, nem sikerült megszabadulnia a waterfall gondolatmenettől, sok project managernek nem sikerült elengednie a dolgozói kezét, nem hiszi el hogy akkor is megcsinálnák a munkát, ha nem lihegne a nyakukba, és tényleg sok dolgozó csak leadja a jelentését a standupon, nem érdekli hogy mivel lehetne még lendíteni (és miért is érdekelje?) Akkor meg mitől lenne más?

2024. február 8., csütörtök

AWS kaland

Van egy érdekes adathalmaz, sajnos 2 TB bz2 tömörítve. Csináltam egy kis programot az elő feldolgozásához. Hát elég kínkeservesre sikerült, rettenetes türelem kellett hozzá hogy az első szeletét a laptopomon feldolgozzam. Lenne igény új IT felszerelésre, csak éppen válság van és másra még nagyobb szükség van.
Gondoltam meghúzom amazon-on. Indítottam egy VM-et, 4 epyc core, 16 GB RAM. A munka tizedével végzett kicsit több mint egy hét alatt, közbe 50 dollárnyi számlát csinált. Tehát a teljes munka nagyjából 500 dolláerba kerülne.

500 dollár az elgondolkodtató, mert az egy használható munka-laptop árának a fele lenne. Szóval akkor elgondolkodtam rajta, hogy vajon hol lenne jobb helyen a pénz. Válság van, ha nem jutna eszembe minden szaros percben.

Akkor milyen egyéb opció van? Csináltam pár éjszaka JMH teszteket a program részeire és találtam is pár dolgot, amit igazán jobban is meg lehet csinálni, tulajdonképpen ezek vitték el az idő túlnyomó részét. Sikerült leküzdenem a feldolgozás idejét 5 napra. Újabb tiz százalékkal közelebb a célhoz, annélkül hogy újabb 50 dolcsiba került volna. Mert most már nem AWS-en folytattam, hanem egy öreg használaton kivüli NUC-on. Lassan odaérek majd hogy raspberry-n fut minden.

Még egy optimalizációt találtam, azzal már a feldolgozás ideje leesett 1 napra a nyomi öreg kis NUC-on. Ezzel már néhány nap alatt befejezem. Az 500 dollárnak majd találok valami más helyet.

Végülis nem olyan rossz egy válság, legalább az ember elkezd végre értelmesen gondolkodni, ahelyett hogy minden problémát a hitelkártyájával intézne el.

2023. december 3., vasárnap

Valamire jó lesz

 

Vasárnap esti sztori.

Régebben egy magyar cégnek dolgoztam. A főnököm egyik ötlete az volt, hogy csináljunk egy riport generálót ami PDF-be köpi ki a riportot. Végigmutogattam neki az akkori open source cuccokat, egyik se tetszett neki, azt mondta mind túl lassú. Nem győzött meg igazán, de engem nem is kellett meggyőzni mert ő volt a főnök. Azért nem szokunk ilyet csinálni, mert

  1. Igyekszünk a munkánk eredményét minnél elöbb eljuttatni a felhasználóknak/vevőknek. Ha mindenből sajátot csinálunk, azzal ez messzire eltolódhat - vagy esetleg valaki beelőz és nézhetünk szomorúan.
  2. Ha felhasználjuk azokat a komponenseket, amiket mások is használnak, talán azok a mások már megtalálták és kijavították a hibákat benne.
  3. Sajnos tényleg, a szoftverfejlesztő gyakran sokkal drágább, mint a CPU-idő. Például ezért van maga a JAVA is. Hiszen amit assembly-ben nem lehet megcsinálni, azt nem lehet megcsinálni.

De akkor nem volt más, nekiláttam egy PDF-et generáló riport komponesnek, ehhez át kellett olvasnom a PDF formátum dokumentációját.

Pár hónappal később a főnököm autóbalesetet szenvedett, kórházba került több hónapra, és a végén az orvosok nem tudtak rajta segíteni, meghalt. Vigyázzatok az utakon :( Az új főnöknek nem volt erről a projectről és az előzményeiről lövése se, kicsit zűrös fickó volt, úgyhogy én elbúcsúztam tőlük. Aki átvette tőlem ezt a PDF generáló cuccot, az egyetlen kérdése az volt a dologgal kapcsolatban, hogy "te hülye vagy, bammeg?" Én is valahogy úgy ástam el az agyam valamelyik zugában a PDF formátum technikai részleteit, hogy na ezt egészen biztosan soha többé nem kell előássam.

Eltellett 20 év, mint egy pillanat.

Idén valamikor egy felhasználó panaszkodott, hogy a feltöltött dokumentumából valami hiányzik, kevesebb oldal van, mint amennyit ő feltöltött. A panaszelhárítók második védelmi vonala nem tudott mit kezdeni a dologgal, átírányították hozzám, nézzem meg nem szúrt-e el valamit a becses szoftverünk. Elkértem feltöltött a dokumentumot tőlük, megnéztem egy szővegszerkesztővel és ezt még fejből el tudtam mondani válaszként gyorsan:
A PDF dokumentum a végén kezdődik, ott van egy katalógus, amelyikben minden oldal fel van sorolva. Ha nincs ott a PDF katalógus, akkor a PDF olvasód sem tud mit kezdeni a dokumentummal, akkor az sérült. Ha viszont ott van a katalógus, akkor látod benne az oldalak számát, tehát nem veszthettünk el belőle semmit. A felhasználót tehát elküldtük más balekot keresni magának. Akkor jutott eszembe, hogy mikor és hol olvastam a PDF formátum párezer oldalas specifikációját.

Talán tényleg nincs teljesen felesleges tudás. Talán ha nagyon sokat várok rá, az egyetemi dolgoknak is megtalálom a kicsi kis értelmét, valahol majd megtakarít nekem napokat, vagy talán csak egy órányi fejtörést.


Vagy ahogy a költő mondta "tegyetek el befőttet, lesz még a világ jövőre"

2022. október 10., hétfő

Ha a szoftvered egy ház lenne

Az ember évezredek óta épít házakat, a ma élő emberek életük legnagyobb részét falak között töltik. Nem vagyok történész, de azt gondolom, hogy ez a civilizációnk egyik sikertörténete. Kb 7 milliárd embernek van ötlete arról, hogy ezeknek a falaknak milyennek kell lennie és bár különbözőek az igényeink és elképzeléseink (pl legénylakás, családi ház, művészgarzon, hippitelep, gengszterbarlang) nagyon sok ponton egyetértünk pl hogy ne nyíljon a wc a konyhába, hogy ne a hálószobába nyíljon a főbejárat, satöbbi. Néha láthatsz valamit, ami nagyon meglepő. Akikkel együt nézed, azokkal könnyen meg tudod beszélni az élményeidet, van rá egy közös nyelvünk és szavaink amit mindenki ért, hiszen ezt csináltuk egész eddigi életünkben: falak között vagyunk. Ennyire alapvető közös élmény talán csak az evés lehet, vagy az utazás. És ha esetleg valakivel nem beszélünk egy nyelvet, még akkor is látja a házainkat. Egy teljesen átlagos napon többszáz házat megnézhetsz, el se fáradsz és hamar véleményt alakítassz ki róluk.
Még ha az árak szempontjából nézzük is, a legtöbb embernek van ötlete vagy legalább véleménye egy ingatlan áráról, hogy egyáltalán ér-e annyit vagy teljesen irreális. Az árakat általában az telekár, az anyagköltségek és a munkaerő ára határozza meg. Ha ugyanarra a dologra két különböző beszállítótól kérsz ajánlatot, várhatóan a különbség esetleg 10-20% körül lesz, nem tizszeres árat kérnek.


A szoftver architektúra sajnos eléggé más kérdés. Alig néhány évtizede használunk szoftvereket, bár egyre aktívabban, de azért a valahol lakás élményével szerintem nem lehet összehasonlítani. Még mindig van egy csomó ember, aki egyáltalán semmilyen szoftvert nem használ. Pl Magyarországon még lehet a vonaton jegyet venni, ha a vasútállomáson nem lehetett.
A legtöbb ember csak használ szoftvert, azoknak az aránya, akik módosítanak vagy esetleg teljesen újat írnak viszonylag alacsony a felhasználókhoz képest.
A szoftver-fejlesztés nyelve nem igazán része a hétköznapi kommunikációnak. Látsz valami furcsát, nincsenek rá szavaid hogy egszerűen elmondd a családodnak. Ha megpróbálod, sokág tart, nem értik, furcsán néznek rád, nem is tudják a szoftver furcsa-e, vagy inkáb te. Egy idő után talán te se tudod.
Emiatt viszonylag kevés konvenció van. Nap mint nap találkozol olyan megoldásokkal, aminek az építészeti megfelelője talán egy iglu lenne a szaharában, viszont elég sok időre van szükséged ahhoz, hogy akár a projektmanagerednek megmagyarázd, hogy ez nem oda való. Elmondja, hogy járt a sarkkörön és egy iglu megmentette az életét, hosszasan magyarázhatod, mi a különbség a sarkkör és a szahara között és hogy ez egy tényleg fontos különbség. Nem látható, nem tapintható, a legtöbb ember számára nem egyértelmű. A marhaságnak néha se eleje, se vége.
Ja és végül a szoftver ára... nyilván ez is piacelven működik, de nincs rá tradíció, hogy mennyibe kerülhet egy jó CAD szoftver, vagy mennyibe kerül egy jó IDE, mennyit adnál egy relációs adatbázis szoftverért, az árkülönbségek egészen döbbenetesek.


Ha a szoftvered egy ház lenne... hát igen, az nagyon klassz lenne.

Kapcsolódó: Tvik írása többek közt a lakásfelújításokról

2022. július 28., csütörtök

Review Antipattern: a sötét oldal

Ma egy kis anti-pattern csoportról írnék

  1. fenyegetés
  2. félelem
  3. bosszantás

Példa: a szoftverben, amin dolgoztam, elkezdett felhamozódni egy rakás kód, ami teljesen más konvenciókat és ötleteket követett, mint a többi. Python név-konvenciók. Küldtem rá pár patchet és valaki gyorsan be is mergelte. Azt hiszem már másnap meg is jelent egy mérges szoftverfejlesztő és azzal fenyegetett (első pattern), hogy ha nem csinálom vissza, akkor azzal aláz meg, hogy ő reverteli. Hagytam, had dühöngjön. (harmadik pattern: bosszantás, mit gondoltál, hogy valami szent-ember vagyok, aki odatartja a másik orcáját is?) Értelmesen beszélni nem lehetett vele sajnos.
Közben odajött egy ismerős srác és mondta, hogy ne hergeljem fel azt a pythonos csókát, mert ő a "nagyfőnök kis kedvence". Az, aki a patcheimet bemergelte szintén pánikszerű visszavonulót tartott, még elnézést is kért. - második pattern: beparáztak a nagyfőnök kis kedvencétől.


Szép kis alakok vagyunk, mindenki mást csinált, mint ami elvárható lett volna tőle. És hát jaaa, a cég is olyan... más mint a marketinganyagokban. Nagyfőnök kis kedvence? hmm...

Nagyon szeretném, ha ez egy extrém és ritka helyzet lenne, de nagyon sokszor láttam már hasonló helyzetet, máshol is. A másik baj pedig az, hogy nem is tudom volt-e olyan, amikor nem működött. Sajnos talán nem. Ha a szinvonal már odáig züllött, akkor simán be lehet vetni.
Döntsd el, hogy mit csinálsz vele, de én látok némi igazságot abban a mondásban, hogy többet ront rajtad egy gáz munkahely, mint amennyit te javítassz rajta.


Szóval a pattern nagyon egyszerű, nem kell mást csinálni, csak üvölteni, viszont az ehhez szükséges pozíciót el kell foglalni - nagyfőnök kis kedvence, jótékony diktátor, 10x developer, vagy a többi marhaság. De látod milyen sokan megcsinálták.