Glenn Gillen

Every so often I have a conversation that gives me pause to reflect on how fortunate I've been to work with the people I did at Heroku, on the problems we faced, and the opportunities it exposed me to. Yesterday was another of those days. Where a skill that was constantly coached, refined, and exercised to a point that it feels second nature to me now gets deployed without a thought.

I'm sure anybody who's had the pleasure of working with Mark McGranaghan will be familiar with the title of this post, "First, state the problem". It's such a simple idea. Before you rush into trying to solve something, actually define what it is you're trying to solve. Out loud. In writing. Make it explicit. It seems so obvious it can easily be misconstrued as a frivolous suggestion.

The reality is that when it matters most, when the pressure is high, and we feel an extra sense of urgency to find a resolution that's when we're most likely to ignore the obvious advice. Compound that by having a team of people trying to work together in response to a problem. Now you've a recipe for either everyone heading off in separate directions solving a different version of the problem they've internalised, or blindly following the lead of someone without a clear understanding of what they're actually trying to fix.

Dumb, predictable machines

Experience in a domain over time introduces subtle little pattern-matching systems, shortcuts that can often make decision making quicker. Software developers will often talk about "code smells", a learned sense that says "Hey, usually when I see this pattern it's a sign that I could be doing this in a better way". The problem with this kind of pattern-matching is when it breaks, when the shortcut makes you rush into a decision that is ultimately wrong. It's the difference between what Daniel Kahneman refers to as System 1 and System 2. System 1 reacts instinctively, System 2 takes the time to re-assess information and think logically about it.

Mark's wisdom and the application of it at Heroku was less about doing the obvious, but instead introducing a habit that gave just enough time to question a System 1 response. To give System 2 time to challenge a possibly incorrect assumption and make sure you were making the right decision.

I see this all the time with in-the-heat-of-the-moment incident responses. Where there's a problem, it seems like something is on fire, and "this doesn't make any sense...". That last statement has become a circuit-breaker to System 1 responses. The moment it creeps into my thoughts everything stops and I go back to stating the problem without really realising I'm doing it.

One of the unique benefits of modern software development is computers are boringly predictable. They do exactly what you tell them to do, every time. If that's not the case the most likely case isn't that the computer is misbehaving it's that you don't understand some of the nuance of what it's been asked to do. Step back, state the actual problem. The problem isn't "I've told it to do X and it's doing Y". The problem is: "It's doing Y, I want it to do X. What have I done wrong?".

Breathe. Take a step back. First, state the problem.