A programozói pályát sokan sokféleképpen képzelik el, de azt elmondhatjuk, hogy a középpontban szinte minden ilyen elképzelésben maga a kód áll, emiatt is jött a kifejezés, hogy valaki pl jó kóder. Ezzel nincs is baj, habár számomra a kóder szó inkább pejoratív, de ez egy másik történet. A gond ott van, hogy sokan így is képzelik el a szakmát, vagy éppen így élik meg azt, hogy semmi más dolguk sincs, mintsem kódot írni. Ennél messzebb viszont nem is lehetnénk a valóságtól (legalábbis remélem). Ugyanis a kód az habár fontos produktuma a munkánknak. Álljunk csak meg! Mégis mi a produktuma a mi munkánknak? Mert hogy nem az általunk írt kód az tuti. Na és miért mondom ezt? Mert minket senki sem kért meg soha egyetlen if-else ágra, vagy hogy írjunk SQL-t. Minket egyszerűen nem ezért fizetnek. Hanem azért, hogy problémákat oldjunk meg az ügyfél/ügyfelek számára. Az, hogy történetesen ennek része az, hogy pl. SQL-t írunk, vagy éppen CSS-t hegesztünk, az csupán a szakmánk sajátossága. A cipészt sem kérik meg arra, hogy oda meg oda üssön egy apró szöget, valamit ragasszon meg itt és ott, hanem javítsa meg a cipőt, az hogy mindezt hogy oldja meg, már az ő szakterülete.

Viszont azon a bizonyos kódon kívül még rengeteg mást kell tudnia egy jó fejlesztőnek. Az egyik ilyen, hogy tudnia kell, mikor nem is szabad nekiállni valaminek, mert nem fog működni. Sőt, ezelőtt nem árt, ha egyáltalán tudja, hogy mit is kell csinálnia, ugyanis az ügyfelek nem a jól meghatározott üzleti igényekről híresek. Tehát azt már látjuk, hogy nem tudjuk elkerülni azt, hogy kommunikáljunk a projekt egyéb résztvevőivel, akik bizony nem fogják megérteni a technikai részleteket. Ezt tudnunk kell lefordítani másoknak, valamint visszafele is, az általuk megfogalmazott igényeket is tudnunk kell valahogy technikai nyelvre fordítani. Ha ez nem lenne elég, ha nem egyéni vállalkozóként dolgozunk, akkor nagy valószínűséggel csapatban, emiatt egymás közt is kell kommunikáljunk. Bizony, a sarokban ülő programozó, aki egymaga fejleszt valamit egy kihalófélben lévő faj. A tudást meg kell osztani másokkal, dokumentációt kell írni - bármennyire nem szeretjük azt -, hiszen gondoljunk bele mi mennyi ilyet olvasunk? Valaki ugyanúgy beletette az energiát előttünk, hogy ne a kódból próbáljuk kitalálni mi is történik, vagy éppen stackoverflow válaszokból összehalászni azt.

Na persze ne feledkezzünk el a meetingekről sem. Itt abba nem mennék bele melyik hasznos vagy éppen haszontalan, ezt cége válogatja, de valószínűleg itt vagyunk a legmesszebb a kódtól, hacsak nem lenémítva kódolunk a másik monitoron közben.

Ha már kód, akkor bizony egymás kódját is át kell nézni, a benne talált hibákat érthetően és lehetőleg nem sértőn megírni a másiknak. De gyakran közösen is kell kódolni vagy éppen hibát keresni, logokat, metrikákat bámulni, hogy megtaláljuk a hiba okát, ha nem esünk rögtön a javításának, akkor mindezt felvinni valahova.

Ha pedig felvisszük valahova, akkor elő is kerülnek a projektmenedzsment rendszerek, ahol szintén sok időt töltünk el.

Képzeljük el, hogy házat akarunk építeni. Van egy elképzelésünk, odahívjuk a kőművest, ácsot, stb. és kiadjuk nekik, hogy ezt kell csinálni, van rá öt nap, ők meg rögtön nekiállnak? Dehogy fognak, hiszen lehet amit elképzeltünk nem is megvalósítható, vagy éppen nem biztonságos, időtálló. Azért ők a szakemberek, hogy megmondják, ha valami szakmailag nem lesz oké. Ők fogják megmondani azt is, hogy mennyi idő alatt lesz kb kész. Ugyanez a helyzet nálunk is, mintha minden egyes ticket a projektmenedzsment rendszerben egy újabb építkezés lenne, viszont nálunk sokkal komplexebb elképzeléseket kell megvalósítani, esetleg azok nem annyira letisztultak, így a konkrét megvalósítás kevesebb időt vesz igénybe, mert inkább nyomozni kell az után, mi is a konkrét feladat.

Ugyanezért fontos ismerni magát az üzletet, hogy megfelelően tudjuk ellátni a feladatunkat. Minél jobban ismerjük azt, annál inkább tudunk testreszabott megoldást adni, hiszen nem kódot szállítunk, hanem egy üzleti megoldást. Annak ismerete nélkül igen nehéz lenne. Az információ hiánya, vagy a félreinformálás bizony nagy galibákat tud okozni, ezzel nekem is van egy igen rossz élményem. Amikor egy olyan funkciót fejlesztettünk, ami a felhasználói fiókok megosztását tette lehetővé és felmerült a kérdés, hogy volumenét tekintve egy felhasználóval hány ilyen fiókot is fognak megosztani. Itt azt az információt kaptuk, hogy pár ilyen lesz majd. Ennélfogva a rendszert úgy építettük meg, hogy ezt feltételeztük. Később, mikor élesítettük, akkor bizony kiderült, hogy ezek inkább 200 fölötti számok, amiknél bizony a mi megoldásunk nem teljesített úgy, mert nem erre terveztük az egészet.

Persze van olyan hely, ahol nem ez a helyzet, hanem az előbb említett abszurd módon gondolkozik a vezetés. Ezekről a helyekről érdemes mihamarabb menekülni. Szóval ha esetleg projekt menedzserek, product ownerek is hallgatják az adást, akkor nekik is üzenném, hogy ahogy a fejlesztők sem csak kódolnak, úgy nekik sem annyi a dolguk, hogy rátolják a feladatot, mindenféle kontextus, háttér nélkül a fejlesztőre és az majd megoldja, hiszen már láttuk az én esetemből, hogy miket eredményezhet.

Jó esetben juniorként nem dobnak be rögtön a mély vízbe és a fenti feladatok nagyját leveszik a vállunkról, de ahogy haladunk előre a pályáján, egyre jobban bele kell magunkat ásni a fenti problémákba. Tehát el kell szomorítsam a hallgatókat, ugyanis senki se remélje, hogy mindig kész, jól megrágott feladatokon kell majd dolgoznia és majd elkódolgat a sarokban egyedül.

Hosted on Acast. See acast.com/privacy for more information.