Experienced developers build crisis management skills above all else
If I had to narrow it down to just one thing, it would be crisis management ability.
The ability to detect potential crises, properly assess their probability and severity, and put countermeasures in place in advance—or at least have them ready. It’s the ability to carry out that whole sequence at a high level of quality. Inexperienced developers have zero of this ability, and it’s not something you can acquire just by pushing through the usual learning curve. Note that experience here doesn’t mean years spent developing. It means how many challenges you’ve taken on, and how many failures and successes you’ve been through.
Even within the single word “crisis,” there are ones that originate externally and ones that originate internally.
Externally-originated crises are extremely difficult to control: a delay in parts delivery that affects the schedule, a sudden spec change from a client, a move by a competitor. No amount of effort on your own part will resolve these. So what you can do as crisis management is build in margin. Margin in the schedule, margin in the budget, margin in the room left for spec changes.
Build in too much margin and you end up strangling yourself. The plan gets killed, you lose out in competition, costs never come down. But nothing is more naive and reckless than running a project with no margin at all. A delicate sense of balance is required here, and it tends to be rooted in experience.
Internally-originated crises, meanwhile, essentially mean bugs getting embedded. In principle, these should be controllable. But only ideally. No one embeds a bug on purpose, and most developers release believing “surely there’s no bug.” They release only after sufficiently examining the spec internally, conducting reviews, and running enough tests. And yet bugs still occur. I don’t know a way to bring this down to zero. No matter how carefully you prepare, some kind of mistake still slips through.
Whether or not you understand that, whether or not you’ve fallen into idealism, whether or not you’ve cultivated a habit of always looking at things with a degree of doubt—these things seem to depend on the extent of your experience.
Incidentally, I don’t trust my own design ability. I’m bound to embed bugs, I’m bound to get some part of a circuit wrong somewhere, and there are surely inconsistencies I’ve overlooked or specs I forgot to even decide on. Because I assume these things are bound to happen, I put various measures in place in advance, so that even if such a mistake occurs, I can recover with minimal loss.
Because of this, when an inexperienced designer looks at my schematics, they see redundant-looking parts and mechanisms scattered everywhere whose purpose isn’t clear. Those are the preparations. And what I trust is my overall ability to move a project forward, inclusive of all that.
The content of this post is an excerpt (original text) from the following book. If you’re interested, please pick up a copy.
The Shape of a Happy IoT Startup
The Shape of a Happy IoT Startup
Originally published in Japanese at https://clazytech.com/2022/09/1143/. Translated with LLM assistance and reviewed before publication.