Very good opinion piece going back to Naur's and Brook's important papers about software production. It's a sobering take on how LLM can't bring the promised productivity gains. This is not saying it can't bring productivity gains of course but it'll never be as dramatic as what the current hype cycle pushes people to believe.
I like this article somehow. Indeed I'd like to see more guilt in the people shipping bugs in production (myself included probably). Also I'm very much aligned with the proposed approach to tame issues: thinking, types, tests, and telemetry.
A good piece showing some of the problems with how the term technical debt is widely misused. There's a problem with the metaphor itself, you rarely have the information level needed to call it debt.
Very interesting series I previously missed. It explores if software engineering is really engineering, and the differences with other engineering fields. Quite a few nice lessons to draw from it.
This is too often forgotten by developers. Our job isn't only about the technical side of things, we must also understand the domain the users are working in. It's a part of the craft.
Long but very precise piece about why you can likely ignore LLM for development purpose. Starting from older Fred Brooks work is spot on. Indeed whatever will remain of LLM based tools in the years to come, it's much smarter to focus on fundamental skills than chase the new tools. At least, I'm trying to do my share in getting myself and others better at the craft.
Kind of resonate oddly with the string of talks I gave talking about craftsmanship a decade ago. Looks like FOSS communities at large have no choice but get inspired by such old practice.
There's a lot of this. Learning different languages to get out of your habits definitely brings compound benefits.
Interesting history outlook on where Lean Software Development is coming from. The focus on flow efficiency rather than resource efficiency is definitely key.
Very good distinction between creating and making. That might explain the distinction between people who love their craft and those who want to automate it away. The latter want instant gratification and this can't stand the process of making things.
It's all written oriented toward C++ use. That said I think most of it equally applies whatever the language.
An excellent piece, I like this kind of thinking. It works in fact as several level in your life.
An old one and a bit all over the place. Still, plenty of interesting advice and insights.
I'm not really a fan of the leaderboard part of their approach. That said, if the maturity of the organisation allows it, having such bug squashing sessions is a good idea.
A good reminder that you don't want your code base clean to the point of being sterile. You have to fight off the mess yes, but some of it can stay if it provides affordances.
Apparently people need to be reminded that "Don't Repeat Yourself" is more a guideline than a rule. So "The Rule of Three" is a way to do that (although I find ironic it's called a "rule").
An explanation about where the SRP comes from and what it really means. It's very often misunderstood or overlooked.
Indeed, most complaints against "Don't Repeat Yourself" (DRY) are really arguments against a strawman. Of course you can go wrong, it's like everything else it's about balance... reducing the DRY guideline to a caricature to get rid of it won't help.
I'm not fully aligned with all of this article. That said, it's an interesting way to frame the topic of how we're having to make tradeoffs all the time.
It's been around for a long while now. This is an interesting way to complete the software craftsmanship view which didn't quite capture the "living ecosystem" side of our field.