The best people in software have an innate ability to communicate using code. They have an idea and simply code it up, thereby making it reality. In fact, the best people are, I would say, obsessed with code.
Pick somebody in software that has done great things. Bill Gates comes to mind for me, because that’s who inspired me to get started in software. He wrote code for as long as he could manage, and famously delivered code reviews even as his company grew to 1,000s of engineers. No matter who you pick, I am sure one thing rings true: they obsessed over the details. And when it comes to software, those details are in the code.
Those who cannot read and write code must spend all of their time convincing other people of their ideas, and are usually sufficiently disconnected from reality (i.e., the code) that their ideas do not work in practice. This is an awful situation to be in, particularly at a company whose primary asset is code. Worse, most people voluntarily place themselves into this category, particularly over time in their careers, because they believe that coding is “not one of their job responsibilities.” What rubbish!
I have three particular pet peeve examples to give.
The first is what I like to call the “mediocre mid-level manager syndrome.” I’ll admit that when you manage large enough teams, you have to give up on a bit of coding. I will personally never give it up entirely, even as I manage teams of 1,000s of engineers. I will always use the product my team is building, I will read the checkins to at least understand what’s going on and stay grounded, and, assuming I continue to manage groups building development platforms, I will write code using that platform. But for managers who assume responsibility for 10 or fewer engineers, there is absolutely no excuse for slacking in these areas. Such teams tend to suffer in the areas of “adult supervision”, engineering culture, and in having a strong role model for members of the team. The proof is usually in the pudding, so to speak. Such managers frequently add negative value. Unfortunately, many “Software Development Leads” at large corporations fall into this category, not necessarily completely their fault, but rather largely because it is culturally accepted and encouraged. Needless to say, it is not acceptable on my teams.
The second is something I call “code is beneath me.” The two most prominent examples are folks late in their careers and researchers. The former often goes hand in hand with the mid-level manager problem. But I’ve seen it afflict software engineers too: “I’ve been a professional developer for 10 years, so my job is now to tell others what to do rather than doing anything myself.” At this point, they might adopt the title Architect. The research issue, however, quite frankly perplexes me. Computer Science is an odd mixture of pure math and applied engineering. I get that many CS researchers are more math-oriented, and wish to basically do mathematics rather than software. I also get that much of this research bears fruit. But in my experience there is a very large contingency of researchers that do not produce “first rate mathematics,” and yet resist becoming grounded in code. The idea that you can improve the state of software, whose bloodline is code, without ever writing a line of it or becoming proficient in it, is complete insanity. And yet it’s generally accepted.
The last example, which is close to home since I made this mistake myself for a couple years early in my career, is “I manage things, I don’t build them.” Even people who have strong backgrounds in CS, and have spent part of their lives writing code, end up here. But more often than not, those who stay here don’t love code, and yet can end up “in charge” of making decisions about features, prioritization, competitive offerings, etc. It’s true that some people have great intuition and can make some good decisions without knowing how things work (though it is rare). But when it comes to software, everything really does need to be grounded by the code, else decisions are often disconnected and damaging. And anyway, if code isn’t interesting, there are plenty of other disciplines, like sales and marketing, HR, or one of the many other organizations in a large company, where the focus isn’t on actually building software. Those who love code should be developers, and be proud of it.
I have the utmost respect for people who have fallen into any of these traps, but then realizes it and gets out. Hey, I did so myself.
Even those that write code often don’t do it enough. I’ve seen so many fall into the trap of debating whether or not something would work, or how elegant it would be. Certain people are afraid of failure, or find it difficult to get motivated to “start” coding. The best people, however, realize that questions are easily answered by writing the code in prototype form. They go from 0-60 in an instant, having a vision of what they would like to build, and letting nothing get in the way. I call this “oozing code from your fingertips.” I do think some of this is a skillset thing. In software, the top 20% are easily 50X more productive than the bottom 20%. But I also think these traits can be learned, given role models who exhibit and demonstrate the behavior.
Finally, I do encourage software leaders to read as much code as they can. Reading code is a great way to learn how things work, and to stay on top of what’s actually happening in your project. And it keeps your mind fresh, and often leads to new ideas.
If it isn’t obvious, I might have a slightly atypical bias here. But it’s one of the things I am most passionate about with respect to running software teams. Code speaks. Love the code.