Wednesday, January 5, 2011

How I Learned To Code

I wrote yesterday about writing code as a tool in the tester's toolbox. Phil brought up a great question: "That's nice, smartypants. How?" (I'm paraphrasing; he was more polite!). But he's right - how do you learn to code?

Learning to code is like learning anything else: people learn in different ways. Here's my story:

I left college working for a startup in open source software, and I didn't write any code. Time passed, the startup went out of business, I found a new job... and all of a sudden I find myself the sole dedicated tester at a software company. Oh, and they just bought a Quick Test Pro license.

This is where I started to learn to code.

First of all, I'm human. And I discovered that deploying all the projects to the server, setting up the configuration, and restarting the right services was (1) boring; and (2) error prone. A passing developer said, "why not just write a batch script to deploy it?" So I did. I and Google and lots of "echo this" and "why did it do that?" got the script written. And it worked. I was off to the races. Fire up QTP and.... well, shoot. Record/playback really doesn't work very well. The QTP help manual has a section that indicates you can modify your recordings. So I did. It was Java, but Google knows Java, too. I also got into the habit of stopping by developer desks and asking for help.

From there it was a fairly short step to "hey, I want a JUnit test that looks like that other JUnit test but does foo differently". From there to standalone programs for simple things was also a small step. Changing jobs and changing projects meant picking up new languages - Python, Perl, Ruby, Java - and new frameworks. As I learned, the code just got larger and larger (and eventually smaller and more efficient) and better and better structured.

To this day, I write code to solve simple tasks just to keep fresh during times when work doesn't have me coding. Sometimes it's writing a simple script to normalize my mp3 names, or writing a webapp for use in presenting a concept at a talk I'm giving at a conference. Oh, and I still ask people who are better coders than me to look at my code.

And that's how I got where I am.

So how does that help you? There are some things you can do to get started:
  1. Start small. Don't set out to "learn a language". Set out to solve a small problem.
  2. Don't worry about "good"; worry about "functional". "Good" will come as you get to be a stronger coder.
  3. Read a book or take a class if it'll help you. They're great for concepts and for the language to talk about coding. Keep in mind that these things supplement practice; they don't replace it.
  4. Don't be afraid to ask. Most people are really happy to help (unless they're behind on a deadline, and that's just a temporary state!).
  5. Break the problem down into small parts. The smaller the piece, the more likely you can solve it. Solve something small, string it together, refactor.
Give it a shot! The best way to learn to code is to start.


  1. Good story! For me, my very first software job I shared an office with a senior dev who taught me how to use the debugger right away. It was only years later I realized how unusual this was. So I have been reading code all my career. I recommend reading code, even for non-programmers, it is a useful skill.

    It was years later I decided to teach myself how to program. My very first serious program was a Perl script to throw the I Ching according to the algorithm for coins noted in the Wilhelm-Baynes translation, and cough up ASCII hexagrams onto the terminal. It even showed the changed hexagram after turning 6s into 9s and vice versa.

    So yes, I absolutely agree. If you don't have a problem at work to solve with some code, find a fun personal problem you can solve with some code.

  2. I have trouble reading this because the type is gray on a gray background.