It's not about technology for its own sake. It's about being able to implement your ideas.
I've worked on personal projects where I went badly off track and didn't realize it until much later. What I needed was someone to nudge me in the right direction, someone to objectively point out the bad decisions I was making.
What I needed was a producer.
When a band is recording an album, the producer isn't there to write songs or play instruments, but to provide focus and give outside perspective. A good producer should say "Guys, you sound great live, but it's not coming through in the recording; can we try getting everyone in here at same time and see how that goes?" or "We've got three songs with similar wandering breakdowns; if you could replace one, which would it be?"
(Here I should point out that a producer in the music production sense is different than a producer in film or in video games. Same term, different meanings.)
If you're a lone wolf or part of a small group building something in your basement, there's tremendous value in being able to step back and get into the producer mindset. Maybe you can't be both a producer and developer at the same time, but recognizing that you need to switch hats periodically is key.
What are the kinds of question you should be asking when in your producer role?
Are you letting personal technology preferences cloud your vision? Haskell is a great language, but what if you're writing a lot of code that you'd get for free with Python? Yes, Android is open to some extent and iOS isn't, but should you be dismissing the entire iPhone / iPad market for that reason?
Are you avoiding doing the right thing because it's hard? If everyone you show your project to has the same confusion about how a feature works, disregarding it because it would take a month of rearchitecting usually isn't a valid response.
Are you simply copying existing ideas without offering anything new? It's so easy to see a finished application and jump into writing your own version. But think about the problem that it was designed to solve instead of copying the same solution. A painting program doesn't have to use the blueprint laid out by MacPaint in 1984 [EDIT: that blueprint appeared earlier in Draw for the Xerox Alto and SuperDraw for the PC]. An IDE doesn't have to follow the project tree view on the left schematic.
Are you spending too much time building your own solutions instead of using what's already out there? Should you really be writing another webserver or markdown formatter or JSON decoder?
Do you understand your audience? If you're building an application for graphic artists, are you familiar with how graphic artists work? Are you throwing out features that would be met with horrified stares?
permalink April 22, 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?