Why I Still Write Code

Published: by

I grew up an engineer. You could almost say being an engineer defines me. When I worked as a manager of engineers, and I would go recruit staff, I would tell recruiters - in-house and external - that I wanted "engineers." "Ah, they would say, you want developer," or perhaps "programmers" or even "administrators." "No, I want engineers." They would ask, "what's the difference?" My response was always the same. "An developer or programmer writes code in languages s/he knows; a system administrator administers systems s/he knows. But an engineer isn't a job description, it is a mindset. It is the kind of person who figures out how things work and then figures out what to do with them. If I hire a C developer or a Java programmer, and tomorrow we switch languages, they are lost. But an engineer will always figure it out."

Unsurprisingly, most recruiters met my response with a blank stare... and a loss of my business.

Nowadays, though, I have an MBA from Duke and make my living doing operations management consulting. Sure, most of my work is in the technology space, especially cloud/online services, but I am not paid to deploy systems or develop software any more, and haven't been in quite some time. So many clients and friends are surprised when they learn that I still write code. "Aren't you a level beyond that?" is a common question. That I do so actively and contribute to numerous open-source projects, is even more surprising.

After having answered the question enough times, here are my reasons for why this management consultant still writes code:

  • Fun: Because I still really enjoy it.
  • Community: Open source is one of the defining movements of technology in the late 20th and early 21st century. I am honoured to be part of it, but only deserve to be a member when I contribute. Sheer icing on the cake is the great people that I get to meet.
  • Thinking: The methodologies used for designing and building software encourage and develop critical thinking, macro (big picture) and micro (detail) focus, and excellent work habits.
  • Clients: In my work, especially in the tech world, I need to be able to work closely with people at all levels. If I am to be successful and efficient with clients, I had better be conversant in a hands-on manner with the CEO, CFO, COO and CIO, as well as the engineers and administrators in the trenches.

That last point is a really important one. I need to know what is going on in the tech world and what it really means (not just the trends reported in techcrunch or allthingsd), first-hand, if I am to work with all levels and provide value. If my clients want someone who just can talk at a high-level but doesn't know how it really solves their problems, and get their engineering staff on-board, there are lots of "MBA-only" (a.k.a. "empty suit") consulting firms out there, large and small. My customers expect me to solve their strategic (CEO) and operational (COO/CIO) problems with solutions that make financial sense (CFO), working with their engineers to deliver the real goods.

You only get that by melding engineering roots with real management.