Miért lettem mentor egy Java fejlesztő képzésben?

Magyarországon egyre több junior programozóképzés indul. Ahogy egyre többekhez jut el, egyre több tévhit és félreértés terjed az interneten. Mivel egy ilyenben veszek részt, mint mentor, szeretném egy kicsit erről az oldalról is bemutatni. Minden reklámtól mentesen, és sokszor a technológiára koncentrálva, hiszen ez az én fő területem. 2016 végén kerestek meg a Training360-tól, hogy csatlakozzak a Yellowroadhoz, kidolgozni a Java junior képzés tematikáját, valamint mentorként részt venni a csoportok munkájában, embereket hozzásegíteni egy új karrierhez. Kis gondolkozási idő után igent mondtam. Hogy miért? És hogyan próbálok minden nap helyt állni? Erről szól ez a poszt.

Előző posztomat hasonló témában Programozó szeretnék lenni, menjek-e egyetemre? címmel írtam.

Disclaimer: 2001 óta Java fejlesztőként, architektként dolgoztam, rengeteg projektben vettem részt, programozót interjúztattam, és közben folyamatosan oktattam. Jelenleg a junior fejlesztőképzéssel foglalkozó Yellowroad egyik mentora vagyok. Az itt közölt poszt csak a saját személyes véleményemet tükrözi. Fenntartom a jogot, hogy a posztot folyamatosan bővítgessem, javítgassam.

Ahhoz, hogy a döntésemet indokoljam, először ismerni kell a szakmai tapasztalatomat. A Debreceni Egyetemen végeztem 2001-ben, ahol már az utolsó években demonstráltam (C és Java programozás), valamint egy cégnek programoztam Javaban. Azóta több projektben vettem részt, közigazgatásban, telekommunikációban, bank- és biztosítási szektorban, energetikában. Voltam junior, senior és vezető programozó, architect. Sikerült mindig a technológia közelében maradnom, kevés olyan nap volt, amikor nem írtam volna kódot. Eközben folyamatosan oktattam, volt, hogy egy évben pár hetet, volt, hogy három hónapot. 2016-ban kerestek meg a Training360-tól, hogy legyek tagja a Yellowroad csapatának, és segítsek a Java tematika kidolgozásában, valamint mentorként Java junior fejlesztők képzésében. Kis gondolkodás után igent mondtam, azóta teljes állásban ezt csinálom.

Mi volt a fő indok? El kellett döntenem, hogy jelenlegi élethelyzetemben az eddigi tapasztalatomat hol tudnám a legjobban kamatoztatni. Egy újabb projekt implementálásában, vagy programozó képzésben, ahol tehetséges és motivált embereknek adom át a tudásom, ezzel elindítva őket a programozói pályán. Akik persze olyan szoftverek megalkotásában fognak részt venni, mint magam is tenném. Különösen egy olyan helyzetben, amikor nem csak országos, de globális szinten is ennyire szükség van programozókra. Azt gondoltam, hogy az oktatásban nagyobb hasznomat vennék, és nagyobb szükség van rám. Azt hiszem, ezt nem is kell tovább magyarázni.

Ezt a döntést erősítette azt is, hogy a Training360 vezetőivel, munkatársaival gyakorlatilag egyetem óta folyamatosan együtt dolgozunk, hasonló értékrenddel rendelkezünk, és nagyon hiszünk az oktatásban. Vezetői és oktatás módszertani témákban is sokat tanultam és tanulok tőlük.

Hiszek-e abban, hogy lehet-e ilyen intenzív képzéseken junior fejlesztőket képezni? A tanfolyam nálunk négy hónap hosszú. Ha nem hinnék benne, nem vállaltam volna el. Sajnos a fejekben a junior fejlesztőkről elég vegyes kép él. Természetesen a cégek azokat a fejlesztőket részesítik előnyben, akik mögött 5 év egyetemi képzés áll, a Java nyelvet tökéletesen ismerik, különböző nagyvállalati keretrendszerek (pl. Java EE) ismeretének birtokában vannak, ismerik mind a frontend, mind a backend technológiákat, hibátlanul tudnak algoritmizálni, beszélnek legalább két idegen nyelvet, és jó prezentációs és kommunikációs képességekkel rendelkezzenek.

Ellenben mindenhol vannak kevesebb szaktudást és tapasztalatot igénylő feladatok, projektek, pozíciók. A cégeknek erre elegendő lenne olyan fejlesztőket felvenniük, akik nem az előző csoportba tartoznak, de hamar megértik a feladatot, némi iránymutatás után el tudják végezni, és megvan bennük a potenciál, hogy fejlődjenek, immár a cégen belül. Nem győzöm hangsúlyozni, hogy itt mekkora felelősségük van a kellő tapasztalattal rendelkező senior fejlesztőknek, sőt az oktató cégeknek is a továbbképzésben.

Tehát milyen junior fejlesztőket lehet ennyi idő alatt képezni? Én úgy definiáltam, hogy olyanokat akikkel én magam is szívesen dolgoznék együtt, és helyet tudok találni egy különböző szintű programozókat tartalmazó csapatban. Akiknek, ha elmondom, specifikálom, hogy mit kell csinálniuk, megértik. Mi kell ehhez? Egyrészt nem kell határtalan algoritmizáló képesség, nem feltétlen kell rekurzív algoritmusokat terveznie. Tapasztalatom alapján egy három szinten egymásba ágyazott vezérlési szerkezet megértése és átlátása a határ. Ha ennél bonyolultabbra van szükség, úgyis a rutinosabb kollégák fogják megoldani. A Java nyelv legmélyebb szintű ismerete azonban megkerülhetetlen. Egyrészt az interjúk többségében ilyen típusú kérdéseket tesznek fel, másrészt pontosan és magabiztosan tudja használni az eszközrendszert, a nyelvet, az IDE-t. Ne kelljen gondolkoznia ezek használatakor. (Kb. ahogy az autót kéne a tanuló vezetőknek rutinszerűen használniuk, mielőtt kimennek a forgalomba, ne kelljen azon gondolkozniuk, hogyan nyomogassák a pedálokat.) Ismerjék a kódolási konvenciókat, a tiszta kód elveket és a OO alapelveket (egységbezárás, polimorfizmus, is-a/has-a kapcsolatok, S.O.L.I.D. principlinák, stb.) Ismerjék az alapvető adatszerkezeteket, és azok Javas implementációit, és az implementáció részleteit is. De nem baj, ha nem tudnak táblánál megírni egy gyorsrendezést, vagy egy Knuth–Morris–Pratt keresést. Nem, egyáltalán nem hiszek abban, hogy akár egy keretrendszert is meg kell ismerniük. Minden cégnél mást használnak, másképp, más szabályok szerint. Ugyanígy vagyok a tervezési mintákkal is. Ahhoz, hogy ezeket meg tudják érteni, bizonyos mennyiségű programozási problémába már bele kell futniuk. Viszont hiszek abban, hogy miután elhelyezkedtek, és dolgoznak fél-egy évet, és felszedtek struktúrálatlan keretrendszer tudást, jöjjenek vissza, és kapják meg ezt rendszerezett formában. Nem hiszek abban sem, hogy tökéletesen kell ismerniük az OO tervezést. Melyik junior programozóra bízunk rá olyan feladatot, hogy 5-10 osztálynál több komponenst tartalmazó almodult kelljen megterveznie. Értse az alapelveket, tudjon egy UML diagrammot elolvasni. Megint csak a tapasztalt kollégák dolga az ilyen tervezés, persze ez után már a megvalósítást ki lehet adni a junior programozóknak. Legyen benne a továbbfejlődés lehetősége, de ezt már a cégnél kell biztosítani.

Igen, ez teljesen más, mint az egyetemek hozzáállása. Nem, természetesen nem lehet azt az öt évet három hónapba tömöríteni. Tapasztalatom alapján azonban az egyetemről kijövő friss diplomások között is nagyon nagy különbségek vannak. Van egy vékony felső réteg, akik tehetségesek, megfelelően használták ki az idejüket (lásd Programozó szeretnék lenni, menjek-e egyetemre? posztomat). Ők jól programoznak, tudnak algoritmizálni, jó problémamegoldó képességgel rendelkeznek. Mindenki őket akarja felvenni. Ez gyakran hibás elgondolás. Persze vannak olyan munkahelyek, ahova ők az ideálisak, azonban sok nem ilyen. Egyrészt értük sokan versenyeznek, magasabb a bérigényük, ráadásul nagyon nehéz őket megtartani. Sajnos ezek után van egy hatalmas szakadék, nincs egy átlagos képességű középréteg. Utána azok következnek, akik diplomát szereztek, de nem állják meg a helyüket egy állásinterjún. Nem ismerik a nyelvet, vagy nem tudnak algoritmikusan gondolkodni, esetleg semmi gyakorlati tapasztalatuk nincs. Pont e két réteg közé szeretnénk eljuttatni a nálunk végzetteket. Az egyetemen nagyobb számban végzett, de munkába még nem állítható friss diplomások fölé, de természetesen nem vehetik fel a versenyt azokkal, akik az öt évet kihasználták.

Az egyetemen van egy másik probléma is, hogy nagyon nehéz motiválni az ott hallgató diákokat. Gyakran elég, hogy csak átmenjenek a vizsgán, bemagolják az anyagot. Irreális elvárásaik vannak, mind az oktatással, mind a későbbi munkába állásukkal kapcsolatban. Az intenzív fejlesztő képzésekben részt vevő diákok motiváltak. Egyrészt komolyan érdeklődnek a szakma iránt, és készek áldozatokat hozni, hiszen egy ilyen képzés során vagy rengeteg időt, vagy rengeteg pénzt kell befektetniük. Lehetnek pályamódosítók, akik már rendelkeznek egy szakmával, dolgoztak is, így megtapasztalták, hogy milyen az, mire képesek, mihez lenne kedvük. Ha nem sajátítják el az anyagot, vagy nagyon sokat bukhatnak, esetleg álláshoz sem jutnak.

Alkalmas-e mindenki programozónak? El lehet-e juttatni mindenkit a képzés során ugyanarra a szintre? Mikor belekezdtem, azt gondoltam, hogy kellően felépített tananyaggal, jó mentorokkal, és különböző tanításí módszerekkel igen. Azonban több csoporttal szerzett tapasztalatok alapján azt kell mondanom, hogy nem, nem válhat mindenkiből programozó. És ezt mielőbb fel kell ismerni. Sajnos azonban még nem tudom megfogalmazni, hogy pontosan milyen képességekre is van szükség ezen szakma műveléséhez. Ahol a diákok el szoktak bukni, az egyrészt algoritmikus gondolkodás, amikor egy cél eléréséhez vezető utat nem tudják lépésekre bontani, és azt szekvenciával, szelekcióval és iterációval megfogalmazni. A másik probléma, az absztrakciós képesség hiánya (osztály és példány), a közös jellegek kiemelése, a különbözőségek elhagyása. Harmadrészt a mintafelismerés, valamint a minták használatával a problémamegoldás, a minta megfelelő módosításával. Továbbá problémát szokott okozni a struktúra felismerése, a bonyolultabb problémák kisebbekre bontása, valamint a mindig a megfelelő szinten való gondolkodás. Ezt ott lehet tettenérni, hogy a diák csak tekergeti a scrollbart, a teljes forráskódot egyszerre akarja megérteni, nem képes kizárólag pl. egy metódusra koncentrálni, érteni akarja a osztály teljes struktúráját, valamint a hívó oldalt is. Nem azt mondom, hogy nem tanítható rá meg mindenki, de azt igen, hogy ennyi idő alatt biztos nem.

Külön fejezetet lehetne szentelni annak, hogy mennyire nem tudnak tanulni, különösen önállóan. Mi három oldalról is támogatjuk a tanulást. Egyrészt klasszikus frontális oktatás, egy-egy lecke bemutatása élőszóban, élőben kódolással. Ami meglepő, hogy kb. húsz perc az, ameddig koncentrálni tudnak. Utána lankad a figyelem. Persze, lehetne mondani, hogy érdekessé kell tenni az oktatást. Itt azonban nem szórakoztatás zajlik, hanem oktatás, és igenis vannak száraz anyagrészek, nem standup van, a generikus wildcardok esetén az upper bound használatát nem lehet könnyű musical betétként előadni. Amúgy is mindenkinek más az érdekes. Van angol nyelvű könyv is, valamint rengeteg hivatkozás, az önálló, olvasni szerető diákoknak. És van a mentorált oktatás, ahol mindenki maga dolgozza fel az előre videóra felvett anyagot, és oldja meg mentori segítséggel a feladatokat. Itt mindenki a saját tempójában tud haladni. Érdekes, hogy vannak ismétlő kérdések az anyagban, ami arra való, hogy át lehessen venni segítségükkel az anyag elméleti részét. Ezeket a diákok többsége olvasás nélkül átugorja.

És vannak, ha nagyon kevesen is azok, akiknek út közben derül ki, hogy mégsem ezzel akarnak foglalkozni, vagy egyszerűen túl lazán veszik, és azt hiszik, iq-ból, tanulás nélkül megoldják. Nem, ez így nem fog menni. Többségük még időben döbben rá erre, azonban egy elhanyagolható, de létező százaléknak ennek felismerésében is segítség szükséges.

Természetesen nagyon szeretek alkalmazásokat tervezni, majd részt venni azok implementálásában. Azonban egészségesnek tartom bizonyos időközönként kicsit kikapcsolni, az addig összegyűlt tudást mélyíteni, rendszerezni, átadni, majd ezután újra visszatérni. Hiszek abban, hogy nem lehet folyamatosan tanítani, részt kell venni éles projektekben, különben az ember eltávolodik a gyakorlattól, és nem tud hiteles maradni, nem követi az újdonságokat. Azonban senior szint és afelett a fejlesztőnek kötelessége a tudását átadni. Ez legtöbbször cégen belül történik, azonban ha erre szélesebb körben is lehetőség nyílik, érdemes megfontolni.

Hiszek abban is, hogy a fejlesztésből néha ki kell szállni, ugyanis hajlamos az ember egy kicsit kiégni. Nekem nagy szerencsém volt az eddigi munkahelyeimmel és a projektjeimmel. Ha nem olyan jól sikerül a projekt, az ember hajlamos kicsit kiábrándulni. Ennek oka lehet pl. határidő csúszás, túlóra, irreális ügyfélelvárások, rossz architektúra, rosszul megválasztott technológiák, rossz ügyfélkezelés, nem motivált kollégák. Biztos te is vettél már részt olyan projektben, mely a fióknak készült, belekerültél végelláthatatlan szubjektív érveket felsorakoztató technológiai csetepatékba, implementáltál olyan funkciókat, melyeket az ügyfél nem használt, vagy refaktoráltál úgy kódot technológiai felettesed kérésére, amelyben nem hittél. Ekkor nem is kérdés, hogy ezek helyett hasznosabb-e tanítani, hiszen ha az a tudást, amit átadsz, az ott ülő tíz-húsz junior fejlesztő csak egy része is hasznosítani tudja, már többszörösen megtérül.

A tanulás egyik legbiztosabb formája az oktatás. Egyrészt itt komoly határidők vannak, az átadandó anyagot időre kell tökéletesen elsajátítanod. Sajnos egy projekt közben nincs időd arra, hogy minden technológiának, módszertannak alaposan utánanézz, átvedd az elméleti alapjait, netalántán el is gondolkodj azon, miért így kerültek kialakításra. Hogy cikkeket és könyveket olvass, hogy magad is tanfolyamokat végezz el. Ha oktatsz, akkor időt kapsz a felkészülésre. Nagyon sok dolog nekem is oktatás közben “esett le”, rögzült. Hogy ugyanazt próbálod több oldalról is megvilágítani. És persze a hallgatók folyamatos kérdései, amelyek sok esetben rendkívül éleslátóak és részletekbe menőek, mondhatni szőrszálhasogatóak, a folyamatos fejlődés zálogai. Nem kell ott azonnal mindenre válaszolnod, de utána kell nézned.

És igen, van egy nagy adag szórakozás is benne. Egyrészt minden technológiai feltétellel el vagyunk látva, modern szerverek, munkaállomások, notebookok, stb. Rendelkezünk egy csomó Arduinoval, Raspberry Pi-vel, és LEGO Mindstorms EV3-mal. Ezek mind rendkívül motiválóak tudnak lenni, megteremtik a tárgyi feltételeket, színesítetik az oktatást. Ezen kívül sok jó szakemberrel vagy körülvéve, akik értenek nem csak a Javahoz, hanem más programozási nyelvhez, és platformhoz is, úgymint JavaScript, PHP, .NET, Python, stb. Jó látni, hogy ugyanazt a problémát más nyelvekben hogyan oldották meg.

Kérdezték, hogy nem hiányzik-e a kódolás. Nem, hiszen minden nap rengeteget kódolok. A jelenleg kidolgozott anyag több, mint 200 leckéből áll, minden leckéhez egy vagy több gyakorlati feladat. A feladatok megoldása több, mint 12 000 kódsorból áll, projektenként magasabb, mint 80%-os tesztlefedettséggel. Continuous integraton és code quality rendszerekkel dolgozunk. Ezen kívül a hallgatókkal minden reggel valamilyen algoritmikus problémát oldunk meg. Vagy gyűjtjük a pontokat a HackerRanken. Ezek akár coding dojoként is felfoghatóak. Igaz, hogy ezek apróbb feladatok, de gyakran nagyobb kihívást nyújtanak, mint egy sokadik képernyő implementálása. Valamint rendkívül változatosak tudnak lenni.

Nem csak kezdő programozó képzés van, hanem haladó képzésekben is részt lehet venni, mint Java EE, Spring Framework, Maven, tervezési minták, unit tesztelés, perzisztencia (pl. JPA). Számomra az egyik legérdekesebb képzés a nemrég tartott Haladó JPA tanfolyam volt, amelyre több éves JPA tapasztalattal rendelkező programozók jöttek, és csak olyan haladó témákról esett szó, mint lazy fetch, entity graph, tranzakciókezelés, query hints, lockolás, first és shared cache, valamint provider specifikus performancia hangolások. Természetesen ezen én is sokat tanultam tőlük.

Ebben a posztban a saját véleményemet fogalmaztam meg. Szeretném elejét venni az értelmetlen, cél nélküli vitáknak azzal, hogy felajánlom, hogy akit nem sikerült meggyőznöm, továbbra is úgy gondolja, hogy ezen programozó képzések nem elég hatékonyak, vagy a céljuk a diákok kihasználása, hogy nincs mögötte érdemi előkészítés, komoly munka, vendégem egy kávéra, szívesen leülök vele, és ha közösen értelmét látjuk, akár benézhet egy oktatásra, beszélhet egy diákunkal, hogy lássa, meddig lehet eljutni ennyi idő alatt.

Ha a mentorálás esetleg felkeltette az érdeklődésedet, és szeretnél részt venni a programban, keress meg!