Software development is based on computer science, but it is an art form. Any artist has to learn how to manage anxiety while under pressure to deliver.
In software development, just as the rest of life, people often don’t ask for what they want, they ask for what they think they can get. Someone makes a bizarre feature request. You ask some probing questions and find out the real need is totally different. Why didn’t they ask for that? They thought it would be too much, so they invented an alternative which they imagine (often incorrectly) would be easier.
Another form of mis-directed request: Anxiety Transfer.
Someone’s nervous about the project. Big promises have been made. No one checked with development whether the promises were feasible. But a delivery date has already been specified in a contract.
Understandably, what this person wants is to not be nervous anymore. But they’re seeking to relieve their anxiety in the wrong way.
The best way to relieve anxiety is some form of physical exercise. I ride a bicycle and do yoga for exactly these reasons. A long walk can do the trick too.
Instead, this person wants _me_ to be nervous. It may be unconscious, or they may be aware of it and feel bad about it. But the projection can be intense.
Much like the bizarre feature request, they want developers to feel this way for the wrong reason. They think that a freaked-out developer will frantically work nights and weekends to get the features done by the deadline. And they’re often right about the overtime schedule, to the point there’s an industry term for it: a ‘death march’.
What they’re wrong about is the result the death march produces. Freaked-out developers working in the middle of the night produce bad code. You might technically get all the features you wanted, but they’re like chunks embedded in a pile of crap. Along with the features come bugs, a compromised user experience, and all the other reasons why most software sucks.
In order to write good code, a developer has to be in a calm state of mind. I have had to work on the ability to resist anxiety transfer. Easier said than done, right? Here’s some methods that have worked for me.
Instead of focusing on what “should” get done, focus on what _can_ get done. Figure out the most important element, get that done first. Put some fallback or checkpoint in place so that item won’t slip back to un-done. Only then move onto to next most important item.
Communicate with consistent candor. Anxiety gets transferred when you implicitly buy into the transferer’s assumption, that it is not only desirable but possible to satisfy an unrealistic request. To stay calm in an unrealistic situation, you need to openly describe what’s unrealistic about it.
And last, be prepared to call a bluff: some folks will hint (or say straight out) that you should be able to do what they want if you were just a better developer. And of course the related subtext that if you don’t, maybe you’ll be fired. But unless they can find someone better than you to do the work, right now, then you are actually the best developer in the world that they have available. The hypothetical better developer will contribute very little if you get canned.
Assert your right to stay calm, for both your own well-being and the quality of the work.
