Podcasts

For tre år siden lagde jeg en liste over det jeg den gang mente var de 12 beste podcastene for programmerere. Det er på tide med en liten oppdatering!

Det har ikke skjedd forferdelig mye i podcast-verden, og flere av showene jeg hører på er de samme som jeg anbefalte i starten av 2009. Hanselminutes, .NET Rocks, Herding Code og Software Engineering Radio har vært med meg hele veien. Sistnevnte har også blitt betraktelig mere interessant de siste årene.

Så uten noe mer “om og men”, her er listen over podcasts jeg lytter til gjevnlig, og hva jeg synes om dem. Og jeg begynner med de middelmådige, og ender med de helt suverene:

	The Java Posse Fire utviklere som egentlig skal snakke om Java, men som ender opp med å snakke om alt mulig annet. Java Posse er helt uten struktur, og minner mer om en typisk pub-samtale mellom geeks. Kan sammenlignes med program som Nytt På Nytt eller Trygdekontoret på NRK. Selv om jeg ikke interesserer meg for Java er dette podcastet underholdende nok når jeg ikke orker å høre på noe annet.
	Pragmatic Podcasts Et podcast fra The Pragmatic Programmers. Veldig bra intervjuer, men veldig få publikasjoner – fem stykk i løpet a 2011, og ingen sålangt i år. Du finner shows om smidig og craftsmanship, Ruby, CoffeeScript, webutvikling m.m.
	Brain Science Podcast Ikke akkurat et podcast for utviklere, men det er viktig å få inpulser fra mange ulike kilder, og dette er for dem som vil få et bedre innblikk i hva vi vet om hvordan hjernen fungerer.
	Drunk And Retired Et ganske useriøst show om programmering og andre nerde-tema. Mye humor og relativt sterke meninger om industrien vår. Ganske underholdende, men ikke et podcast for dem som bare vil holde seg oppdatert.
	Software Engineering Radio Dette podcastet er litt “tørrere” enn de fleste andre, men går også dypere på ulike tema enn mange andre show. Altså ikke alltid så underholdende, men faglig veldig spennende. Tema i det siste har blant annet vært MongoDB, IBM Mainframes, domenespesifike språk, distribuert Scrum og quantum computing.
	.NET Rocks! Sansynligvis det mest kjente utviklerpodcastet, med to nye show hver uke. Jeg irriterer meg ofte over at nivået er litt for lavt for meg, men kvaliteten på showet er likevel så bra at jeg stadig hører på det. Er du ikke allerede en early adapter vil du kunne holde deg veldig oppdatert på hva som skjer i .NET-verden med .NET Rocks.
	Hanselminutes Scott Hanselman er en instererssant fyr, og veldig pedagogisk. Han intervjuer folk både i og utenfor .NET-verden, og jeg føler jeg får endel ut av det. Lengden på ca 30 minutter pr show er akkurat passe. I det siste har det blant annet handlet om F#, startups, MonoTouch, Science Fiction-bøker og om ekteskap mellom geeks og ikke-geeks.
	Herding Code Herding Code var lenge mitt favoritt-cast; en uformell diskusjon mellom fire geeks. Ikke så ustrukturert og mer “on topic” enn The Java Posse. I det siste har de blant annet snakket om ASP.NET MVC og WEB API, JavaScript-bibloteker, Code52, Contiuous Testing og Git, og intervjuet folk som Roy Osherove og Douglas Crockford.
	This Developer’s Life Et anderledes og estetisk vakkert podcast for utviklere isped mye bra musikk. Det er Scott Hanselman og Rob Conery som står bak dette, og de snakker mye om hvordan det er å være en utvikler, og hvordan de forholder seg til læring, stress, kritikk, og mye annet. De presenterer historier fra virkeligheten, og intervjuer mange spennende mennesker. Anbefales på det sterkeste!
	ThinkRelevance: The Podcast ThinkRelevance er et veldig spennende firma – tradisjonelt har de drevet med Ruby-utvikling, men er nå også sterke på Clojure. Det jobber et hav av ekstremt dyktige utviklere der, og i dette podcastet intervjues de en etter en. De snakker om hva de holder på med, hvordan de jobber, og hvilke prinsipper som ligger til grunn hos alle som jobber her. Meget inspirerende!

Jeg har laget en ny video til dere; denne gangen har jeg tatt opp mitt forsøk på å gjennomføre Bowling Kata i Clojure (bakgrunn om Bowling Game Kata på codingdojo.org og butUncleBob.com).

Jeg sier forsøk fordi jeg knoter litt underveis. Jeg valgte derimot å beholde videoen slik den var i stedet for å ta den opp igjen – å se hvordan jeg feiler, og hvordan jeg får hjelp av testene til å hente meg inn igjen, har også en viss verdi.

Så hvis du trenger litt TDD og/eller Clojure-inspirasjon, her har du en ærlig og munter code cast:

Vi utviklere er noen merkelige dyr av og til! Og det er når vi er på vårt aller mest merkelige at vi henter frem programmeringsspråk som brainfuck.

Brainfuck er ikke laget for å være praktisk; det er et fullverdig, Turing-komplett språk, men det er verken forståelig eller spesielt enkelt å bruke til noe fornuftig. Grunnen til at det i sin tid ble laget var at man ville se hvor liten man kunne få en kompilator. Oppfinneren Urban Müller klarte å lage en kompilator for brainfuck til Amiga OS som var på bare 240 bytes.

Jeg har lekt meg litt med brainfuck i det siste. Hvorfor det spør du kanskje? Tja, det er jo noe å lære seg.., en mental utfordring. Millioner av folk over hele kloden bruker jo timevis hver uke på å løse Sudoku – å løse oppgaver i et kryptisk programmeringsspråk er vel egentlig ikke så veldig mye mer spesielt?!

Jeg har til og med installert et integrert utviklingsmiljø for brainfuck – bfdev – hvor jeg kan steppe gjennom instruksjoner, inspisere program-minnet o.l.

Men jeg har tatt det litt lengre enn som så også – jeg har nemlig implementert min egen brainfuck-tolker. På github finner du nå bf-clj som du kan bruke til å kjøre brainfuck fra Clojure. Igjen har jeg gjort dette fordi det var en mental utfordring.

Så veldig krevende var det heller ikke, men litt spennende å få til i et funksjonelt språk. Det er ikke alltid lett å finne små men utfordrende øvingsoppgaver man kan bruke til å trene programmering, men brainfuck kan i alle fall være en slik. Så jeg anbefaler alle å forsøke å implementere sin egen brainfuck-tolker.

Her har jeg laget en liten video som demonstrerer bf-clj…

På NNUG-møtet i Bergen på onsdag ble jeg inspirert til å gjøre en stack-basert kalkulator-kata. Det var nok ikke det som var foreleserens intensjon, men dette var det mest spennende jeg fikk ut av foredraget.

Siden onsdagen har jeg gjort denne kataen tre ganger, i Clojure, med ganske ulike resultat hver gang. Den siste gangen filmet jeg det jeg gjorde, la på litt musikk, og her er resultatet.

Men les gjerne det som står nedenfor først, sånn at du vet hva du går til…

Stack-based Calculator Kata in Clojure from Torbjørn Marø on Vimeo.

Ren og skitten kode

Det som kanskje er litt spesielt er at jeg implementerer kalkulatoren med funksjonell programmering og “rene” funksjoner. Det vil i praksis si at koden ikke kan pushe eller poppe data på/av stacken. Funksjonene må ta inn en stack som parameter, returnere en ny stack tilbake som programmet kan bruke videre, og ellers ikke gjøre noen ting.

Denne implementasjonen illustrerer derfor seperasjonen mellom “ren” kode uten bieffekter og “skitten” kode med bieffekter, slik som jeg snakket om i blogposten hemmeligheten bak funksjonell programmering avslørt.

TDD

I videoen bruker jeg tester som støtte når jeg implementerer den rene delen av programmet. Men dette var som sagt tredje gangen jeg løste oppgaven, og jeg følte meg ganske sikker. Derfor ble testene kanskje ikke så gode, dvs. de drev ikke utviklingen på samme måte som første og andre gangen.

Strengt tatt kunne jeg ha droppet en av testene jeg brukte også, for den var veldig lik en av de andre. Men det oppdaget jeg ikke i farten…

å forstå Clojure-koden

Koden som demonstreres i videoen er egentlig ganske basic, og bør passe for dem som er relativt ferske i Clojure. Her er noen tips som kan gjøre det enklere å følge med.

Den beste datatypen å bruke for å representere en stack i Clojure er en vector. Det er en slags array som er optimalisert for å legge til elementer på enden. Man kan opprette en tom vector slik: [], eller en vector med noen numre slik: [1 2 3 4 5].

For å legge til et nytt element på stacken brukes funksjonen conj. (conj [1 2 3] 4) returnerer en ny vector: [1 2 3 4].

I denne tredje implementasjonen valgte jeg å bruke det som kalles destructuring – en form for pattern matching. Når jeg gjør dette: (let [[x y & r [1 2 3 4]]]) vil x få verdien 1, y får verdien 2, og r får resten av vectoren, altså [3 4] i dette tilfellet. Men om du følger nøye med så ser du at jeg nå plukker elementer fra starten av vectoren, og da ser det mer ut som en kø enn en stack. Trikset er at jeg reverserer stacken før jeg gjør dette, og da går det jo for det samme.

Selve utregningen, evalueringen av pluss, minus, gange og deling, benytter seg av det faktum at i Clojure er data det samme som kode, og kode er det samme som data. Jeg bygger rett og slett opp et Clojure-uttrykk, f.eks. (+ 1 2), som jeg så evaluerer og får resultatet 3.

Bloopers

Alle filmer inneholder feil, også denne. Blant annet implementerte jeg en måte å avslutte programmet på (ved at man sendte kommandoen quit), men jeg tok den aldri i bruk.

Den morsomste feilen er derimot metoden som ble hetende promp! Det skulle selvsagt ha vært prompt.

Har du lyst til å se meg kode? Jeg har laget en code cast video jeg håper du vil like, men først litt bakgrunn…

Joe Armstrongs foredrag om Message Passing Concurrency in Erlang på QCon London i fjor forandret meg! Han viste meg en måte å trylle med kode på som inntil da hadde vært helt fremmed for meg. Etter det har Erlang, og deretter Clojure, formet nye mønstre i hjernen min, om hvordan det er mulig å skape fantastiske ting med dynamisk kode.

I presentasjonen lagde Armstrong noe han kalte for en universell server – en server som kunne bli hva som helst, bare ved at man sendte den ulike kommandoer. I min video lager jeg en lignende server i Clojure. Jeg forventer ikke at min video skal gi noen den samme kvasireligiøse a-ha-opplevelsen som Joe gav meg, men kanskje den kan gi deg noen nye ideer…

Jeg hadde veldig lyst til å bruke Daft Punk’s TRON Legacy soundtrack som bakgrunnsmusikk, men jeg turde til slutt ikke å bruke musikk jeg ikke har rettighetene til. Musikken er derfor hentet fra Mevio’s Music Alley. Skru på høytalerne!

The Universal Server from Torbjørn Marø on Vimeo.

Vil gjerne høre hva du synes!

Av alle de spennende tingene som skulle skje på Norwegian Developer Conference 2009, var det en ting jeg gledet meg mere til enn noe annet. Jeg skulle nemlig få oppleve en hel dags workshop med Scott Bellware.

http://www.flickr.com/photos/digidragon/ / CC BY-NC-ND 2.0

Bellware er en utvikler og Agile coach fra Austin, Texas. Han har fått MVP-tittelen fra Microsoft fem ganger, men er mest kjent for å være en sentral person i Alt.Net miljøet, og kritiserer Microsoft ganske åpenlyst. Han er en fargerik person, og kan karrakteriseres som en aldri så liten bråkebøtte. Følger du @bellware på twitter så merker du raskt hva jeg mener.

Jeg var så heldig å få “henge litt” med Scott utenom workshopen og foredragene også, og selv om han er Stor i Kjeften har han mye interessant å komme med, og jeg synes det er helt fantastisk at Jon Arild har invitert Scott til å komme å forelese for NNUG i Bergen senere i år.

Workshop’en

Workshopen handlet i hovedsak om å skrive automatiserte tester i form av Context Specifictions. Scott’s budskap var at vi må gjemme all støyen fra testene/spesifikasjonene våre – testene er dokumentasjon, og skal være enkle å lese. Han sier at man oppnår høy produktivitet i utvikling om man har et godt design, og et godt design kommer av god TDD.

Med dette som bakteppe kom Bellware inn på mange ulike områder, og her er noen høydepunkter fra notatene mine:

TDD: De to første stegene i TDD – (1) lag en test som feiler og (2) få den til å passere på enklest mulig måte – er egentlig en test av selve testen. Ved å bevise at den først feiler og deretter passerer ved forventet “input til asserten” kan man stole på testen. Først etter at testen er grønn implementerer man funksjonaliteten slik den skal være. (Jeg har forsøkt å poengtere det samme flere ganger, men er ikke alltid like flink til å følge det selv.)

TDD: Gjør TDD i så små steg som mulig. “Jeg trodde at de små stegene Kent Beck presenterer i TDD boken sin var som de var for å illustrere prinsippene,” sa Scott. “Det tok meg to år å skjønne at det faktisk er sånn de beste utviklerne praktiserer TDD.”

TDD: Jobb bare med én test om gangen. Gjør du en endring som fører til at to tester må endres så gjør du sansynlig vis for mye på en gang.

TDD: Ikke bryt testene dine. Skal du gjøre en refakturering som krever en endring av testen er det bedre å legge tilrette for å endre testen uten å fjerne den eksisterende implementasjonen. Når alt er på plass kan du endre testen, uten at den behøvde å bli rød på noe som helst tidspunkt. Til slutt kan du fjerne den delen av implementasjonen som støttet den gamle versjonen av testen.

TDD: Husk å alltid skrive hva du ønsker skal eksistere før du implementerer det. Ikke bar når du skriver tester. “Jeg trenger en metode” oppdages ved å kalle metoden (som ikke finnes enda). Først deretter implementeres den.

DDD og IoC: Unngå dependency injection inn i metoder

DDD og IoC: Unngå dependency injection inn i Enteties

DDD: Enteties bør ikke tilby aggregert data (rapportdata) – som f.eks. TotalOfPreviousOrders

DDD: customer.Orders er no no! repository.GetOrders(customer) er bra!

Verktøy: Check in til kildekode-systemet hele tiden! Hver gang du har gjort en endring som fungerer: Get latest, run the tests (nant/rake), and commit changes.

Verktøy: Autohotkey er et interresant verktøy. Scott gav oss et autohotkey script som lar deg bytte ut space med underscore og dermed gjør den enklere å skrive metode_og_klassenavn_som_dette.

Verktøy: Sett opp shortcut for å kjøre en eller flere tester med TestDriver.net og en annen shortcut for å kjøre tester om igjen. Dermed går det raskere å kjøre samme test eller testsett flere ganger mens man jobber i koden.

Scott brukte også endel tid på å snakke om det jeg kjenner som the onion architecture. Han beskrev dette som et grunnleggende Alt.Net pattern som brukes over alt for tiden. Det virker veldig logisk og i trå med alt jeg har lest av Uncle Bob i det siste, og jeg må sette meg grundig inn i dette og finne ut hvordan det vil endre hvordan jeg designer løsningene mine.

En av testene vi skrev..

Her er et eksempel på hva vi produserte i workshopen. Denne spesifikasjonen beviser at en ordre tar høyde for avslag når man ber om prisen. Scott brukte MSpec, Machine Specification, til å skrive testene.

Spesifikasjonen er enkel å forstå, den lar seg lese nesten som vanlig engelsk. Når man har en ordre med en verdi av 100 dollar, og man gir 10% avslag, så skal prisen reduseres med 10%, hvilket vil si at totalen skal være 90 dollar.

Detaljene er gravd ned i OrderContext, som spesifikasjonen arver fra:

Jeg har tidligere blogget om hvordan jeg har gått fra å skrive tradisjonelle enhetstester til å skrive GivenWhenThen senarioer med et rammeverk som heter TinyBDD. Bellware gav meg mange flere tips om hvordan slike spesifikasjoner bør konstrueres. Det ironiske er at jeg etter dette har droppet å bruke BDD-rammeverk til fordel for å skrive mine egne DSL’er. TinyBDD, MSpec og lignende skaper mer støy enn nødvendig, og ved å skrive ren og selvdokumenterende kode føler jeg at jeg kan oppnå vel så god effekt uten dem.

Her er et eksempel på hvordan testene jeg skriver for tiden ser ut:

Dette er en testklasse for et View i et konsoll-basert spill som bruker Model-View-Presenter. Det viktigste kommer først – selve testene. Og de kan leses av hvem som helst, og lar deg fokusere på adferden – implementasjonsdetaljene er støy, så de kommer lengre nede.

Du synes kanskje dette er galskap? Jeg føler denne måten å spesifisere adferd på hjelper meg å skrive bedre kode, og de dokumenterer ganske bra hva systemet skal gjøre. Forvent mer om mine enhetstester i kommende blogposter..

Mer Bellware?

Er du interessert i å høre mer om hva Bellware har å si om TDD/BDD anbefaler jeg at du lytter til Hanselminutes #146: Test Driven Development is Design – The Last Word on TDD.

Og er du mer interessert i hans bråkete side kan du lytte til Alt.Net podcast #17: The State of Alt.Net, hvor han rakker ned på miljøet han har vært med å bygge opp. I så fall bør du også laste ned show nummer 18: Talking with Jeremy Miller about Alt.Net, som forsøker å roe ned situasjonen igjen.

Knagger: Alt.Net, BDD, Bellware, DDD, Dependency injection, NDC, NNUG, TinyBDD

Crowdsourcing har vært et hot begrep lenge, men det er først nå i det siste at vi virkelig har begynt å se mange bedrifter etablere seg basert på denne modellen.

Prinsippet er å distribuere problemløsing og produksjon; en oppgave kringkastes til stor gruppe ukjente problemløsere – amatører og frivillige, eller gjerne også profesjonelle. Enkeltpersonene i denne gruppen, the crowd, leverer hver sin løsning. Gruppen kan også brukes til å stemme frem de beste løsningene. Disse blir så levert til oppdragsgiveren, the crowdsourcer, og den/de som vant blir kompansert – enten med penger, en pris, kudos, eller annen form for belønning.

Fordelene ved crowdsourcing kan være at problemer kan løses raskt, og til en relativt lav pris pga. stor konkurranse. Man betaler kun for resultater, og som oppdragsgiver kan man utnytte talentet til mange flere personer enn man tradisjonelt sett kan ansette selv.

Det finnes som oftest tre ulike parter innenfor crowdsourcing, illustrert i tegningen over, og alle posisjonene i modellen er interessante. Som profesjonell utvikler kan jeg utnytte crowds til å levere verdi for meg på en kostnadseffektiv måte. Som et individ med kunnskaper og fritid kan jeg også bli medlem av et crowd community, og kanskje tjene litt penger på småoppdrag som distribueres til alle medlemmene. Og som en person interessert i inovasjon og nettverksbygging høres det utrolig spennende ut å fasilitere crowdsourcing, og å kunne høste en fortjeneste på å formidle oppdrag.

Den siste tiden har jeg blitt oppmerksom på flere, nystartede firmaer som tilbyr softwaretesting basert på crowdsourcing. Her er noen tjenester man ikke bør overse i disse trange tider:

Testcrowd 1: uTest
uTest gir deg et virtuelt QA team når du trenger det. Nettverket består for tiden av over 16 tusen testere. Du gjør tilgjengelig det som skal testes, f.eks. linken til en testsite, og beskriver gjerne hva som skal testes og eventuelt hvordan. Du betaler kun for bugs som blir funnet (etter at du har kontrollert dem), og du kan også lage en liste med kjente feil, slik at du ikke trenger å betale for ting du vet om på forhånd.

Testerne bygger opp en kvalitets-score, og som oppdragsgiver kan du spesifisere hvilken type testere du ønsker, hvor mange, hvor lenge de skal teste, osv. Startup Success Podcast #22 går i dybden på uTest, og diskuterer også hvordan man bygger et crowd community. Meget insteressant.

Testcrowd 2: UserTesting
Dette nettverket har spesialisert seg på usability testing. Dette er en form for testing som ofte er vanskelig å få til selv, og som normalt koster mye tid og penger om det skal gjøres skikkelig. For 29 dollar tilbyr UserTesting en video av en tester som bruker websiten din mens han forteller hva han opplever, samt en skriftelig oppsummering hvor testeren forteller hva han likte, ikke likte, osv.

Last gjerne ned Startup Success Podcast #20, som går i dybden på UserTesting.com.

Testcrowd 3: BrowserMob
Dette er en litt annen form for crowdsourcing. Kanskje er det mer riktig å kalle det cloudsourcing. BrowserMob automatiserer load-testing av websiden din ved hjelp av virtualisering, og viser deg nøyaktig hvordan siden oppfører seg i ulike browsere under høy last. Startup Success Podcast #18 intervjuer Patrick Lightbody som står bak BrowserMob.com, så lytt gjerne på det hvis du er insteressert.

Mange andre typer crowdsourcing..

Sammen med en kollega har jeg forsøkt meg litt på et crowdsourcing-konsept selv også, nemlig The Forecast Exchange, hvor man kan tappe kunnskapen til en gruppe mennesker for å spå om fremtiden. Nå i mai kjører vi andre runde med beta-testing, og tar du en titt på forsiden kan du se hvor stor tro brukerne har bl.a. på hvordan det vil gå med den norske børsen fremover, om Liverpool kommer på andreplass i premiere league, og om Norge vinner melodi grand prix.

Ting som Open Source Software, Wikipedia og StackOverflow er også varianter av crowdsourcing. Uservoice, som vi bruker på Forecast Exchange, er en crowdsource facilitator som gjør det mulig for oss å få tilbakemelding fra brukerne om hva de vil ha i produktet fremover. 99designs er et crowdsourcing community hvor du kan legge opp en konkurranse for grafiske designere, hvor folk konkurrerer om å komme opp med et design som du er villig til å betale for.

Er du interessert i flere slike crowds kan du ta en titt på denne listen fra Open Innovators over plattformer og tjenester. Crowdsourcing i ulike former er fremtiden. Det betyr mindre og mindre hvor man befinner seg i verden, og de som klarer å tappe kunnskap og talent over internett vil komme seirende ut av de komende årene. Dette er et utrolig spennende felt, og jeg gleder meg til å se mange, nye måter å utnytte dette på fremover.

For en stund tilbake hørte jeg rykter om at ProgramUtvikling as hadde begynt å podcaste, men da jeg forsøkte å gå til kilden så viste det seg å bare være planer. Men nå, noen måneder senere, kom jeg tilfeldigvis over dette igjen, og ble glad for å oppdage at de to første episodene er publisert.

Du finner podcastet på adressen http://www.programutvikling.no/podkast/. Jeg vet ikke om planen er å gjøre det hver gang, men disse første episodene er i alle fall video-podcasts. Intervjueren er Johannes Brodwall, og objektet er ingen ringere enn Robert C. Martin! Jeg håper dette kan være med på å spre ideene og oppfatningene til Bob i Norge - de er utrolig viktige for at vi skal kunne få en god og solid (pun intended) fremtid i softwarebransjen.

Mens jeg har din oppmerksomhet vil jeg også nevne at .NET Rocks! nummer 439 ble sluppet i går, og intervjuobjektet denne gangen er vår egen Jonas Follesø. Check it out!

Har du fulgt med så vet du at jeg liker å høre på hva Robert C. Martin har å fortelle. På Hanselmintes #150 (podcast) sa Onkel Bob Martin noe av det samme som jeg tenkte for 2-3 måneder siden, og som fikk meg til å starte .net ninja-initiativet mitt.

“Our industry does a disservice to people because there’s no consistent career ladder. In a lot of cases the career path is: A couple of years slinging code, a couple of years leading a team, and after that I’m a manager. And once you’re a manager you never write code again.“

“I think this is dead wrong. I think it’s the wrong approach for our industry all together. If you are really serious about your profession you’re willing to be slinging code for 30 or 40 year.”

Bob påpeker at advokater forblir advokater, og kirurger forblir kirurger. Noen av dem går over til å administrere, men de fleste fortsetter sitt håndtverk. Han har forøvrig mange ganger tidligere sammenlignet det å være programmerer med yrker som advokat og lege. Alle forholder seg til noe uoversiktelig hvor det finnes mange muligheter – alle jobber med å administrere og redusere høy komplekistet.

Jeg så tidlig for meg å gå mer over til prosjektstyring og administrering – det virket liksom helt naturlig. Og ved å ta ansvar har jeg gjennom karriæren fått tildelt mye ansvar og roller som prosjekt- og teamleder. Men det er egentlig ikke det jeg vil. Jeg tar slike ansvar når det er behov for det – når jeg ikke oppfatter at andre tar dem. Men egentlig vil jeg bare bli en super utvikler.

Og jeg er enig med Onkel Bob – nå er det på tide at bransjen verdsetter programmerere som utvikler seg i faget. Det holder ikke at man kaller seg juniorutvikler de første to årene og deretter er man senior. Det er faktisk ganske latterlig. Jeg vet ikke hvordan vi skal få det til, men kanskje en definert karriærestige er det vi trenger. En som ikke innebærer at man må slutte å programmere.

Jeff Atwood og Joel Spolsky fikk kraftige reaksjoner da de snakket negativt om TDD, SOLID-prinsippene og Robert C. “Onkel Bob” Martin. For å gjøre det godt igjen fikk Onkel Bob være gjest på Jeff og Joel’s podcast. Og her kom han med noen svært krasse uttalelser selv:

“I think one of the problems we have as an industry is that we got way too many people slinging code. And we should probably reduce the number of people slinging code to the group that cares about it.”

Jeg har stor respekt for Onkel Bob, og synes han sier mye bra. Nå er ikke dette sitatet like hyggelig for alle, men husk da min kommentar om en utviklers karakter: Alle kan bli dyktige utviklere. Det krever ikke noe annet enn interesse for å utvikle sine egne vaner. Er du en av dem Onkel Bob mener ikke burde kode? Ta deg sammen da vel – alle kan klare det!

Lytt til Stack Overflow Podcast #41 om du vil høre mer.