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.

Good mulling for thought. It's always a bit challenging to nicely explain the tie between engineering metrics and how they impact the business. This is a nice starting point.

This can change from organization to organization. This post proposes a career ladder which will work in some contexts. What's clear is that it's all about scope and impact.

Interesting tips to keep learning on the technical side of the job as you get more managerial responsibilities.

Interesting musing on the heuristics we use when solving problems. There are good advices in there to make progress and become a better developer.

Another good set of advices. They're not all technical which is to be expected.

Nice post, and indeed it's not about Python if you read until the end. It shows that it's important to be able to make informed choices and not just pick your tech stack based on knee-jerk reactions.

Interesting musing about what it takes for engineers to grow. Clearly there are a few paradoxes in there... that gives ideas to manage your career though.

Aren't we loosing something if we focus on productivity numbers too much? A good reminder that intrinsic motivation is an important driver in people behavior. I wouldn't throw all the metrics out of the door but they'd better be a limited amount and they'd better be informative rather than objectives.

This is an interesting framing of the question. We often talk about the scope, but how thorough are we when handling it? Should we even be that thorough? Might make some of the trade offs more explicit.

Funny experiment at drawing parallels between engineering leadership and how you should behave when hiking in nature. This works surprisingly well.

Interesting musing about the "software crisis" which was declared in the late 60s. We're coping with it by piling levels of abstractions but clearly we're still not out of it. Our craft still needs to grow.