Photo by Balakov

I’ve been programming for about 16 years now.

I almost called this my “Most Important Programming Lessons”, but I consider writing software to involve far more than a mastery over programming arcana.

When I first discovered source code, I didn’t pick up a manual and start reading about data structures and flow control. That was a lucky decision for the current me, because the former me would probably have been overwhelmed and lost interest.

Instead, I kept myself entertained by making little changes to programs that I already knew worked. I’d do fun things, like surprising the gorilla in the QBasic game ‘Gorillas‘ by modifying his thrown bananas to explode like atomic weapons. The poor guy never saw it coming.

I was writing code for me.

Anytime I showed my latest tweaks to somebody they would laugh in appreciation — but then they would always come up with another idea to push things further. What if the bananas fragmented on their descent like a MIRV missile? What if the bananas became the hero and they threw gorillas? Ha! I was hooked.

I was dealing with feedback from people who became truly inspired only after seeing something working already.

Eventually, I figured out enough through my tinkering that I could face a blank screen and enter my first instructions to make the computer do something. Paint the screen red. Draw a box. Beep!

I would only make a couple small improvements before compulsively running the program again. Did I predict how things would behave, or was I about to be rewarded with something completely unexpected (and often hilarious)?

I was practicing iterative development.

As the years of experience piled on, and I worked through various programming gigs, I started to get overly-confident in my ability to think like the computer. I wrote code for longer stretches, at times making changes so vast that it was impossible to actually run the program for several days. I also started to preemptively add new features, and I delayed for longer periods between demonstrating the new changes to actual users. “It will be finished when my task list is finished!” I thought, naively.

My growing confidence in programming was undermining my ability to collaborate with non-programmers. I was also looking at projects as a checklist of disparate tasks, instead of a cohesive experience for the user.

One day, probably after completing yet another soulless project — with my team breathing a collective sigh of relief, as if being spared from an execution at 30 seconds before midnight — it finally dawned on me that things shouldn’t be this way. Things didn’t used to be this way.

I made a short list of things that detracted from the fun I had when starting out:

• We were writing projects that we didn’t need, and wouldn’t use, ourselves.
• Management, alone, was deciding the tools we used to solved our problems, usually because of executives who bought into vendor marketing at face value.
• Our project managers weren’t programmers, and they weren’t end-users, so they couldn’t effectively communicate with either side. Their project plans revolved around the least important party — the middleman.
• Our talents were being rented out at five times our compensation.
• We had no stake, or risk, in the success or failure of our work.

Shortly after this epiphany I quit my job as a complacent programmer. I co-founded a new software company where we established an ethos of:

• Writing software that we would use as much as our end-users.
• Talking directly with our end-users instead of using middlemen.
• Sharing ideas and changes as early as possible.
• Emphasizing that sales were votes of confidence in what we’re doing going forward, opposed to a payment that merely offset our past work.

Dozens of projects, half a dozen programming languages, and tens of thousands of hours of experience later, and I it turns out I learned my most important software writing lessons in those first tinkering days with QBasic.

Did you practice any of your favorite software development lessons well before you realized what you were doing? I’d love to hear about it in the comments!

Related reading:
http://www.extremeprogramming.org/
http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast