It's not about technology for its own sake. It's about being able to implement your ideas.
Suppose there was a profession called "maker." What does a maker do? A maker makes things! Dinner. Birdhouses. Pants. Shopping malls. Camera lenses. Jet engines. Hydroelectric power stations. Pianos. Mars landers.
Being a maker is a rough business. It's such a wide-ranging field, and just because you've made hundreds of flowerpots doesn't give you any kind of edge if you need to make a catalytic converter for a 1995 Ford truck.
Now think about a profession called "programmer." What does a programmer do? A programmer programs things! Autonomous vehicles. Flight simulators. Engine control systems. Solid state drive firmware. Compilers. Video games. Airline schedulers. Digital cameras.
If you focus in on one area it expands like a fractal. Video games? That covers everything from chess to 3D open world extravaganzas to text adventures to retro platformers. Pick retro platformers and there's a wide range of styles and implementation techniques. Even if you select a very specific one of these, slight changes to the design may shift the problem from comfortable to brain teaser.
The bottom line is that it's rare to do software development where you have a solid and complete understanding of the entire problem space you're dealing with. Or looking at it another way, everything you build involves forays into unfamiliar territory. Everything you build is to a great extent a research project.
How do you come to grips with something you have no concrete experience with? By running experiments. Lots of little throwaway coding and interface experiments that answer questions and settle your mind.
Writing a PNG decoder, for example, is a collection of dozens of smaller problems, most of which can be fiddled around with in isolation with real code. Any significant app has user interactions that need prototyping, unclear and conflicting design options to explore, tricky bits of logic, API calls you've never used--hundreds of things. Maybe five hundred. And until you run those experiments, you won't have a solid understanding of what you're making.
(If you liked this, you might enjoy Tricky When You Least Expect It.)
permalink August 23, 2012
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?