programming in the
twenty-first century

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

Getting Past the Cloning Instinct

When I write about creativity or similarly non-technical subjects, I often get mail from pure coders asking how they can become better at design. There's an easy response: take an idea from your head all the way to completion.

Almost certainly that idea isn't as well thought-out as you'd hoped, and you'll have to run experiments and backtrack and work out alternate solutions. But if you stick with it and build everything from the behind-the-scenes processing to the UI, make it simple enough for new users to learn without you being in the room to guide them, and agonize over all the choices and details that define an app, then congratulations! You've just gone through the design process.

Obvious advice? It would be, except there's a conflicting tendency that needs to be overcome first: the immediate reaction upon seeing an existing, finished product of "I want to make my own version of that."

It's a natural reaction, and the results are everywhere. If a fun little game gets popular, there's an inevitable flood of very similar games. If an app is useful, there will be me-too versions, both commercial and open source. Choosing to make something that already exists shifts the problem from one of design to one that's entirely engineering driven. There's a working model to use for reference. Structure and usability problems are already solved. Even if you desperately want to change one thing you think the designer botched, you're simply making a tweak to his or her work.

Originality is not the issue; what matters is the process that you go through. If your work ends up having similarities to something that came before it, that's completely different than if you intentionally set-out to duplicate that other app in the first place.

The cloning instinct makes sense when you're first learning development. Looking at an existing application and figuring out how to implement it is much easier than creating something new at the same time. But at some point, unless you're happy being just the programmer, you need to get beyond it.

(If you liked this, you might enjoy The Pure Tech Side is the Dark Side.)

permalink July 16, 2013



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?