Pa kad bi sve islo glatko ...

Stvar i jeste u problemima i u nacinu kako se nosis s tim. Od problema ne treba bezati, vec traziti ne samo resenje, vec najbolje od vise resenja, jer u tom resavanju se i najvise uci i napreduje.

Ako si hteo neki penzionerski posao, gde nemas problema i rokova -

Da, sve nabrojano. Ne možeš očekivati od posla da 100% vremena sediš i kucaš kod. Ne bi ni valjalo da je tako.

pa to mi je jasno.
ali se javlja problem efikasnosti.
jer tebe netko plača da radiš, a ne da traziš rješenja što zbog neznanja ili ne iskustva ili nečeg drugog, osim ako si pripravnik.
tebe poslodavac plača za rad, a ne za zajebanciju.
pa zar nije onda recimo neugodno reći, da se rješenje traži.
vrijeme ide, a tvoj posao stoji i čeka dok ti nađeš rješenje, a opet si plačen kad i stojiš.
kako to u praksi izgleda.
itd..

Pa podrazumeva se da poslodavac mora ulagati u tvoj razvoj, verovatno je svestan da ne znas "bas sve", a ako se bojis prigovora na racun tvoje efikasnosti, postavlja se pitanje kako se efikasnost programera meri: u broju kodnih linija, ili je merilo nesto sto se bas ne da tako lako izmeriti ...

Ja se ne bih brinuo na tvom mestu, ako nesto stoji zbog toga sto ne znas, kazes da ces zavrsiti kada pronadjes resenje i das neke okvirne rokove za to (ako od tvog posla i drugi zavise).

Vidi, niko ne zna sve. Poznato je istraživanje da produktivnost različitih programera ume da varira do par desetina puta. Jednostavno, ako imaš boljeg programera pored sebe, pitaš ga. Ako nemaš, istražuješ, kopaš po netu, budžiš itd. Ako poslodavcu treba neko ko će da bude produktivniji od tebe, moraće da plati više.

Nemoj da se opterećuješ tim stvarima "šta ću ako..." :) Za početak je potrebnija petlja, a kasnije (kad uspeš) ćeš se čuditi kako si samo mogao da se usudiš da tražiš posao. Kad dođeš u neku firmu uglavnm te nisu unajmili da ti njih naučiš "kako se prave deca" nego oni tebe.

Na primer, u jednoj ozbiljnoj softverskoj firmi možda 95% vremena sam provodio u Wordu projektujući i crtajući interfejse, odnosno kako treba da izgledaju i šta treba da rade neki budući podsistemi, a 5% u razvojnom okruženju. Drugim rečima, krenulo se od Projekta koji je samo korak od Helpa, a ima ko će da isprogramira čak iako ja ne budem znao. Moje je bilo da projektujem podsisteme najbolje što sam video, a ne onako kako bih umeo da odradim. Tada nisam kapirao da je važnije je znati ŠTA se hoće, nego KAKO nešto uraditi.

Nema tu filozofije, samo hrabro.

Hajde da probam da rangiram korake (po efikasnosti) koje bi preporucio:

1. Pitas nekog iz tima da ti da savet kako i sta u raditi u datoj situaciji
2. Izvuces telefonski imenik i raspalis po prijateljima za koje znas da bi mozda znali odgovor na tvoje pitanje
3. Google is your friend
4. U slucaju da nista od gore navedenog ne upali (a secam se X takvih slucajeva), zasuces rukave, pa onda
u zavisnosti od problema: ili raspalis po literaturi ili raspalis po kodu (ako imas problem sa koriscenjem nekog API-ja koji nece
da radi bas kako si zamislio - nemoj uvek da se oslanjas na to da su drugi bas 100% znali sta rade, ja sam nalazio mali milion
bug-ova u tudjem cak i profesionalnom kodu) ili stara i proverena PiG metoda (proba i greska) odnosno cackas dok ne iscackas

I bitna stavka - upornost, upornost ...

Bitno je takodje da si svestan sta umes a sta ne umes, i naravno ne daj da sujeta radi i ako nesto ne znas, prvo trazi pomoc
...

Imam nekoliko prijatelja programera koji zbog grize savesti sto nesto ne znaju ostaju na poslu do 23h umesto do 17h, onda sednu u poslednji dnevni autobus pa cim uhvate mesto otvore laptop i nastave sa radom. Prespavaju i ujutro kad ustanu opet isto - autobus, laptop, posao. Ne znam da li je to u redu, ali oni tako rade.

obicno je plata prilagodjena znanju, a ocekivanja plati... tako da te placaju da ucis i trazis resenje, jer bi neko ko ne gubi vreme na te stvari (neko sa vise iskustva i znanja) kostao srazmerno vise.

Najbolje je da programer sam proba naći rešenje (dokumentacija, google... ), ako ne može onda da se konsultuje sa nadležnim (project manager ili ko već), a kao poslednja opcija bi bila da pitaš kolegu programera... Nema ništa gore nego kad dobar programer gubi vreme pomažući oko trivijalnih stvari lošim programerima... Ti loši ili nek sami nauče, ili će taj dobar uzeti taj problem i sam rešiti za deseti deo vremena...

Uz bazicno znanje, ovo je sushtina!Cenim takav stav;)

dali se samo piše kod, ili se moće tu i tamo kompajlirati pa pogledati kako radi i dali radi.
ili se testira isključivo poslije?

kako mislis pisanje koda bez kompajliranja? kako da znas da si napisao ono sto treba?
ja barem ne cuh da se programira bez kompajliranja..

Da ti nisi s FON-a? :) Čuo si nekad za skript jezike? PHP, zvuči poznato?

@ventura: Ni manje ni više, nego projekt menadžera... Interesantno.

Pa koga da davi, čistačicu, vrtlara?

Da davi team leadera on je obično programer, i obično ima pamenija posla nego da se zajebava sa nekim trivijalnim glupostima, a ako se obrati PM on mu eventualno može pomoći tako što će ga uputiti na najmanje zauzetog programera, a i u opisu posla mu je da koordiniše i da na najefikasnij način upravlja timom...

Ja samo mogu reci ono sto su ti vec drugi rekli, treba biti hrabar i resavati probleme kad na njih naidjes, ja sam se nasao u milion situacija da me rok ubija a problem se cini na prvi pogled neresiv jer sam sve koncipirao na pogresan nacin od pocetka, na kraju sam ipak nasao veoma pametno i optimalno resenje, tako se u stvari i uci. Najvaznije za programera je da koristi dokumentaciju i da zna da se snadje, dzabe ti sve ako ne mozes da resis problem ili da se snadjes kako da ga resis.

Imas Google, imas forume imas prijatelje u najgorem slucaju ako nista ne uspes da nadjes na internetu, ali nemoj se oslanjati na druge vec pridji problemu sam i samo uporno, shvati da ti to mozes i moras i uspeces ne postoji drugi recept.

a,jesam, cuo sam :D
ne znam sta mi bi da smetnem sa uma skript jezike ("brzi" za testiranje od "kompajlirajucih")... verovatno zato sto je poruka na koju odgovorih delovala kao da se odnosi (samo) na jezike koji se kompajliraju


e, spominjete rok: kako se doslo do nekog roka (vasi primeri iz praxe, ako je moguce)? posto softverski projekti uglavnom znaci probijanje rokova ili pogresno procenjivanje roka zavrsetka

Prosto. Prodavac softvera iz najrazličitijih razloga (da ostavi utisak, da pretekne konkurenciju, iz potpunog neznanja itd) pred kupcem lupi neki rok. Onda programerima kaže "e, to je kupcu hitno, hoće da to uradimo do kraja oktobra".

Ili, često u većim firmama, korisnikov zahtev zaglavi u inboxu nekog PM ko je na odmoru ili ko jednostavno ne čita mejlove i onda kad to dođe do programera već je kasno.

Milion razloga, a većina njih nema veze sa programerom.

Prva stvar koju bi trebalo da uradiš je da pitaš svog pretpostavljenog, ne postoji efikasnije rešenje.
Ovo pod pretpostavkom da nisi glavni programer ili specijalizovani senior koji bi trebalo i da zna
više u svojoj oblasti od glavnog programera. Kopanjem po dokumentaciji i guglanjem možeš često doći
do odgovora ali to radi u slobodno vreme ako želiš da popraviš svoju sposobnost kao programera.

Ako ćutiš i mučiš se da rešiš može da se dogodi da rad na zadatku potraje daleko duže nego što
bi trebalo i opet je tvoja efikasnost nula. Ja to zovem "kineski pristup" :)
Izuzetak je samo ako imaš dovoljno dugačak rok u kome možeš i da obaviš istraživanje/učenje sam.
Ja lično umesto dugih rokova volim da vidim dobre programere.

@ventura
Ovo o čemu pričaš je uobičajena zabluda, glavni programer je menadžer, ne programira preterano jer
nema kada da stigne od menadžerisanja zadataka, kontrole verzija, izveštaja, pomaganja drugima i tako dalje.
Takođe, menadžer projekta ne bi trebalo ni u kakvoj varijanti da bude čovek koji upućuje kod najmanje
zauzetog programera, to postavlja PM-a na poziciju glavnog programera a glavni programer onda je ništa
više nego najcenjeniji programer, i to samo po tituli. Time se potpuno zaobilazi hierarhija koja postoji
sa razlogom.

Moguće, ali ja pričam iz svog iskustva... Ja recimo u firmi radim kao project manager, dakle svo to menadžerisanje, izveštaji, verzije, prijem i obrada zahteva, dokumentacija, rokovi, makro upravljanje taskovima, birokratija radim ja... Naravno, uz sve to ja imam saradnju sa glavnim programerom koji mi daje tačne rokove, i koji radi direktno dodeljivanje taskova programerima, a dalje većinu menadžmenta (tj. koliko god je moguće) preuzimam ja, kako bi on što manje vremena gubio na to, jer je on najiskusniji i najproduktivnij programer koji stvarno odradi lavovski deo posla... E sad, znam tačno kakva je situacija kad manje iskusan programer dobije neki task, pa krene da ga cima svako 15 minuta za gluposti, onda se dođe u situaciju da ne samo taj što zapitkuje, već i glavni programer ne urade ništa, jer ovaj treba da mu svako malo objašnjava nešto... A da ne pričamo o prekidima i prostom gubitku koncentracije sa svakom sitnicom... Zbog toga je kod nas pravilo da ukoliko iskrsne neki problem, prvo se obraćaju meni, ako ja ne mogu da pomognem, ja uvek znam ko šta radi, koji task, i koliko vremena ima i onda preusmerim to u tom pravcu, a ako i to ne uspe, onda ga pustim da sam reši problem, a ako i to ne uspe onda se obraćamo glavnom programeru za pomoć... Ali i to naravno se svodi da ga neću cimati svako 15 minuta, već čekam da se skupi nekoliko stvari pa tek onda... I naravno taj početnik programer je u drugoj klasovnoj kategoriji od programera, senior programera i glavnog programera(team leadera), tako da su te stvari sasvim očekivane, i vremenom se proređuju...

Ali dobro, to je kako mi radimo posao, sigurno važi ono pravilo 100 ljudi 100 ćudi..

jel bar taj pita nešto konkretno ili banalne stvari?

_{[Ovu poruku je menjao Gojko Vujovic dana 22.10.2007. u 11:56 GMT+1]}

Ko?

pa ovaj šta je ispitivo svakih 15 minuta

Verovatno svaka firma ima neke svoje principe rada, ne verujem da se može napraviti paralela za sve.

Ja sam naleteo na sledeći slučaj:
1 NIVO: gazda + nekakav administrator (objasnicu kasnije)
2 NIVO: 2 vrhunska progamera
3 NIVO: 15-tak programera
4 NIVO: 20-tak volontera programera

Da krenem otpozadi:

(4) To su bili talentovani studenti koji bi da nesto nauce ali i da budu kandidati za 3 nivo. Oni su uglavnim vrsili Whitebox i Blackbox testiranje projekta, a najcesce su za pocetak isli po Helpu i trazili neusaglasenosti, dakle bug je ako u Helpu pise jedno a program radi drugo, bez obzira sto program radi i vise nego li Help tvrdi. Na primer u Helpu ne piše da je moguće štampanje. Takodje, dobijali su i delove koda, najcesce klasa i trebali da je nateraju da pucaju za odredjene vrednosti parametara. Ko se pokaže kao talentovan, mometalno ide u 3 nivo (odakle već neko sam odlazi zbog iscrpljenosti, nezadovoljstva ili neznanja).

(3) Tu sam bio i ja. Dužili smo između 1 i 5 podsistema, zavisno od njihove složenosti a i stepena verziranosti samog programera. Ko će šta da duži, određivali su oni iz nivoa 1 i 2, bez administratora. Naša primarna misija *nije* bila da napišemo kod, nego da projektujemo podsisteme. Zapravo bio je greh reći u govoru PISANJE koda. Gazda se opsano ljutio. Takođe, greh je bilo reći i TESTIRAO sam kod, trebalo je reći verifikovao sam kod. Testiranje je nešto sasvim drugo, barem po njemu... ima tu i istine.

Dakle, u Wordu smo crtali (sa screenshotovima iz Delphija :) ) kako šta treba da izgleda i šta treba da radi, kao da je Help u pitanju, a sam projekat (ko je umeo) projektovao je u UML/Rationa Rose-u (on je samo dekriptivan, pa ne treba sporedna dokumentacija u vezi toga, naravno).

A kad se programira? Čekaj, još je rano!

(2) Ovo su najbolji, najverziraniji programeri u ekipi. Oni zajedno sa gazdom čine Product Team i donose sve važne odluke. Oni razvijaju ključne podsisteme projekta i daju zeleno svetlo za neki podsistem koji ovi iz nivoa 3 treba da urade. Kada neki programer iz nivoa 3 projektuje neki podsistem, šalje se njima na verifikaciju. Oni proučavaju funkcionalnu secifikaciju (pomenuti Word dokument) i UML i daju primedbe. Prodje i po nekoliko revizija (iteracija piši/briši) dok se ne dobije zeleno svetlo za početak kodiranja.

E, tek tada ide kodiranje. Drugim rečima, ni jedna jedina linija koda bez projekta nije vredela ništa.

(1) gazda, donosi odluke kad ko treba da se ukloni iz ekipe. Vodi računa da izvređa i omalovaži one iz nivoa 3, ne bi li im smanjio platu i naterao da rade još više, 24h ako može, i gleda da ohrabri one iz nivoa 4 da upadnu u klopku. Inače, zvuči suludo, ali onaj projekat koji su odradili oni iz nivoa 3 je zlata vredan. Takvo nešto, servirano na tacni i pročišćeno od svih mogućih anomalija može bilo ko da uradi, pa čak ne mora niko iz ekipe. Daće ga na berzu ako treba. Taj (sa strane) koji za 1000DEM odradi taj podsisterm smatraće se srećnim, ali je gazda mnogo srećniji jer je to tek pola plate/plata jednog programera u toj ekipi, i njemu vredi barem 100x više od tih 1000DEM kada je u sklopu projekta.

(1) administrator (najneukiji od svih, uopšte i nije programer, pitanje je da li i tablicu množenja zna 100%), skuplja informacija od svih.

Svaki radni dan programera je morao biti dokumentovan stavkama (šalje se emailom)
1. šta sam danas radio
2. na koje sam probleme naišao
3. šta ću sutra raditi

... na osnovu toga pravi neke tabele i obaveštava 1 i 2 nivo (dnevni izveštaj).

Naravno, on služi i da fotokopira i šalje potrebene knjige, nabavlja softver (tada je bio Dial-up), da deli platu, cinkari po potrebi u korst gazde.

E sad, nama programerima je bilo PREĆUTNO ZABRANJENO da arčimo skupo vreme onih iz nivoa 2, pa smo bili prepušteni sami sebi i Guglu. Džaba smo emailom kontaktirali onu dvojicu, oni se jednostavno ne jave ili se jave kasno. A možda je to i bila neka taktika da nas se otarase kada privedemo projekat i interfejse kraju... he he :)

Pa to ti je slučaj sa svakim novice programerom... Uglavnom su to banalnosti vezane za sam projekat, neke tehničke nedoumice i sl... A ako nešto ne zna, tu mu je F1 i Google pa nek traži sam, jer takvih problema&rešenja obično ima na tone po netu.. Plata mu to dozvoljava... A ako baš je neki problem onda ide ko što sam napisao...

a dali mu rok to dozvoljava?

ako je stiska, vremena malo?

Teško da neka firma/tim sa rokovima zavisi od rada junior programera... Obično isti rade trivijalne poslove u početku, i ima dosta vremena za sve...

ovaj odgovor se tražio.

@ventura
Ovo što sam napisao podrazumeva da je tako nekom junior programeru dovoljna relativno
kratka instrukcija posle koje može samostalno da dovrši istraživanje. Smaranje na
svakih 15 minuta sigurno nije nešto što bi se tolerisalo :)

@X files
Ovo što si opisao je previše rigorozno i sigurno ne doprinosi finoj radnoj/timskoj atmosferi.
Potseća me na priče o Džordžu Lukasu koji je poznati psihopata i u koga je zabranjeno čak i gledati ili sledi otkaz :)
Inače, kategorija 4 potseća po opisu najpre na QA/QC ekipu (white/black box).

Da, slažem se sasvim, ali to je valjda bio deo strategije. U toj ekipi niko ni u koga nije imao apsolutno poverenje. Posao je bio polu TelJob (na daljinu). Sastajala se ekipa barem 2 puta mesečno u BG-u da se licem u lice razgovara o važnim aspektima razvoja projekta.


Ni ovo nije daleko od istine. Kako se dobar deo posla radio od kuće, postojao je Web interfejs da se prijaviš/pauziraš/odjaviš. Radno vreme je bilo 8h, i za to vreme je shodno tvom statusu gazda zvao da vidi jesi li na radnom mestu. U početku sam pauzirao i kad idem u WC, a pogotovo kad doručkujem, ručam. Ako radni dan zatvoriš sa 08h15min, gazda se ljutio rečima - jedva čekate da završite posao.
...i da ne detaljišem, već sam i zaboravio sve što se negativno događalo. Da ne pominjem zaostatak plate za 3 meseca koji su zapravo veštački otkazni rok.

Poenta je bila u tome da je za razmere tog projekta broj programera bio mali i nije bilo vremena za nečiju obuku. Trebalo je odjednom znati i UML i CVS i zagnjuriti se u projekat koji se kompajlirao satima. Tip je čak nudio raznim fakultetima da im opremi najsavremenije računarske učionice u kojima će da rade po "njegovom" programu, a da za uzvrat godišnje njemu daju jednog/dva studenta koji su nabolje savladali "obuku".

Izrabljivanje na balkanski način.


Upravo. To i jeste bila QA/QC ekipa. Zato se gazda i ljutio kad kažemo da smo mi nešto TESTIRALI.

Ovo je jedan od razloga zbog kojeg remote posao nije preterano produktivan, ne postoji
mogućnost da se upotrebi distribuirani build sistem (osim ako nemaš klaster kod kuće).
Doduše, pitanje je koji je konkretan razlog dugog kompajliranja, neretko je problem u samom projektu.

mozda mogu da momognu iskustva sa mog radnog mesta, mada mi nismo programeri vec vise administratori...
Svima nam je jasno da neefikasnost jednog coveka znaci neefikasnost celog tima, a toga ne sme da bude. Cim se problem pojavi, svi priskacu u pomoc, problem se resava, radi se dalje, pojavi se problem kod nekog drugog, opet svi priskacu u pomoc... Ponekad nervira to sto kad pocnes nesto da radis a neko te na pola prekine sa necim desetim, ali, ko hoce da mu se pomogne mora i da pomaze, tako da se to prihvata tako i veoma smo efikasni, od nas 6 uvek neko zna resenje iz momenta, nikada se ne izgube sati na proucavanje dokumentacije. E, sad, ne znam da li je taj nacin rada moguce primeniti na programere.

Projekat je pre svega bio ogroman. Zvuči nadrealno, ali u to vreme firma se obraćala Borlandu (OWL vreme) za novim linkerom koji je mogao da svari broj fajlova koji su se krčkali. I dobili su ga. Postojala je mogućnost posedovanja velikog broja OBJ + manjeg broja CPP fajlova, pa da se projekat kompajlira, ali ja sam po prirodi posla morao da imam ceo kod pa mi je to oduzimalo vreme. A moguce je i da je make fajl bio sumnjiv...

@X files
Jedno od rešenja za takav problem je da se za svaku biblioteku napravi po jedan ili dva cpp fajla
koji bi imali nešto ovako (na primer lib.cpp):

Time dobijaš daleko veću brzinu kompajliranja zato što se procesira manje header-a, a i broj obj
falova je za red veličine manji. Problem sa ovim pristupom je što menjanjem jednog fajla rekompajliraš
kompletnu biblioteku. Drugi problem je što je kod retko dovoljno "čist" da bi se tako nešto uradilo.