Miért nem online mindig egy oktató?

Pár ügyfelünk megjegyezte már, hogy jobb lenne, ha folyamatosan online lenne egy oktató, hogy ha felmerül valami kérdés a tanulás során, akkor meg lehessen tőle kérdezni.

Megértem a kérdés mögött húzódó szándékot. Mihamarabb választ akar kapni, hogy minél többet tudjon tanulni.

Hogy miért döntöttünk úgy, hogy ezt a szolgáltatást egy rendszeres, de viszonylag ritka mentorálásra építjük fel?

Az a célunk, hogy programozókat képezzünk azokból, akik egyelőre még nem értenek hozzá. Mivel hiú vagyok, szeretném azt, hogy aki ebből a rendszerből kikerül, az nemcsak “egy junior programozó” lenne vagy “egy futottak még junior programozó”, hanem “kiváló junior programozó“.

Hogy mitől lesz valaki kiváló?

Kezdjük azzal, hogy egy picit belegondolunk, hogy miért is vesznek fel egy céghez új programozót: nyilván azért, mert kevés a kapacitás. Azok, akik jelenleg ott dolgoznak, már nem bírják a munkát, és bővülésre van szükség, új munkaerőt kell bevonni. Céges szempontból az új munkaerő betanítása mindig egy pluszmunka: valaki a megszokott munkáján felül foglalkozik azzal, aki újonnan jött. És ugye már így is kevés a kapacitás…

Szóval mit szólnának az új cégednél ahhoz, ha ahhoz lennél szoktatva, hogy bármi kérdésed van, odamész valakihez, megkérdezed, majd 10 perc múlva megint. A programozás elmélyülést kívánó munka, megzavarás esetén 10 perc kell, mire újra fel tudja venni az ember a saját fonalát. Mi van akkor, ha 10 perc múlva a junior újra jön a következő kérdéssel? Végül a senior (akinek amúgy már eddig is túl sok volt a munkája) gyakorlatilag semmit nem tud elvégezni, mert állandóan a junior betanításával foglalkozik. Tehát a cég rosszabbul jár, mint akkor, ha fel sem vesznek, mert te még nem végzel munkát, de a betanításod miatt már a senior sem tud. (Nem véletlenül mondják a rossz nyelvek projektmenedzsmentből, hogy egy csúszásban lévő projekt csúszását az új ember bevonása csak tovább növeli)

Ezt senki nem akarja. Te sem, én sem és a céged meg főleg nem.

Ezért inkább a legelejétől ahhoz szoktatunk, hogy a szupervíziók viszonylag ritkák (olyan ütemezésben, ahogy egy seniort sem zavarna a kérdezés), és a köztes időkben pedig rá vagy kényszerítve arra, hogy önállóan haladj. Adott esetben önállóan utánanézz a dolgoknak, egy jól körülhatárolt problémára önállóan próbálj megoldást találni. Ha nagyon “elvesznél az erdőben”, pár nap múlva ott az oktató, aki kirángat az erőd mélyéről és visszatérít a megfelelő útra, de addig is nyertél egy csomót:

  • gondolkodtál önállóan egy kihívást jelentő problémán (programozóként is általában ezt fogod tenni)
  • olvasgattál az interneten, a cikkek értelmezéséből fejlődtél egy csomót (programozóként is általában ezt fogod csinálni)
  • ha rájössz a nyitjára, az a legjobb, mert önálló felfedezésből lehet a legjobban tanulni, ez tuti megmarad egy életre, és még a programozással kapcsolatos önbizalmad is növekszik
  • szokod azt, hogy nincs ott mindig a senior, hogy önállóan dolgozz, így szokás szinten beléd ivódik, hogy kiváló junior programozó legyél
  • szokod azt, hogy megküzdj azzal az érzéssel, amit programozóként érezni fogsz, mikor úgy látszik, hogy kifog rajtad egy probléma (elő fog fordulni)

És mégsem vagy magadra hagyva, mert ha minden kötél szakad, ott az oktató pár nap múlva: elmondja a megoldást, támogat, biztat, újraépíti az önbizalmad, és továbblök a következő szintre.

(Az oktatásunkra való jelentkezés első lépése az Alkalmas vagy programozónak? teszt kitöltése)

Kell-e “papír” ahhoz, hogy valaki programozó legyen?

Ha néhány évet visszalépünk az időben, mondjuk az ezredforduló utánra, akkor még bizony az volt az általános, hogy jó helyre csak akkor tudott bekerülni valaki, ha volt diplomája valamely híresebb egyetemről vagy főiskoláról. A rossz nyelvek még azt is mondták, hogy ha egy bizonyos iskolában végeztél, akkor az önéletrajzod automatikusan a kukában landolt, míg ha egy másik helyen, akkor automatikusan be is hívtak interjúra.

Azóta sokat változott a világ. Számos új programozandó eszköz jelent meg (pl. okostelefon platformok), és a cégek (illetve az ügyfeleik) is jobban igénylik, hogy digitális szolgáltatást kapjanak (netbank, webshop, online ügyfélszolgálat…), ezért az igény azóta jelentősen megnőtt, nem csak Magyarországon, hanem a világban máshol is. Az informatikusok száma nem követte eléggé az igények növekedését.

Persze el kellett telnie egy kis időnek, míg a cégek HR-osztálya is elfogadta, hogy megváltozott a világ, és nem lesz képes minden egyes cég a legjobbakat magához vonzani, és ott tartani.

Tavaly kimentünk a HVG Állásbörzére körbenézni (jól szervezett rendezvény, merem ajánlani!). Az egyes területek képviselőinek különböző színű mappákat adtak, az informatikáé a kék volt. A kék mappa gyakorlatilag úgy viselkedett, mint a mézes madzag. Csak sétáltunk egyik helyszínről a másikra, egymással beszélgettünk, menet közben megállítottak, és invitáltak megnézni a cégük ajánlatát.

Egyik célunk az volt, hogy utánajárjunk a “papír” kérdésének, így megkérdeztünk erről a témáról minden olyan céget, aki feltüntette a tájékoztatójában, hogy juniorokat is felvenne, hogy mi az ő hozzáállásuk. 10 és 20 közötti céget kerestünk fel, és mindössze egyetlenegy volt az, aki azt mondta, hogy csak és kizárólag diplomás embereket akar felvenni. A többieknél a tudás volt a fontos.

A tudás viszont fontos, és minél aktuálisabb valakinek a tudása az adott területen, annál jobb.

Néhány információmorzsa még:

  • a Google 6 évvel a megszerzése után már nem tekinti előnynek a diplomát (mert elavul a tudás és a szakmai tapasztalat fontosabb, akár diplomás az ember, akár nem)
  • az egyetemeken első sorban általános tudást adnak, sok különböző szakma/téma alapjait is elsajátíthatod egy-egy képzésen belül. Számtalanszor volt olyan élményem az egyetemen egy-egy tárgy kapcsán, hogy szívesen belemélyednék, és megismerkednék vele mélyebben is, de tovább kellett rohannunk. Így például megtanultam a távközlő hálózatok alapjait, de nem lett belőlem cégnél bevethető tudásszintű távközlési mérnök
  • volt már, aki a Stackoverflow pontjai (ún. reputation) miatt kapott állást
  • a LinkedIn vélemények és endorsementek (valaki más úgy nyilatkozik, hogy te értesz valamihez) egyre fontosabbak

Már a tanfolyam fejlesztésének elkezdésekor is a bárki számára ellenőrizhető tudás átadására koncentráltam, de mivel volt rá igény, oklevelet mi is kiállítunk, ha elvégzed a képzéseinket (Java, Maven, Git,…).

Hogyan legyél programozóként is profi?

Rendszeresen hangoztatom különböző oldalaimon, hogy elég, ha csak addig eljutsz, hogy felvegyenek programozónak, és a cégnél értékes munkát tudj végezni, utána már megy minden, mint a karikacsapás.

De tulajdonképpen hogy is van ez miután felvettek?

Nagyobb vagy tőkeerősebb cégek esetében a felvett junior programozó először a cég belső tanfolyamán találja magát, ahol egyrészt egy közös szintre hozzák az újakat, illetve meg is ismertetik őket a vállalat sajátosságaival (pl. konkrét eset, hogy ha egy csomagküldő szolgáltató informatikai részlegére mész dolgozni, akkor a csomag kézbesítésekor használatos kis terminálról is oktatnak), a cégen belüli folyamatokkal. Felkészülhetsz arra, hogy ilyen esetben 1-2 hónapig, vagy akár 3-4-ig is a cég azért fizet, hogy tanuljál. Nem meglepő ebben az esetben – végtére is az oktatás egy elég drága és értékes mulatság – tanulmányi szerződést kötnek veled. Az oktatásodért cserébe elvárnak 1-2 év szerződést, amikor te nem mehetsz el, csak ők tehetnek ki. Ez teljesen normális. Ha már kiképeznek, legyen meg a hasznuk.

Kisebb cégek a felvétel utáni képzést általában nem engedhetik meg maguknak, már csak azért sem, mert egyszerre nem vesznek fel annyi embert, hogy a külön oktató megfizetése megérné. Ilyen esetben általában egy rövidebb és kevésbé formális betanulás után jöhet az éles munka – és az aközbeni tanulás. (Attól még, hogy nincs formális oktatás, nem kell leírni egy céget: sokszor érdekesebb munkák vannak, a fejlesztési ciklus hamarabbi szakaszába kapcsolódhatsz bele, így igazán sajátodnak érezheted azt a projektet, amin dolgozni fogsz. Ráadásul könnyebben meg lehet beszélni és oldani helyzeteket, ha a “nagyfőnök” szinte folyamatosan az üzletmenet része).

Ha olyan cégnél találod magad, ahol nincs formális képzés (amire várhatóan on-the-job betanulásként hivatkoznak), akkor kapsz egy feladatot, és oldd meg, és közben rájössz a mikéntjére.

Hogy mindezt hogyan?

  • Ha a mi tanítványunk voltál, akkor átnézel egy-két kapcsolódó anyagrészt, hátha találkozol legalább koncepcionálisan hasonló részekkel, amit át tudsz vinni az új feladatra
  • Elkezdesz neten utánanézni a dolognak, ami persze azért több idő, mert kezdőként nem biztos, hogy el tudod dönteni, mi való neked, és mi lesz mélyvíz.
  • Tutorialokat nézegetsz (ez szintén időigényes)
  • Befizetsz egy tanfolyamra te magad (ha kellően proaktív vagy, ki tudod járni a cégnél, hogy részben vagy egészben ki is fizesse. Nekik ez költségként elszámolható)
  • Elolvasol egy-két könyvet (valószínűleg a veled foglalkozó senior fog egyet-kettőt javasolni)
  • … és csinálod!

Mire profi programozó leszel, addig ennek a mikéntjét is kitanulod. Kezdőként viszont az a nehéz, hogy a struktúráját, lényegét, belső összefüggéseit megértsd egy eszköznek (mi erre helyezzük a hangsúlyt).

Ami még fontos, hogy a programozást azért nehéz megtanulni, mert egy csomó új gondolati struktúrával találkozik az ember. A jó hír az, hogy ezek a struktúrák ismétlődnek: ha egy elvet megértesz, akkor a következő hasonló megértése nem lesz nehéz. Mondok egy példát, amit feltételezésem szerint te is ismersz: a névtér fogalmát (na biztos nem így! :-)). Gondolj a könyvtárrendszerre: Van a C: meghajtó, azon belül könyvtárak (mappák), a könyvtárakon belül más könyvtárak és fájlok. Létezhet ugyanolyan nevű fájl két különböző könyvtárban (pl. C:\TEMP és C:\WINDOWS). De ugyanígy vagyunk a webcímeket alkotó somain nevekkel is: van a .hu, mint legmagasabb szint, alatta a programozas-oktatas vagy a studicore, és mindkettő alatt lehet mondjuk www vagy online. Olyan, mintha egy fájlrendszert látnánk, csak fordítva írjuk és másra használjuk. De az elv ugyanaz! És az informatika tele van ismétlődő elvekkel… de ezeket egyszer azért meg kell tanulnunk!

A lényeg, hogy minél tovább vagy informatikus/programozó, annál kevesebb új van a nap alatt számodra a szakmádban.

És akkor álljon itt a csinálás mellett még három eszköz, ami hosszú távon is használható egy programozó önfejlesztése esetében:

  • könyvolvasás: lehet, hogy elektronikusan, vagy ebookolvasóról, de érdemes könyveket is olvasni a programozás egyes, saját szak- vagy érdeklődési területedbe vágó témában, viszonylag rendszeresen
  • cikkek olvasása, szakértők nyomon követése: olyan szakmában dolgozunk, amiben a nagy klasszikusok, szakmánk “alapító” atyjai még velünk élnek: Bill Gates, Linus Torvalds, Tim Berners-Lee vagy éppen James Gosling. Már egyre kevesebben vannak aktív korban, de aki igen, azokat érdemes követni
  • kódolvasás, azaz más programjai forrákódjának olvasása: ez lehet, hogy meglepő, de nagyon sokat lehet tanulni abból, hogy ha egy jól összerakott, kellően komplex program részeit próbálod meg megérteni és adott esetben akár kiegészíteni. Még abból is tanul az ember, ha nem a legjobban van összerakva, vagy az idők során összekutyulódott (szokása a programoknak), hiszen akkor friss és külső szemmel ránézve a hibáit, gyengeségeit is meg tudod találni

De ezek már a haladó eszközök, kezdőnek semmiképpen nem ajánlom, mert inkább pótcselekvés és időhúzás, mint hatékony célelérés, szóval először inkább tanulj meg programozni, és ha az alapok megvannak, és bekerültél egy céghez, akkor utána még mindig ráérsz ezeket elkezdeni. (Ha sosem bringáztál még, akkor nem azzal fogod elkezdeni az edzést, hogy leborotválod a szőrt a lábadról, hogy kisebb legyen a légellenállás… Pedig egy bizonyos ponton annak is megvan a létjogosultsága)

 

Mitől jó egy programozó?

Amennyiben foglalkoztat a programozástanulás kérdése, biztosan felmerült már benned az is, hogy mitől lesz egyik programozó jó, a másik meg kevésbé jó. Ezen a területen minőségi különbséget tenni nem olyan könnyű, mint mondjuk egy szék, asztal vagy ruhanemű esetén.

Előrebocsátom, hogy egy programozó a lehető legtöbb esetben gazdasági környezetben működik, azaz a fizetését és a kapcsolódó egyéb költségeket egy véges pénzügyi erőforrásokkal rendelkező szervezet biztosítja, ami lehet egy profitorientált vállalkozás, vagy akár egy nonprofit alapítvány, de mindenképpen valahonnan kapja a pénzt. A cél, hogy minél kevesebb pénzből minél nagyobb haladást érjünk el.

Így az első minőségi kritérium a gyors kódírás. Mondjuk el kell készíteni egy új androidos applikációt, egyáltalán nem mindegy, hogy 1 hónap vagy 3 hónap alatt készül el. Ezt értjük. Az ételek íze sem mindegy.

Kapcsolódik, de kicsit mégis más, hogy egyáltalán meg tudja-e oldani valaki az adott feladatot, mert lehet, hogy nem. A juniorok pl. inkább kisebb, egyszerűbb feladatokat oldanak meg, mert az összetettebb feladatokkal nem tudnak még megbirkózni, még akkor sem, ha a világ összes ideje a rendelkezésükre áll.

A hibátlan kódírás is fontos: minél precízebb valaki, annál jobb ezen a téren. Manapság bevett az, hogy programok tesztelik a programokat, szóval jó esetben már nem (vagy kevesebb) hibát tartalmaz a program, ami elkészül, de minél precízebben sikerül valakinek a programot megírnia, annál gyorsabban jut túl az ellenőrző teszteken. A Java Távoktatás tanfolyamban az első leckétől ezt a folyamatot szimuláljuk: a programnak teljesítenie kell az elfogadási teszteket: egy ellenőrző program értékeli a beküldött programot.

A következő már nem annyira egyértelmű: ha az alkalmazást módosítani kell, mennyire lehet a kész produktumot gyorsan módosítani. Kevés olyan alkalmazást láttunk, amiből megállt volna a fejlesztés egy adott verziónál. A Windows 10 is azért Windows 10, mert volt már előtte 9 másik. Ha éppen fejlesztjük az új funkciókat, nagyon nem mindegy, hogy az eredeti változatot az eredeti programozó mennyire írta könnyen módosíthatóra. Ez egy ahhoz hasonló rejtett minőségi paraméter, mint az ételek tápértéke. Lehet, hogy ízre jó a gyorséttermi kaja, de ha sokat eszik belőle az ember, megnézheti magát. Ennek egy része az, hogy “olvasható” kódot írjon, ami lefordítva azt jelenti, hogy olyan programsorokat írjon az ember, ami megfelel a programozás “íratlan” szabályainak, úgy épül fel, hogy az egyik programozó könnyen tudja követni elődje munkáját. Ha ez megvan, akkor a program könnyebben módosítható, mint ha nincs. A Java Távoktatás tanfolyamban azért alkalmazunk tapasztalt programozókat, hogy ezeket az íratlan szabályokat is ellenőrizzék és átadják a növendéknek.

Mennyire erős az analízis képessége: Ha maradunk az ételes példánál, akkor azt kell mondjam, hogy a szoftverfejlesztés kicsit olyan, mintha valaki mesélne egy ételről, amit valamikor evett, de nem ismeri a receptet, amiből utána el kellene készítenünk, amire vágyott: először ki kell tudni szedni a megrendelőből, hogy mire vágyik (ezt nem feltétlenül a programozó végzi), utána analizálni kell, meg kell állapítani, milyen összetevőkből állhatott, azok hogyan kapcsolódtak egymáshoz.

Ha ez megvan, akkor az összetevőket a megfelelő eljárások alkalmazásával össze kell állítani, azaz egy meglévő eszközkészletből dolgozva meg tudja konstruálni a végső megoldást (illetve milyen gyorsan és jól teszi ezt meg). Ez a LEGO-zás része a programozásnak: a LEGO-játékban is van egy halom különböző építőkocka, amiket szinte tetszőlegesen lehet kombinálni egymással, és a végén kijön belőle mondjuk egy tűzoltóság két tűzoltóautóval. Ha szerettél régen LEGO-zni, akkor a programozást is élvezni fogod!

Ez utóbbiak a legnehezebben átadható részei a programozásnak, kell, hogy elmélyüljön, összeérjen a tudás a fejben. Ezért van sok összetettebb programozós feladat a Java Távoktatás tanfolyamon, és nem csak 3 billentyűt kell lenyomni a megoldás érdekében. Célunk, hogy olyan programozók hagyják el a tanfolyamot, akik – a tapasztalati szintjükhöz mérten – a lehető leginkább rendelkeznek az analízis és a konstrukció képességével, gyorsan írnak olvasható, módosítható programkódot, hogy utána hasznos és megbecsült tagjai legyenek a programozócsapatnak, ahova a végzés után kerülnek.