programming in the
twenty-first century

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

Get Good at Idea Generation

I get more mail about The Recovering Programmer than anything else I've written. Questions like "How can I be more than just the programmer who implements other peoples' master plans?" are tough to respond to. Seeing that feeling of "I can make anything!" slide into "Why am I doing this?" makes me wish there was some easy advice to give, or at least that I could buy each of these askers a beer, so I'd like to offer at least one recommendation:

Get good at idea generation.

Ideas have a bad reputation. They're a dime a dozen. They're worthless unless implemented. Success is 90% perspiration. We've all seen the calls for help from a self-proclaimed designer and his business partner who have a brilliant company logo and a sure-fire concept for an app. All they need is a programmer or two to make it happen, and we all know why it won't work out.

Now get past ideas needing to be on a grand scale--the vision for an entire project--and think smaller. You've got a UI screen that's confusing. You have something non-trivial to teach users and there's no manual. The number of tweakable options is getting out of hand. Any of the problems that come up dozens of times while building anything.

The two easy approaches are to ignore the problem ("What's one more item on the preferences panel?") or do an immediate free association with all the software you've ever been exposed to and pick the closest match.

Here's what I do: I start writing a list of random solutions on a piece of paper. Some won't work, some are simple, some are ridiculous. What I'm trying to do is work through my initial batch of middling thoughts to get to the interesting stuff. If you've ever tried one of those "write a caption for the image" contests, it's the same thing. The first few captions you come up with seem like they're funny, but keep going. Eventually you'll hit comedy gold and those early attempts will look dumb in comparison.

Keep the ideas all over the place instead of circling around what you've already decided is the right direction. What if you were had to remove the feature entirely? Could you negate the problem through a change in terminology? What's the most over-engineered solution you can think of? What if this was a video game instead of a serious app? What would different audiences want: a Linux advocate, the person you respect most on twitter, an avant garde artist, someone who can't speak your native language?

The point of this touchy-feeliness isn't just to solve your current problem, but to change your thinking over time. To get your mind working in a unique way, not just restating what you've seen around the web. Every so often you'll have a small breakthrough of an idea that will become a frame for future solutions. Later you'll have another small breakthrough that builds on it. Eventually you'll be out in a world of thought of your own making, where you're seriously considering ideas that aren't even in someone else's realm of possibility.

(If you liked this you might enjoy Advice to Aimless, Excited Programmers.)

permalink March 27, 2014



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?