programming in the
twenty-first century

It's not about technology for its own sake. It's about being able to implement your ideas.

The Software Developer's Sketchbook

It takes ten-thousand hours to master your field, so the story goes, except that programming is too broad of a field.

Solving arbitrary problems with code isn't what ultimately matters, but problems within a specific domain. Maybe it's strategy games. Maybe vector drawing tools. Music composition software. Satellite control systems. Viewed this way, who is truly an expert? Once I was asked how many high-end 3D games I work on a year, and I wrote "3" on the whiteboard, paused a moment to listen to the "that's fewer than I expected" comment, then finished writing: "1 / 3". How many satellite control systems do you work on in a decade? One? Maybe two?

Compare this to carpenters or painters or cartoonists who can look back on a huge body of work in a relatively short time, assuming they're dedicated. Someone who does roof work on fifty houses a year looks a lot more the expert than someone who needs two years to ship a single software project. Have you mastered building user interfaces for paint programs when you've only created one, then maintained it for five years, and you've never tried alternate approaches?

To become the expert, you need more projects. They can be smaller, experimental, and even be isolated parts of a non-existent larger app. You can start in the middle without building frameworks and modules first. This is the time to try different languages, so you can see if there's any benefit to Go or Clojure or Rust before committing to them. Or to attempt a Chuck Moore-esque exercise in extreme minimalism: is it possible to get the core of your idea working in under a hundred lines of code? But mostly it's to burn through a lot of possibilities.

This sketchbook of implemented ideas isn't a paper book, but a collection of small programs. It could be as simple as a folder full of Python scripts or Erlang modules. It's not about being right or wrong; many ideas won't work out, and you'll learn from them. It's about exploring your interests on a smaller scale. It's about playing with code. It's about having fun. And you might just become an expert in the process.

(If you liked this, you might enjoy The Silent Majority of Experts.)

permalink January 1, 2015

previously

archives

twitter / mail

I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.

Where are the comments?