The Problem Isn’t Knowing How To Code

It’s Knowing How To Think

Learn to code, you must learn to code, if you don’t learn to code, you can’t function in tech, if you can’t code, you can’t function in the world.

Hear that a lot, don’t we. Now, there are things you can get from learning to code, for whatever value of that you use. Which brings up one of my first objections to this mantra: it has no useful meaning.

If someone learns how to cobble together some Powershell, Bash, or AppleScript to get something done, and they didn’t know how to use those things before, they have learned how to code. I’m not thinking that’s going to have VCs and Facebook at their door on bended knee. It’s a remarkably vague, unactionable, trite phrase that means only what the person using it wants it to mean, and that is probably not what the person hearing it wants it to mean, so it means nothing, and it’s ultimately useless.

Secondly, at this point, it’s a magic spell. For example in this article “Should I code if I want to be a tech entrepreneur?”, Poornima Vijayashanker makes a number of arguments that, according to the first part of her post, learning to code is almost required to do:

  • Vetting talent
  • Calling BS on wasting time and (over)complicated solutions
  • Empathizing when things are going astray
  • Not making people have to explain why doing something is valuable like taking the time to test the an application, paying down tech debt, or setting up an onboarding process for additional hires.
  • Getting more respect when someone realizes she can code

Now, before you start getting too OMG over her article, read the entire thing, because she does a masterful job, after the above bullets, of explaining why no, a tech entrepreneur actually doesn’t need to know how to code, but they do need a certain level of literacy and knowledge. That if you don’t have deep technical knowledge in a needed area, there are these things called “other people” who sometimes know things you do not. She points out that it is perfectly okay, even encouraged to team up with “other people” who know more than you, so that any gaps in your knowledge are filled by their knowledge. Vice-versa is assumed, and correct.

Seriously, Poornima makes some really great points in the post, and does a nice job of playing with the OMG CODING trope, without coming across as anti-coding. That’s some good writing and thinking there.

Which is what, I think her point is more about: thinking. Learning how to code just to fill the latest checkbox for societal success isn’t going to be nearly as useful as many people want you to think. (Fun activity: when you read the articles and posts that hammer on about YOU MUST CODE, see how many of them are written by people running or working for companies that just happen to teach coding.)

Knowing how things work, knowing how to think about systems and bits within those systems, knowing how to think about systems is far, far more useful. Most of the things I’ve gotten out of my career that have been the most useful haven’t been things like knowing how to automate things with scripts or learn enough code to cobble together a program I need. It’s been how to think.

How to, even if I don’t know the deep details of a given product, even if I can’t code in <language> at all, know how things work so that I can spot a fragile process that is guaranteed to break. When I was in the Air Force, I had no clue about any of the coding for the Defensive Avionics Systems I worked on. God only knows what the friggin’ ACUs were programmed in. Given the planes I worked on were built in 1986 and designed in the 1970s, probably some form of assembly. Could be Ada too. No idea.

But, at a non-coding level, I knew how those systems worked really well. Intimately. Which meant I could maintain them, test them, call bullshit on contractors (a necessary skill), etc. I also knew how those systems worked on the actual planes, not in a test jig or a simulator. There’s a bit of a difference. (I also knew what they looked like when run through by a goose at a relative speed of 600mph. Yuck. Stank like hell too.)

I knew how to troubleshoot them, analyze their behavior, all of it, even though I didn’t know line one of the coding behind them, and honestly, knowing that would not have really helped. It was knowing the systems, how they worked together, and how to troubleshoot. That made me good at my job.

As a sysadmin, knowing how to code beyond some basic scripting, while handy, isn’t required. I don’t need to know how to read Exchange’s source code to troubleshoot it. What I need to know is how Exchange works, how it interacts with Windows Server, how email works, etc. How clients connect and interact with Exchange and how all that interacts with Active Directory.

It isn’t necessary. It can help, absolutely. Well, maybe. I’ve always been a fan of going to Apple’s WWDC, regardless of how many “sysadmin” sessions their are, because while I’m never going to code at that level, knowing how the systems within the OS work, how security works within macOS/iOS/etc., that helps me know what’s going on within the platform better, so I can troubleshoot better.

Me knowing how to code in Objective-C(++) or Swift has very little to do with that.

When I’m hiring, what I’m looking at isn’t what the person knows, beyond the very basics for the position. What I’m interested in is how they think. How they approach a problem. How they evaluate the problem. I can teach anyone tech. That’s the easy part. What is hard, what I can’t teach them, even remotely easily, is how to think.

And that is a problem in tech, especially in IT, because so many people confuse troubleshooting and spaghetti testing. You can easily see it at work. Join a sysadmin list and see what happens when someone posts a problem. 99%, if not 100% of the responses will be solutions. “Do this.” “Do that”. It will be vanishingly rare that anyone asks for more information on the problem, or asks the OP to maybe post some log extracts, or asks for more information on the symptoms.

It’ll all be “throw solutions until one sticks”. Which actually does work, eventually. I mean, you’re bound to get lucky sooner or later. But it doesn’t help anyone actually understand the problem. It just helps them stick a bandaid on it and move on to the next one. Which is why, when that problem happens again and the old bandaid doesn’t work, that person’s lost. They don’t understand the problem, which means they cannot understand the solution, so it’s blind bandaids and hoping one or more don’t fall off.

Before you learn how to code, learn how to think. That will serve you better, and longer than memorization of syntax.