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?
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.
Clickbait titles aside, how you use your signals is important. Not just for measuring code coverage.
Time is hard. When you find out about something is just as important as when it actually happened. So you need to track ALL of the details.
You need to know where to step before you can worry about how far you’ve come.
You can only keep so many things in your head at once. The trick is making sure they’re the right ones.
It’s important to distinguish the how from the what and the why.
There are an infinite number of integers. How many do you use in your thinking and planning?
Releasing with stablity is good. Waiting for release to get stability, not so much…
Eventually what was a best practice in one situation turns into an average practice for the industry.
There might not be any existing code for your new platform, but that doesn’t mean you’re free from constraints
When you say you want quality software, what are you really asking for, and how can you get it?
The trick is to know which models to use, and when to use them.
I got my attribution wrong, and you probably did too, but the point is just as valid.
You can write bad code in any language. You can write good code in any language. The choice is yours.
There are many types of risks for a software project. New projects/teams have their own in addition.
Be careful when looking at aggregate data. If can be hiding what you need to see.
You might have been wrong, and you can always make new choices, but the decision process you used yesterday doesn’t change.
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.
Some bugs are caused by the things you do, some are caused by the things you don’t do.
Just because you can shell out and call a script, that doesn’t mean you should.
There IS a difference between the two. Make sure you’re going for the one you need.
Primitive obsession sneaks in when you least expect it and makes things worse.
We aspire to uncouple with clear boundaries, but we need to work together
Even thought the 1’s never get worn down, software needs maintenance too.
There are lots of management quotes. Make sure you are using the full quote, not just part of it.