Interesting findings about procrastination. Some effects were expected, others less so. The actions to avoid it in teams should be well known now.

Looks like a good approach to integrate LLMs in your development workflow. In case that would become something trustable.

Interesting ways to look at processes and their outcomes. Depending on the mental model you won't ask the same questions when investigating incidents.

You can't be in the backseat when using those tools. Otherwise you might feel productive by cranking out code but it can't do the essential tasks for you (most notably actual problem solving or architecture thinking). The quality would clearly suffer.

Or why it's important to deeply understand what you do and what you use. Cranking features and throwing code to the wall until it sticks will never lead to good engineering. Even if it's abstractions all the way, it's for convenience but don't treat them as black boxes.
Interestingly this article draws a parallel with organizations too. Isn't having very siloed teams the same as treating abstractions as black boxes?
Quite some food for thought here.

There are clearly more to know. But this is a good list already.

This opinion piece is getting old... and yet, it doesn't feel like our professions made much progress on those questions.

This is indeed almost always leadership you need in your organization. An engineer who want to manage, maybe be careful about their skills and motives.

A bit of a self-serving post towards the end. Still I like it because it clearly mention that it's not about dropping all documentation in favor of the code (quite the contrary in fact, documentation is very much needed). It really is about treating code like documentation, putting the same care into it in terms of readability and understandability. If you wonder what code reviews are for... it's also for this readability concern.

This is a good list of skills and behaviour to develop if you want to get better at our craft.

For sure the aforementioned manager need to fix his communication style. That being said the core advice was indeed good.

Nice post. Explains well why the answer is not a number to target. You want to impact the distribution.

I like this. Sometimes a simple word can make all the difference in the way we behave. Code stewardship is indeed a better word.

It like this parallel. The bigger the endeavour, the more complexity... And that will require thinking in very different ways for each order of magnitude.

There's clearly a tension on that topic and the expectations from engineering managers tend to change over time. I like the proposed answer here and the distinction made between writing code and being in the code.

Not a huge fan of the writing style and the pokemon metaphor. That said, seeing your growth as an engineer based on circles is spot on.

Good advice to work with large legacy code bases. You better know it very well before you make large changes to it.

Struggling with making your first technical roadmap? Driving it from measurable problems is a good first step.

There is some good advice in this piece. If you want to maintain something for a long time, some aspects need to be thought out from the beginning.

Nice example of organization to foster more autonomy and ownership in engineering teams. Clearly needs to be adapted to the project context but gives quite a few ideas. It strikes a nice balance at keeping both an individual and a team view of the responsibilities.