The opinions of ‘Uncle Bob’ have always been harmful both when it comes to code as well as non-code. It’s a bit shameful for us as an industry that it took so long for people to wisen up to this.
Remember that in any organisation, people make decisions — decisions are about trade-offs, and decisions can be influenced, overturned, and changed. More importantly, organisations evolve— the way decisions were made yesterday might not be the way they get made tomorrow!
An uncommonly sophisticated piece of how to think about technical debt and how to tackle it organizationally. It already starts off right by not using a debt-is-money comparison.
Not just one thing that every dev should know but a bag full of hard won non-technical multipliers that will improve all of your interactions in this podcast episode with Jesica Kerr.
I’ve always felt that programming is more similar to languages than to mathematics. The number of hard maths problems that we solve as part of this work are really limited, the number of language problems on the other hand is immense.
An overview of the philosophical and technical revolutions that are necessary to be able to develop in production. It’s a long way but I believe even the journey to get there is worth it.
One of the points in this list by Paul Osman that I recently stumbled on is that things like “staging” are indeed mostly useless however much people want to keep using them.
I usually get a lot of resistance when I suggest using monorepos but this article explains really well what cultural benefits that choice entails.
That is a fully comprehensive and excellent list of guidelines to unlearn toxic behaviour in code reviews by Sandya Sankarram.
A long treatment of how to scale work as organizations grow with some helpful guidelines: “Keep the work parallel, the groups small, and the resources local.”
I’m glad that this takedown of Clean Code by Dan Abramov got so much traction. I have no problem with clean code (lowercase), but inevitably the process of getting there and the things people do as a consequence make the entire endeavor an anti-pattern.
“Obsessing with “clean code” and removing duplication is a phase many of us go through. When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured. A set of strict lint rules, a naming schema, a file structure, a lack of duplication.”
As always, people get too attached to the parts that are the most obvious and the least important.