Harom fele programozo letezik

A "B" tipusu programozok egyszerubb emberek. Mindenkeppen joval rugalmasabbak. Mondhatni arany kozeput az "A" es a kesobb emlitett "C" tipusu programozok kozott. Kelloen igenyesek ahhoz, hogy olvashato es karbantarthato kodot irjanak, de "hasznaljak az eszuket". Csak akkor alkalmaznak patterneket, ha patterneket kell alkalmazni. Tipikusan ok azok a fejlesztok, akik peldaul 10-bol 9x teljesen MVC-nek megfeleloen valositanak meg valamit, 10. alkalommal pedig total megkerulik az MVC-t, mert eppen olyan feladatuk van, aminek megvalositasara az MVC pattern vagy az altaluk hasznalt MVC framework teljesen alkalmatlan (pl. egy SQL utasitassal tobb sor INSERT optimalisan). Altalaban nem annyira muveltek, mint az "A" tipusu programozok, de hasznaljak az eszuket, es jobban epitenek sajat logikajukra.
Hatranyuk, hogy a munkaeropiac legtobbszor pont olyan embert keres, aki vagy "A" (illik a megfontolt csapatba), vagy "C" (nem sz*rozik) tipusu programozo. Ok ugymond az "atmenet", akiknek el kell adniuk magukat vagy "A" vagy "C" tipusu programozokent igenynek megfeleloen. Masik hatranyuk, hogy bar sokszor logikus es kovetkezetes a kodjuk, sokszor a rajtuk levo stressz mennyisegen mulik kodjuk minosege. Ha raernek, ugyanugy kepesek orakat vitatkozni egy 10 soros es amugy mukodo fuggvenyen, ha meg kapkodnak, akkor meg olyan kodot irnak, hogy sikitofraszt kap, aki csak hozzanyul kesobb, es a kesobb emlitett "C" tipusu fejlesztokkel ellentetben nicns is "nagy rutinjuk" a "kapkodva kodolasban". Sokszor nagyot lehet csalodni bennuk egy pillanat alatt, mikor evekig jo kodernek hitted. Jellemzo parbeszed veluk tobb ev egyuttdolgozas utan: "Te, miert generalsz a modelben olyan javascript kodot, ami html class-t ad egy DOM-hoz? Te nem szoktal ilyet csinalni en meg ket oraja ezt debuggolom" "Bocs, kapkodtam amikor ezt kellett release-elni".
Hibaik ritkan annyira komplexek, mint az "A" tipusu fejlesztoke, es ritkan annyira primitivek mint a "C" tipusu fejlesztoke, de mindketto hibatipus naluk is elofordul, es a "ketto kozottinek mondhato" hibak sem ritkabbak naluk. Sokan kozuluk azonban okosan tesztelnek, hasznalva az eszuket. Erteni szoktak a unit test-eles trukkjeit is, de ok szoktak a leghangosabban hangsulyozni, hogy vannak bizonyos feladatok, amikhez a unit test abszolut nem nevezheto megoldasnak. Erdekesseg meg, hogy neha ok maguk is visitanak a sajat kodjuktol, mikor megtudjak, hogy egesz mas lett vegul a feladat.
Emellett a "B" tipusu fejlesztok a legrugalmasabbak, sosem mondjak, hogy "ebben ezt nem lehet megirni", esetleg felvazoljak, hogy "nem erdemes", de megcsinaljak ha kell. Legtobbszor gyorsan megertheto es felfoghato a kodjuk, es rajuk a legjellemzobb, hogy egy bonyolultabb fuggveny kozepen is lesz magyarazo komment, nem csak a fuggveny fejleceben, mondvan "ott kotelezo". Ha elmennek szabadsagra is jo esellyel lesz, aki pillanatok alatt tudja folytatni kodjaik 90%-at, emellett altalaban kepesek par percben megmagyarazni, mit miert csinaltak ugy, ahogy csinaltak.
Szeretik az egyszeru de nagyszeru megoldasokat, kedvenc technologiaik sokszor "egyfuggvenyes" github projektek, par soros scriptek, egyszerubb fuggvenykonyvtarak.

A "C" tipusu programozok a leglenyegretorobbek. Ok tudjak a leginkabb betartani a hataridoket. Kepesek 1 honap alatt 3 olyan projektet befejezni specifikacionak megfeleloen (es veletlenul sem jobban), amin "A" tipusu programozok tizei ulnenek honapokig. Altalaban uj projektekre teszik oket, es ajanlgatjak egymasnak oket startupok tulajdonosai, mert "valakinek el kell kezdeni epitenie a kodot", es ugye fontos, hogy egy ilyen kod minel hamarabb mukodjon. Egy okos "C" tipusu fejleszto eseteben szinte "zsenirol" beszelhetunk szemelyeben, de ugyanakkor a "C" tipusu fejlesztoknel a legnagyobb az az arany, akiket nem az eszukert szeretunk. De a hataridoket a kevesbe ertelmes egyedeik is tartjak, lehet hogy a projekt vegul egy 8000 soros spagetti kod lesz egyetlen forrasfajlban tele copy-paste-elt kodduplikacioval, de elkeszul.
Ugyanakkor ok vegtelenul tiszteletlenek. Sokszor muveletlenek is. Nem hajlandok ertelmezni pattern doksikat, ha van egy cegnel kodolasi konvencio, semmit nem tartanak be belole. Csak a sajat hibaikbol es peldakodokbol hajlandok tanulni, es elzavarjak a fenebe azokat, akik tul bonyolult technologiat akarnanak letolni a torkukon.
Ezenfelul ok a felelosek a gyengen tipusos nyelvek letezeseert. A PHPistikek is az o halmazuk kevesbe tapasztalt peldanyai (meg nem tanultak a sajat hibaikbol), es ok azok, akiknel egy fuggveny visszateresi erteke akar 4 kulonbozo tipusu is lehet - a nullt bele sem szamitva. Mar ha hasznalnak fuggvenyt egyaltalan. Ha mar a PHPistikeket ebbe a halmazba tettuk, erdemes megemliteni, hogy a "script kiddie"-k is idesorolhatok, mar ha ez a halmaz nem a script kiddie definicioja onmagaban.
Van, hogy egesz eletukben nem csinalnak absztrakt osztalyt, interface-t, es singletont is csak tizevente egyszer. De ugyanakkor az o REST-like (veletlenul sem RESTful) API-juk mindig valahogy tizedannyi ido alatt kesz van valami csoda folytan, es tokeletesen teszi a dolgat.
Barmilyen meglepo is az eddig leirtak utan, sokszor nagyon is hajlandoak ujat tanulni. De ehhez az kell, hogy olyan legyen a tanitott technoliga altal megoldott problema, amit mar lattak, vagy konnyen el tudnak kepzelni. Es ez sem eleg onmagaban: keves bemutatkozassal es rizsaval rogton valami latvanyosat kell mutatnia ennek az uj technologianak. Kedvenc technologiaik azok a kozepes komplexitasu technologiak tartoznak altalaban, amiknek kesobb jovoje is lesz. Szinte ok a hirnokei annak, hogy mi fog elterjedni ebben a nagy IT dzsungelben. Webes peldakon maradva a composer peldaul tipikus peldaja annak, amiket "C" tipusu fejlesztok irtak "C" tipusu fejlesztoknek, persze az evek soran kinotte magat, leven ahogy varhato volt, elterjedt. Mas weboldalak scrape-eleseben is mindenkeppen ok a leghatekonyabb csoport, a curl parametereit altalaban kivulrol tudjak, valamint a html feldolgozassal kapcsolatos libek kozul is kulon erzekuk van kivalasztani a leghatekonyabbat.
Hibaik ritkan bonyolultak, leven ritkan dolgoznak bonyolultabb logikan vagy kis reszfeladatokra nem lebonthato feladatokon. Ugyanakkor a kodjaik rendszeresen allnak meg bent hagyott "echo 'reached'; exit;"-ek es egyeb trivialis "manualis debug" uzenetek miatt. Rajuk a legjellemzobb, hogy egy text editort szeretnek hasznalni IDE helyett, az automatikus debuggerre pedig csak annyit mondanak: "overkill" vagy "overengineering". Emellett az o kezeik kozul kerulnek ki a legsurubben - halistennek altalaban rovid, de - write-only kodreszletek es kommentalatlan tobb soros regexpek is. Ha a kodjukban nem talalod meg 5 perc alatt a hibat, jobb is, ha visszaadod a koltonek, eselyed sincs. De az a jellemzobb, hogy megtalalod. Jellemzo reakciod meg, mikor a kodjukba futsz: "Miert igy? En ezt total maskepp csinaltam volna" (de legalabb ekkor megertetted, mit es hogy valositott meg). Jellemzo, hogy 2-3 oran at gyakorlatilag refaktoralod egy kodreszletet szebbre, pedig valojaban az elejen a feladat csak egy 5 perces bugfixnek indult.
Ezekbol is kovetkezik, hogy egyedul dolgozva a projekten a leghatekonyabbak, esetleg kis meretu csapatban. De ugyanakkor elonyuk, hogy pontosan tudjak, hogy az ido penz, ok pazaroljak a legkevesbe a megrendelo penzet "oradij" cimszo alatt, es nem csinalnak csak ugy masik 10 fejlesztonek munkat. A legproblemasabb kodreszeik is aranylag keves munkaoraval lecserelhetoek, refaktoralhatoak. Sot, barmilyen hihetetlen, altalaban erre szukseg sincs, mert a kodjuk evekkel kesobb is teszi a dolgat. Es ami meg az idot illeti, az "A" tipusu fejlesztokkel ellentetben azt is felfogjak, hogy nem eppen lesz fejlesztotarsuknak a legjobb elfoglaltsaga egy 600 soros konyvet elolvasni, es altalaban tudnak konstruktivabb tanacsot adni a feladatra koncentralva.

Es barhogy is nezem, mindharom programozo szemelyisegtipusra szukseg van. Eppen ezert igyekeztem igazsagosan bemutatni elonyeiket es hatranyaikat, remelem sikerult.