A szoftvermérnöki tapasztalataim sokat változtak a kezdetek óta. Remélem, hogy az utam hasznosnak, inspirálónak vagy egyszerűen szórakoztatónak bizonyul.

Kezdjük az elején…

1. szakasz: OMG! Működik a kódom!

Ahogy minden szoftvermérnök elmondja, az a pillanat, amikor az első kód működik, különleges. Érezheti az erőt, az adrenalint és a több utáni éhséget.

Nem érdekel, hogyan néz ki a kód, amíg működik, és ez rendben van. Ez a megfelelő idő a játékra és a rendetlenségre. Tudom, hogy megtettem.

Felismerheti magát (vagy egy fiatalabb kollégáját) ebben a szakaszban, ha azt látja, hogy eljut arra a pontra, ahol a kódja működik, büszkének érzi magát, és azt mondja, hogy kész.

2. szakasz: Talán újra fel tudnám használni…

Egy idő után ismét azon kapod magad, hogy „OMG”-t mondasz, de ezúttal azért, mert megláttad az általad teremtett szörnyet. Fogalma sincs, hol van bármi, és nincs mód arra, hogy bármit megváltoztasson, mert összeomlik (szó szerint).

Azonban ismétlődő kódmintákat kezd látni, és ezzel eljut a következő szakaszhoz – a kód újrafelhasználásához. Kezdje a függvények létrehozásával, és ez szépen megtisztítja a kódot. Ezen a ponton újra eligazodhat a kódban, így egyre több funkciót kezd el gyártani.

Ahogy a kód közeledik az ezer sorhoz, még a függvények sem tudnak segíteni. Szerencsére az osztályok segítenek, és megtanulod, hogyan lehet hasonló funkciókat logikai egységekben foglalni. Ez egy nagy mérföldkő a karrierjében, mert megtanítja a jó szoftverek mögött meghúzódó alapelvekre. Ez azonban nem megy könnyen – szó szerint megtanulsz másképp gondolkodni.

3. szakasz: A Mátrix látása

A projektek összetettségének növekedésével egyre nagyobb mintákat kezd látni. Kitalálja, hogyan rendezheti a kódot modulokba, könyvtárakba és szolgáltatásokba, hogy újra felhasználhassa őket különböző projektekben. Láthatja, hogy ezek az egységek hogyan lépnek kapcsolatba egymással, és mi a szerepük.

Ezen a ponton inkább építésznek tartja magát, mint kódolónak. Ön virtuális univerzumot épít a saját szabályaikkal és ügynökeikkel. Nem törődsz többé az if-kkel, az else-kkel, a ciklusokkal, a függvényekkel vagy akár az osztályokkal. Érdekel az összetevők felelőssége, a kommunikáció módja és az információáramlás. Valószínűleg több időt tölt a tábla előtt, mint a számítógép előtt.

Ez egy nagyon megerősítő szakasz, mert úgy érzed, hogy a való világot is kezded jobban megérteni. Láthatod az ismétlődő alapelveket, minden mögött meghúzódó alapvető erőket, sőt néha befolyásolhatod is őket.

4. szakasz: Nincs tökéletes világ

Ahogy alakítod a virtuális univerzumodat, kezd csalódott lenni. Elkezdesz látni, hogy több módszert is elérhetsz ugyanannak a célnak, de egyik sem oldja meg teljesen a problémát. Ez olyan, mint a fizika törvénye, amely nem engedi meg tökéletes megoldás kidolgozását. A fiatalabb éned éppen az első megoldást választotta volna, ami eszedbe jut, de elkezded látni a „másik oldalt” – minden megoldásnak megvannak a következményei.

Most meg kell tanulnia jó kompromisszumot kötni:

  • Olyan aszinkron kéréseket választ, amelyek javítják a teljesítményt, de bonyolultabbá teszik és növelik a hibák esélyét, vagy olyan szinkron kéréseket, amelyek ennek ellenkezőjét teszik?
  • Bevezetne egy másik programozási nyelvet a verembe, amellyel gyorsan meg tud oldani egy adott problémát, tudván, hogy másokat kényszerít más dolgok megtanulására, kockáztatja az ismeretlen hibákat és több karbantartást vezet be?
  • Mi a helyzet az adatbázisok replikálásával? Mikroszolgáltatásokat használ? Centralizáció vagy decentralizáció? …

5. szakasz: A kód nem számít, az emberek igen

Számos technikai kihívás megoldása után úgy érzi, végre jól átlátja a szoftverfejlesztés őrült összetettségét. A kód jól néz ki, minden (többnyire) működik, de valahogy az ember egyre jobban lemaradt az üzleti igényekkel.

Rájössz, hogy egyedül nem tudod megcsinálni, így a csapat növekedésnek indul. Hamarosan két dolog egyike (vagy mindkettő) valószínűleg megtörténik:
1. Még több dolgod van, mert minden döntésnek rajtad kell mennünk.
2. Úgy érzed, veszítesz. megragadni, és a kódbázis ellenőrizhetetlen irányokba tér el.

Akárhogy is, egyre kevesebb kódot írsz. A te szereped többé nem az, hogy a legokosabb legyél és megoldd a nehéz problémákat. Ezt nehéz elfogadni, mert a kihívások megoldása egyenletes dopamináramlást adott, és így mérted az önértékelésedet.

Mindazonáltal továbbra is problémamegoldó vagy, akár úgy döntesz, hogy a vezetői pályára lépsz, akár a technológiai vezetővé válsz. A trükk a kép újrakeretezése. Már nem a hibákat vagy a szolgáltatásteljesítmény-problémákat oldja meg, hanem a csapathatékonysági problémákat, gondoskodik arról, hogy mindenki megértse a célokat, minőséget biztosít a folyamatokkal, és mindenekelőtt megosztja a tudást.

Most az Ön feladata, hogy megbizonyosodjon arról, hogy csapata a megfelelő dolgokat építi fel, ezt hatékonyan teszi, és együtt fejlődik. Ha egy nagy gépként képzeli el cégét, láthatja, hogy a munkája nem sokat változott, csak az eszközei. Néhány kérdés, amelyekkel szembesülhet:

  • Hogyan fogja nyomon követni a fejlődést és mérni a sikert?
  • Egy hónapot fektet be egy stabil megoldás megalkotásába, vagy egy csúnya, de működő prototípust készít egy hét alatt?
  • Vásárol egy kész megoldást, vagy megvalósítja a sajátját?
  • Hogyan oszthatja meg tudását skálázható módon?
  • Milyen védőkorlátokat fog beépíteni, hogy csapata biztonságban legyen?
  • Hogyan méri valaki teljesítményét, és hogyan biztosíthatja, hogy gyors visszajelzést kapjon?
  • Hogyan biztosíthatja, hogy mindenki ugyanazon a vízión dolgozzon?

Ezek gyakran nagyobb kihívást jelentenek, mint a mérnöki problémák, de hosszú távon kifizetődőbbek is. Ha sikerrel jársz, megsokszorozod a hatásodat, és olyan kultúrát alakítottál ki, amely továbbra is a későbbi generációk számára fogja learatni a jutalmakat.

Ez a történet arról szól, hogyan éltem meg az utazásomat, és hogyan látom az előttünk álló utat. Megosztottam az utam abban a reményben, hogy segíthetek azoknak, akik most kezdik, vagy úgy érzik, hogy elakadtak. Szeretnék hallani a nagyobb tapasztalattal rendelkezőktől, hogy jobban megvilágítsák azt, ami túl van.

További növekedési tanácsokért tekintse meg korábbi blogbejegyzésemet: https://betterprogramming.pub/junior-to-senior-developer-in-2-years-3740bd8f8cca