Didn't know this kind of architectural pattern had a name. Interesting. I wouldn't recommend it in any context though, but one more metaphor to reason with.

Very nice piece. This is indeed mostly about building organizational knowledge. If someone leaves a project that person better not be alone to ensure some continuity... lost knowledge is very hard to piece back together.

Nice short post about cohesion in software design. Also gives clue about what proxy we can use to gauge this cohesion.

As Moore's law fades away this question is indeed essential. Looks like there will be more pressure on software and algorithms than before (at last one might say, we had decades of waste there). Streamlining hardware architectures will have a role too, we might see simpler cores in greater numbers.

It might not look like a lot from the outside, but "just implementation details" in fact hides quite some work and complexity.

Very nice piece about the various types of complexities we encounter in our trade, and what we can or should do about it.

This is a funny pretense, and yet... If any of this remind you of a real context, this would be paper cuts. Have enough of those and indeed the organization might grind to a halt.

This is indeed a good way to classify events probability in requirements. It definitely impacts how you handle them in software.

Indeed this is not for any environment and projects. So take it with a grain of salt. That said, I think this piece has a core truth to it which is more general. Software architectures shouldn't be considered as something fixed as soon as they are planned, they need to be validated through use and to be prepared to evolve over time as needed.

Good food for thought. Explains quite well the factors which impact software development.

Interesting take even though I'm not sure I buy it completely. This is an interesting pledge for aiming at power efficiency and squeezing performance out of software.

Indeed, fads come and go mainly to keep the circus running. You can't have growth with something nicely working and stable, change needs to be brought up to justify selling more.

Interesting idea, why not use similar workflows than to develop software? For sure this would bring more transparency and automation, should help focusing on higher value tasks.

Yes, definitely this. Plenty of reasons why it's important.

This rings true to me. What a messy path to get better at our craft!

Nice overview of what it takes to increase your uptime. It can get expensive quickly. This is also a good reminder that it's not only about software, it's a lot about people and administrative constraints as well.

A simplified mental model of complexity in software projects. It's not completely accurate but is valuable in the way it is easy to reason about it and probably use it for decision making.

Overall good piece about how to make quality software. That being said the whole section about "Hire the Best Engineers You Can" should be read with caution... it clearly starts from the "10x coder" fallacy, it's not true and suddenly completely ignores the project context.

Good exploration of what "engineer" and "engineering" means. Also helps to overcome what software people like us assume is done by the "real engineers" while in fact sometimes they can be as sloppy than us.