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.
Understandability is indeed a very important goal. There are easy ways to improve it in a system.
Nice suggestion for talking about your work in various type of situations. Definitely worth trying to frame it like this.
Nice writeup about the benefits of homogeneity in an engineering organization. It also shows how it is a balancing act though, since you need experiments to happen in a controlled way for evolution to still happen.
Interesting list. Definitely good things to try to learn there.
It sometimes feel a bit like caricature... but there's some truth grounded into this article. The faster new software engineers internalize the proposed "truths", the better for their own mental health.