Wed Jul 25 18
"Kernel Panic"
Never before has an error message been more poignant and elegant in it's execution. At the same time it tells you both that something's wrong, and it's time to panic. As a developer, I admit to a small amount of sadistic pleasure when a user is frustrated with software. To clarify though, I'm not laughing at my poor user, rather I'm laughing at how I must've looked when I had the same issue.
Panicking is natural when millions of dollars is on the line, but it's entirely unhelpful. What evolves from panic is a shitty software delivery mindset/mechanism where you're busy covering your own ass (CYOA) and blaming everyone else. What gets delivered is a set of binaries that are unhelpful at best and dangerous at worst. It all stems from uncertainty and doubt.
This is "Chicken Little Driven Development" or CLDD for short. Basically, you arrive at work and a person with arms flailing tells you the sky is falling. To fix this, you boot your terminal and type some magic runes. After the immediate panic is settled, another person with flailing arms will tell you there's a different but equally serious problem. This eats into your feature timeline so that gets pushed back, but it'll end up getting released anyway because some other team needs it. This hatches a new batch of chicken littles to give you more work down the track.
When faced with chicken little, the most important thing you can do is to reduce the panic of the situation. It's important to remember that a user will have a lot of important work to do with your software. Empathise with the frustration and try to get to the root of the problem as quick as you can. This process of lowering the defcon level of a software problem is how a problem will get fixed.
It's never as bad as it looks. You probably just missed a loop counter
This is what I tell myself almost always. As I get more into the computer configuration side of things, I replace "loop counter" with "config entry in IIS". The user/The BA/The boss/The moneyman will always panic. They're the ones (after all) who are losing their valuable time with the software. It's your duty to help them out as the software developer at his job. You are not doing your duty if you panic. I personally find a multi-point approach is best
The other important thing I always tell myself about users is this
The user isn't stupid, they're just stuck/upset/stressed about something else. You're the only one who can fix their day.