Computerworld magazin 2022.06.29. LIII. évfolyam 12. szám

More documents

Recommendations

Info

HAVASI FERENC life & business coach havasiferenc.hu TECHNOLÓGIA Hogyan upgradeljük a motivációnkat informatikusként? Első hallásra az informatika és a motiváció két nagyon távoli terület: az informatika erősen reáltudomány, a „kockák” világa, míg a motivációt leginkább a pszichológiához, önismerethez kötjük, ami pedig humán terület. 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: – 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. 20 | | 2022.06.22.
TECHNOLÓGIA 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. – Mélyebb javítás: ilyen fajta javítás például a refaktor, amikor az adott kód - bá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 ne - hezebb 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 Alkalmazások 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. Programkönyvtárak Operációs rendszer Firmware Hardware 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 fi r m w a r e é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. Eredményes debuggolást és verzió frissítést kívánok! A teljes előadásomat videóformában a következő QR-kód alatt találhatja meg a kedves olvasó. 2022.06.22. | | 21
Page 1 and 2: 2022. június 22. • LIII. évfoly
Page 3 and 4: TARTALOM | 2022. június 22. / IMPR
Page 5 and 6: Azonosságvédelem egységesen A bi
Page 7 and 8: AKTUÁLIS Idén is bárki jelölhet
Page 9 and 10: AKTUÁLIS a termék értékesítés
Page 11 and 12: LEGALTECH A jogi technológiák hat
Page 13 and 14: 24 June Friday Panel 2 Legaltech in
Page 15 and 16: LEGALTECH rossz ebből a szempontb
Page 17 and 18: TECHNOLÓGIA gáltatásra. Emellett
Page 19: AKTUÁLIS Előretekintve az IT-veze
Page 23 and 24: TECHNOLÓGIA QAYUM DANIEL tanácsad

Computerworld magazin 2022.06.29. LIII. évfolyam 12. szám

Create successful ePaper yourself

Delete template?

Save as template?