god morten!

God morgen!

God morgen!

God morgen

Fått satt opp varmeovn under pulten. #klarforvinteren

Ja, høsten kom tidlig i år

God morgen, godtfolk av Clojurnia!

Jeg har en artig historie om varmeovner under pulten i én del av bygget, som ødela for klimaanlegget i hele bygget 😅

Kortversjonen: Én avdeling i en fløy av én etasje i bygget synes det var kaldt, så de gikk til innkjøp av ~15 varmeovner til alle pulter. Da ble det kaldt i andre deler av etasjen, fordi klimaanlegget ble forvirret av varmen i det éne området. Da kjøpte flere personer varmeovner, så ble det kaldere i andre etasjer også, osv. Klimaanlegget ble maks forvirret, så det ble enten alt for varmt eller alt for kaldt, litt avhengig av hvem som var på jobb og hadde skrudd på varmeovnene sine. Løsningen var å fjerne alle varmeovner (til tross for lidenskapelige protester) og kalibrere klimaanlegget.

Rekursive systemeffekter og den intrikate dypøkologiske bevegelsen på kontoret viste seg. #HistorierFraEtTidligereVerneombud

haha

Hadde en lignende opplevelse på NRK. Der satt vi et slags åpent landskap som var delt i to. Dessverre var klimaanleggets hovedmotor i den ene delen og temperatursensorene i den andre. Dermed ble det badstue på den ene siden av veggen og iskaldt på den andre 😅

Det scenarioet er kanskje en god analogi som kan brukes for å illustrere sideeffekter bivirkninger.

Indeed 😄

På Telenor i gamle dager hadde de spot-klima. Hver plass hadde en liten dyse i taket med en bokstav/tall-kode. Så kunne man gå inn på en nettside, punche inn nummeret sitt og individuelt justere.

Det fungerte helt medium bra. Men det samme systemet styrte gardinene på byggene. Veldig gøy da vi skjønte systemet i de kodene og satt og kjørte gardinene opp og ned for nabobygget 😂

Ingen autentisering annet enn “vær på lokalt nett”

Vi hadde sånne "sluser" i taket på det gamle kontoret, men det var ikke "personlige sluser." Det var bare én i hvert område. Dessverre var de ofte plassert rett over pulten til en stakkar. Så når klimaanlegget satte i gang for fullt ble det istapper i skjegget på stakkar'n som satt rett under.

😂

Sluser per pult ser snedig ut, men ettersom pultene ikke har vegger rundt seg så er det helt begrensa hvor godt det kan fungere

Særlig hvis du er uenig med naboen om ønsket klima 😄

Åpent landskap ass, hat

men synergier da ✨

Jeg er fan av Joel Spolsky og hans selskap Glitch (tidligere Fog Creek Software) i NYC. De som laget Stack Overflow. Han har skrevet mye om fasiliteter og kontorer for utviklere. Det har også Timothy Lister, f.eks. i boka "Peopleware." Jeg har brukt mye av deres arbeid i kampen om bedre kontorer, dog uten gjennomslag.

Det er helt utrolig hvordan selskaper ansetter utviklere, betaler dem mye, og plasserer dem i et kontorlandskap hvor de ikke kan jobbe effektivt.

blir traumatisert bare av å tenke på at dette bildet av Facebook-kontoret finnes

Thanks, I hate it

Jeg har tidligere brukt https://youtu.be/fnbMGM718Ks?si=ikaZUVsPz0CR281K&t=30 for å forklare problemet til ledelsen i ulike bedrifter. "Se for deg at du vil ha en tatovering. Du bruker masse tid på å velge deg et motiv og finne den beste tatovøren. Du betaler denne tatovøren godt for å få et perfekt resultat. Men så insisterer du på at tatovøren må utføre jobben sin her. [Spiller av video.] Er det smart?"

“It’s a total smiley face, dude” 😂

Steve-O er ikke typen til å klage

Her er en post jeg skrev på vår interne Workplace 15.03 2023 når vi hadde anledning til å redesigne kontoret: > Generally speaking, open office plans are horrible for knowledge work and are usually about saving money on packing more people into a smaller space. Management will often say "it's better for teamwork," etc. But that is usually bullshit gaslighting to justify short-sighted and ineffective cost-saving initiatives. > > Joel Spolsky, Timothy Lister, and Tom DeMarco have written quite a bit about this. > > Check out this article for starters: https://www.joelonsoftware.com/2003/09/24/bionic-office/ > > And this follow-up article: https://www.joelonsoftware.com/2006/07/30/private-offices-redux/ > > Here's another one: https://stackoverflow.blog/2015/01/16/why-we-still-believe-in-private-offices/ > > Those articles contain quite a few references to other material. > > For a more in-depth exposition, I can recommend the book "Peopleware: Productive Projects and Teams": https://www.amazon.com/dp/B00DY5A8X2/ > > The relevant chapter is "Chapter 9 - Saving Money on Space"

har litt medfølelse og, når jeg jobbet i NSB så sleit de med at det rett og slett var fult, så folk satt og delte kontorer, vi utviklerne havnet på et møterom i et annet bygg, osv osv

La folk jobbe hjemme

Jeg mener å ha lest at sånne landskap ikke engang er billig når man gjør et større regnestykke: produktivitet, sjukdom (mye mer smitte i åpne landskap, i tillegg til at folk blir stressa og sjuke bare av å være der)

ja, det høres jo “enkelt ut”, men det er jo også helt bananas at vi må ha 2x så mange bygg som vi trenger fordi man enten er på kontoret eller hjemme, og halve Oslo står til enhver tid tomt

Jepp! Det har jeg også lest, @christian767. Det kan være billigere hvis man kun har ansatte som ikke gjør "kunnskapsarbeid" og krever dyp konsentrasjon over lang tid, f.eks. forretningsfolk, telefonselgere, osv. De må kun konsentrere seg i kortere perioder for å flikke på et Word dokument eller en PowerPoint presentasjon, og mangler en forståelse for konsentrasjonsarbeid. Hovedproblemet er at folkene som bestemmer hvordan kontorlandskapet skal utformes ofte er toppledelsen, HR, og forretningsfolk, som har helt andre behov.

De vet ikke hva de ikke vet, og det er vanskelig å forklare det på en forståelig måte sånn at det synker inn.

Min beste erfaring fra arbeidslivet er små teamrom. Ikke for mye folk, og de som deler rommet jobber tett sammen. Da trenger man ikke ekstra møterom, får litt sosialt i løpet av dagen, men med få nok blir det også naturlig rolig for konsentrasjon.

Når vi bygde det nye kontoret, brukte jeg forslaget til HR og entreprenøren som utgangspunkt til å estimere antallet forstyrrelser i kontorlandskapet, og gjorde et ganske detaljert regnestykke på antall forstyrrelser i hverdagen, basert på gjennomsnittlig lønn vi betaler til utviklere, bortkastet tid, etc. For å vise i kroner og øre hvorfor det var et kostbart forslag.

Men det var bare https://www.youtube.com/watch?v=myWaa6xvPZ4 som vanlig, lol

Wow

Sørgelig

Kult at du gikk så hardt inn for det 😊

Ja, nettopp! Nå har vi mange fine møterom som stort sett står tomme og ubrukte mesteparten av dagen, med åpent kontorlandskap rundt. Det gir jo ikke mening rent økonomisk en gang. Hvis alle har eget kontor, eller hvis vi har mindre team-rom, så er det ikke nødvendig med møterom heller. Da kan folk bare ha møter i sine egne kontorer.

Jeg har tatt den kampen i tre selskaper, haha

Det er en viktig kamp å ta! Synd du ikke har hatt mer hell

Ja, hehe! Det er egentlig litt derfor jeg alltid har drømt om å starte et selskap av kodere for kodere og gjøre det riktig, for å tiltrekke de beste utviklerne, og lage et kult produkt sammen. Det var det Joel Spolsky gjorde, fordi han ikke kunne finne et selskap (miljø) hvor han hadde lyst til å jobbe som utvikler. Han og Jeff "Coding Horror" Atwood. De hadde ingen produktidé en gang. Idéen var bare å lage et godt miljø, tiltrekke seg de beste fagfolka, og lage noe kult og lønnsomt sammen. Resultatet var Stack Overflow, og senere Stack Exchange.

kult å høre om, tankene dine går dypere enn “det hadde vært artig å starte noe greier” 🙂

Snu den tradisjonelle pyramiden på hodet, og sette koderne i førersetet. Forretningsfolk, administrasjon, markedsføring, selgere, etc. kan være innkjøpte og kommisjonsbaserte tjenester. Disse rollene bør etter min mening jobber for utviklerne og produktet, ikke motsatt, som ofte er tilfellet. Det er de som faktisk skaper som bør styre.

Jeg føler at kunstnere, designere og utviklere har blitt "hjernevasket" av forretningsfolk til å tro at de ikke har noen verdifulle idéer, ikke evner å organisere seg og strukturere arbeidet sitt. Det mener jeg er feil. Store og tradisjonelle bedrifter har ofte 70-90% forretningsfolk og 10-30% "doere" (de som faktisk produserer "fysisk output"). Det burde være motsatt. Man trenger ikke så fryktelig mange folk med idéer og meninger om hva som skal gjøres, men man trenger ganske mange folk for å eksekvere. Alle i bedriften bør i det minste være i stand til å tenke på en kreativ og/eller teknisk måte.

Jeg hadde eget kontor de første 2.5 årene jeg jobbet, synes det var kjempedeilig. Savner det.

Spillindustrien var mye bedre der. Stort sett alle kunne produsere et eller annet, selv "managers" var erfarne spesialister eller MacGyver-aktige generalister. Det var nesten ingen som ikke kunne produsere "fysisk output" av et eller annet slag, om det så var 3D modeller, teksturer, animasjoner, kombinerte assets til monstre og verdener, forfattet tekst, gjorde oversettelser, kode, scripts,

Fiken er et selskap som startet på samme prinsipp, altså å lage en bra arbeidsplass for utviklere

Det av problemene er at kontorleiekostnader er veldig konkrete. Utgifter som følge av åpent landskap er ikke det.

Det er sikkert en sunk-cost fallacy her også. Jeg får jo samme lønna uansett hvor produktiv jeg er.

Ja, helt klart

Og, jeg tror at med en gang et selskap når en viss størrelse, og jeg tror den størrelsen er veldig liten, så er det så mye waste i maskineriet at individuell innsats knapt er målbart.

og når McKinsey og andre forsøker å lage måter å objektivt måle utviklers produktivitet og fokus på, får de bare pepper av utviklere 😇

@leif.eric.fredheim lissom, hvis du tok en 100x utvikler og ansatte hen i Elkjøp, ville vi se resultatet av det på bunnlinja? Neppe.

@christian767 jeg så den!

@slipset den kom på feil sted!

hadde vært morsomt å ha en slags måte å måle “produktivitet til utvikler-teams” over tid, i stor skala, og sett om det var noen trender. Tipper at vi ville sett at det er sykt mye lettere å lage Elkjøp nå enn det ville vært for 20 år siden

npm install ecommerce-website

litt som at gjennomsnitts IQ øker over tid, uten at vi har noe håndfast svar på hvorfor

veldig vanskelig å måle sånt. Ikke åpenbart hva man skal måle, hva suksess er. Ofte er en del av forbedringen i produktivitet over tid at man finner bedre mål. Tror det er tilsvarende vanskelig å måle kvaliteten på kunst som funksjon av byen kunsterene har vokst opp i, eller kvaliteten av musikk som funksjon av hvilket tiår musikken er laget i. Nytteverdi er kontekstavhengig.

Men jeg håper jo og tror jo utvilsomt at vi er bedre på programvareutvikling nå enn vi var i 2003!

Tror ikke svaret på det er et udelt "ja". Er nok mye både og

godt poeng @teodorlu og. “Lage Elkjøp” er jo ikke en gang det samme i 2003 som i 2023

juni 2003 😄 Er en handlekurv der og greier da

Tror å se på utviklere i isolasjon blir feil. En pm sa fint til meg en gang at hvis du spør en utvikler om a lage en rakett, så lager hen en rakett som går til mars, når man egentlig bare trengte å gå til månen. Ja, man kan lage masse effektivt i isolasjon, men med tanke på organisasjonen man lager denne koden for så er man bare like effektiv som de andre funksjonene i organisasjonen. Hvis det hadde vært klart fra dag en når elkjøp startet hva det var de ønsket, så hadde det i større sannsynlighet vært mye mer effektivt.

En ting som er fort gjort å glemme er at Elkjøp har ca. 500 fysiske butikker i 7 forskjellige land, med ca. ~15K ansatte, i tillegg til 4 nettbutikker 🙂

Og er eid av et gigantisk Britisk selskap.

Funnene i den devops-boka er kanskje det beste vi har. Der har de gjort masse kvantitative undersøkelser og korrelert bunnlinja med kultur og forskjellig praksis. Da får du en puls på hele organisasjonen, og modenhetsnivået har en tydelig korrelasjon med inntjening.

Det er utgitt en bok om Elkjøp's historie som faktisk er ganske interessant!

Jeg skulle ønske vi kunne resette kapitalismen. Jeg syns det er så nitrist at absolutt alt er eid av ett eller annet ansiktsløst gigantselskap.

Denne!

Store organisasjoner som f.eks. Elkjøp må pivotere, justere og endre seg hele tiden, for ikke å dø. Der er faktisk Elkjøp ganske gode i sin industri. Det er en relativt fremoverlent og "agil" (æsj, jeg kan ikke fordra det ordet, men kom ikke på noe bedre) organisasjon på mange måter.

Her har du et bedre: smidig

Jeg har autoignore på folk som bruker "agil" som et norsk ord. Siste advarsel! 😅

Sant det! "Smidig" hadde jeg glemt.

hva med å transliterere (?) “reproduce bug” til “reprodusere feil”? Blir fort nswf om man ikke passer seg

Reproduksjonsfeil? lol

har aldri fått klarhet i om “refactor” er “refakturering” (sende faktura på nytt?) eller “refaktorisering” (kjøre en faktorisering en gang til?)

Bruker “reprodusere feil” rett som det er, har aldri falt meg inn at det skulle være nsfw. Måtte legge hodet i bløt for å skjønne hvordan.

Det siste

“gjenskape” blir vel hakket mere korrekt, reproduksjon er jo relevant for domene her på Animalia da skal sies 😄

hehe, sant

Jeg har alltid sagt “refaktorere”, for jeg syns det høres bedre ut. Men når jeg leser spørsmålet ditt nå @augustl er det klokkeklart at det er “refaktorisere” som er riktig norsk. Shit, den må jeg øve inn.

man blir litt :face_with_monocle: (på en bra måte) av “refaktorisering”, synes jeg

Hjertesukk fra foredragsforberedelser: Når du er dårlig på å kommunisere visuelt tar det lang tid å lage dårlige slides 😖 😂

transliterering er vel i seg selv transliterering. Woha ✨

refactoring -> omkalfatring

Til litt lenger oppi her og Kent Becks kommentarer. Jeg tror det er en vesentlig forskjell i å måle folk ut i fra et ønske om å gjøre ting bedre for dem og ut i fra at man ikke stoler på dem.

Man kan jo se for seg at hmm, vi har så mange flinke utviklere, likevel blir ingenting levert? Hvorfor er det sånn, hvordan kan vi gjøre det enklere for utviklerne å levere mer? Hva slags støy og flaskehalser kan vi fjerne?

Eller så kan man se for seg: Disse utviklerne altså. De står bare å henger rundt fusbalbordet og bare driver dank. Vi må jammen få på plass no’ målinger sånn at vi kan sette større krav til dem! (eller noe)

Det er vel fortvekk et sånt mindset som fører til at McKinsey setter seg ned for å lage rapport?

Mulig det er fordommene mine som snakker

Jeg tror i allefall at det lett er slik at selvom man ønsker å hjelpe så blir det oppfattet som at man skal piske.

Gjentar min beundring av The DevOps Handbook, som ser hele software-organisasjoner under ett og måler deres ytelse i markedet. Gode, konkrete mål, men vanskeligere å sette fingeren på akkurat hva som er utløsende faktor. Samtidig har de nok volum til å trekke noen konklusjoner.

Er det noen her som har synspunkter rundt hva som kjennetegner kode av høy kvalitet? Her er mitt innspill (kopiert fra https://www.linkedin.com/feed/update/urn:li:activity:7101918867161051136?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7101918867161051136%2C7101922684648742912%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A7101918867161051136%2C7102259205608243200%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287101922684648742912%2Curn%3Ali%3Aactivity%3A7101918867161051136%29&dashReplyUrn=urn%3Ali%3Afsd_comment%3A%287102259205608243200%2Curn%3Ali%3Aactivity%3A7101918867161051136%29): > To paraphrase what https://www.linkedin.com/in/dwhubbard/ said in his book ("https://www.amazon.com/dp/1118539273/"): "If it can be clearly defined, it can be measured." So, what is "code quality?" How can we differentiate between "bad code" and "good code?" What are the defining characteristics? When we have a concrete and unambiguous definition, we can begin discussing ways to measure it. How would you define it? > > Here is my attempt: "High-quality code" solves a problem or creates value with acceptable performance characteristics while being easy for other developers to understand and change. Furthermore, "high-quality code" is not "complect" to borrow a term from https://www.linkedin.com/in/richhickey/'s talk, "https://www.infoq.com/presentations/Simple-Made-Easy/." > > I'm not convinced LOC is a good way to measure that.

> hva som kjennetegner kode av høy kvalitet Jeg mener at kvaliteten på kode må vurderes opp mot hvor godt problemene koden skal løse blir løst. Mer subjektivt, og nærmere det Rich snakker om med enkel/sammenvevd kode: Når vi skriver kode i en kodebaser, innfører vi frihetsgrader. Steder der vi kan endre på ting. Jeg tror vi trenger nok steder vi kan endre på ting (til at vi klarer å løse de problemene vi skal løse), men ikke flere. Med flere spaker og brytere enn vi trenger, går effekten av å dra i spakene og å trykke på bryterne i konflikt med hverandre.

Jeg vil våge å påstå at dersom man gjør en god jobb med å løskoble aspekter som ikke egentlig har noe med hverandre å gjøre, får man flere spaker å dra i samtidig som det blir mindre kode og ting blir lettere å forholde seg til. Det høres fantastisk ut, men følger relativt naturlig fra at ting som er godt nok løskoblet kan kombineres på fantastifullt vis uten at de må vite om hverandre - man får mindre kode for å koble konkrete ting sammen.

godt poeng. føler at du treffer på noe av verdien for å dele koden i lag. “riktig grad av fleksibilitet i ett lag gjør det lettere å skrive koden i laget over”. Det kommer ikke helt fram av min “minimalt antall spaker er best”.

Interessant at alle svar foreløpig snakker om kodekvalitet ved å snakke om løs kobling

For å parafrasere en (dritt)bok jeg nettopp leste: “We’re going to look for porn”

Hva sierru, sierru?

“I can’t define porn, but I’ll tell you what it is when I find it”

Selvom quote’n over er mer detaljert enn “god kode” er det fortsatt synsing. “being easy for other devs to understand” hvordan måler man det?

Nei, det ekke målbart

Men i hvilken grad ting er sammenkoblet er forholdsvis målbart

Jeg sier forholdsvis, for det krever en viss innsikt å komme til at noe egentlig har flere bestanddeler. “Å, denne koden som har fremstått som en klart definert enhet i 3 år er egentlig to separate ting”

Det går an å måle afferens og efferens - hvor mange andre ting som avhenger av denne tingen, og hvor mange andre ting denne tingen avhenger av. Ting med høy afferens bør ha en lav endringstakt, og ha høy(ere) grad av testdekning.

virker nesten som at hvor “god” en abstraksjon er, ikke er en egenskap av abstraksjonen, og at man må se på koden som resulterer av abstraksjonen for å si noe om abstraksjonens kvalitet?

Jeg tror også en sånn graf som viser kode-churn over tid ala den som gikk rundene på nett (Clojure vs Scala) sier noe interessant

Ja, den illustrerte veldig effektivt det jeg har hørt fra Scala-folk: titt og ofte må de gjøre endringer i applikasjonskode fordi verden under dem endrer seg. Det skjer aldri (nesten aldri?) i Clojure.

clojure.core har høy afferens (alt avhenger av den), og skal derfor ha lav endringstakt.

Riktig. Det har den også, så det holder.

Og det er mer eller mindre utelukkende additivt

Din egen webkontroller har forhåpentligvis lav afferens, og kan derfor endres ofte og med lav risiko.

Driver du med fornorskning @msolli? 😄

Tja, det er faguttrykk som fra medisin som har kommet inn i fagfeltet vårt: https://sml.snl.no/afferens

Kult, takk!

Men har bare lest engelsk litteratur om emnet, og det er litt vanskelig ord, det skal innrømmes. Men det er presist! 🙂

Ja, jeg likte det godt!

afferens - mange innkommende koblinger efferens - mange utgående koblinger Det hjelper ikke at ordene, som betyr det motsatte, er så like heller!

Bare idéen om å føre metrikker over innkommende og utgående koblinger var jo et aldri så lite gullkorn

Dette er vel litt av de greiene som codescene jobber med?

Kjenner jeg ikke til?

https://codescene.com

Adam Thornhil - your code as a crime scene.

https://www.youtube.com/watch?v=hWhBmJJZoNM&list=PLZdCLR02grLoBx0Y5ZrpdmLxc160PIwzQ&index=8

Det var her jeg hørte om han første gangen. Han har endel andre interessante talks også.