1 / 10
Det er velkendt, at programmører og udviklere har nøje kendskab til en sær verden fyldt med mærkelige kodelinier og mærkelige tegn.
Men det er langt fra det hårdeste ved jobbet. Det er derimod en række opgaver, der ikke har noget særligt med kode at gøre.
Det viser en tråde på debat-foraerne Quora og Ubuntu Forums, hvor udviklere har diskuteret de opgaver, som de mener er de sværeste.
Klik videre og se de sværeste opgaver.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
2 / 10
Det kan være en svær opgave at komme med et sandfærdigt estimat på, hvor lang tid det vil tage at udføre en kompleks opgave allerede inden man overhovedet er gået i gang.
Men det kan man som programmør sagtens blive afkrævet svar på - også selv om man aldrig har udført en lignende opgave før.
Det betyder, at man skal lægge an på fornemmelser - og så lægge noget tid oven i på de uforudsete hændelser, der altid opstår.
Som en programmør skriver: "Efter min mening er 'estimate' det sværeste, fordi de fleste personer normalt tager det som et løfte."
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
3 / 10
Mange udviklere finder det meget svært at designe og implementere hele den tekniske løsning på baggrund af kundens og it-arkitektens krav.
Opgaven kan eksempelvis bestå af design af data- og kodestruktur, funktionelle algoritmer og fastlæggelse af applikationsflow, som alt sammen skal passe til forretnings-logikken på en måde, så kunden bliver tilfreds.
Bliver dit design for stort, kan det hele kollapse. Den rette løsning kræver, at du har en ide om, hvordan tingene egentlig kommer til at spille, inden du overhovedet sætter i gang.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
4 / 10
Det kan være en udfordrende opgave at skrive test, når man egentlig bare gerne vil i gang med at skrive selve applikationen, som det hele drejer sig om. Men der er ingen vej uden om. Der er brug for eksempelvis isolerede softwaretest, der kan sikre, at individuelle funktioner lever op til de opstillede kriterier.
At skrive test er vigtig, da det kan blandt andet kan anvendes til at identificere og fjerne bugs tidligt i udviklings-processen, ligesom det kan danne grundlag
for senere test efter koden bliver ændret eller opdateret.
Nogle udviklings-metoder anbefaler, at man skriver testen før selve koden udvikles.
Det kan være en langstrakt opgave først at vælge de test, man skal skrive, og dernæst kode dem - og det bliver ikke bedre, hvis man egentlig bare gerne vil i gang med at skrive selve applikationen.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
5 / 10
Mange programmører vil rigtigt gerne kode og fokusere på deres skærm.
Mindre godt er det, hvis de skal bruge deres tid på at indsamle krav og ønsker fra kunder, udforme status-rapporter til cheferne, samarbejde med testfolk og bruge tid på at diskutere projektet og detaljerne med andre programmører, der altid ved bedre og altid har 'gode' råd til, hvordan koden egentlig bør skrives.
Mange programmører tænder især helt af på at skulle forklare tekniske ting til ikke-tekniske folk samt på at skulle have arbejdet endevendt af andre.
Som en af programmørerne skriver: "Det er meget nemmere at overbevise en processor om dens opgave, end det er at overbevise visse personer."
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
6 / 10
Som programmør er det svært at komme uden om at en gang imellem at skulle vedligeholde, debugge eller videreudvikle en applikation eller noget kode, som en anden udvikler egentlig står bag.
Udfordringen ligger i først og fremmest at forstå den fremmede kode helt til bunds - og forstå, hvad den oprindelige udvikler egentlig havde i tankerne.
Det kan være en stor opgave - selvfølgelig især, hvis den oprindelige programmør ikke lige er til at få fat på samt hvis koden er dårligt skrevet eller dårligt dokumenteret.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
7 / 10
Enhver udvikler kender til opgaven med at skrive dokumentation, der jo som bekendt skal forklare for eftertidens brugere og kodere, hvad koden gør og hvordan applikationen virker.
Det kan være en tidskrævende opgave, som ovenikøbet kan føles som sur tidsspilde - især hvis man ikke lige kan forestille sig, hvem det lige er, der skal læse dokumentationen.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
8 / 10
Som udvikler og programmør kan det meget vel være, at man kommer til at skulle implementere en funktionalitet eller en feature, som man ikke personligt mener burde have nogen gang på jord.
Udfordringen er selvsagt at glemme sin personlige mening og fokusere på at udføre opgaven ordentligt og professionelt - alene fordi kunden eller chefen siger det.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
9 / 10
Programmører er kode-folk - ikke sprogfolk.
Det kan gøre det til en udfordring at finde navne til procedurer, funktioner, objekter, database-komponenter og de andre ting, der indgår i et projekt.
Selv i et lille program eller en lille applikation er der behov for en række navne til de forskellige komponenter. Og navnet skal helst udtrykke, hvad funktionen eller kompontenten dækker over.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
10 / 10
Programmører er nørder, hvis hoveder er proppet med specialviden, og mange finder det ifølge debat-trådene ofte svært at forklare familie og venner nøjagtigt, hvad de arbejder med.
Mange programmører regnes eksempelvis for at være computer-eksperter, som ofte bliver bedt om at fikse alle computer-relaterede problemer i familien - inklusive installering af alverdens pirat-software.
Skrevet i samarbejde med Computerworld News Service/Phil Johnson.
