Providing customer value is what we’re all here for. Unfortunately, it’s not the only thing we end up doing because of demands on our time.
We think we want a one size fits all solution because it will be easier and save time. But it never does.
No one reads those automated status emails. You’ve got to radiate the information
What if we were to think of the role of engineering manager as equivalent to a dungeon master? How does that lens change how we see things?
The hurrieder I go, the behinder I get.
Don’t just tell people what to do. Help them understand why they want to do it and how it’s good for them (and everyone).
Can you design for change and re-use? Should you? Isn’t doing one thing and doing it well the goal?
It’s very easy to fall into the habit of seeing like a state. It’s also not very helpful.
What can Jazz teach us about the art of software development.
There’s a lot to learn from aviation. Particularly around incident management
What are these forces, and how do they interact?
Perhaps oddly, perhaps not, the traits of an effective software engineer have nothing to do with software
You can rubber duck too much, but please, take a moment to think about the problem before you give up trying.
Balancing forces can make for apparent paradoxes
What are those policies for? Why do we have them and how long should they live?
60 years in, the Unix way still makes a lot of sense
As long ago as 1968, BDUF was a bad idea.
We aspire to uncouple with clear boundaries, but we need to work together
If you can’t change the error how can you fix it?