A Programmer Learns to Code

And the difference between the two

It’s a problem all too often found amongst computer scientists—we’re great at programming, but pretty bad at coding. That sounds like the same thing, so let me elaborate. Programming is the thing that you learn how to do in school. You learn how to implement a hash function, how the kernel does context switching, how a Red-Black tree actually works, or the dubious practice of “programming” a Turing machine. These sorts of things teach you a lot of great, if somewhat narrow, problem solving skills and are certainly critical things for a well-rounded computer scientist to understand. The bottom line though, is that they are a bit distant from the actual practice of programming, or what many refer to as coding or hacking.

Coding is different.

Coding is more than just writing the literal code and this is because the way we form coding problems is different than the way we form programming problems. Programming problems are inherently defined—use language X to execute algorithm Y on architecture Z and make sure that you match the correct API. Coding problems are inherently undefined, because the problem itself becomes the defining factor, not the solution. I don’t want anybody to think I am trying to discount either at the expense of the other. Both are important, and being good at either requires an exceptionally talented individual. But the talents and nature of these two things are actually quite different and as a result if you blindly apply programming ideologies to coding problems you will not be taking the path of least resistance. I learned this the hard way.

So what is it then that we need to learn in order to be good at coding? At a basic level, you do need a bit of a toolkit that you can adeptly use to do the literal building of things. I’ll cover that later in the post, but first I want to highlight the less tangible but more important methodologies and ideas that have made the biggest difference for me.

Stay focused on solving problems, not creating new ones.

This is the crux of this post, and the trap I most often see hot shot programmers (including myself) falling into. You need to remember that you’re not embarking on this project to show off to everybody how great and clever of a programmer you are. If you want to do that just go to grad school for 5 years or do some programming competitions. What you do want to do is solve your actual problem in the quickest and easiest way possible, and that generally does not include self-aggrandizement or detours for clever “solutions” to problems you made up along the way.

For example—if I told somebody with a particularly extreme case of this disease to build me a quick website, I’d expect them to break out Vim and the command line, get a barebones AWS instance, and watch them screw around with config files and setup scripts for the next 6 hours. Instead of doing that, I want you to get a Google App Engine account, open up PyCharm, and immediately do the stuff that is getting you closer to giving people something they want rather than giving you the pleasure of playing with your favorite toys.

Is this getting me closer to my goal?

This simple question is the thing that I have found the most effective for converting myself from programming mode to coding mode, and it’s something I wish somebody beat into me earlier than a kind mentor did. One huge difference between programming environments and coding environments is that when you’re coding you have enormous latitude in decision making. You are constantly faced with a plethora of options for what to do next and the path to the solution is generally ambiguous. As a result, if you are not constantly being vigilant and pulling yourself back up to the goal level, you will endlessly get trapped solving small problems that you are creating ad hoc rather than the big one that is the real target.

If you are about to take 2 hours to understand how to use a particular API, you better be convinced that this API is critical to moving the project forward. If you are about to drop into C from Python code, you better be damn sure that the performance issue you think you are addressing actually exists. Doing all those little things surely adds some benefit, but in the scheme of things they generally aren’t moving you forward as fast as you could go. I find the more often than not it’s not the raw programming skill that differentiates good coders from great coders—it’s how good they are at avoiding unnecessary detours. It’s easy to create complicated work to do, any sufficiently well educated engineer will be an all-star at that game. What takes talent is figuring out what work you must do.

Getting the Toolkit

Okay, let’s get down to the dirty work. You’ve got yourself a problem and you think you’ve framed it well—so how do you actually go about solving it?

Google App Engine + Bootstrap + PyCharm = Quick and Easy Solutions

That’s it. I’m not going to rehash the platform wars argument here, lots of other people have done that. Rather, this is an easy way to step into the coding world. Google App Engine is incredibly simple to setup and the one-click deploy actually works. The default Google data store and webapp2 Python framework do a great job of getting out of your way and taking care of the stuff you don’t want to deal with. Bootstrap does the same sort of simplification for your CSS and HTML. Finally, PyCharm is a great IDE for Python, and you’ll thank yourself later when you switch over from Vim/Emacs. If your goal is to get working on the problem rather than getting caught in the setup and learning phase, this is a great way to go.

You could pick more “powerful” tools than these, but the question you need to constantly ask yourself is if those power tools are solving more problems than they creating. It may be fun to go buy a huge John Deere tractor to cut your lawn, but by the time you get it home, fuel it up, and actually figure how to use the thing I’ll already be watching football after happily walking with my push mower. While you were spending all day just figuring out how to turn your tool on, I was already working on solving the actual problem. When we code, we must be our own forcing function. Don’t be the sucker with the John Deere when the job called for a Honda.

Tenaciously Pursue the Goal

That’s what I want you to take away from this piece. When you start wandering off from the idyllic fields of academia, every idea is a potential mini-project and its easy to be disabled by the seemingly endless march of specs and frameworks people are telling you to learn. You cannot, however, be distracted by all of that. If you’re already a great programmer, don’t intimidated by frameworks like GAE and Bootstrap, picking them up will be a breeze. And before you start diving into something new, just remember to check yourself at the goal level.

When we start coding, we are immediately thrown into a torrent of ambiguity. The thing that makes you stand out is not how quickly you can run around, but rather how quickly you can make your problem and goals precise. Good luck, stay focused, and happy hacking.

Like what you read? Give Alex Daifotis a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.