I’m a conviction engineer.
To me it’s the only way to be an effective engineer, software developer, and technical leader. You’ve simply got to truly believe in the value of what you do, and you’ve got to believe in doing it the right way.
So how does a conviction engineer act? How do you know the right thing to do? What should guide you? Some of my favourite quotations from fact and fiction might help.
“Churchill is not ashamed of his worries, but is proud of them; he considers it an example of how a responsible person should act…the issue is much too big and the cure much too cheap….”. — Herman Kahn, On Thermonuclear War (1960)
Kahn, a thinker and strategist of nuclear war, relates a story about Winston Churchill, who, as Home Secretary, was attending a dinner party in London only a few years before the outbreak of World War I. At the time Europe was on edge. A chief of police in attendance happened to remark that the entire reserve of naval cordite lay guarded only by a couple of unarmed constables, and this was how it had been for many years. Churchill was horrified that the supplies were so vulnerable to German infiltrators. There and then he called the War Office and demanded that Infantry start guarding it immediately. There was serious resistance, but Churchill insisted. Within hours the cordite was safe.
The point is that Churchill did not care what people thought of his action. It was the right thing to do, and he made sure it got done. It wasn’t about politics, and it wasn’t about ego. This story reminds me of the many times I’ve pushed for backups, backup testing, and security. It just must be done, and never be embarrassed by sincerely caring about your systems.
“In the matter of reforming things, as distinct from deforming them,
there is one plain and simple principle; a principle which will probably
be called a paradox. There exists in such a case a certain institution
or law; let us say for the sake of simplicity, a fence or gate erected
across a road. The more modern type of reformer goes gaily up to it
and says, ‘I don’t see the use of this; let us clear it away.’
To which the more intelligent type of reformer will do well to answer:
‘If you don’t see the use of it, I certainly won’t let you clear it away.
Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.'” — G.K. Chesterton, The Thing (1929)
Chesterton’s Fence is a wonderful principle. The essence of good engineering — engineering people can rely on — is being conservative. You shouldn’t change a system until understand why it operates the way it does — in fact, one of the signs of a very experienced developer is one who can approach a code base and quickly grasp what is incidental, and what is deliberate.
You must understand what went before you. You must understand the build procedure, the DevOps processes, the libraries in use. When it comes to refactoring code, and rebuilding systems, Chesterton’s Fence is key.
SPOCK: “Reliant’s prefix number is one-six-three-zero-nine.”
SAAVIK: “I don’t understand”.
KIRK: “You have to learn why things work on a starship”.
Star Trek II: The Wrath of Khan (1982)
This three-line exchange, from my favourite Star Trek film, says so much about the engineers I have admired and emulated. In The Wrath of Khan Kirk gains a critical advantage over Khan because Kirk isn’t just a superb commander of men, but he understands everything about his ship.
You must do the same when it comes to being an engineer. To excel you have to know how stuff actually works. Pretending to know doesn’t cut it.
There is no secret to getting there. You must take the time to study your discipline — and it will take time. But it makes all the difference.
Before he became the 34th President of the United States, Eisenhower wrote a lucid book on the invasion of Europe that liberated the continent from Nazi Germany. He made the above comment about General Patton, a man with whom he often disagreed, but whom he acknowledged was a superb leader of men on the battlefield. He knew that Patton was right to drive his men as hard as possible in battle, because doing so actually saved their lives.
What I always took from this is that by always pushing your team to do their best, to go the extra mile, you’re actually saving them more work in the long run. Of course, one must know when to stop — this is why management is hard — but you should never hesitate from pushing your fellow programmers to be their best, and do their best work.
“For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled.” — Richard Feynman, Personal observations on the reliability of the Shuttle (1986)
As engineers we work in the real world; there is no magic. When something won’t work, you must accept that it won’t work, and as engineers and developers we must always remember this. We must communicate this to our peers, and we must be honest with ourselves.
Bugs don’t solve themselves, system failures don’t occur without reason. They can’t be wished away.
To be a successful programmer – to build systems that operate, reliably for years — you must get the details right. Because it’s all details to a computer, and the computer is relentless. The machine does exactly as it is instructed, and of course, that’s its strength. But you can’t fool it. You have to build it right.
So to be an effective engineer, be a conviction engineer. Believe in what you do, and always believe in doing it right.