Jómagam mintegy 30 éve kezdtem el informatikával foglalkozni, "kemény kockaként" nőttem fel, aminek megvannak a maga előnyei, élveztem is őket, de egyre inkább szembesültem a hátrányaival is. Talán emiatt is kezdtem el körülbelül 20 éve önismerettel foglalkozni egyre intenzívebben. Majd rádöbbentem, hogy ez engem jobban motivál, mint maga a programozás, így pár éve teljesen váltottam. Jelenleg coaching folyamatokkal és önismereti jellegű egyéni konzultációkkal foglalkozom, ahol a motiváció témaköre igen gyakran előkerül.
A régi és az új "szakmámat" összevetve azt látom, hogy jól használható analógia van a számítógépek - az ember által tervezett legbonyolultabb gépek - és az emberi működés között. Ha ezt az analógiát megismerjük, akkor informatikusként a már meglévő tudásunkat önismereti szempontból is kamatoztathatjuk.
Program (és motiváció) továbbfejlesztés menete
Az alábbiakban egy program továbbfejlesztésének/javításának menetét mutatom be a végletekig leegyszerűsített formában:
1. A hiba észrevétele: egy program használata során viszonylag könnyen érzékeljük, ha hibázik. Ugyanígy önmagunk "használata" közben is érzékeljük, ha valami nem stimmel. A lelki működésünknek jó indikátora például a "motiváltság", amit elég könnyen észrevehetünk, ha egy ideje már "nem az igazi". Így ez a lépés általában viszonylag könnyű.
2. A hiba komolyan vétele: ez a lépés már sokkal nehezebb. A programhiba esetén ez abban nyilvánulhat meg, hogy például bejelentjük a hibát. Na, de az észrevett hibák mekkora részét szoktuk bejelenteni? Általában nem túl nagyot, ami egy sokak által használt program esetében lehet egy működő stratégia: majd úgyis észreveszi valaki más, bejelenti, vagy maguk a fejlesztők bukkannak rá, és a következő verzióban kijavítják, és nekem csak frissítenem kell. De ez a stratégia nem működik az egyedi programoknál, márpedig rajtunk "egyedi program" fut. Ha ebben a "programban" valami hiba van - aminek a jele lehet például a tartós demotivált állapot is - akkor az energiabefektetésünk nélkül magától nem sok eséllyel fog megjavulni. Ezt informatikusként pontosan tudjuk például a saját kütyüink esetében: ha valami gond van velük, akkor utána kell járni, időt, energiát, pénzt kell belefektetni, hogy kijavítsuk. Vajon magunkba, a saját "fejlesztésünkbe" fektetünk-e energiát, vagy csupán várjuk, hogy majd csak lesz valami?
3. A hiba körüljárása: ha úgy döntünk, hogy belefektetjük a szükséges energiát, akkor jön a következő lépés: mit is írjunk a "hibajelentő űrlapba"? Mikor jön elő a hiba? Pontosan mi történik? Hasonlóképpen kezdődik egy coaching folyamat is: igyekszünk körüljárni, hogy pontosan miről is van szó, mikor jön elő, vagy mikor nem - ez utóbbi néha külön jelentőséggel is bír. Sőt egy jó tesztelő nemcsak annyit tesz, hogy az első hibának érzékelt működést lejelenti, hanem kicsit "játszik" vele, és megpróbálja felderíteni, hogy mi lehet a hiba gyökere. Egy ilyen alaposabb tesztelés után leírt hibajelentés különösen nagy kincs a fejlesztők számára. Hasonlóképpen a coachingban is megpróbáljuk megnézni, hogy mi a probléma gyökere. Sok esetben ez korlátozó hiedelem, amit valamikor régen "tanultunk" nem tudatosan, és most is aszerint próbálunk cselekedni. Holott, ha tudatosítjuk ezt a hiedelmet, lehet, hogy könnyen belátjuk, hogy ez a hiedelem már nem is igaz, ami nagyban segít abban is, hogy később változtatni tudjunk rajta.
4. A hibajavítás: ezt több szinten művelhetjük. Én most az egyszerűség kedvéért csak két szintet mutatok be:
4.1 Felületes javítás: a legfelületesebb javítások egyikét "workaround"-nak is szokták nevezni, ami lényegében nem javítja ki az adott problémát, hanem csak kicsit átrendezi a rendszert, hogy lehetőleg kevesebbszer vagy kevésbé súlyosan jöjjön elő a hiba. Ez céges környezetben sokszor delegálást jelent: ha azonosítjuk, hogy nekünk valami nem megy, például kommunikációs stílusunk inkább passzív, erősen konfliktuskerülő, akkor egy-egy nehéz ügyféllel jobb, ha nem mi beszélünk, hanem átadjuk azt egy olyan munkatársunknak, akinek jó a kommunikációs készsége. Ettől persze a probléma nem múlik el, és - főleg, ha vezetők vagyunk - akkor a cégen belül és azon kívül is nagy szükségünk van az asszertív kommunikációra.
4.2 Mélyebb javítás: ilyen fajta javítás például a refaktor, amikor az adott kódbázist mélységben átdolgozzuk. Ez általában sokkal tovább tart, mint egy felületes hibajavítás - órák helyett inkább hónapokban mérhető - és ráadásul sokkal nehezebb is megbecsülni az idejét. Ennek analógiájára jelentősen nagyobb energiabefektetést igényel az önmunka is a mélyebb rétegeinken, de valódi minőségi javulás csak így képzelhető el.
A mélyebb rétegeink
A számítógépek világában leegyszerűsítve az ábrán látható rétegeket különíthetjük el. Minél felületesebb egy réteg, annál könnyebb rajta változtatni. Például az ember állása - stílszerűen - az alkalmazásrétegben található: programozói állásunkat lecserélni egy másik programozói állásra - mert mondjuk, nem jöttünk ki a főnökünkkel - viszonylag könnyű megtenni. Más kérdés, hogy lehet, hogy az új helyen sem fogunk kijönni a főnökkel, ha valójában a saját mélyebb rétegeinkben van a probléma.
Mik a mélyebb rétegek? A két legmélyebb szoftveres réteg a firmware és az operációs rendszer rétege. Ezekbe programozóként is sokkal ritkábban nyúlunk bele. Minek felel meg ez bennünk? Leginkább olyan fogalmakat párosíthatunk vele, mint a hiedelmek, sémák, vagy egy másik terminológiában parancsok/tiltások, avagy a sorskönyvünk, ami ezeknek egy egész forgatókönyve. Ahogy a gépek esetében is rögtön a gyártás után felkerülnek ezek a szoftverrétegek, ugyanúgy a mi mélyebb szintű programozottságunk is nagyon fiatal gyermekkorban íródik belénk, ráadásul túlnyomórészt nem tudatosan.
Ez utóbbi adja a dolog nehézségét is. Mivel ezeknek a mélyebb programjainknak (főleg az önismereti út elején) nem vagyunk tudatában, így külön kihívás a saját viselkedésünk önreflexív megfigyelése segítségével felfedezni, "debuggolni", és aztán javítani azt. Ráadásul az adott probléma mélységétől és súlyosságától függően más-más szakember vagy módszer segítsége lehet számunkra igazán hasznos.
A következő verziónk
A fenti esetben valamilyen hiány vagy szenvedés indított el az (ön)fejlesztés útján, mert valami nem működött jól. Ugyanakkor van olyan is, amikor igazából nincs semmi "nagy baj", mint amikor a programunk aktuális verziójában nincs hiba, teljesen jól működik, akkor miért kellene a "következő verzióra" frissítenünk? Aztán egy idő után egyre problémásabbá válik a helyzet, mert a világ fejlődése elhúz mellettünk...
Az életben hasonlóan történik: egy ideig jól elvagyunk egy adott állapotban, de ha belül nem változunk, akkor annak hiányát a motiváltságunk csökkenése jelezni fogja. Először csak finoman, aztán egyre erősebben, végül akár testi tünetekben is megnyilvánulhat.
Na, de hogyan tudjuk, hogy merre van a mi "következő verziónk", hogy "kik vagyunk mi valójában"? Ha bővebben is szeretne utánaolvasni a témának a kedves olvasó, javaslok két kiindulópontot:
- S.R. Covey "A kiemelkedően eredményes emberek 7 szokása" című könyvben ezt személyes küldetésnyilatkozatnak nevezi, és támpontokat ad arra, hogy hogyan dolgozzuk ki.
- Simon Sinek miért nyilatkozatnak nevezi, aminek a megtalálására a "Találd meg a miértedet!" című könyvében osztja meg a módszerét.
Az emberiség azonban már régebb óta foglalkozik ezzel a kérdéssel: a keleti filozófiákban dharmának nevezik, Japánban pedig ikigainak. Ez utóbbit a nyugati tanulmányozónak talán a következő ábra mutatja be a legjobban:
Eredményes debuggolást és verzió frissítést kívánok!
A teljes előadásomat videóformában ezen a linken találhatja meg a kedves olvasó.
