Milyen egy programozó napja, milyen feladatokat kap?

Reggel meeting, jira ticketset “elveszel” és elkezded megcsinálni amit kell (dokumentálva, clean code elveket követve és commit message értelmes kell legyen), délben valamikor egy nagyobb szünet van étkezni, kaja után talán lesz még egy meeting és a nap hátralévő részénen folytatod a programozást.

Amire figyelned kell, hogy probléma esetén ne egyből, de ne is ezer év után fordulj a senior kollégákhoz és fogadd el, ha megszólják a kódodat, mert hidd el nem rosszból csinálják.

Ami szerintem jobb csapatban, hogy juniorként semmi nyomás sincs rajtad egy nagyobb cégben. Azért szerintem érezted, hogy egyedül dolgozva minden a te felelősséged, viszont ez most változni fog. Ami szerintem jó, mert tudsz 100%-ban a tanulásra koncentrálni, ami juniorként a legfontosabb dolog.

“junior fejlesztőnek milyen feladatai vannak egy nap?”

Kb ugyan az mint a senioroknak vagy bárki másnak. Csak annyi a különbség, hogy a juniorok lassabbak, sokszor irányba kell igazítani vagy éppen teljesen át iratni a megoldását.

1-1 combosabb feladat van azért néha, ami tipikusan juniornak nem adnak. Pl.: Keycloak bevezetése projecten.

“mekkora részét kell a kódnak karbantartania“

Vannak “techdept” feladatok minden projecten, ahol korszerűsíteni kell elavult, rossz megoldásokat szimplán mert változtak a követelmények vagy csak össze lett csapva határidők miatt és egy nyugisabb időszakban van idő kijavítani.

“mire mennyi időt hagynak neki?”

Többnyire elnézőek a juniorokkal. Nincsenek időkorlátjai a feladataiknak, de ha azt látják, hogy nem halad megfelelően és nem kérdez, akkor rákérdeznek, hogy kell-e segítség neki. Esetleg valaki mellé ültetnek, hogy nézzék át picit a feladatot.

Csak mert konkrét példát akartál:

“XY external service integrálása”

“Bufix: KZ esetben hibás email megy ki.”

“Spring boot verzió migrálása 3.2-re és a Java verzió 21-re”

“HF service refaktorálása”

Meg kb bármilyen feature lefejlesztése.

"A kérdésem az lenne, hogy egyébként egy átlagos junior fejlesztőnek milyen feladatai vannak egy nap?"

Kb. ugyanaz, mint egy senior-nak. Mondjuk senior-nak lehet több meeting-je, mert beesik valami, amihez pont ő ért vagy valami architect meeting stb.

De mindenkinek megvan az item-e, amin dolgozik.

"Például mekkora részét kell a kódnak karbantartania, mire mennyi időt hagynak neki?"

Nincs így megmondva, hogy X darab fájl a tied. Általában csapatok vannak és a csapatnak van egy felelősségköre. Az, hogy ez mennyi kódot jelent, az nyilván függ, hogy hány csapat van.

A karbantartás meg jelenthet nulla munkát is.

Időt általában item-ekhez rendelnek. Pl. van egy item, hogy "legyen egy új warning message" vagy valami hasonló, és akkor ezt planning során megbecsülik, hogy mondjuk 3 napnyi munka lenne. Ezek általában felső becslések, szóval sokszor egy junior is simán végez vele.

Vannak napi meeting-ek, ahol mindenki elmondja a csapat többi tagjának, hogy hogy halad, így ilyenkor is tudnak egymásnak segíteni a csapattagok.

"Ez nyilván cégfüggő, pl akik egy nagy, ezeréves kódbázist tartanak karban, másjellegű feladataik vannak, mint egy weboldal gyáros cég alkalmazottainak."

Azért annyira nem. Inkább attól függ, hogy hány fejlesztő van, mire van idő, esetleg milyen terület.

Mármint egy sima weboldal lehet hibás, sok problémát nem okozol, ha valami kicsit lassabb, de ha pl. repülőkhöz fejlesztesz szoftvert, akkor ott jó lenne, ha nem halna le random a program.

"Csak szeretném tudni, hogy ti például milyen jellegű feldatokat kaptok"

A junior általában kisebb feladatokat kap, sokszor még csak nem is development item-et, hanem bugfix-et.

Nyilván cél, hogy ismerkedj a kódbázissal is egyszerűbb task-ok során.

"mennyi idő alatt kell megoldani"

Ha normálisan dolgozol és haladsz a melóval, akkor senki nem fog megszólni normális cégnél.

Még akkor se, ha tovább tart, mint a becsült idő.

"mekkora kódbázist kell használnotok?"

Ez alatt mit értünk? A kód mekkora részébe kell belenyúlni? Hát, kisebb változtatások esetén már frontend-be is nyúltam bele backend fejlesztőként, de szerintem pár 10 ezer sornál nem több a production kód, ami hozzánk tartozik elvileg.

#4

Ez egyébként elég szar helynek hangzik. Mármint gondolom te örülsz, hogy semmit nem csinálsz egész héten, de ezt nehezen lehet munkának hívni és meg is látszik, hogy mennyi tapasztalatot szerez az ember egy ilyen helyen.

Arról nem beszélve, hogy leírásod alapján még normálisan a tervezés se megy.

"Nem igazán dolgoztam még csapatban."

Akkor majd fogsz. Ahány cég/vállalti kultúra annyi fajta csapat felépítés és dinamika van. Két céget összevetve is fellelhető különbségek, de nem csak csapatilag hanem cég struktúrában is.

Ha csak a csapatokat nézzük van az Spotify-like féle felépítés és az (én úgy nevezem, hogy) Amerikai felé.

Előbbi azért Spotify-like mert ők vezették be azokat a szavakat, hogy "Tribe", "Squad" vagy "Guide" amikkel egy csapat(ok) felépülnek.

Részleteket itt megtalálsz: [link]

Az amerikai meg jó öreg hierarchy rendszerben gondolkodik, hogy van egy "Főnök" és az összes beosztottja abban az egy kisebb/nagyobb csapatban van, ellentétben a Spotify-féle rendszerrel, ahol a csapat főnöke nem a te munkáltató jogokat gyakorló személy.

(Itthon az OTP Bank és a Magyar Telekom használja a Spotify-like csapat struktúrát, amiről tudok.)

De minden esetre egy csapatban mindenkinek meg van a saját felelőssége és azt kell csak végrehajtani, plusz segíteni a másik scope-ban (területen) dolgozó személyt. (pl.: Hogyan éri el a FrontEnd-es azt az API-t, amit írtál.)

"junior fejlesztőnek milyen feladatai vannak egy nap?"

Ahogy felettem is említették, mint a Seniornak. Bár az új Senior csapat tag se ismeri a kódbázist vagy a domain-t. Tehát onboarding-al kezdődik a művelet, eleinte kisebb feladatok a kódbázis megismeréséhez.

"pl rendesen használni a git commit parancsot"

:) 5-6 éves tapasztalattal a hátam mögött, az elmúlt 2 évben, max használtam 20x a git parancsot terminálban. Nem ez fogja az életedet megváltani. Ez inkább szokás, a hogyan kellene rendesen használni.

Amúgy nézd meg GitHub-on, hogy hogyan írnak message-et commitokra.

De ebből is van egy rakat cikk online. Mennyit kerestél meg belőle?

Pl.: [link]

Commit tekintetében én így használom. A (kód) JIRA vagy más issue kezelőben jelszett kódot írom. Pár példa hasra csapva:

fix(ABC-0000): database record delete rollback error

feat(ABC-0001): newcomer user saving

"ti például milyen jellegű feldatokat kaptok, mennyi idő alatt kell megoldani"

Hát ez változó, attól függ, hogy mi a feladat, kihez tartozik vagy van-e rá specifikus csapat? Pl.: ha van DevOps-os csapat, akkor nem kell feltétlenül DevOps-os munkát végezni, de persze függhet a kód tőle, szóval rá kell hangolni, ha van ilyen.

- Feature fejlesztés (új eddig nem támogatott működés)

- Karbantartás (olyan munka ami nem ad új feature-t a rendszerhez. Lehet refactor, dependency verzió emelés és ezzel járó fix-ek, devops, kódminőség, ...)

- Hibajavítás (feature fix, mert valami eddig jó volt (vagy eddig se), és most se az, csak most tűnt fel.)

"mekkora kódbázist kell használnotok"

Attól függ, mit nevezünk annak. Lehet több microservice, ami service-enként nem több mint 30-40 fájl 300-400 sor/file. De lehet jó nagy monolitikus rendszer is. Projekt válogatja. Nem tudod előre megmondani...