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.

Beautiful text. She talks with fondness about her grandfather, but there's indeed lessons about craftsmanship here. It's not only about machines, it can't extend into a humanist world view.

Definitely this. One is more painful than the other though. It's a question of paying small price over tine vs paying a big cost later.

Definitely a good advice. We're just better at understanding positive boolean expressions.

There will always be some design and some testing. The intensity of both activities needs to be properly managed over time though.

It's one of the two hardest problems of programming after all. Needs to be thought through.

Since we often still see in the wild code with deep nesting due to edge cases handling, it looks like this advice is still very relevant.

A bit of a rambling, there's something interesting in it though. Splitting small functions early will do more harm than good if they're not reused. Don't assume they automatically make things easier to read.

I always felt uneasy around this "law" as well. It's a good deconstruction of it and proposes proper alternatives. It's all about dependencies really.

Interesting way to look at our profession... I wonder if this is the core reason of why we have a hard time to turn into a proper engineering discipline, is it even possible at all then?

We went from quality to quantity it seems. We also have whole swats of developers who are just consuming content without critical thinking and it's a problem. The conclusion says it all: "Don’t consume. Create. Ask questions. Stay curious."

Interesting take... Is it really practical? Until which size is it viable? What are we loosing by aggregating? Also makes me wonder about alert fatigue... It clearly raises extra questions.

Nice short post listing the main positions (and linking to corresponding articles) on the debate around technical debt. Worth mulling over all those.

We might start in a software career attracted by the "perfection of the machines" (already debatable) but indeed to make anything meaningful we need to interact with other people. I often say it but I'll say it again: it is a team sport.