Prikaži potpunu verziju : Odakle početi?
Zdravo svima,
naziv teme jeste pomalo šaljiv, ali zaista imam prilično veliku nedoumicu i problem..
Radi se o tome da ne znam kojim delom programiranja želim da se bavim, ali zaista, a verujem da mnogi koji su u ovome godinama i daleko iskusniji mogu da udele konkretne savete i pomognu..
Sebe ne mogu zamisliti kao programera koji kuca kodove satima, jer bih verovatno prolupao.. Svaki posao koji sam radio do sada, i koji sada radim je izrazito dinamičan i kreativan, te be kodiranje dnevno duže od 4h bilo ubijanje u pojam za mene. Imam neku kreativnu stranu, iako nisam radio nikada dizajn, ali mislim da mi to može leći i da imam smisla za to.
To bi mogao biti neki kreativan posao, padao mi je na um i game design, ali o tome ne znam apsolutno ništa (što naravno ne znači da ne mogu da počnem), ali mi tek to deluje potpuno neistraženo.
Padalo mi je napamet i nešto poput project management-a za IT (nešto nalik ovome i sada radim, samo nije u vezi sa IT), ali za to treba dovoljno iskustva kako bi mogao voditi projekte, kao i u bilo kojem PM .. Možda i ovo dolazi u obzir, ali kada steknem iskustva u nečemu što bih radio.
Odgovaralo bi mi nešto gde postoji velika doza slobode, kreativnosti, istraživanja i svakako konstantnog učenja i rada na sebi, ali je IT svakako takav po sebi.
I da, ono što je najbitnije, imam u planu da za par godina odem u inostranstvo i da se ovim pozivom bavim tamo. Namerno sam naveo par godina, jer znam da se ne uče ove stvari preko noći, ali sam takođe svestan svojih sposobnosti. Za posao koji obavljam uopšte nisam bio "obrazovan", ali sam ga učio učio i naučio, takođe sam i svestan žrtve, vremena i truda kojI treba da se uloži da bi se nešto postiglo, i novac mi nije bitan faktor, niti "programer su plaćeni" , već da radim nešto što ću da volim.
Takođe, ako neko ima neko "rešenje" bilo bi izuzetno lepo kada bi napisao gde mogu da krenem, materijal za učenje, sajtove, kurseve, literaturu, bilo šta korisno..
I da, pitanje zašto ne odem kod psihologa na savetovanje ili testove profesionalne orijentacije je potpuno na mestu, ali su to testovi i savetovanja opšteg tipa, a ja znam i želim da se bavim IT-jem.
Svakako hvala svima na pomoći i komentarima.
Radi se o tome da ne znam kojim delom programiranja želim da se bavim.
Sebe ne mogu zamisliti kao programera koji kuca kodove satima, jer bih verovatno prolupao..
Dve potpuno nespojive stvari. Kao da si rekao da želiš da budeš hirurg ali ne podnosiš krv. Programiranje prosto zahteva gubljenje vida ispred monitora i gomilu vremena provedenog buljeći u kod.
Dve potpuno nespojive stvari. Kao da si rekao da želiš da budeš hirurg ali ne podnosiš krv. Programiranje prosto zahteva gubljenje vida ispred monitora i gomilu vremena provedenog buljeći u kod.
Dakle, ne postoji niti jedan vid IT-ja koji ne podrazumeva isključivo kodiranje?
Dakle, ne postoji niti jedan vid IT-ja koji ne podrazumeva isključivo kodiranje?Pa ne postoji programiranje koje ne podrazumeva kodiranje. To je ono što si pitao.
Čak i da pokušaš da se baviš nekim apstraktnijim vidom IT-a tipa softverskog inženjerstva prosto ne možeš da budeš dobar u svom poslu ukoliko ne stekneš dobru predstavu o tome kako prašinarski deo posla funkcioniše.
Pa ne znam što svi podrazumevaju da ceo dan sediš i kodiraš, ja efektivno kodiram dva sata ako i toliko, ostalo prodje u sastancima, planiranju, crtanju i slično.
Al ako ti ne leži i mučenje ti je da kodiraš, bolje nemoj da se mučiš i nastavi dalje
Pa ne znam što svi podrazumevaju da ceo dan sediš i kodiraš, ja efektivno kodiram dva sata ako i toliko, ostalo prodje u sastancima, planiranju, crtanju i slično.
Al ako ti ne leži i mučenje ti je da kodiraš, bolje nemoj da se mučiš i nastavi dalje
Ja sam rekao da bih mogao, kao i ti, do dva-tri sata, preko toga ne..
A čime se ti tačno baviš, ako bi želeo da me uputiš?
Ja sam embedded developer, igrom slučaja, radim C++ primarno, plus neki C, asembler i skriptovanje po potrebi. Na projektu gde sam trenutno se insistira na kvalitetu, pa su rokovi manje više nepostojeći.
Ono što ja hoću da kažem da se programiranje ne svodi na puko kodiranje, ima i toga al nije to sve, ima tu dosta drugih stvari, više il manje zanimljivih koje čine profesiju. Ja lično ne mogu da poverujem da neko može da efektivno programira 8 sati u danu. Ja sam sebi odredio ritam da to bude do 3,4 sata jer toliko mogu da držim punu koncentraciju i da budem koristan i sebi i timu, sve van toga počinjem da brljam i pravim samo *****a.
Ja lično ne mogu da poverujem da neko može da efektivno programira 8 sati u danu.Videćeš da itekako može kad počneš da radiš negde gde rokovi postoje :D Uostalom, niko nije rekao da gledanje u kod mora da podrazumeva pisanje koda. Jako puno vremena odlazi i na code review, pisanje dokumentacije, testiranje itd.
Aktivno i korisno kodiranje je vrlo mali deo od tih 8 radnih sati, nekad za ceo dan kada smatram da sam "se ubio od posla" napišem tek pedesetak linija koda jer sam ceo dan zapravo debagirao nečiji loš kod, između toga pisao i ispravljao unit testove, radio code reviewove, analizirao tickete, proveo nešto vremena na sastancima bio na pauzi... U celoj toj priči mozak stalno "menja kontekst" I onda ne sediš I ne šljakaš zapravo ceo dan onako kako to ljudi zamišljaju.
E, sad, kad je projekat u početnoj fazi ili bukvalno u sred razvoja (ne znam još realno da ocenim šta je gore) onda može da bude stresno i naporno ali se kod mene to offsetuje time što dosta toga doživljavam samo kao izazov i priliku za učenje novih stvari i ne osećam taj stres o kome mnogi pričaju. Samo treba paziti na sebe i svoje potrebe i mentalno i fizičko stanje kao i kod svakog drugog posla.
A nešto "van programiranja" što sam spominjao? Game design ili bilo kakav dizajn?
Možda se ja nisam najspretnije izrazio, a takođe sam otvorio temu na PDF-u "Programiranje" ali sam zato više puta i inicijalnom postu spominjao da želim da se bavim IT-jem, ne striktno programiranjem.
IT je i sistemska administracija (koja sada obuhvata virtuelizaciju i cloud), mreže (takođe virtuelizacija i cloud), web dizajn i dizajn mobilnih aplikacija (user interface / user experience), QA / verifikacija, bezbednost (ovde moraš dobro znati programiranje da bi znao kakvi sigurnosni propusti postoje i kako mogu da se iskoriste), "biznis intelidžens", data majning.
A uvek možeš da se spremaš za projekt menadžera, to je suštinski organizacioni posao a opet si nekako u IT-u.
IT je i sistemska administracija (koja sada obuhvata virtuelizaciju i cloud), mreže (takođe virtuelizacija i cloud), web dizajn i dizajn mobilnih aplikacija (user interface / user experience), QA / verifikacija, bezbednost (ovde moraš dobro znati programiranje da bi znao kakvi sigurnosni propusti postoje i kako mogu da se iskoriste), "biznis intelidžens", data majning.
A uvek možeš da se spremaš za projekt menadžera, to je suštinski organizacioni posao a opet si nekako u IT-u.
PM, makar u delatnosti kojom se ja bavim, pored organizacionih sposobnosti zahteva visok nivo poznavanja procesa za koje se projekti vode..
Verujem da je ovo kod IT-ja još izraženije.. Možda bih se upustio u IT PM, ali tek nakon određenog stepena iskustva, a do tada mi ostaje da razmišljam odakle da krenem.
water wizard
30.3.2018, 1:03
uzmi onda neki projekat za vežbu, nešto što ti se sviđa, pa istražuj kuda te vodi..
Svakako da bi postao PM moraš da imaš neko hands-on iskustvo.
Ja lično imam ogroman problem sa ljudima koji vode tim il projekat a ne poznaju posao, tj. nikad nisu bili u poziciji onih ljudi koje treba da vode.
Uostalom prijavi se negde i probaj da radiš, ovo sve ovde se svodi na mlaćenje prazne slame. Veoma je individualna stvar kako će ti se svideti itd. Ovde slušaš kako su drugi ljudi prošli u različitim okolnostima i sa različitim afinitetima. Ukoliko završavaš posao tu gde si sad i poslodavac je zadovoljan sa tobom, ne vidim razlog zašto te ne bi primio nazad u slučaju da odlučiš da nećeš da se baviš programiranjem il čime već. Samo nemoj da zatvarš vrata dupetom, što bi rekao moj otac :)
uzmi onda neki projekat za vežbu, nešto što ti se sviđa, pa istražuj kuda te vodi..
Pa kako da radim projekat, ako ne posedujem fundamentalno znanje iz bilo čega u IT-ju? :)
A kada kažete testiranje, gde se takva testiranja uopšte održavaju?
water wizard
30.3.2018, 16:50
znanje stičeš usput, naiđeš na problem i polako ga rešavaš i stičeš znanje i iskustvo
A nešto "van programiranja" što sam spominjao? Game design ili bilo kakav dizajn?
Možda se ja nisam najspretnije izrazio, a takođe sam otvorio temu na PDF-u "Programiranje" ali sam zato više puta i inicijalnom postu spominjao da želim da se bavim IT-jem, ne striktno programiranjem.
QA (quality assurance) iliti narodski rečeno testiranje. Kod nas, a i u svetu, je nažalost trend da svi hoće da budu programeri i dizajneri. Nemamo dovoljan broj kvalitetnih testera. Jer svi misle da je tester neko ko samo sedi i nešto klikće i da svaki idiot to može da radi. A to je trenutno grana u IT koja ima najveću ekspanziju i bukvalno postaje zasebna grana nauke u IT koja polako stiče sve veći značaj kako softver postaje kompleksniji. Npr kod mene u firmi zapošljavamo ljude i sa poljoprivrednim fakultetom koji hoće da se prešaltaju u IT samo kako bismo ih od početka obučavali za QA, jer nema dovoljno mladih ljudi zainteresovanih za ovu oblast. Dokle god prođu osnovne tehničke intervjue i pokažu sposobnost logičkog zaključivanja, daj ovamo.
A što se tiče samog posla, balans između kodiranja i "nekodiranja" je baš ono što bi tebi odgovaralo. Možeš da ostaneš tzv manuelni tester i da u karijeri ne napišeš ništa komplikovanije od SQL upita, pa kasnije napreduješ u karijeri do test lead-a i dalje, ali ako želiš i da kodiraš možeš kasnije, kada stekneš malo QA znanja i iskustva, da ideš i u automatizaciju testova. Što je (najprostije rečeno) kodiranje botova. Korisnih, koji testiraju softver, ne onih stranačkih što jedu sendviče. Automatizacija testova (engl. test automation) je ono čime se ja bavim, pa ti pričam iz ličnog iskustva. Ofrlje je 50% kodiranje, a 50% administracija, pisanje manuelnih testova, dokumentacije ili dokazivanje programerima da nisu nepogrešivi bogovi, već regularni bilmezi kao svi mi i da im je kod đubre :D A i kreativan je posao, moraš da budeš kreativan u pogledu načina kako da pokušaš da razvališ i zakucaš neku aplikaciju ili sajt.
Mogao bi o ovome da razmisliš ako bi hteo da uđeš u IT vode, a da nemaš baš mnogo kodiranja. Čak i ako u budućnosti budeš hteo da se prešaltaš na full time development (kodiranje od 8 sati dnevno) možeš da ideš putem manual test-> test automation-> development. U svakom slučaju lakše ćeš naći početni posao u test grani bez nekog velikog tehničkog znanja ili znanja programskih jezika.
Kod nas, a i u svetu, je nažalost trend da svi hoće da budu programeri i dizajneri. Nemamo dovoljan broj kvalitetnih testera.Zato što QA u klasičnom smislu već godinama unazad praktično nestaje. Savremeni razvoj softvera odavno je prešao na moderne agilne modele gde je TDD de facto postao standard koji softver neprekidno testira od faze začeća ideje pa sve do isporuke. Ključ efikasne organizacije timova postala je konvergencija uloga tj. sposobnost pojedinaca da po potrebi brzo i efikasno preuzmu neku drugu dužnost a poslodavci su i više nego svesni da takvu univerzalnu ulogu najbolje ispunjavaju osobe koje zapravo kreiraju softver. Drugim rečima, mnogo je lakše napraviti QA testera ili podršku od nekoga ko je radio na pisanju koda jer je njegova dnevna rutina i onako već podrazumevala pisanje testova, ispravljanje bagova, pisanje dokumentacije itd. nego raditi bilo šta u obrnutom smeru.
Dedicated QA je za većinu kompanija prosto postao previše skup sport pa se sve veći broj njih odlučuje da teret testiranja prebaci na podršku ili zajednicu. Recimo danas nije ništa neobično da proizvod bude ponuđen u bar dve varijante gde je prva oslabljena besplatna i open-source varijanta u kojoj bagove ispravlja zajedica i druga u punoj komercijalonoj closed-source varijanti koja integriše sve ispravke open-source varijante. Zajednica i klijenti dobijaju bolji i stabilniji softver a kompanija praktično nema nikakvih troškova na QA. Win-win scenario.
DevOps zanimanje je možda ono što autoru teme treba. Koliko sam razumeo, DevOps radnici se bore sa serverima, kontejnerima (Docker, LXC i sl.), cloud servisima, a kao oružje koriste programiranje tj. obično neki interpretirani jezik tipa Python i Ruby.
sonebrate
10.4.2018, 10:26
Zato što QA u klasičnom smislu već godinama unazad praktično nestaje. Savremeni razvoj softvera odavno je prešao na moderne agilne modele gde je TDD de facto postao standard koji softver neprekidno testira od faze začeća ideje pa sve do isporuke. Ključ efikasne organizacije timova postala je konvergencija uloga tj. sposobnost pojedinaca da po potrebi brzo i efikasno preuzmu neku drugu dužnost a poslodavci su i više nego svesni da takvu univerzalnu ulogu najbolje ispunjavaju osobe koje zapravo kreiraju softver. Drugim rečima, mnogo je lakše napraviti QA testera ili podršku od nekoga ko je radio na pisanju koda jer je njegova dnevna rutina i onako već podrazumevala pisanje testova, ispravljanje bagova, pisanje dokumentacije itd. nego raditi bilo šta u obrnutom smeru.
Dedicated QA je za većinu kompanija prosto postao previše skup sport pa se sve veći broj njih odlučuje da teret testiranja prebaci na podršku ili zajednicu. Recimo danas nije ništa neobično da proizvod bude ponuđen u bar dve varijante gde je prva oslabljena besplatna i open-source varijanta u kojoj bagove ispravlja zajedica i druga u punoj komercijalonoj closed-source varijanti koja integriše sve ispravke open-source varijante. Zajednica i klijenti dobijaju bolji i stabilniji softver a kompanija praktično nema nikakvih troškova na QA. Win-win scenario.
Vidiš, upravo takav pristup dovodi do lošeg softvera i istovremeno predstavlja veliki "kulturološki" problem i kod nas, a i u svetu, iz dva razloga. Masovno ljudi misle da su unit testovi sve što ti treba, ali ipak nije tako. Agile ne znači da treba da zanemariš sve osim unit testova i da svako može da radi sve (ne može kardio hirurg da operiše mozak i ne može somun bez bar čet'ri kifle da balansira) i sloboda Mile, jednakost, kuloća, Apple proizvodi i lake droge, već agile znači da možeš metodologiju i proces razvoja da prilagodiš svojim potrebama, nema fiksnog "ein zwei drei" kao kod waterfall-a.
Prvo, ne možeš kompletan razvoj iole komplikovanijeg softvera zasnovati isključivo na unit testovima i oslanjanjem na zajednicu. Postoje i funkcionalni testovi, a iz svog iskustva govorim da velika većina malih firmi upravo kiksa na ovome kada dođe do nečeg ozbiljnijeg i komplikovanijeg. Oslanjaju se isključivo na unit testove i kao malo promrndžaju po gotovom proizvodu, kakav crni functional regression, pa kada proizvod dospe u javnost mali milion bagova ispliva. To je možda i OK ako praviš malu mobile aplikaciju ili jednostavniji web portal koji nemaju veliki uticaj na samo poslovanje klijenta ili je retail oriented aplikacija (namenjena širokim narodnim masama, merimo puls, kalorije i ti fazoni), ali ako imaš ozbiljan komad softvera, recimo finansijski, administrativni, industrijski ili prilikom implementacije ERP rešenja funkcionalni testovi su must have. Jer ako tu dođe do funkcionalnih bagova koji dospeju u live verziju šteta može da se meri milionima. A to developeri ne mogu da rade, već mora da postoji dedicated QA, jer niti developeri imaju vremena da se bakću sa tim, niti znaju kako da se bakću sa tim, niti javnost i klijenti imaju znanje za ozbiljniji bug hunt.
Drugo, opšte poznato nepisano pravilo je da developer nikada ne može biti dobar test automation QA ili QA uopšte. Jednostavno drugačiji mentalitet i modus operandi. Developeri grade nešto, QA pokušava da to razvali, najprostije rečeno. Takođe postoje pravila razmišljanja oko pisanja funkcionalnih testova, kao i razne metode koje developeri ne poznaju, ne zato što su glupi i nesposobni, već zato što im nije u opisu radnog mesta niti su to bilo gde učili. Dobro obučen i iskusan QA zlata vredi. Dalje, auto testovi moraju biti rogobatni (u smislu da ne izgledaju "lepo na oko" kao što developeri vole da krate i da sve bude reusable kod), prilagodljivi, pouzdani, čitljivi (u smislu koda, da bukvalno iz linija koda čitaš "fizičke" akcije koje se izvršavaju) i jednostavni. Developeri koji rade automation jaaaako često, u oko 99% slučajeva, zakomplikuju automation framework i onda dolazimo u situaciju da većina testova koji padnu prilikom izvršavanja padaju zato što se framework zaglupeo. Takođe, komplikovani framework je težak za održavanje, nepouzdan i izuzetno produžava vreme i napor potreban da se napišu novi testovi. Da ne govorim što proveravaju pogrešne stvari kao checkpointe ili ne proveravaju dovoljno stvari. Developeri imaju mentalitet da ako je na kraju funkcionalnosti assert = true sve je superiška. Šta se dešava između nema veze. Ne bi verovao koliko sam puta u 12 godina karijere bacio u đubre legacy framework koji su pisali "refaktorisani" developeri i krenuo sve iz početka, jer je jednostavno bilo lakše da se tako uradi nego da se budži postojeće. Ne zato što su ti developeri loši inženjeri, takav je pristup i logika posla, opet kažem.
Velika većina bagova nastaje, a i otkrije se upravo kod integracije i krajnje funkcionalnosti, a to upravo pokrivaju funkcionalni testovi. Do dana današnjeg nisam video unit ili integracioni test koji pokriva boundary value analizu, niti je to moguće ubaciti u unit testove, a upravo to otkriva ogroman broj bagova.
Tako da dedicated QA ne samo da ne "izumire" već je sve više i više važan deo razvoja softvera. Ne bi najveće svetske kompanije pucale grdnu lovu na to da je nebitno. Jer na kraju štedi lovu i vreme.
Oslanjaju se isključivo na unit testove i kao malo promrndžaju po gotovom proizvodu, kakav crni functional regression, pa kada proizvod dospe u javnost mali milion bagova ispliva.
Cak ni oslanjanje na unit testove nije problematicno koliki je problem nepoznavanje relevantnosti testa. Kako kaze jedan moj kolega: "Dzabe ti test ako nece da padne kada promijenis biznis logiku u implementaciji".
Moram se sloziti da su unit testovi generalno, jeftini. Iz mog iskustva, integracioni testovi su se pokazali kao mnogo relevantniji. Pokrivas citavu "vertikalu". "End-to-end" testovi takodje imaju ogroman znacaj iako su mnogo "skupi" jer oduzimaju mnogo vremena da bi se napisali. Medjutim, najteze od svega je rvati se s musterijom i ubjedjivati ih da su testovi neophodni. :)
sonebrate
13.4.2018, 13:41
Medjutim, najteze od svega je rvati se s musterijom i ubjedjivati ih da su testovi neophodni. :)
Can I have an "amen" for this? :D
Ali ni end-to-end testovi nisu skupi ako imaš dobre alate i inženjere koji znaju šta rade.
I zvanično odosmo off topic :)
Ja i kao developer gledam kako mogu da raz***** rodjeni kod, jer ko ce to znati bolje od mene koji sam ga napisao, kontam da je to osnovni korak u razvoju.
QA meni vise dolazi do izrazaja zbog navike pisanja testova da kod prodje, odnosno test napisan za ono sto kod radi, sto ume da bude drugacije od onoga sto bi trebalo da radi. Mada kod mene na projektu nema QA il Testera uopste, tj. pozicije koja samo to radi, vec svi sve rade a zanimljivo je sto je projekat klasifikovan kao nesto od cega zavise ljudski zivoti.
vBulletin® v3.8.7, Copyright ©2000-2024, vBulletin Solutions, Inc.