Jobber du med programvareutvikling i et produktteam? Dette dokumentet er til deg.
Lenge følte jeg at jeg ikke ante hvordan man burde jobbe sammen når man lager produkter. Jeg startet med en teknisk utdannelse og en teknisk jobb. Jeg lærte meg hvordan jeg kunne løse problemer alene.
Etter hvert slo virkelighetsbildet mitt sprekker.
Disse erfaringene har ført til at jeg gjør enkelte ting annerledes enn før. Jeg har andre forventninger til meg selv og til menneskene mine rundt meg.
Jeg velger nå å skrive disse erfaringene ned. Det hjelper meg selv å få oversikt, og det hjelper meg med å kommunisere med de rundt meg.
Jeg publiserer på Internett fordi jeg mener at kunnskap bør være fritt tilgjengelig på Internett. Du er hjertelig velkommen til å lese dette dokumentet og prøve ut ideene selv om vi ikke kjenner hverandre—men vær obs på at dette dokumentet handler om god praksis, og god praksis ofte må læres fra personer, ikke lærebøker.
Fra januar 2024 har jeg hatt gleden av å jobbe med Elisabeth Irgens. Uten Elisabeth, hadde jeg ikke startet på denne teksten helga 17. og 18. februar. Hvorfor?
Jeg har samlet opp meninger om hvordan programvareutvikling og produktutvikling bør gjøres. Elisabeth har ved svært mange anledninger stilt “hva mener du med X?”-spørsmål.
Så tusen takk, Elisabeth! Jeg setter pris på å kunne jobbe med deg.
https://www.goodreads.com/en/book/show/71730
Jeg misliker tittelen “ikke-voldelig kommunikasjon”. Jeg synes det er en dårlig beskrivelse for hva boka handler om. Er det ment til å implisere at de som ikke har lest boka og gjør det den sier er voldelige? For meg fremstår det som en rar holdning å ha.
Det jeg liker med boka er at den beskriver en måte å be om å få ting uten å ta valget om å gi vekk fra den du ber om noe.
Det gjør at folk lettere kan gi deg det du trenger når de kan, og kan si nei når de ikke har anledning. Det gjør også at du splitter mellom informasjonen om hva du har behov for og handlingen du ønsker. Kanskje det du ba om ikke var det du egentlig ville ha.
I boka No Rules Rules, beskriver Reed Hastings og Erin Meyer hvordan tilbakemeldinger gis og tas i Netflix.
Jeg siterer:
Giving Feedback
- Aim to assist: Feedback must be given with positive intent. Giving feedback in order to get frustration off your chest, intentionally hurting the other person, or furthering your political agenda is not tolerated. Clearly explain how a specific behavior change will help you
David Deutch om teori.
Teori er objektiv, uten verdivurderinger. Praksis er subjektiv, med verdivurderinger.
Neil Gaiman / Sandman / Dream / Morpheus Da folk sluttet å drømme
Her er tre engelske ord. Vi bruker ofte disse ordene når vi snakker om programvareutvikling, selv på norsk.
| Begrep | Norsk begrep? | Min definisjon |
|---|---|---|
| Deploy | Få ny kode ut sammen med den “ekte” koden | |
| Release | “prodsetting”? | Starte å kjøre den nye koden |
| Review | Kodegranskning | Noen andre ser over koden og kommenterer. |
Les mer (på engelsk): Review the interface
Tillit, kvalitet og intensjon i relasjonen til de som skal bruke produktet.
Hvis du starter med organisering etter navnerom, kan du innføre opt-inn-hierarkier i etterkant, akkurat som Wikipedia gjør det. Hvis du starter med organisering etter hierarki / taksonomi, blir du låst. Hva gjør du når du har kategorisert noe feil? Hva gjør du med referansene til det du har kategorisert feil?
Før tenkte jeg hierarki / taksonomi for å splitte en kodebase i filer (klasser, …). Nå tenker jeg navnerom.
| hierarki/taksonomi | Kategorisering av et domeneproblem |
| navnerom | Et sett med ord som er fine å bruke sammen |
Det beste eksempelet jeg vet om på dette er hvordan standardbiblioteket til Clojure er organisert. Det aller meste er i clojure.core. Det er ikke gjort forsøk på å kategorisere alle tingene man trenger som Clojure-progravareutvikler. Det er i stedet gjort en innsats for å bygge opp et sett med navngitte byggeklosser som fungerer godt sammen.
Et annet navnerom jeg liker godt og bærer preg av tanken “la oss lage ett kraftig navnerom” er datomic.api. Ett navnerom med det du trenger for å jobbe med data.
Navnerommet alene svarer ikke på hvor man bør starte først. (Da bør man lese en guide, ikke en API-referanse). Men dette er en kjapp start:
datomic.api/connect for å koble
til databasendatomic.api/db for å hente siste
versjon av databasendatomic.api/as-of for å hente en
tidligere versjon av databasendatomic.api/q for å gjøre en
databasespørringdatomic.api/entity for å hente ut
én entitet fra en primærnøkkel.Du kan nå trygt slutte å lese dette dokumentet. Denne seksjonen er ikke ment til å leses fra A til Å, men er ment som et sted til å samle ting som ikke passer andre steder.
Kommentarer fra andre, problemer med teksten, uferdige og utygde ting som bør inn, you name it.