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

I used to do that, fell into the "taking notes on the computer". And clearly it's not the same, I'm thinking going back to paper notebooks soon.

Interesting insight. Gives a lot to ponder indeed. Focusing on technical debt alone probably won't improve a project much. It's thus important to take a broader view for long lasting improvements.

Nice advice, there's a lot of variation on the role. And yet, some things seem to always be there.

This is a good overview of what the Staff Engineer can be. There's of course a lot of variation depending on time, priorities and the culture of the organisation.

This is good advice. To improve your organisation, focus only on the biggest constraint. Otherwise you'll quickly be spread thin.

Some areas of our industry are more prone to the "fashion of the day" madness than others. Still there's indeed some potential decay in what we learn, what matters is finding and focusing on what will last.

An old one and a bit all over the place. Still, plenty of interesting advice and insights.

Interesting thinking, indeed expectations are changing quite a bit for engineering managers over time. Thus the proposed list of core and growth skills is interesting. It is likely a good framing for the job, then the art is finding the right balance for your organisation.

I'm not really a fan of the leaderboard part of their approach. That said, if the maturity of the organisation allows it, having such bug squashing sessions is a good idea.

Definitely this. It's a good reminder of the boy scout rule. It's fine to clean up as you go and when you find the opportunity.

I like the approach. Indeed what matters is to have visibility, don't weaponize measurement otherwise the trust will falter.

I'm not fully aligned with all of this article. That said, it's an interesting way to frame the topic of how we're having to make tradeoffs all the time.

Nice list of templates to use for better handling of engineering management in your organisation. Pick, choose and adapt what makes sense to the context.

I like this article. Indeed, focus on building organisations and teams where it's easy to do the right thing bit hard to fail. This is much better than obsessing over mythical 10x engineers.

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.

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.

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

Definitely this. The difference between a well performing team and one delivering subpar software is the basics of our trade. Minding your data models, your architectures and the engineering practices will get you a long way.

Interesting idea on how to schedule large refactorings and make sure they happen over time.

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.