The Middle Way of Software Development

In what Buddhists consider to be the first teaching the Buddha gave after he achieved enlightenment, he counseled his listeners to adopt a middle way, between the extremes of sensual indulgence on the one hand, and severe asceticism on the other.

Of course, I’m definitely no buddha, but this idea of charting a middle course between two extremes is something I’ve been thinking about a lot lately. This is because social media seems to me to have a lot of posts that capture two extreme positions on software development. I believe the correct course is a middle way between those two extremes. If you’re uncomfortable with the mention of Buddha at the outset, we can also cast this tale in the tradition of Goldilocks, with the goal being to find the porridge that’s neither too hot nor too cold.

The extreme positions I’m talking about are what I call the dumbification of software development on the one hand, and the engineerier-than-thou position on the other. These neologisms aside, the tendency of these two extremes is simple enough. On the one hand, there’s a tendency to portray software development as less of a hard-won skill than it is; on the other, there’s the opposite tendency to make it more of an abstruse scientific discipline than it is.

In my view, the dumbification of software is the far more prevalent tendency. As individual posts, it’s consistent with folks making friends through a form of self-deprecating humor, but taken in total, it represents a negation of the effort and skill that many of us have put into our careers. Here are some examples:

  • “I’ve been programming 20 years, and I don’t write unit tests.”

  • “I’ve been programming 20 years, and I debug code using console.log.” (I challenged this author, who responded that over the course of 20 years he’d “perfected it”. Perfected printf, really? And it only took 20 years? Carry on!)

  • “How did they code Google without Google?”

The dumbification of software sometimes serves commercial interests, too. The folks selling boot camps online often will assure you that learning software development is just easy enough that you don’t need a four-year degree, but just hard enough that you shouldn’t do it on your own. Don’t pay that other guy \(150,000. \)17,000 to me ought to cover it. Mastercard and Visa accepted.

The other extreme, which I call engineerier-than-thou, is not as common, but sometimes you’ll see it in response to someone claiming that software development is a creative act. In response, the argument will be made that there’s a difference between software engineering, which is a thing that real-men-like-me do (engineerier-than-thou is invariably first-person), and what the rest of you “mere developers” do, in your clueless and inferior way.

I think some of engineerier-than-thou comes from folks needing to justify to themselves that they’re paying off way too many student loans, while their “mere developer” colleagues snuck in through the back door.

Another trend that I think is informed by engineerier-than-thou thinking is the habit of giving algorithm-based coding tests. This is management throwing engineerier-than-thou thinking a bone. “I need you to be able to balance this binary tree, see. Otherwise, how will I know you can code a web page?”

Most of the time, however, management doesn’t want to embrace engineerier-than-thou thinking entirely. Having employees who are highly skilled would mean they could not be made to suffer the indignities of pair programming (“You guys are so bad, I need two of you idiots to do this”) or “swarming” (“You guys are so dumb, I’m going to treat you like a hive of bees”).

So what is the middle way – the just-right porridge between these two extremes of dumbification and engineerier-than-thou thinking? The middle way is the right-sized view of software development as neither too difficult to master nor too trivial.

Here’s how I see it. I’m a trained professional. To be sure, in my case, for many years I trained myself. Other people took a different route.

I perfected printf sometime in the first month or so, plus or minus some format specifier corner cases, and learned how to use a debugger in my first real job, after a few years of teaching myself to code without one. If I use console.log or the like, I would tend to call that logging rather than debugging, but that’s just me, picking nits.

I write unit tests for my code; whenever I don’t, I’m embarrassed, I don’t boast about it on LinkedIn.

I don’t have a degree in Software Engineering, though I do have a Masters’s degree in the History and Philosophy of Science. Big hairy deal either way.

Generally, I’d be OK if someone wants to call me merely a software developer and not a software engineer. Your insecurities don’t reflect on me, because I know what I’m doing. If drawing a flowchart before you write code and spouting a bunch of O-notation gives you a warm fuzzy, knock yourself out. I find I can generally pick the right data structure without too much arm-waving, but that only happened after I’d been at this a while.

I haven’t studied algorithms in forever. I’ll concede that doing so makes you a better developer, and admire the newcomers who are all over them.

Pair programming? Look, I’m happy to work with a newcomer who needs help from time to time, and I’ll be the first to ask for help if something doesn’t make sense, but 99 times out of 100, I program alone. Mom let me start going to the corner store alone some time in elementary school, and I’ve made several unaccompanied trips to other places since. We won’t be needing to go to the bathroom together, either, but I hope you won’t feel the loss too deeply.

This is a real profession, that’s sometimes difficult and serious, and it takes time to master. But that doesn’t make it rocket science. Enjoy it.