Easy to misunderstand as an elitist stance... But it's not the way I read it. Churning more code faster isn't going to help us, you need to take the time for people to grow and improve. It's not possible to achieve if you're drowning in eager beginners.
Those principles are old now, but they really captured the zeitgeist of the time.
A short list of common code smells that people need to know.
If your team is solely in "pushing tickets out" mode, there's indeed a problem. Teams needs more agency and care for the output to actually strive long term.
Since the movie became fashionable again, it might be interesting to go through this piece. The movie wasn't great, the article is a bit of a stretch... but at times it tells something about what's required to master a craft. It's a funny and short piece.
This is an important piece of advice. You need to try things for yourself and fail to really learn. I'm not talking about failing in production of course. But trying to break something locally to see how it behaves, reading the errors, etc. is part of learning. This is how you will troubleshoot things faster the next time.
The metaphors are... funny. But still I think there's good lesson in there. If you use generative AI tools for development purposes, don't loose sight of the struggle needed to learn and improve. Otherwise you won't be able to properly drive those tools after a while.
A list of opinions on our field. It's personal and biased of course, so make that you want out of it. I agree with most I'd say. A couple are rather niche though.
This is a good list of skills and behaviour to develop if you want to get better at our craft.
Or why analogies with physical work don't work...
Nice post. Explains well why the answer is not a number to target. You want to impact the distribution.
Makes sense, the "boyscout rule" has a psychology impact as well.
Very interesting discussion weighting the main differences and disagreements between a Philosophy of Software Design, and Clean Code. I read and own both books and those differences were crystal clear, it's nice to see the authors debate them. I'm a bit disappointed at the section about TDD though, I think it could have been a bit more conclusive. It gives me food for thought about my TDD teaching though and confirms some of the messages I'm trying to push to reduce confusion.
A very precious document. Shows great organization in the work of Knuth of course but the self-reflection has profound lessons pertaining to estimates, type of errors we make, etc.
This is a good point. Idiosyncrasies are not necessarily a bad thing for naming things. Natural languages are fickle friends, you might need to rely to specific metaphors in order to disambiguate.
If you're just doing the minimum to deal with a task to "mark it done" you're probably not doing enough and missing out on learning opportunities.
Interesting musing on the heuristics we use when solving problems. There are good advices in there to make progress and become a better developer.
Another excellent piece from Kent Beck, he's right that the real differentiator in our profession is about digging deep on topics, seeing them through even if that's on the side. Curiosity is a key trait.
Indeed, those are fundamental traits to make sure you learn and make progress on your journey.
I very much agree with this. The relationship between developers and their frameworks is rarely healthy. I think the author misses an important advice though: read the code of your frameworks. When stuck invest sometime stepping into the frameworks with the debugger. Developers too often treat those as a black box.