Miért szomorúak a programozók? És hogyan lehetnének mégis boldogabbak?

Ha tetszett, oszd meg ismerőseiddel!

A 2024-es Stackoverflow Developer Survey felmérés szerint, a programozók 80%-a elégedetlen a jelenlegi munkahelyével, és csak 20% nyilatkozta azt, hogy elégedett a mostani munkáltatójával. A lenti screenshoton is jól látszik, hogy minden harmadik programozó egyáltalán nem boldog a munkahelyén, vagy kifejezetten gyűlöli azt. A programozók majdnem fele nyilatkozott úgy, hogy igazából el van, de csak a minimum effortot teszi bele a munkájába.

Számomra megdöbbentőek voltak ezek az adatok. Igaz azt hozzá kell tenni, hogy a kérdőívet kitöltők nagy része az USA-ból származik, így inkább az ő véleményüket tükrözi ez a felmérés, de valószínűleg itthon sincs ez nagyon másképp. A cikk végén egyébként Ti is szavazhattok erről.

A számok azért is döbbenetesek, mert az IT szektorra és azon belül is a programozókra mindenki nagyon jól fizető, rugalmas munkarenddel és kecsegtető juttatásokkal rendelkező terület, ahol a fejlesztők akár a Balaton partjáról is bejelentkezhetnek egy-egy meetingre, otthonról vagy akár egy kávézóból is tudnak dolgozni és mindemellett a cégek számos juttatás csomaggal, és kiemelt bérezéssel jutalmazza a munkájukat. Így hát érdemes belemélyülni jobban a témába és megnézni, hogy miért lehetnek a programozóknál még a farmerek és a vízvezetékszerelők is boldogabbak?

A boldogtalanság első oka: a pénz

A bevezető alapján talán pont nem erre gondolnánk, hiszen az általános elképzelés, az hogy a programozók bőre alatt is pénz van. A valóság azért ennél árnyaltabb. Egyáltalán nem mindegy, hogy milyen programozási nyelvet ismer az illető, milyen tapasztalati szintje van benne és melyik országban dolgozik, de még az országon belül is számít, hogy mekkora vállalatnál írja a forráskódot.

Például a PHP-ban fejlesztők kifejezetten rosszul keresnek, míg az Erlang, Go vagy Rust fejlesztők 1,5-2-szer annyit is hazavihetnek.

A kereseti lista alján a PHP fejlesztők
A fizetési lista tetején akár 1,5-2szer annyit is hazavihetnek, mint a lista alján lévők

A gazdasági recesszió mélyen érintette a fejlesztők pénztárcáját is, hiszen tavalyhoz képest több programozási nyelvben fejlesztők medián jövedelme visszaesett. A PHP fejlesztők tavaly még hazavihettek $58,899-t, idén már csak $49,586-t. De nem mindenkit súlytott visszaesés. A Nim, az Apex vagy a korábban is említett Erlang fejlesztők viszont még többet is kerestek 2024-ben, mint 2023-ban.

Kb 15%-kal volt alacsonyabb a PHP fejlesztők idei medián jövedelme tavalyhoz képest. Erre még rájön az inflációs hatás, így a reálbér akár 20-30%-os csökkenést is elszenvedhetett.

Hogyan lehetséges ez?

A PHP egy egyszerű programozási nyelv, amit bárki könnyen megtanulhat. A cégek könnyen találnsak PHP-s környezethez programozót, hiszen belőlük Dunát lehet rekeszteni.

Míg az Erlang, Nim vagy Apex kevésbé kedvelt programozási nyelvek, mondhatni lasszóval kell fogni a fejlesztőket az ilyen projektekhez, így értelemszerűen a programozók is csak magasabb bérért hajlandók elvállalni a munkát.

Persze a PHP-val és úgy egyébként a webprogramozással, weblap fejlesztéssel lehet jó pénzeket keresni, de ezt általában egyéni vállalkozásban teheti meg az ember, alkalmazotti munkaviszonyban maximum erős közepes fizetést vihet haza, még úgyis, ha többévnyi tudása van.

A boldogtalanás második oka: a technikai adósságok

Ez már talán egy érdekesebb terület, hiszen sokkal inkább technikai jellegű a probléma. A technikai adósságokkal való mindennapos küzdelem a kérdőívet kitöltők kétharmadánál okoz bosszúságot és veszi el a kedvét a programozástól. Hogy mi is a technikai adósság és hogyan lehet ezzel megküzdeni az egy másik cikk(sorozat) témája lesz, itt most csak röviden térjünk ki rá. A lényege, hogy a fejlesztők többsége nem zöldmezős projekteket fejleszt, hanem hozott kódbázison kell dolgozni, ezt nevezzük legacy kódnak.

A legacy kód önmagában nem egy rossz dolog, de a benne megbújó technikai adósságok már igen. Technikai adósság minden, amit azért csinált valaki, hogy rövidtávon meggyorsítsa a fejlesztést, de hosszú távon végül nem karbantartható és nehezen módosítható kódot produkált. Valószínűleg mindenki találkozott már olyan osztállyal vagy metódussal, amihez senki nem mer hozzányúlni, mert valami csodafolytán működik, teszi a dolgát. Üzletileg nagyon kritikus, dokumentálatlan és többezer soros valami, amiben ha egy picit is módosítani kell, a fejlesztőket kiveri a hidegveríték.

A probléma ezzel, hogy lassítja a fejlesztést, nagy kockázatot hordoz magában a módosítása. A fejlesztők számára nagyon frusztráló, ha nem tudnak haladni a feladatukkal, mert folyton valamilyen logikai és/vagy programozási turpisságba botlanak. Erre még rájön az üzleti-, és időnyomás is, és a felelősség terhe, hogy ezt bizony nem szabad elb*szni. Ez a stressz hosszútávon könnyen kiégéshez vezethet, ami se a fejlesztőnek, se a cégnek nem jó.

A boldogtalanság harmadik oka: megszoksz vagy meghalsz

Ezzel lényegében el is érkeztünk a harmadik ponthoz: az üzlet vagy a projekt menedzser felől érkező olykor csak sugalmazott, máskor egészen kézzelfogható nyomáshoz, amely oda vezet, hogy sok fejlesztőt teljesen vállalhatatlan határidők teljesítésére kényszerít. Ezzel pedig a fejlesztőket túlórázásba, stresszbe és kiégésbe hajszolja. Elég csak megnézni, hogy a big tech cégeknél átlagosan mennyi ideig maradnak a fejlesztők. A 2 év már jónak számít, de az Ubernél kicsivel több, mint 1 évig maradnak.

Ez a gyors rotáció a cégeknek sem feltétlenül kedvez, hiszen folyamatosan toborozniuk kell, és az újaknak kell idő, míg belerázódnak a rendszerbe és a fejlesztésnél alkalmazott toolok használatába. Ez általában 3-6 hónap, és csak ezután kezdődik el a tényleges munkavégzés, és kezdhet el hasznot termelni az alkalmazott a cég számára.

Nem igazán érzem teljesen produktívnak, hogyha a betanítást és próbaidőt követő hónapokban az illető felmond. Hiszen a cég sok erőforrást áldozott arra, hogy a munkavállaló náluk dolgozzon, számos értékes információval gazdagodott az illető a cégről és az alkalmazott technológiákról.

Ez pedig az érem másik oldala: az USA-ban nagyon gyakori, hogy egyesek bezsebelhető trófeaként tekintenek a big tech cégekre. Már az is jól mutat a CV-ben, ha csak 1 évet lehúzott mondjuk az Ubernél vagy az Apple-nél fejlesztőként, hát még ha esetleg 3-4 másik nagy céghez is sikeresen jelentkezett.

A boldogtalanság negyedik oka: a céges bürokrácia

Sok fejlesztő érzi úgy, hogy a céges bürokráciában csak egy apró fogaskerekek egy hatalmas gépezetben, és hogy munkájuknak nincs igazán értéke. Sokan panaszkodnak arról a tipikus jelenségről, amikor meetinget írnak ki arra, hogy egy másik meeting időpontját egyeztessék. Aztán mivel azon a meetingen valami félremegy és nem arról van szó, amiről kellene, hogy legyen, ezért ki kell írni még egy meetinget. A rengeteg egyeztetéstől pedig sokan úgy érzik, hogy épp a munkájukat nem tudják már elvégezni.

A harmadik ponthoz lehetne még visszacsatolni, amivel sajnos már én is találkoztam munkahelyen, amikor a projekt menedzsered naponta két meetinget is berak, csak azért, hogy meggyőződjön róla, hogy jól haladsz-e a feladattal. Fejlesztőként ez baromi frusztráló, hiszen dolgoznál, elmélyülnél egy nagyobb feladatban, de nem tudsz, mert folyamatosan megszakítanak.

A boldogtalanság ötödik oka: leépítések

A jelenlegi gazdasági helyzet egy ideig nem igazán kedvez a fejlesztőknek: juniorként nehéz elhelyezkedni, seniorként pedig nem dúskálsz a lehetőségekben. Mindezek mellett még ott vannak a nagyméretű leépítések is, amelyek egyértelműen nem tesznek jót a mentális egészségnek, és növelik a szorongást.

A boldogtalanság hatodik oka: egészségügyi problémák

Az a kérdőívet kitöltők átlagéletkorából is látszik, hogy a fejlesztők nagy része már 25-34 év közötti, vagy 35 év feletti. Fiatal korban az ember el van napokig pizzán és energia italon, hogy letolja a coding session-t, és ezt akár huzamosabb ideig is tudja csinálni, de 30 felett már megváltoznak a dolgok. Az ülő munka és a mozgásszegény életmód egyébként sem kíméletes, és épp ez az a korosztály amely először érzi magán a testi problémákat. A fáradékonyság, a mozgásszervi-, szív-, és emésztési problémák igazán csak ebben a korban kezdik megmutatni magukat.

Hogyan lehetnénk mégis boldogabbak?

Természetesen vannak megoldások is ezekre a problémákra, bár kifejtésük akár több könyvet is megérhet, így sok esetben csak felületesen fogok belemenni a témákba, amolyan gondolatébresztőként.

Az egyik legnagyobb probléma, hogy érdekellentét van egy cég és a fejlesztő között. A cég produktivitást vár el a fejlesztőtől, amire mindenféle metrikákat próbálnak ráhúzni (írott kód mennyisége, commitok száma, lehozott sztori pontok), míg a fejlesztők többsége más értékrendet tartanak szem előtt. A fejlesztők szentháromsága a minőség, a folyamatosság és az értékteremtés.

A boldogság első kulcsa: a kódminőség

A második helyen állt a boldogtalanságot okozó ranglistán a technikai adósság. Egy apró érdekesség: a fejlesztőcsapatok 42%-a nyilatkozott úgy, hogy napi szinten több órát vesz igénybe a technika adósságok kerülgetése. Mindössze 10% nyilatkozott úgy, hogy ezeket aktívan javítják, vagyis csökkentik a technikai adósságukat. Ez egy lefelé tartó spirált jelent, hiszen mindig több technikai adósság kerül a kódba, mint amennyit kivesznek belőle.

Mit lehet tenni a kódminőség javítása érdekében?

Nem, nem a teljes refaktorálás a megoldás, még mielőtt mindenki egybehangzóan üvöltené. Bevezethetünk coding standard-et, amit a csapat elfogad és az új kódokat már az alapján írják meg. Használhatunk különböző lintereket, kódformázókat, amelyek vagy automatikusan beformázzák a kódot a coding standard alapján vagy szólnak, ha valami csúnyaságot akarunk művelni a kódban.

Bevezethetjük a code review-t is, amitől sokan ódzkodnak. Aláírom, ha rosszul csinálják tényleg lehet belőle konfliktus a fejlesztők között, de alapvetően egy egyszerű szabályt kell betartani CR esetén: ne legyél paraszt. Az nem konstruktív, ha odaírsz egy kaki emojit a kódhoz. Fejtsd ki, hogy szerinted miért nem jó a megoldás, szánjatok rá időt és beszéljétek át. Kérhettek egy harmadik véleményt is, ha esetleg nem tudjátok feloldani a problémát, és nem közelednek az álláspontok. A code review nem arról szól, hogy kinek a f*sza nagyobb, vagy hogy kiír jobb kódot. Hanem arról, hogy mindenki ugyanolyan minőségű kódot írjon és ezáltal a fejlesztők fejlődjenek, igényesebbek legyenek maguk és mások munkájára is. A code review kapcsán azonban nem csak a reviewernek kell elsajátítani készségeket: az author-nak is el kell fogadnia a másik szakmai kompetenciáját.

Mindenképp javasolt a unit tesztek és az automata tesztek írása, amelyeket akár CI/CD pipeline beépítve automatikusan futtathatóvá tehetünk, így minden push előtt lefutnak, és a fejlesztő értesülhet róla, hogy valahol probléma van. Ráadásul a unit tesztek és az automata tesztek segítenek abban, hogyha a későbbiekben nagyobb refaktorálást szeretnénk végezni a kód egyes részein.

Automata teszthez én nagyon ajánlom a Playwright-ot, mivel gyorsan futtatható tesztek írhatók hozzá Typescript-ben. Felületi elemek, de akár API request-ek tesztelésére is alkalmas.

A boldogság második kulcsa: a folyamatosság

A folyamatosság alatt egyfajta flow-t kell érteni, de nem abban a klasszikus értelemben, ahogy gondoljuk. Nem arról a tudatállapotról beszélek, amikor mindent kizársz a külvilágból és csak te és a kód léteztek. Inkább arról van szó, amikor a feladatokat egymás után folyamatosan tudod megcsinálni, szépen átmennek code review-n, lefutnak rá a tesztek és még a QA is visszajelez, hogy minden király. Ha azt hiszed, hogy ez egy elérhetetlen álom csupán, meg kell cáfoljalak: elérhető ez a folyamatosság, igaz nem állandóan, de néha elérhető.

Természetesen ehhez kell, hogy értsd a feladatot, azok jól is legyenek kiírva. Körültekintően végezd el a módosításokat, és mind a reviewer, mind a tesztelő ne legyen nagyon elhavazva. Sajnos a hétköznapokban gyakori, hogy a review akár napokig is elhúzódik, mert a reviewer nem ér rá éppen vagy elfelejt ránézni. Ekkor értelemszerűen felveszel egy másik taskot a backlogból. Mire megérted és lefejleszted, lehet, hogy visszajön észrevétel a reviewertől. Így megint visszaugrasz a korábbi feladatokra. Ez az ide-oda pattogás a feladatokban nagyon idegörlő lehet, hiszen úgy érzed, hogy ugyanazokat a köröket futod. A folyamatos scope change, a ping-pongozás nem jó, ezt mindenképp csökkenteni kell.

A code review folyamatának gyorsítására és így az oda-visszapattogás csökkentésére többféle lehetőség is van. Kijelölhetsz egy időpontot, amikor foglalkozol a code review request-ekkel. Ezt célszerű nap elején vagy végén megtenni, és állíts be rá emlékeztetőt is. A daily standupon a team lead is kérheti a reviewereket, hogy nézzenek rá a requestekre. Az én csapatomban pedig egy olyat vezettünk be, hogy egy külön chat szobában kérhet meg a fejlesztő két embert megtagelve, hogy nézzenek rá adott merge requestre. Így a megjelölt reviewerek gyorsabban megnézik a kódokat. Emiatt aztán nálunk igen alacsony a code review státuszban lévő jegyek száma és kevés időt is töltenek ebben a státuszban a taskok.

Fontos a feladatkörök pontosítása és azok betartása is. Bár papíron baromi jól hangzik, hogy egy fejlesztő több területen is megállja a helyét, nagyon hamar káoszba fulladhat egy fejlesztőcsapat munkája, ha nincsenek egyértelműen lefektetett szerepkörök és azok hatáskörei. Csak káoszt és anarchiát szül, ha például a frontendes folyamatosan belenyúl a backend oldali osztályokba vagy az adatbázisba, és visszafelé is igaz ez. Szintén probléma, ha a fejlesztő a projekt menedzser helyett kezeli a jegykezelőt és szervez ki feladatokat másoknak, a menedzser tudta nélkül.

A boldogság harmadik kulcsa: értékteremtés

Alapvetően szeretné mindenki úgy érezni, hogy a munkájával értéket teremt, hogy ad valamit a vásárlóknak, felhasználóknak, még ha a világnak nem is feltétlenül, de a piacnak vagy a cégnek mindenképp. Ezért kiemelten fontos, hogy lássák a fejlesztők munkájuk eredményét, legyen az a bevétel, az újonnan regisztrált felhasználók száma, vagy például belső CRM rendszernél az ügyvitel tempójának változása. Ezeket az eredményeket a vezetőknek kell a fejlesztők felé tolmácsolniuk. Nincs is annál rosszabb, mint amikor projektről projektre esik a fejlesztőcsapat, nincs idejük megünnepelni a kisebb-nagyobb sikereket, mert már a következő feladatra kell koncentrálni. A fogaskerék a gépezetben érzéshez sajnos nagyban hozzájárul ez is.

És nem, egy pizzaparty nem fogja orvosolni a problémát, de egy közösen eltöltött iszogatós, beszélgetős, játszós este mindenképp csapatépítő erővel bírhat. Természetesen ennek a jellegét mindig a csapat döntse el közösen.

Források

Fireship – 80% of programmers are NOT happy… why?

CraftConf 2023 – Sven Peters: Developer Joy – How great teams get s%*t done

Te mennyire vagy elégedett a jelenlegi munkahelyeddel?

Hogy tetszett a poszt?

Van bármi észrevételed?


Ha tetszett, oszd meg ismerőseiddel!