mboost-dp1
Unlearn, Young Programmer
Ikke min oplevelse, men det er sikkert rigtig for rigtig mange.
Men det hele handler om at man ikke er bange for at stille spørgsmål. Og arbejder hos en virksomhed, der faktisk kan håndtere nye ansatte.
Code-reviews og en ordenlig udviklings methodology (f.eks. SCRUM), med små tasks som man kan starte med, gør underværker.
Virksomheder der faktisk har fokus på software-udvikling, og ikke alt muligt andet, er klart de bedste sted at starte som nyansat -- desværre er det de færreste jobs der tilbyder sådan et miljø.
Banker og virksomheder der bruger IT til produktionsmiljøer er de værste, da IT bruges til at løse ikke-IT problemer med.
Hvor at f.eks. Google og Microsoft, bruger IT til at løse IT problemer med.
Men det hele handler om at man ikke er bange for at stille spørgsmål. Og arbejder hos en virksomhed, der faktisk kan håndtere nye ansatte.
Code-reviews og en ordenlig udviklings methodology (f.eks. SCRUM), med små tasks som man kan starte med, gør underværker.
Virksomheder der faktisk har fokus på software-udvikling, og ikke alt muligt andet, er klart de bedste sted at starte som nyansat -- desværre er det de færreste jobs der tilbyder sådan et miljø.
Banker og virksomheder der bruger IT til produktionsmiljøer er de værste, da IT bruges til at løse ikke-IT problemer med.
Hvor at f.eks. Google og Microsoft, bruger IT til at løse IT problemer med.
God artikel, og på mange måder har han rart. Folk skal lærer at stille spørgsmål, men også lære at forklare opgaverne ordenligt.
Jeg er selv en ung programmør, og arbejder et sted hvor mange har været der siden tidernes morgen, og hvor de har opfundet de fleste af de tools vi bruger.
Jeg vil selv sige jeg er god til at spørge når jeg får opgaver jeg ikke er helt med på, eks. ved brug af gamle systemer de har udvikler hvor man er nød til at kende særhederne, kan det være svært som "ny" at forstå hvorfor det der i ens hoved virker logisk og som den rigtige løsning bare overhoved ikke virker.
Men, hvis man gerne vil have at ens unge medarbejdere spørger om hjælp og råd, så er man også nød til at være tilgængelig og åben samt have tålmodighed.
Vi unge programmører forstår jo altså ikke altid at det virkede logisk den gang tilbage i 1999 at man gjorde tingene på lige præcis den måde :)
som en sidste note vil jeg dog lige påpege at jeg synes mine kollegaer er gode til at tage fat i og spørge om råd :)
Jeg er selv en ung programmør, og arbejder et sted hvor mange har været der siden tidernes morgen, og hvor de har opfundet de fleste af de tools vi bruger.
Jeg vil selv sige jeg er god til at spørge når jeg får opgaver jeg ikke er helt med på, eks. ved brug af gamle systemer de har udvikler hvor man er nød til at kende særhederne, kan det være svært som "ny" at forstå hvorfor det der i ens hoved virker logisk og som den rigtige løsning bare overhoved ikke virker.
Men, hvis man gerne vil have at ens unge medarbejdere spørger om hjælp og råd, så er man også nød til at være tilgængelig og åben samt have tålmodighed.
Vi unge programmører forstår jo altså ikke altid at det virkede logisk den gang tilbage i 1999 at man gjorde tingene på lige præcis den måde :)
som en sidste note vil jeg dog lige påpege at jeg synes mine kollegaer er gode til at tage fat i og spørge om råd :)
Hvis jeg skulle følge min uddannelses model for hvordan et projekt skulle køres, ville det ikke kunne betale sig at tage projekter på under en kvart million.
#4
Der er firmaer som har processer der gør at de ikke kan levere projekter under 1 M$.
Men forskellige virksomheder er forskellige. Projekter i forskellige størrelser. Projekter med forskellige krav til fejlfrihed. Projekter med forskellige krav til afvigelse i forhold til estimat.
Forskelligheder i krav gør forskellige processer optimale.
Man udvikler ikke en 20000 liniers web app med reklame visning på samme måde som 2 millioner linier kode til at styre et kampfly.
Der er firmaer som har processer der gør at de ikke kan levere projekter under 1 M$.
Men forskellige virksomheder er forskellige. Projekter i forskellige størrelser. Projekter med forskellige krav til fejlfrihed. Projekter med forskellige krav til afvigelse i forhold til estimat.
Forskelligheder i krav gør forskellige processer optimale.
Man udvikler ikke en 20000 liniers web app med reklame visning på samme måde som 2 millioner linier kode til at styre et kampfly.
Helt sikkert.arne_v (5) skrev:Man udvikler ikke en 20000 liniers web app med reklame visning på samme måde som 2 millioner linier kode til at styre et kampfly.
Koden til kampflyet bliver udviklet langtsommere og dyrere fordi at der er sindsyge mængder bureakrati der gør udviklerne super ineffektive, uden nogen rigtig grund (udover paranoia og idioti)
Ellers udvikles begge dele ved at der sidder en person, og trykker på nogle taster på et keyboard.
Og man kunne sagtens forestille sig at begge dele blev udviklet af små teams der benyttede SCRUM på præcis samme måde.
Windcape (2) skrev:
Banker og virksomheder der bruger IT til produktionsmiljøer er de værste, da IT bruges til at løse ikke-IT problemer med.
Hvor at f.eks. Google og Microsoft, bruger IT til at løse IT problemer med.
Det er hvad jeg plejer at kalde:
* IT forbrugende virksomheder
* IT producerende virksomheder
De første er i sagens natur i overtal.
Men jeg er dog ikke sikker på at det altid er sjovest at arbejde i sidstnævnte.
Ja - de sidstnævnte har software udvikling som primær funktion og det giver naturligvis lidt prestige. Men det betyder altså også at omkostinger primært er software udviklings omkostninger.
Windcape (6) skrev:Ellers udvikles begge dele ved at der sidder en person, og trykker på nogle taster på et keyboard.
Ingen af delene udvikles ved tastaturet.
Hello world og op til lad os sige 2000 liniers programmer udvikles ved tastaturet.
Større programmer designes. Og som en lille detalje indtastes der noget kode.
Windcape (6) skrev:Koden til kampflyet bliver udviklet langtsommere og dyrere fordi at der er sindsyge mængder bureakrati der gør udviklerne super ineffektive, uden nogen rigtig grund (udover paranoia og idioti)
Der er fundamental forskel på små og store projekter.
Prøv og overvej fiasko procenten for projekter af 10K, 100K, 1M og 10M linier kode.
Den trend er næppe tilfældig.
Windcape (6) skrev:Og man kunne sagtens forestille sig at begge dele blev udviklet af små teams der benyttede SCRUM på præcis samme måde.
Sagtens.
Men det løser altså ikke problemerne.
Windcape (10) skrev:Problemerne ved små og store projekter er essentielt de samme, forskellen er bare skalaen.
100 programmører vil jo åbenlyst lave 10 gange flere fejl end 10 programmører.
Nej.
Og det er hele problemet.
100 programmører lavere mere end 10 gange flere fejl end 10 programmører.
Software udvikling skalerer ikke lineært.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund