Why Great Programmers Pull Back the Curtain While Programming

Some 80 years later, the Wizard of Oz remains one of the most iconic films in history. In one particularly enlightening scene, the intrepid band of adventurers confront the seemingly all-powerful Wizard of Oz, who proceeds to unleash a bombastic tirade on Dorothy and friends. Only, the dog Toto ends up pulling back the curtain, literally, to reveal that the Wizard of Oz is nothing but an ordinary man in a machine.

The Wizard of Oz was a charlatan. You’d be surprised, too, how many programmers don’t understand what’s going on behind the curtain either. Some years ago, I was talking with the CTO of a company, and he asked me to explain what happens when you type a URL into your browser and hit enter.

Do you actually know what happens? Think about it for a moment.

I had a solid grasp and drew out a small diagram with the domain registrar, some DNS and HTTP servers, the load balancer, databases, and a few other necessary details. Here the CTO was, at the top of his field, and he was impressed by my general knowledge of the process.

Why? Because he knew many web developers and other supposed experts lacked even a basic understanding of the process. Most would understand the bit about HTTP servers and a few other concepts, but only because it directly impacted them. The rest? Out of sight, out of mind.

Over the years, I’ve frequently asked my employees, coworkers, and other stakeholders to pull back the curtain and explain how a process or piece of software operates. Sometimes, I’m surprised and the programmer or other expert really knows his or her stuff. Occasionally, I find myself learning new things. Yet often, my questions are met by blank stares and half-baked answers.

Who cares? They could get by without these tidbits of knowledge, so what did it matter?

I certainly don’t know everything. Yet as often as possible, I try to discover the ghost in the machine, so to speak, and how everything functions. Some years ago, I was working on a complex technical problem, trying to integrate one piece of software I hadn’t used before with another piece I had never even seen before.

At first, I figured it’d be somewhat easy. Ha! It took three solid days of work. Along the way, I ended up going through four emotional phases.

First, I was enthusiastic, jumping into the work. There was some documentation, which I skimmed through, but honestly, I didn’t bother reading most of it because it didn’t make any sense. But no big deal right? I’d simply get the software and it’d all click into place.

Ha again! As I moved into the next phase, guessing, I was all but certain it’d take a few minutes, maybe a couple of hours tops, to get everything working. Drawing assumptions about the code and logic, I started throwing new lines of code at the wall, hoping something would stick.

Turns out, my assumptions were wrong and the lack of understandable documentation had morphed from minor nuisance into major frustration. Indeed, frustration was destined to be the next phase of my emotional journey. Hitting Google, Stack Overflow, and various other sites, I looked for answers, or at least some clarity.

Then frustration gave way to depression. I felt like a chimp trying to drive a race car. Simply getting things into gear and rolling was proving all but impossible. It was my fault for not being smart enough. And it was the other developers’ faults for not providing clear documentation.

Probably every programmer has gone through the above cycle at some point. What distinguishes the great programmers from the mediocre ones is how they react. A bad programmer throws in the towel. A mediocre programmer chugs alone, sinking further into depression, but eventually gets the software working, even if he or she doesn’t fully understand how.

A great programmer? He pulls back the curtain. Instead of merely getting the software to work, he reads up the documentation and searches the Internet for answers. Eventually, he understands how the software works, the basic logic of the other programmers, and how to get all the right gears turning. He doesn’t simply patch together a solution that merely works, but instead codes to perfection.

The hate dissipates, replaced by understanding and knowledge. And when the project is finished, it’s not just another piece of software, it’s a milestone, an achievement that allowed the programmer to further his skills. The lessons learned today will pay off for years to come.

Being a mediocre programmer is somewhat easy. You don’t have to be a rocket scientist or brain surgeon to slap together a bit of code and make functioning software. Becoming an excellent programmer, however, is far more difficult. It takes effort and the willingness to not merely make software that "just works," but to truly understand what you’re doing, the logic of the code, and the best ways to produce results.

As for myself? Some days I’m a mediocre programmer. I admit it. But I’ve continued to advance my skills by slowing down and taking the time to truly understand the software I am working with. Sure, it takes effort, but it also fends off work-related depression and allows me to become better.

And that’s why great programmers pull back the curtain, looking not just for quick answers, but deeper understanding.
 

Yegor Bugayenko is founder and CEO of software engineering and management platform Zerocracy.