Az utóbbi időben egyre jobban érdeklődni kezdtem a filozófia iránt, különösen a Sztoicizmus esetén. Ennek a tanításait meglepően gyakorlatiasnak és alkalmazhatónak találtam a modern élethez. De mit tudnak a Sztoikusok tanítani nekünk, hogy jobbá váljunk a szoftverfejlesztésben?
Epiktétosz az egyik fő személye a Sztoicizmusnak. Az egyik kulcsfontosságú tanítása, amire fókuszált, a Sztoikus irányítás dichotómiája (kettőssége). A Beszélgetések művében így mondja:
"A fő feladat az életben egyszerűen ez: azonosítani és elkülöníteni a dolgokat, hogy azt mondhassam magamnak, mik azok a külső dolgok, amik nincsenek az irányításom alatt, és mik azok a választásaim, amiket valóban irányíthatok."
Epiktétosz Beszélgetések II.5. (How to be a Stoic könyv, Massimo Pigliucci idézete alapján, Basic Books, 2017)
Egyszerűbben kifejezve, ez annak a ráeszmélése, hogy egyszerűen nincsen minden a mi irányításunk alatt a világban - és meg kell tanulnunk bölcsnek lenni, hogy arra fókuszáljunk, amit irányíthatunk, és meg kell tanulnunk kevesebbet aggódni arra nézve, amiket nem irányíthatunk.
Egy kis megjegyzés, ez az ötlet egyáltalán nem egyedi a Sztoicizmusra nézve. Az ókori tanítók már rájöttek erre, kultúráktól és koroktól függetlenül. Például találunk hivatkozásokat a keresztény teológiában és a buddhizmusban is.
Az irányítás dichotómiájának átölelése a szoftverfejlesztésben
A szoftverfejlesztés, mint szakma eléggé színes, és a kihívásai sokfélék és változatosak. Az egyik kihívás ezek közül az, hogy a közvetlen irányításunk korlátozott azon sokféle faktor felett, amik befolyásolják a munkánkat.
Megadok itt néhány példát a saját tapasztalatom alapján:
Kiváló megbízhatóságú és rendelkezésre állású szolgáltatásokat keresünk. Aztán egyik nap az S3 (Amazon felhőszolgáltatás) megadja magát és magukkal ránt minket és vele a fél Internetet. Izé!
Azt szeretnénk, hogy a leszállítandó fejlesztéseket a megállapodott határidőn belül megvalósítsuk. Ezután váratlan összetettségű szituációba kerülünk a fejlesztés során, amit a felhalmozott technikai adósság okoz (tech debt). Ez azt okozza, hogy az eredeti becsléseink fájdalmasan pontatlanok lesznek. Hupsz!
Előléptetést szeretnénk elérni. Ezután jön egy visszajelzés az előléptetésről döntő bizottságtól, hogy a csapatunkban lévő fejlődés ellenére még mindig magunk mögött vagyunk és bizonyítanunk kell több területen is. Nos, hát...
Arra törekszünk, hogy az álom munkát megtaláljuk az interjúk során. Ezután összekerülünk egy interjúztatóval, aki tele van előítéletekkel, amik ellenünk működnek, és emellett még rossz napja is van. A végén azt mondja, próbálkozzunk 6 hónap múlva annak ellenére is, hogy a legjobb formánkat hoztuk. Kellemetlen...
Megtürtőztetve magunkat a kétségbeesett sírástól, azt állítva, hogy a világ és az istenek ellenünk vannak, észrevehetjük a mintát, hogy mi az, ami közvetlen irányításunk alatt van, és mi az, ami nincs.
Képtelenek vagyunk...
...megjósolni milyen alapvető infrastrukturális komponens fogja megadni magát holnap. Követhetjük a bevett trükköket az elosztott rendszerek tervezése során, és beépíthetünk extra redundanciát és feladatátvételi mintát a tervezésünkbe, a legjobb tapasztalatunk, képességünk és erőforrásunk szerint.
...heteket tölteni egy feladat becslésével, hogy az összes rejtett komplexitást felfedezzük, vagy refaktorálni az összes csúnyaságot a kódbázisunkban. Hozhatjuk a legjobb formánkat a becslés során és biztosíthatjuk, hogy az érdekelt feleket naprakészen tartjuk és kezeljük az elvárásaikat, amikor valamilyen váratlan dologba rohanunk.
...hogy tökéletesen kalibrált belső mércével rendelkezzünk a következő előléptetési szinthez, amit el szeretnénk érni. Talán valóban nem érünk fel hozzá, de nem is tudjuk, hogyan kéne. Fenntarthatunk egy hatékony kapcsolatot a menedzserünkkel és beszélgetéseket kezdeményezhetünk, hogy milyen kompetenciákat teljesítünk jelenleg és min kell még dolgozni. Meg tudjuk írni az előléptetési dokumentumunkat a legjobb képességeink szerint.
...irányítani a következő interjúk körülményeit vagy eldönteni ki lesz az interjúztatónk, hogy biztosítsuk a tökéletes kémiát. A legjobb képességeink szerint felkészülhetünk az interjúra, azáltal, hogy kikutatjuk, hogyan fog kinézni az interjú tölcsér az adott cégnél, gyakorolni a gyakori kérdéseket vagy jegyzetelni példa szituációkat a régebbi interjúkból a gyakori viselkedés jellegű kérdések esetére.
"Ezt könnyebb mondani, mint megtenni." Tudom. Valami, ami az irányításunk alatt van, nem jelenti azt, hogy könnyű kontrollálni.
A kulcs üzenet az, hogy bölcsnek kell lennünk ahhoz, hogy kevesebbet aggódjunk azon dolgok iránt, amik felett nincsen irányításunk és fókuszáljunk azon dolgokra, amik felett van befolyásunk.
A valóságban pedig megkülönböztetni a kettőt nem olyan könnyű, ugye? A két kategória közötti megkülönböztetés jellemzően zavaros, különösen amikor túlságosan benne vagyunk egy szituációban, ahol minden nagyobbnak és félelmetesebbnek tűnik - a nagy összefüggések, minták alapján - mint amilyenek azok valójában. Ez az, ahol a tapasztalatok összeadódnak és a gyakorlati bölcsesség, amit építünk, reflexió által képbe kerül.
Elfogadni a tökéletlenséget
Az egyik dolog, amit megtanultam ebben az iparágban az az, hogy megfelelően kell cselekedjek ahhoz, hogy átöleljem a tökéletlenséget és azzal kezdjek valamit. A precizitásra és tökéletességre törekvők jellemzően nem teljesítenek jól ebben.
Az összes randa szituáció esetén, ami megtörténhet velünk szoftvermérnökként, az a helyzet, hogy több dolgot is tehetünk hogy csillapítsuk őket. Ezek csökkentik az esélyét ezeknek a szerencsétlen eseményeknek, hogy megint megtörténjenek, de nem fogják megszüntetni a kockázatot. Ezek gyakran kétélű kardként működnek, és nem kívánt következményekkel járnak. Csakhogy megemlítsek ezekből néhányat:
A tesztek nem fognak megmenteni az éles környezet hibáitól, de segíteni tudnak. A tesztek extra karbanartást igényelhetnek és lelassíthatják a termékfejlesztés gyorsaságát - vitatható téma tudom, de most itt egyszerűsítek kicsit. Talán nincs szükségünk 100%-os tesztlefedettségre és TDD-re egy olyan termék feature esetén, ahol a piaci érvényességét szeretnénk kideríteni - ehelyett néhány erős jelre lehet szükségünk az end-to-end tesztek formájában.
A részletes termék metrikák és az irányítópultok nem mentenek meg minket a kihagyásoktól, de segíthetnek. Ezeket túl is tolhatjuk, ami információs túltengést okozhat, és így az emberek elvesznek a színes grafikonok labirintusában és előfordulhat, hogy nem néznek rájuk alaposan. Talán csak egy irányítópultra van szükség, ami az 5 legfontosabb magas szintű metrikát mutatja ad-hoc elemzéssel egy szituáció esetén - ahelyett, hogy 40 grafikont mutatna az összes lehetőséggel, így könnyedén felszerelhetjük ezzel a szolgáltatásunkat.
A paranoid kiterjesztési taktikák nem fognak megmenteni a kihagyásoktól, de segíthetnek. Ezeket úgy is meg lehet tervezni, hogy túlzottan óvatosak legyenek, ami azt okozhatja, hogy a teljes fejlesztés gyorsasága értelmetlen mértékben lelassul. Talán nincs szükséged arra, hogy teszteld az új Adatvédelmi Irányelvek oldal fejléc tervezését egy tesztelés alatt lévő piacon egy hónapon keresztül, azon aggódva, hogy eltörheti a tölcsér lényegi részét.
Egyensúly
Ha irányítással rendelkezünk valami felett, az nem jelenti azt, hogy túlzásba kéne esnünk vele. Egy egészséges egyensúly a termék megtérülésében az, amit a sikeres mérnökök jól csinálnak. Ez egy trükkös dolog, mert az ideális állapot egy mozgó célpont - azoktól a körülményektől függ, amikben éppen vagyunk.
Szokás szerint nincsenek egyszerű megoldások az összetett problémákra, de állandóan fejlesztenünk kell a megközelítéseinken. Ez azt jelenti, hogy egy idő után elbukunk néhányszor, vagy azért, mert nem tettünk meg eleget, vagy azért mert túlzásba estünk - és ez rendben is van, addig, amíg tanulunk belőle és korrigálunk.
Az egyik dolog, amin dolgozni szoktunk a csapatainkban, amikben tag vagyok, az a gyakori kísérletezés szokása azokon a pontokon, amik felett irányításunk van - de ez megérhet egy önálló posztot valamikor.