Forum » Programiranje » Kako mentorirati začetnika na delovnem mestu?
Kako mentorirati začetnika na delovnem mestu?
moose_man ::
Torej, problem: na delovno mesto je prišel programer začetnik. Precej očitno je, da mu programiranje ni strast hobi in izkušnje si bo nabiral samo na delovnem mestu. Pustimo ob strani razloge, zakaj je prišel v ekipo (njegovi sodelavci pri odločitvi nismo imeli besede). Je pa ekipa dobila nalogo, da ga uvede v delo. Na kakšen način bi se vi lotili zadeve?
Mi smo uvajalni program zastavili precej "klasično"; v prihodnjih mesecih bo dobival postopoma čedalje težje/kompleksnejše naloge. Zaenkrat mu gre OK (je približno toliko hiter kot bi pričakoval glede na njegove izkušnje), ampak zelo velike težave se kažejo pri razčlenjevanju / berljivosti / strukturi njegove kode (tudi pri *zelo* preprostih problemih). Kodo je sposoben izboljšat le pod direktnim vodstvom (večkrat narekovanjem) koga izmed nas. Zaenkrat mu delamo redne code reviewe, ki požrejo ogromno časa, počasi se vidi da mu narašča znanje ampak prej omenjeni problemi pa ostajajo. Ima kdo kak nasvet, kako postopat v takem primeru? Ne moremo si namreč privoščit da bi mu leto dni tako intenzivno gledali pod prste, hkrati pa nas bo takšna koda tudi čisto preveč po nepotrebnem ovirala.
Mi smo uvajalni program zastavili precej "klasično"; v prihodnjih mesecih bo dobival postopoma čedalje težje/kompleksnejše naloge. Zaenkrat mu gre OK (je približno toliko hiter kot bi pričakoval glede na njegove izkušnje), ampak zelo velike težave se kažejo pri razčlenjevanju / berljivosti / strukturi njegove kode (tudi pri *zelo* preprostih problemih). Kodo je sposoben izboljšat le pod direktnim vodstvom (večkrat narekovanjem) koga izmed nas. Zaenkrat mu delamo redne code reviewe, ki požrejo ogromno časa, počasi se vidi da mu narašča znanje ampak prej omenjeni problemi pa ostajajo. Ima kdo kak nasvet, kako postopat v takem primeru? Ne moremo si namreč privoščit da bi mu leto dni tako intenzivno gledali pod prste, hkrati pa nas bo takšna koda tudi čisto preveč po nepotrebnem ovirala.
harmony ::
Dajte mu naloge tipa "poisci napako v kodi". Dajte mu svoje kode, zanalasc dajte not napake, katere pri njemu ne bi zeleli zaslediti in naj razmislja z glavo kaj je narobe. Mogoce se bo tako potem navadil lepse pisati kodo.
Ker nisem programer drugega nasveta nimam.
Ker nisem programer drugega nasveta nimam.
Invictus ::
Daj mu delo.
Če se bo znašel in kaj naredil, O.K. Drugače ga vrzi ven.
Če se bo znašel in kaj naredil, O.K. Drugače ga vrzi ven.
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
moose_man ::
Znajde se in naredi, ampak za njim ostane katastrofalna koda, to je problem (glej moj drugi odstavek).
Zato me je zanimalo, če ima kdo izkušnje z učenjem začetnika podobnega tipa, kot sem ga opisal zgoraj.
Zato me je zanimalo, če ima kdo izkušnje z učenjem začetnika podobnega tipa, kot sem ga opisal zgoraj.
Dpool ::
Meni bi bilo všeč, če bi se kdo od mentorjev vsedel z mano in najprej predebatiral problem oz. kodo s katero se ukvarjamo. Še pred tem pa jasno razložil katere tehnologije so zahtevane pri razvoju kode v tej ekipi. Nisi napisal sicer o kakšni kompleksnosti projektov se tukaj pogovarjamo, ampak če je projekt kompleksen je zelo pomemben pravilen onboarding. Imate kakšno dokumentacijo pripravljeno za ramp-up? Naprimer slajdi, PDF, ki razlagajo vaš način implementacije kode, uporabe določenih knjižnic, arhitektura kode.. proces razvoja projekta ipd. Toliko da novinec sploh zazna kako se v vaši ekipi lotite dela in zakaj se ga tako lotite.
Kar se tiče čistosti kode je pa prav to kar njemu manjka: praksa. Ko si začetnik, potem iščeš način da boš rešil nalogo - ne gledaš še, ali bo to po najboljšem načinu. Čez čas pa ti reševanje podobnih problemov postane praksa in se pričneš ukvarjat s posodabljanjem svojega pisanja kode in uvajaš postopoma izboljšave.
Mnogim se zdi, da če posadiš programerja pred obstoječ projekt in mu poveš "naštudiraj zdaj to kodo" in potem mu vmes daš nek task, da je stvar rešena. Dosti lažje je, če si dejansko kdo, ki je zadolžen za mentorstvo dejansko uvede novinca v ekipo in stil programiranja. Če želiš to dosečt v nekaj mescih, potem to storiš z besednim spremstvom (delavnice, pogovori, ipd).. če pa želiš, da naj sam išče pot, potem to lahko traja tudi leto dni, kot si sam omenil. Vse je odvisno tudi kakšen tip osebe si seveda! Jaz govorim iz svojega stališča. No, nekateri pa morda preferirajo, da jih pustiš na miru in bodo sami naštudirali zadevo.
Če povzamem is faksa: če nisem obiskoval predavanja, sem za izpit sam moral naštudirati knjigo. To mi je vzelo precej več časa, kot pa če sem obiskoval predavanja profesorja in potem doma na hitro predelal snov.
Na začetku si vzamite čas, malce več kot bi si dejansko lahko dovolili. S tem boste morda zaostali vsega skupaj 2 tedna pri vašem rednem delu. A na dolgi rok boste si prihranili čas in denar. Če pa boste sedaj ga pustili naj se sam uči, potem vas bo zmeraj zaviral.
Kot dober mentor si sedaj verjetno že ugotovil njegov stil kodiranja in kako ON razmišlja. Sedaj pa si vzameš čas da njegov problem preučiš in ugotoviš kako mu boš razložil, da bo v bodoče boljše kodiral. Naprimer če si učitelj matematike na začetku še ne veš kateri učenci ne vedo vektorje. Šele po nekaj kontrolkah / ustnih spraševanj boš to opazil (tako kot si ti sedaj pri njemu). Takrat učitelj (če je dober), preveri kje pa dela ta učenec napake najbolj pogosto pri vektorjih (sedaj to ti morša analizirati njegov način kodiranja). Ko izluščiš problem kaj ga moti / kaj ne razume ravno prav, se pripraviš da mu razložiš pravi način, po možnosti tako, da vidi na njegovem lastnem primeru kode.
Direktive kot: "Variabla ne sme biti static." "Naredi posebej objekt za to." "Naredi posebej metodo / funkcijo za to." ipd. Ja, saj bo popravil.. ampak NJEMU ni jasno točno še zakaj mora tako narediti. "Naredi posebej metodo / funkcijo za to logiko, saj drugače bo tvoja koda postala preveč nasičena in zelo netestabilna. Vedno imej na umu, da tisti, ki bo tvojo kodo pregledal, bo zlahkoto sledil njenemu toku in kasneje tudi testiral zadevo. Če imaš ti vse operacije zajete v eni funkciji, koda več ne bo lahko berljiva in precej kompleksna za testirati." (to je samo hiter primer za na Forum, ne dejanski nasvet!!)
No, kljub temu pa se mi zdi napaka, da je podjetje zaposlilo Junior Developerja, za katerega se pričakuje, da obvlada stvari. Saj Junior dev pomeni da nima 0 ali zelo malo izkušenj.. torej neke prakse ne more imeti za sabo.
Kar se tiče čistosti kode je pa prav to kar njemu manjka: praksa. Ko si začetnik, potem iščeš način da boš rešil nalogo - ne gledaš še, ali bo to po najboljšem načinu. Čez čas pa ti reševanje podobnih problemov postane praksa in se pričneš ukvarjat s posodabljanjem svojega pisanja kode in uvajaš postopoma izboljšave.
Mnogim se zdi, da če posadiš programerja pred obstoječ projekt in mu poveš "naštudiraj zdaj to kodo" in potem mu vmes daš nek task, da je stvar rešena. Dosti lažje je, če si dejansko kdo, ki je zadolžen za mentorstvo dejansko uvede novinca v ekipo in stil programiranja. Če želiš to dosečt v nekaj mescih, potem to storiš z besednim spremstvom (delavnice, pogovori, ipd).. če pa želiš, da naj sam išče pot, potem to lahko traja tudi leto dni, kot si sam omenil. Vse je odvisno tudi kakšen tip osebe si seveda! Jaz govorim iz svojega stališča. No, nekateri pa morda preferirajo, da jih pustiš na miru in bodo sami naštudirali zadevo.
Če povzamem is faksa: če nisem obiskoval predavanja, sem za izpit sam moral naštudirati knjigo. To mi je vzelo precej več časa, kot pa če sem obiskoval predavanja profesorja in potem doma na hitro predelal snov.
Na začetku si vzamite čas, malce več kot bi si dejansko lahko dovolili. S tem boste morda zaostali vsega skupaj 2 tedna pri vašem rednem delu. A na dolgi rok boste si prihranili čas in denar. Če pa boste sedaj ga pustili naj se sam uči, potem vas bo zmeraj zaviral.
Kot dober mentor si sedaj verjetno že ugotovil njegov stil kodiranja in kako ON razmišlja. Sedaj pa si vzameš čas da njegov problem preučiš in ugotoviš kako mu boš razložil, da bo v bodoče boljše kodiral. Naprimer če si učitelj matematike na začetku še ne veš kateri učenci ne vedo vektorje. Šele po nekaj kontrolkah / ustnih spraševanj boš to opazil (tako kot si ti sedaj pri njemu). Takrat učitelj (če je dober), preveri kje pa dela ta učenec napake najbolj pogosto pri vektorjih (sedaj to ti morša analizirati njegov način kodiranja). Ko izluščiš problem kaj ga moti / kaj ne razume ravno prav, se pripraviš da mu razložiš pravi način, po možnosti tako, da vidi na njegovem lastnem primeru kode.
Direktive kot: "Variabla ne sme biti static." "Naredi posebej objekt za to." "Naredi posebej metodo / funkcijo za to." ipd. Ja, saj bo popravil.. ampak NJEMU ni jasno točno še zakaj mora tako narediti. "Naredi posebej metodo / funkcijo za to logiko, saj drugače bo tvoja koda postala preveč nasičena in zelo netestabilna. Vedno imej na umu, da tisti, ki bo tvojo kodo pregledal, bo zlahkoto sledil njenemu toku in kasneje tudi testiral zadevo. Če imaš ti vse operacije zajete v eni funkciji, koda več ne bo lahko berljiva in precej kompleksna za testirati." (to je samo hiter primer za na Forum, ne dejanski nasvet!!)
No, kljub temu pa se mi zdi napaka, da je podjetje zaposlilo Junior Developerja, za katerega se pričakuje, da obvlada stvari. Saj Junior dev pomeni da nima 0 ali zelo malo izkušenj.. torej neke prakse ne more imeti za sabo.
Zgodovina sprememb…
- spremenil: Dpool ()
cekr ::
Z nadzorom nad njim, ne boste prav nič dosegli. On bo še vedno naprej packal po svoje.
Če imate v firmi nek svoj način kode, mu pokaži,
- kaj pričakuješ od njega
- obliko kode
- komentiranje
- obliko spremenljivk
- poimenovanje map
- shranjevanje varnostnih kopij (je fajn, da ima že od začetka v krvi)
- verzije
...
Če je prišel v firmo z null znanja, ne moreš pričakovat, da bo kar profi.
Tudi če je predelal vse knjige, bo imel še vedno drugačen način kodiranja, kot ga imate ostali v firmi.
Navadi ga, da lahko kakšna ideja pade tudi v prostem času. Ne v smislu, da mora delat doma. Samo razmišljanje o nekem problemu.
Pa ne mu težit in mu viset za hrbtom za vsako podrobnost. Tako mu boš samo vzel voljo in bo prej ali slej rekel "Ne grem se več."
Bo pa težko, če mu računalnik ni tudi hobi.
Da ti bo pa že po pol ure gledal na uro, kdaj bo malica ali pa konec šihta, je pa bolje, da greste takoj v iskanje novega mazohista.
Še to:
takoj mu dajte za delat nek konkreten problem v firmi, za katerega se vam ne mudi.
Tudi če bo šlo počasi, bo imel takoj občutek, da dela nekaj konkretnega. Abstraktne zadeve ubijajo.
Razlago naloge/problema se mu nariše na tablo. Najslabše je nekemu nekaj razlagat zunaj na čiku. To gre vse ven.
Če imate v firmi nek svoj način kode, mu pokaži,
- kaj pričakuješ od njega
- obliko kode
- komentiranje
- obliko spremenljivk
- poimenovanje map
- shranjevanje varnostnih kopij (je fajn, da ima že od začetka v krvi)
- verzije
...
Če je prišel v firmo z null znanja, ne moreš pričakovat, da bo kar profi.
Tudi če je predelal vse knjige, bo imel še vedno drugačen način kodiranja, kot ga imate ostali v firmi.
Navadi ga, da lahko kakšna ideja pade tudi v prostem času. Ne v smislu, da mora delat doma. Samo razmišljanje o nekem problemu.
Pa ne mu težit in mu viset za hrbtom za vsako podrobnost. Tako mu boš samo vzel voljo in bo prej ali slej rekel "Ne grem se več."
Bo pa težko, če mu računalnik ni tudi hobi.
Da ti bo pa že po pol ure gledal na uro, kdaj bo malica ali pa konec šihta, je pa bolje, da greste takoj v iskanje novega mazohista.
Še to:
takoj mu dajte za delat nek konkreten problem v firmi, za katerega se vam ne mudi.
Tudi če bo šlo počasi, bo imel takoj občutek, da dela nekaj konkretnega. Abstraktne zadeve ubijajo.
Razlago naloge/problema se mu nariše na tablo. Najslabše je nekemu nekaj razlagat zunaj na čiku. To gre vse ven.
Sinclair ZX Spectrum [Zilog Z80A - 3.5 MHz, 48kB, dvojni kasetofon,
TV-OUT, radirke, Sinclair-Basic], Sinclair ZX-81 [Z80A, 3.25MHZ, 1kB]
TV-OUT, radirke, Sinclair-Basic], Sinclair ZX-81 [Z80A, 3.25MHZ, 1kB]
Zgodovina sprememb…
- spremenilo: cekr ()
harmony ::
Sedaj je na strani OP-a, da odgovori, ce sploh posedujejo dokumentacijo. V kolikor tega nimajo, potem ne morete od vasega novega sodelavca nic boljsega pricakovati.
Kako vam tocno izgleda vas uvajalni program, ter na koliko casa je omejen? 2meseca, pol leta, leto?
Za vsak mesec bi morali imeti tocno doloceno katera znanja mora pridobiti. Ne prehitevati in biti nestrpen. Dajte mu njegov plan in ce se mu gre za job in uspeh, bo ta plan resno vzel in se na njega tudi pripravil.
Spomnim se svoje prve resne sluzbe, kjer sem imel tri mesecni plan, kjer je bilo tocno v detaljih napisano kaj moram v tem casu doseci. To je bil tudi pogoj za sluzbo za nedolocen cas. Ta papir sem imel sprintan in vsak teden sem vanj pogledal, kje sem ter se na vsake 14 dni pogovoril z mentorjem kje se trenutno v planu nahajam. Ali zaostajam ali sem na dobri poti ipd.
Na koncu sem seveda uspesno prisel skozi poskusno dobi in dobil zaposlitev za nedolocen cas. Po tem obdobju sem kar malce pogresal taksen nacin dela, saj je to bila ena res huda motivacija zame.
Kako vam tocno izgleda vas uvajalni program, ter na koliko casa je omejen? 2meseca, pol leta, leto?
Za vsak mesec bi morali imeti tocno doloceno katera znanja mora pridobiti. Ne prehitevati in biti nestrpen. Dajte mu njegov plan in ce se mu gre za job in uspeh, bo ta plan resno vzel in se na njega tudi pripravil.
Spomnim se svoje prve resne sluzbe, kjer sem imel tri mesecni plan, kjer je bilo tocno v detaljih napisano kaj moram v tem casu doseci. To je bil tudi pogoj za sluzbo za nedolocen cas. Ta papir sem imel sprintan in vsak teden sem vanj pogledal, kje sem ter se na vsake 14 dni pogovoril z mentorjem kje se trenutno v planu nahajam. Ali zaostajam ali sem na dobri poti ipd.
Na koncu sem seveda uspesno prisel skozi poskusno dobi in dobil zaposlitev za nedolocen cas. Po tem obdobju sem kar malce pogresal taksen nacin dela, saj je to bila ena res huda motivacija zame.
Invictus ::
Znajde se in naredi, ampak za njim ostane katastrofalna koda, to je problem (glej moj drugi odstavek).
Zato me je zanimalo, če ima kdo izkušnje z učenjem začetnika podobnega tipa, kot sem ga opisal zgoraj.
Delaš "code review".
Sploh za začetnika... A tega nihče ne počne več?
Kaj bi novodobni delodajalci radi, da se zadeve kar same storijo? Brez njihovega vložka?
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
moose_man ::
Nisem njegov šef (delodajalec) ampak sodelavec. Rad bi ga čimbolje uvedel v programiranje. Zaradi opažanj, navedenih v mojem prvem postu pa sprašujem za nasvete.
Kot sem napisal v prvem postu mu delamo code reviewe. Imamo alociran čas za ukvarjanje z njim. Zanimali so me bolj nasveti na podlagi izkušenj, kako ga čimbolje učit.
Kot sem napisal v prvem postu mu delamo code reviewe. Imamo alociran čas za ukvarjanje z njim. Zanimali so me bolj nasveti na podlagi izkušenj, kako ga čimbolje učit.
SimplyMiha ::
Za nalogo mu servirajte podobno kodo, kot jo dela sam, pa naj pogrunta problem. Če ga to ne izuči, ga ne bo nič! Seveda predpostavljam, da ste se pogovorili z njim glede kvalitete kode.
Invictus ::
Če podjetje nima "code practice" dokumenta, potem je težko novozaposlenemu povedati kako kodo naj piše.
Saj to imate?
Saj to imate?
"Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
moose_man ::
Imamo, ampak ni tako podroben, da bi v njem bil natančno določen vsak aspekt pisanja kode. Takšno znanje posredujemo naprej preko pogovorov / code reviewejev / same kode.
harmony ::
Isotropic ::
poj mu pa dajte za začetek odpravljanje bugov (dokumentiranih, ne nekaj na lepe oči), da se spozna s kodo.
mislim da je tko moj kolega začel.
mislim da je tko moj kolega začel.
Invictus ::
Ali imate linterje kot del pull request testov? Ali se jih ostali držite?
Mislim, da je "code review" znotraj builda kode skoraj neobstoječ v večini firm
.Čeprav zna kak lint ali kaka simple skripta, ki išče najbolj pogoste "typo" napake jezika, najti cel kup zablod.
Kot npr...
http://www.cprogramming.com/tutorial/co...
Nekaj jih najde compiler, ampak vseh pa ne...
@OP
Ne leti to samo nate
. "Life is hard; it's even harder when you're stupid."
http://goo.gl/2YuS2x
http://goo.gl/2YuS2x
janezvalva ::
haha,
tipični slovenci, "tukaj imaš delo pa ga naredi"
s kadrom se ne bi ukvarjali pa če pekel zmrzne.
tipični slovenci, "tukaj imaš delo pa ga naredi"
s kadrom se ne bi ukvarjali pa če pekel zmrzne.
IQ test: v enem vedru imaš 2l vode, v drugem 1l vode. koliko veder imaš?
Sgt. Lipnikar ::
SimplyMiha je izjavil:
To velja po vsem svetu, Janez. Smo potem vsi na svetu tipični slovenci?
Ne, ni vsepovsod tako. Pri nas pošljemo new hire na 3 tedensko izobraževanje, kjer jih naučimo best practices. To vse je del on-boardinga.
krneki0001 ::
Pri nas so pošiljali na izobraževanje ljudi, pa so bili na 10ih izobraževanjih na IBM-u (center v radovljici) in še danes ne znajo lepo programirat. Pa je jezik COBOL, ki je zelo pregleden (samo omejen na 72 znakov na vrstico).
eric_cartman ::
Mogoče še moje 2 centa na to. Bil sem že v vlogi mentorja z drugega področja, trenutno pa se tudi sam učim programirati.. Mogoče bo pomagal še pogled nekoga, ki šele osvaja znanje programiranja.
Torej hočeš nočeš, če želiš nekoga, ki nima veliko izkušenj uvajat v programiranje najprej ti kot učitelj rabiš veliko potrpljenja. Če ga nimaš, ne moreš biti mentor nekomu, ker bosta na koncu oba imela škodo. Ti boš živčen on pa se ne bo nič naučil.
Predlagam, da mu sestaviš nek plan kako bosta stvari predelala. In predlagam, da delata na konkretnih problemih. Veliko teh, ki se uči in so na praksi, se bojijo karkoli vprašat, ravno zaradi tega ker maš dosti takšnih ljudi, ki niso pripravljeni bit mentorji --> iz tega sledi, da mu vsako stvar na začetku razložiš čisto po kmečko. Nekateri (sploh programerji) sem opazil, da stvari zelo radi zakomplicirajo in se trudijo ostat pri strokovni razlagi. Opusti to in če mu ne bo jasno pojdi na razlago na magari osnovnošolski ravni.
Še bolj konkretno o učenju. Izberi si nek primer najprej ga predelajta skupaj. Razloži mu česa bi se ti najprej lotil in kakšna so pravila o strukturi kode v vašem podjetju. Potem ga nekaj časa pusti samega, naj razmisli in proba. Ti pa bi moral met prav tako za točno ta primer že spisano kodo. In na koncu skupaj predebatirata tam kjer se njegova koda močno razlikuje od tvoje in mu razložiš in pokažeš na kakšen način bi blo to boljše naredit in zakaj. Skratka nauči ga da razmišlja podobno kot ti.
Jst sem sam mentoriral ravno na tak način. Danes (po dveh letih) imam poleg sebe sodelavca, ki je dosegel naše znanje pa je bil na začetku ravno tako še brez dobre podlage.. Pri meni je trajalo kar dobrih 5 mesecev dela z njim.
V parih mesecih takšnega dela bo tudi on dojel logiko. ---> Ali pa bo dojel, da mu programiranje ni všeč. Ampak to ni na tebi. Na tebi je le to, da si potrpežljiv in da si probaš namenit čim več časa za njegovo učenje.
To pa bi bilo to.
Torej hočeš nočeš, če želiš nekoga, ki nima veliko izkušenj uvajat v programiranje najprej ti kot učitelj rabiš veliko potrpljenja. Če ga nimaš, ne moreš biti mentor nekomu, ker bosta na koncu oba imela škodo. Ti boš živčen on pa se ne bo nič naučil.
Predlagam, da mu sestaviš nek plan kako bosta stvari predelala. In predlagam, da delata na konkretnih problemih. Veliko teh, ki se uči in so na praksi, se bojijo karkoli vprašat, ravno zaradi tega ker maš dosti takšnih ljudi, ki niso pripravljeni bit mentorji --> iz tega sledi, da mu vsako stvar na začetku razložiš čisto po kmečko. Nekateri (sploh programerji) sem opazil, da stvari zelo radi zakomplicirajo in se trudijo ostat pri strokovni razlagi. Opusti to in če mu ne bo jasno pojdi na razlago na magari osnovnošolski ravni.
Še bolj konkretno o učenju. Izberi si nek primer najprej ga predelajta skupaj. Razloži mu česa bi se ti najprej lotil in kakšna so pravila o strukturi kode v vašem podjetju. Potem ga nekaj časa pusti samega, naj razmisli in proba. Ti pa bi moral met prav tako za točno ta primer že spisano kodo. In na koncu skupaj predebatirata tam kjer se njegova koda močno razlikuje od tvoje in mu razložiš in pokažeš na kakšen način bi blo to boljše naredit in zakaj. Skratka nauči ga da razmišlja podobno kot ti.
Jst sem sam mentoriral ravno na tak način. Danes (po dveh letih) imam poleg sebe sodelavca, ki je dosegel naše znanje pa je bil na začetku ravno tako še brez dobre podlage.. Pri meni je trajalo kar dobrih 5 mesecev dela z njim.
V parih mesecih takšnega dela bo tudi on dojel logiko. ---> Ali pa bo dojel, da mu programiranje ni všeč. Ampak to ni na tebi. Na tebi je le to, da si potrpežljiv in da si probaš namenit čim več časa za njegovo učenje.
To pa bi bilo to.
BigWhale ::
janezvalva je izjavil:
haha,
tipični slovenci, "tukaj imaš delo pa ga naredi"
s kadrom se ne bi ukvarjali pa če pekel zmrzne.
Kje pa ti vidis 'tipicne slovence' in kaj sploh je to? V oddelku programiranje bos moral nek tip mal bolj konkretno definirati, ce ga bos zelel uporabljati. ;)
Drugace je pa clovek prisel po nasvet kako uvesti nekega zacetnika in se povedal je koliko se ukvarjajo z njim.
lisaac ::
Za učit nekoga je potrebno veliko volje, časa in potrpljenja. Če tega s strani mentorja ni, bo zelo težko za oba. Sicer nisem v tej stroki (programiranje), toda lahko povem s svoje stroke, da ko sem nekoga učil/uvajal se mi je zdelo na momente neumno razlagat nekaj, kar sem ji/mu razlagal že par dni nazaj, pa sem se moral ponavljat znova in znova (pa makar osnova). Ampak sem pa tud vedu, da če bom tega dobro naučil (pa magari bo treba mu 5x povedat eno stvar) se mi bo v prihodnje obrestovalo ali pa ekipi ki bo z njim v prihodnje delala. In še dandanes se mi obrestuje :)
Skratka, kar hočem povedat je to, da se mu posvetite maksimalno, sprašujte njega če razume, če ima kakšno vprašanje, spodbudit da razmišlja..ker ni vsak tak, da bo skopčal in pokazal navdušenje nad novo informacijo, kot tudi ni vsak za učenje novo zaposlenega kadra. Sam sem bil pod mentorstvom, kjer sem se lahko veliko naučil in bil sem tudi pod "mentorstvom" ki je zgledal kot da bi neplavalca porinil v globoko morje rekoč "na, plavaj". Pri obeh izkušnjah sem se nekaj naučil, le da je bil pri drugi izkušnji prisoten še stres ...in stres, na katerega pa spet vsi isto ne reagirajo, zato ponavljam, posvetite se maksimalno novemu, vam se bo vrnilo dobro čez čas.
Skratka, kar hočem povedat je to, da se mu posvetite maksimalno, sprašujte njega če razume, če ima kakšno vprašanje, spodbudit da razmišlja..ker ni vsak tak, da bo skopčal in pokazal navdušenje nad novo informacijo, kot tudi ni vsak za učenje novo zaposlenega kadra. Sam sem bil pod mentorstvom, kjer sem se lahko veliko naučil in bil sem tudi pod "mentorstvom" ki je zgledal kot da bi neplavalca porinil v globoko morje rekoč "na, plavaj". Pri obeh izkušnjah sem se nekaj naučil, le da je bil pri drugi izkušnji prisoten še stres ...in stres, na katerega pa spet vsi isto ne reagirajo, zato ponavljam, posvetite se maksimalno novemu, vam se bo vrnilo dobro čez čas.
Zgodovina sprememb…
- spremenilo: lisaac ()
AndrejO ::
Mi smo uvajalni program zastavili precej "klasično"; v prihodnjih mesecih bo dobival postopoma čedalje težje/kompleksnejše naloge. Zaenkrat mu gre OK (je približno toliko hiter kot bi pričakoval glede na njegove izkušnje), ampak zelo velike težave se kažejo pri razčlenjevanju / berljivosti / strukturi njegove kode (tudi pri *zelo* preprostih problemih). Kodo je sposoben izboljšat le pod direktnim vodstvom (večkrat narekovanjem) koga izmed nas. Zaenkrat mu delamo redne code reviewe, ki požrejo ogromno časa, počasi se vidi da mu narašča znanje ampak prej omenjeni problemi pa ostajajo. Ima kdo kak nasvet, kako postopat v takem primeru? Ne moremo si namreč privoščit da bi mu leto dni tako intenzivno gledali pod prste, hkrati pa nas bo takšna koda tudi čisto preveč po nepotrebnem ovirala.
Moji predlogi/razmišljanja:
#1 Stopnjevanje je ok, samo sprotno prilagajajte tempo. Ta naj sledi dosežkom in ne nekem fiksnem terminskem planu.
#2 Code review je muz in ti bodo na začetku brezpogojno pobrali veliko časa in energije. Ne vem kako imate delo in porabljen čas ovrednoten in kako je z načrtovanjem terminov, ampak delanje CR-jev je v tem primeru samostojno delo, ki mora biti planirano, ker bi sicer izpadlo, kot da vam je produktivnost padla. Če veste, da je za to poskrbljeno, potem to več ni zgolj "požiranje časa", ampak konkretna delovna naloga, enakovredna drugim nalogam.
#3 Ukinite gledanje pod prste. Po mojih izkušnjah to negativno vpliva na celoten učni proces, ker daje mentorirancu lažen občutek varnosti in ga razrešuje občutka odgovornosti.
#4 Ker bo rezultat #3 čista katastrofa, se mu začne predajati naloge, kjer se pričakuje le omejena količina spremenjenih vrstic kode. Recimo max. 25 za začetek (odvisno od jezika/okolja ampak v vsakem primeru bolje grešiti na spodnjo stran). Edino strogo in neizprosno pravilo je, da mora vsa spremenjena/dodana koda izgledati tako, kot preostala. Če pravila niso formalizirana, jih bo potrebno ponotranjiti, ponotranjilo pa se jih bo s posnemanjem obstoječega stila. Posnemanje pa je se začne tako, da se najprej spreminja malo po malo.
#5 Ker bo rezultat #4 izgledal kot "obup ali celo šikaniranje", se z menotirirancem najprej vsedeta skupaj in predebatirata razloge za spremembo pristopa.
#6 Mentorstvo terja oseben odnos s strani mentorja. To pomeni, da ima mentoriranec hkrati samo enega mentorja. Izberite si enega med seboj in ta bo v vseh pogledih njegov prvi stik za razlago, njegov prvi code reviewer, njegov primarni sestankovalec. Mentor je tisti, ki prenaša pričakovanja skupine in podjetja mentorirancu na kar se le da strukturiran in urejen način. Drugi to počno le izjemoma. Če tega ni, potem se mentoriranca mede, ker se še nista našla dva človeka, ki bi imela čisto o vsaki stvari čisto enako mnenje.
#7 Če še nimate "designated mentorja", potem si ga izberite in, ko ga izberete, naj bo ena izmed njegovih nalog tudi vsakodneven kratek (15min) 1:1 pogovor o čemer se želi pogovarjati mentoriranec. Ta pogovor naj bi bil resnično 1:1 (ne tako, da še polovica firme "prisluškuje") in izveden toliko neformalno, kolikor je to še dopustno v okviru vašega podjetja. To je čas, kjer bo človek lahko povedal kaj ga resnično žuli. To ne sme nikoli biti čas za razpredanje o tem, česa še ne zna, kaj bi lahko naredil bolje ali čemerkoli drugem. Tukaj mentor predvsem posluša, da bo vedel kako ravnati naprej in odgovarja na vprašanja, ki jih postavi mentoriranec.
#8 Do sedaj najbolj grozen kos kode, ki ga je mentoriranec spisal, ohranite za naslednjih nekaj mesecev (recimo tri mesece). Po preteku tega časa bo njegova naloga, da ta kos kode na netrivialen način funkcionalno dopolni. Zelo pomaga, če človek obišče kodo, ki jo je že pozabil in poskusi na njej narediti nekaj produktivnega. Takrat se ljudem običajno (lahko tudi z nekaj pomoči) posveti kakšna je razlika med berljivo in neberljivo kodo, ne da bi rabili pisati definicijo enega ali drugega.
#9 Spoznaj dobrobiti, ki jih takšen človek prinese s tem, da ni obremenjen z zgodovino ekipe in podjetja. Se mu zdi vaša koda neberljiva? Morda bi se jo pa res dalo izboljšati. Se mu zdi nek način dela preveč birokratski? Morda je pa res. Je dokumentacija nejasna? Morda bi jo lahko pomagal izboljšati. Ne refleksno odpisati vseh njegovih komentarjev kot b.v. zgolj zato, ker je človek na nižjem nivoju znanja. Kot novoprišel je tudi popolnoma neobremenjen z idejo "vedno smo tako delali" in v dobro celotne ekipe je občasna prevetritev in tudi malo bolj resen razmislek o kakšnem komentarju vredno kot čisto zlato. Včasih je potreben nešolan otrok, da pove cesarju kje se mu izpod obleke vidi rit.
krneki0001 ::
Narediš en lep program, potem pas ga kopiraš in narediš iz njega skropucalo, kakršno dela on. Potem pa naključne napake narediš v obeh programih in mu jih daš za odpravit.
Bo sam videl, da se v lepo napisanem programu da veliko hitreje odkriti napake in jih odpravit. In ko mu to večkrat daš za delat, bo sam dojel, da je treba kodo lepo pisat.
Bo sam videl, da se v lepo napisanem programu da veliko hitreje odkriti napake in jih odpravit. In ko mu to večkrat daš za delat, bo sam dojel, da je treba kodo lepo pisat.
dr. Zgemba ::
Je pa ekipa dobila nalogo, da ga uvede v delo. Na kakšen način bi se vi lotili zadeve?
Ste dobili samo nalogo ali tudi čas / resurse za to, da začetnika uvedete v delo?
Če bo trpelo delo ekipe zaradi tega, ker morate nekoga uvajati, je to lose/lose situacija, ki pa jo ne-tehnični management žal vse premalokrat vidi.
technolog ::
^ Tocno tako.
Uvajat zacetnika, ki ga povrh vsega programiranje sploh resno ne zanima, je lahko huda skoda za celotno ekipo. Sploh ce zacetnik stalno mori z vprasanji cloveka, ki bi bil lahko po 4 ure skupaj v "flow modu".
Uvajat zacetnika, ki ga povrh vsega programiranje sploh resno ne zanima, je lahko huda skoda za celotno ekipo. Sploh ce zacetnik stalno mori z vprasanji cloveka, ki bi bil lahko po 4 ure skupaj v "flow modu".
harmony ::
To je, ko zelite progamerji biti nekaj vec kot "kod mankiji". Ocitno nisi sposoben biti mentor, tako da povej sefu, da tega ne zelis poceti in kodiraj tisto kar pac kodiras.
moose_man ::
Ocitno nisi sposoben biti mentor
Ne vidim, zakaj je to tako očitno, ampak ti že veš.
Obenem se zahvaljujem ostalim za levelheaded mnenja.
Zgodovina sprememb…
- spremenilo: moose_man ()
moose_man ::
#9 Spoznaj dobrobiti
Sem jih. Obstajajo.
Svoje poste sem obdržal jedrnate, da bi bili berljivi in da se ljudje ne bi vpikovali v nebistvene detajle. In seveda nisem hotel opisovati sodelavca, razmer v firmi ali šefa, zato sem namenoma uporabil karikiran motiv začetnika, ki se bo v obrt uvedel samo in izključno preko joba. Zato situacija izpade bolj črna, kot je v resnici.
AndrejO ::
Blazzz ::
Zaenkrat delate code review. Drugace pa ne?
Kot glavni problem navajas berljivost. Ali imate style guide, ki opisuje kaj je berljiva koda v vasem podjetju? Razlicni ljudje, razlicna mnenja.
Kot glavni problem navajas berljivost. Ali imate style guide, ki opisuje kaj je berljiva koda v vasem podjetju? Razlicni ljudje, razlicna mnenja.
codeMonkey ::
Naj za nalogo on posodobi dokument z nenapisinamimi pravili. Npr. s kratkim uvodom zakaj je berljiva koda pomembna, vključi primere ipd. Mogoče bo drugače gledal na to, ko bo to njegovo delo, pa še malo se bo izobrazil, ko bo prebrskal zadeve po netu.
Zgodovina sprememb…
- spremenilo: codeMonkey ()
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Kakšni so predpogoji, preden začnete pisati programsko kodo?Oddelek: Programiranje | 996 (782) | Raptor F16 |
| » | Delo programerjaOddelek: Loža | 4325 (3490) | Jure14 |
| » | Iščejo se programerji za spletno mentoriranjeOddelek: Programiranje | 9184 (6554) | Nublet |
| » | Produktivnost programerjev in programerskih ekipOddelek: Programiranje | 6051 (4869) | Šmorn |
| » | Kako najti delo?Oddelek: Programiranje | 9047 (7231) | listje123 |