This feels a bit too realistic for my taste... and yet... Well this piece of satire is well crafted I'd say.

A bit of a stretched metaphor in here, but indeed being individually faster doesn't automatically make the team faster. Sometimes quite the contrary in fact.

Short and to the point reminder: our job is never only about the tech. It always encompass some people related concerns, be it inside teams, between teams, or the impact on the users.

Nice little commands to use to discover quickly the state of a code base... Or rather of its team.

Everyone makes mistakes, what matters is how you handle them.

The complexity and cost in organisations is indeed mostly about coordination. This is a difficult problem and largely unsolved in fact.

Feels a bit odd to go to such length to put it in numbers. And yet, it's clear that friendships in the workplace are a must. They should be fostered rather than stifled.

This is good advice. Going for something extremely small first is a good way to on board in a new project.

Good questions to consider to gauge how you work. Can improve the organisation if you really get to the bottom of it.

Interesting insights about pair programming.

Indeed, having generalists in teams is definitely what you want. Having only specialists will reduce the project efficiency.

The other advantage of not relying only on specialists. You actually get teams better at solving problems due to the extra context and communication channels the generalists will bring.

This is something I've definitely seen indeed. There are clearly a threshold effect in the amount of code you have to manage. Solutions working at smaller amounts don't work anymore a couple of order of magnitudes higher, and vice versa.

It's fine to surround yourself with people smarter than you. It's a good thing... except if they are competitive. Then it can become a curse and kill your motivation.

A bit too high on the "positive caricature scale" to my taste. That said there's a kernel of truth there, focusing on the developer experience will lead to improved impact.

You can also have experiments on your organisation. This is actually a good thing and probably should be done when something keeps popping up as a problem.

We can cast doubt on the "Spotify Model" (not really a model anyway...) all we want. Still, I think the whole "guild" idea in there was spot on. This article gives a feel of how it can be setup and the benefits it can bring.

Very interesting maturity model about proper communication in a remote work setup. I think it definitely makes sense and doesn't feel too difficult to evaluate.

A very long read but contains lots of insights. Goes from two very famous security related failure, to highlighting how a test first approach could have helped. It then finishes with a long section on how to foster a testing culture in an organisation.

Interesting stuff, very rich I think I'll have to get back to it. This gives good clues and ideas of metrics to look at when evaluating teams output. Some of the findings confirm hunches which is welcome. It also shows that measuring productivity keeps being a messy business, there are so many factors influencing it in some way.