Jeff Atwood over at Coding Horror is frustrated by the tech industry’s current everyone should-learn-to-code theme, and struck back this week with Please Don’t Learn to Code. He makes some good points. But as someone who’s been promoting programming as part of a well-rounded education for years I fundamentally disagree.
Atwood writes, “Can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder?” And of course Mr. Bloomberg wouldn’t. But there’s an implicit assumption that learning to code is the same as becoming an engineer. It isn’t.
Learning to code can mean a lot of things. On one end of the spectrum is the designer or PM who, over time and via trial and error, learns to copy and paste bits of jQuery in order to assemble simple prototypes. On the other is a fundamental grounding in basic concepts – variables, functions, objects, pointers, etc. – provided by an introductory computer science course or equivalent. The former is useful and can be a solid first step. The latter is critical for anyone seeking a career in software development. But it’s also valuable to anyone – far more so than the cut-and-paste stuff.
Like most of us in the software industry, I serve as tech support for friends and family. Why? They’re perfectly computer-literate. Some of them install their own hard drives. My dad just fixed his own motherboard. To borrow Atwood’s analogy, they can “recognize plumbing problems when they see them.”
No, friends turn to me because I have a deeper, more complete mental model of what goes on inside a computer. I can look at the problem and infer whether it’s hardware or software, whether it’s a particular application or the OS. I can suggest a course of action with greater accuracy than they can. How did I get this knowledge? By learning to code.
I don’t know how to change the oil on my car. I should, for exactly the same reason you should learn to code. Sadly, I don’t – I take it to the Subaru place instead. But computers are still in the awkward teenage years between their birth as business and hobbyist devices and their future as fully-serviceable task-centric appliances. The computer equivalents of auto mechanics and plumbers haven’t fully evolved yet, and the devices themselves aren’t as reliable as your car. (It’s acceptable for your computer to crash of its own accord.) Learning the fundamentals of programming gives you the insight you need to maintain your computer in a world that still lacks solid infrastructure to do it for you.
There’s a poster on my wall full of “Dave-isms” that my team made when I left Yahoo!. One is, “I wrote a script for that.” See, I don’t like doing repetitive tasks. Instead, I stop and write little scripts to do them for me. With luck it saves me time and energy. And even if it’s a wash, writing the script is far more interesting than pressing the same six keys two hundred times.
Computers have tremendous potential to automate our lives. In learning Excel or Photoshop, in signing up for MailChimp, in shopping on Amazon we tap into that potential – but only to the extent that the developers of those apps and services anticipated our needs.
There have been attempts to address this: Apple with Automator, Microsoft with Visual Basic. And if you haven’t tried iftt you absolutely should. But even these tools can be tough to understand if you don’t have some background in programming. And those of us who do know that at some point it’s quicker and easier just to whip up a shell script. Doing so doesn’t require advanced computer science knowledge, or code that scales and performs and localizes to twelve different countries. It just requires a little logic.
Tech Industry Professionals
I’m also thrilled to see so many of my non-engineer colleagues learning to code; if I had my way every designer and product manager would have some programming ability. Not because they should be building the products – there’s a huge difference between being able to code and being a great developer, just as there is between being able to fix your leaky sink and being a great plumber – but because the best teams are built on mutual respect and understanding. Things go better when everyone knows just enough of everyone else’s job to collaborate effectively, to understand what the others are doing and why it’s actually hard.
For designers there’s another reason. A designer’s fundamental job is to communicate. Sometimes the best form of communication is a prototype. And sometimes the best way to prototype a particular interaction is by writing code. Further, sometimes the quickest way to move that button 1px to the left is to edit the CSS or JS yourself.
Give a Man a Fish, and Other Idioms
Atwood writes, “Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions.” And he’s absolutely right.
Everything looks like a nail to someone with a hammer; developers run the risk of seeking programmatic solutions to problems that don’t need them. But nothing looks like a nail to someone who’s never seen a hammer. Learning to code puts a powerful tool in your toolbox; you needn’t be a plumber to benefit from owning a wrench.
But perhaps Atwood is simply concerned about a world full of “naive, novice, not-even-sure-they-like-this-whole-programming-thing coders” getting in the way of truly skilled developers, assuming they know best despite all evidence to the contrary. And I’ll grant him, it’s a risk. Ask any designer: they’ve been dealing with it for years.