Hva er en god programmerer?

[torbjørn marø]

En god programmerer trenger ikke nødvendigvis å kunne programmere. Selv synes jeg matten bak, algoritmer og løsningsmåten er viktigere enn om man kan små snarveier og annet i et språk. Programmeringsteknikker over programmeringsspråk, på en måte.

Skjønner hva du mener tror jeg, men blir litt for drøyt å kalle seg en god programmerer (eller programmerer i det hele tatt) om en ikke kan programmere.

 

Programmering er også en god del mer enn å komme opp med algoritmer. En god programmerer er f.eks. flink til å kommunisere (både i kode og med dem han må sammarbeide med), han må kunne strukturere et større prosjekt på en god måte slik at den er fleksibel for potensielle endringer, han må kunne sette seg inn i og forstå brukernes behov i domenet han skal jobbe i. Alt dette og mye mye mer inngår i programmering for meg..

[Hieronymus]

En god programmerer trenger ikke nødvendigvis å kunne programmere. Selv synes jeg matten bak, algoritmer og løsningsmåten er viktigere enn om man kan små snarveier og annet i et språk. Programmeringsteknikker over programmeringsspråk, på en måte.

 

Nemlig!

 

Det hjelper ikke å kunne et språk, hvis man ikke kjenner til hensiktsmessige måter å løse velkjente problemstillinger på.

 

Det jeg snakker om er design patterns. Den mest kjente samlingen av design patterns er Design Patterns: Elements of Reusable Object-Oriented Software som er en bok enhver seriøs programmerer bør ha i bokhylla si.

[worseisworser]

En god programmerer trenger ikke nødvendigvis å kunne programmere. Selv synes jeg matten bak, algoritmer og løsningsmåten er viktigere enn om man kan små snarveier og annet i et språk. Programmeringsteknikker over programmeringsspråk, på en måte.

Skjønner hva du mener tror jeg, men blir litt for drøyt å kalle seg en god programmerer (eller programmerer i det hele tatt) om en ikke kan programmere.

 

Programmering er også en god del mer enn å komme opp med algoritmer. En god programmerer er f.eks. flink til å kommunisere (både i kode og med dem han må sammarbeide med), han må kunne strukturere et større prosjekt på en god måte slik at den er fleksibel for potensielle endringer, han må kunne sette seg inn i og forstå brukernes behov i domenet han skal jobbe i. Alt dette og mye mye mer inngår i programmering for meg..

 

Ja, det som siteres er vel en motsigelse. Programmering (eller CS) er vel en gren under matte, men jeg ser også forbindelser til lingvistikk o.l. -- og selvfølgelig også til dette med organisering og kommunikasjon som du nevner Torbjørn.

 

"Programs must be written for people to read, and only incidentally for machines to execute."

-- Abelson & Sussman, Structure and Interpretation of Computer Programs

 

 

..og det er derfor språk i aller høyeste grad er av betydning når en skal beskrive ikke-trivielle problemer og løsninger. Tenk også på det at matte i seg selv har en notasjon, altså det er et språk eller en familie med språk. Det er også her av betydning (for tenkningen) hvordan en velger å beskrive det en tenker eller til og med greier å tenke. Innen matte finnes det et bredt spekter språk; både horisontalt (typer/sjangre) og vertikalt (høyt/lavt; mer/mindre abstrakt) å velge i. Dette er selvfølgelig ikke tilfeldig, og det er ikke basert på det at en er ute etter å gjøre "små triks".

 

Hvis en kun ser "små triks" som forskjeller mellom språk har en kanskje kun tittet på språk som allerede ligger for nær hverandre; de overlapper med hverandre alt for mye; de er i samme familie.

 

 

edit:

Design Patterns vil forresten egentlig si å kombinere grunnelementer fra et språk på bestemte vis; i mønstre som ofte går igjen. I noen språk kan en selv definere nye elementer i språket, og en kan da navngi en slik kombinering som et nytt språkelement på lik linje med grunnelementene. Dette gjør seg spesielt gjeldende i dynamiske språk ( http://norvig.com/design-patterns/ ). Så valg av språk har også betydning m.t.p. hvordan en forholder seg til Design Patterns. Det går ikke å snu på noe som helst her eller si at noe er hevet over noe annet; det er en sirkel.

Endret 15. juli 2011 av worseisworser

[Matsemann]

Utsagnet mitt var (så klart) satt på spissen, men tror dere tok poenget mitt uten at man trenger å kverulere på ting som "små triks".

 

Hva som kjennetegner en god programmerer kommer også an på hvilket segment man ser på. Det er forskjell på å lage løsninger for en bedrift, f. eks. et system for bankens kunder, låneavtaler osv., og på det å programmere en grafikkmotor som skal yte bra. Det stiller helt forskjellige krav, og ingen er nok gode på alt.

 

Jeg har kommet over veldig mange som er racere på å programmere, kan alle mulige ting som ikke jeg kan. Men det hjelper lite om man ikke vet hvordan man skal løse et gitt, komplekst problem. F. eks. collission detection med 100 000 baller. Én tok hver ball, og sjekket om den overlappet en annen. Der en god løsning ville vært bruk av spatial hash grid eller lignende for å få ned antall beregninger.

[GeirGrusom]

Det vanskelige med programmering er ikke algoritmer. Det er å kunne utvikle kode som er enkel å vedlikeholde, og som lett kan utvides. På høyskolen fokuserte de veldig på algoritmer, som var litt synd ettersom svært få kunne programmere fra før.

Ikke at algoritmer er teit å lære seg, men det er bare ikke det jeg ihvertfall synes er vanskelig med programmering. Det er mer å strukturere korrekt. Hvis en gjør det feil i starten, kan en i verste fall ende opp med å måtte starte helt på nytt.

Kode som er enkel å vedlikeholde og utbedre er vel så viktig som at koden faktisk fungerer.

[Dead_Rabbit]

En god programmerer trenger ikke nødvendigvis å kunne programmere. Selv synes jeg matten bak, algoritmer og løsningsmåten er viktigere enn om man kan små snarveier og annet i et språk. Programmeringsteknikker over programmeringsspråk, på en måte.

 

Her er jeg ganske uenig. Jeg synes det å være en "god programmerer" og det å kunne algoritmer er to vidt forskjellige ting. Jeg har sett en del sammenhenger hvor for stort fokus på algoritmer fører til grisestygg kode (plenty C-style arrays, kode som langt i fra er exception safe, dårlig logikk i koden, etc, etc). Også konseptuelt blir det litt forskjellig mener jeg. En som er flink med algoritmer er kanskje en god probllemløser, men det er ikke sikkert at vekommende er god til å uttrykke denne ideen på en fin måte. Det samme synes jeg også gjelder matematikk. Jeg vet det er mange som mener at "programmering er matte". Dette mener jeg ofte blir feil å si. Matte er i de fleste tilfeller et verktøy for å løse problemer, og har derfor i min mening ikke så mye å gjøre med å være flink til å programmere. Igjen blir det en forskjell på å være flink til å løse problemer, og det å være flink til å uttrykke løsninger.

 

Det jeg mener kjennetegner en som er flink til å programmere er en som kan uttrykke en idé på en mest mulig elegant måte slik at koden i størst mulig grad er robust, fleksibel, pen, selvdokumenterende (i den grad det er mulig), osv. Dvs. at koden har et godt design.

[thelomen]

Å være en god programmerer er stort sett uavhengig av teknologisk plattform, men likevel må man være villig til å sette av nok tid til å lære seg et nytt språk / arbeidsmiljø skikkelig når man møter på det. Et nyttig verktøy da er Code Katas.

 

En kort og anerkjent definisjon på en god programmerer finner du her: http://manifesto.softwarecraftsmanship.org. Tanken er at man skal søke stolthet over faget sitt og prøve å bli en Master / Artisan på samme måte som i andre tradisjonelle håndverk.

 

For å lære mer om tankene bak manifestet (og om å være en god programmerer), sjekk lenkene under "Further reading".

[Matsemann]

Ikke at algoritmer er teit å lære seg, men det er bare ikke det jeg ihvertfall synes er vanskelig med programmering. Det er mer å strukturere korrekt. Hvis en gjør det feil i starten, kan en i verste fall ende opp med å måtte starte helt på nytt.

Nå nevnte jeg også løsningsmåten, ikke bare algoritmer. Så vi er i grunn enige, eller du jager en stråmann.

 

En god programmerer trenger ikke nødvendigvis å kunne programmere. Selv synes jeg matten bak, algoritmer og løsningsmåten er viktigere enn om man kan små snarveier og annet i et språk. Programmeringsteknikker over programmeringsspråk, på en måte.

Jeg synes det å være en "god programmerer" og det å kunne algoritmer er to vidt forskjellige ting.

Nå nevnte jeg flere punkter enn algoritmer, så det samme gjelder her..

[worseisworser]

Vi kan begynne på nytt siden det er helg; en god programmerer er det omvendte av en dårlig programmerer.

 

Hva er så en dårlig programmerer?

[torbjoern_81]

En god programmerer skriver enkel, lettfattelig og samtidig fungerende kode, som i tillegg er veldokumentert slik at de andre utviklerne på teamet lett kan se hva programmet gjør.

 

At det brukes hensiktsmessige algoritmer er en selvfølge. Man lar ikke en metode gå i kvadratisk tid dersom logaritmisk tid kan anvendes.