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.
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.