Lots of good advices of course. It goes a long way to improve the quality of the project and the ease to on-board people. This is quite some initial work though.

All good points. Can we improve? Sure. Does it means we do it bad? No. Just do it more when it makes sense.

Very interesting insights from someone who's been practicing this trade for a long time. I agree with most of it, it's inspiring.

Definitely this. The difference between a well performing team and one delivering subpar software is the basics of our trade. Minding your data models, your architectures and the engineering practices will get you a long way.

Interesting how feeling stupid can actually push you toward good engineering practices, isn't it?

To take with a pinch of salt since it has a couple of biases (most notably it focuses a lot on satisfaction) and the sample size is a bit small. A few interesting insights nonetheless. In particular it hints at autonomy, transparency, technical skills and vision as being the most important factors for satisfaction and success within teams. The applied project management method? Not so important it seems if the other factors are satisfied.

Definitely this, mind the complexity you introduce in your code. Looking smart is not the goal here...

As always from Kent Beck, an excellent set of advices to improve you programming skills.

Indeed the example is a bit extreme. Still it illustrate quite well what should be found in a commit message. It needs to tell a story and motivate the reasons behind a change.

Excellent post about code reviews. I particularly like the introduction about the motivations, it's often forgotten.

Understandability is indeed a very important goal. There are easy ways to improve it in a system.

Can definitely recommend. The pre-commit project also make managing those a breeze.

Review of the newest book from Kent Beck, I'll probably check it out and read it.

Nice ode to simplifying web projects, to great effects. You can go a long way serving millions of requests if you choose your tools properly.

It's indeed important to hone your tools as well. Even though most things are not blocked due to tools, the right ones when well designed can make things easier.

This is a good set of advices for beginners. I especially like the ones about best practices, trying different things and why it makes sense to be conservative tech wise.

Interesting food for thought. The later point about the tension between business and users lately is also a good one and should be kept in mind. That's an ethical concern you find most in companies publishing Free Software though. It's not the full packaged solution but a good starting point.

This is a good set of properties to strive for. Since the SOLID principles start to show their age this might be a worthwhile alternative.

Good summary that TDD is many things... it helps for quite a few dimensions of writing code, still, it's not a magic bullet in term of design. Your software design abilities are crucial to practice it well.

The right nuanced way to see the DRY principle. As usual don't overdo it that's where problems will arise.