It's not about technology for its own sake. It's about being able to implement your ideas.
I've started writing this twice before. The first time it turned into Simplicity is Wonderful, But Not a Requirement. The second time it ended up as Don't Be Distracted by Superior Technology. If you re-read those you might see bits and pieces of what I've been wanting to say, which goes like this:
There is danger in becoming an expert. Long-term exposure to programming, coding, software development--whatever you want to call it--changes you. You start to recognize the extreme complexity in situations where there doesn't need to be any, and it eats at you. You realize how broken the tools are. You discover bygone flashes of amazing beauty in old systems that have been set aside in favor of the way things have always been done.
This is a bad line of thinking.
It's why you run into twenty-year veteran coders who can no longer write FizzBuzz. It's why people right out of school often create impressive and impossible-seeming things, because they haven't yet developed an aesthetic that labels all of that successful hackery as ugly and wrong. It's why some programmers migrate to more and more obscure languages, trading productivity for poetic tinkering.
Maybe a better title for this piece is "So You've Become Jaded and Dissatisfied. Now What?"
Cultivate a "try it first" attitude. Yes, it's amusing to read about those silly developers who can't write FizzBuzz. But your first reaction should be to set aside the article and try implementing it yourself.
Active learning or bust. Don't bother with tutorials or how-to books unless you're going to use the information immediately. Fire up your favorite interpreter and play along as you read. Don't take the author's word for anything; prove it to yourself. Do the exercises and invent your own.
Be realistic about the limitations of your favorite programming language. I enjoy Erlang, but it's puzzle language, meaning that some truly trivial problems don't have a straightforward mapping to the strengths of the language (such as most algorithms based around destructive array updates). When I don't have a clear picture of what features I'm going to need, I reach for something with few across-the-board sticking points, like Python. Sometimes the cleanest approach involves straightforward loops and counters and return statements right there in the middle of it all.
Let ease of implementation trump perfection. Yes, yes, grepping an XML file is fundamentally wrong...but it often works and is easier than dealing with an XML parsing library. Yes, you're supposed to properly handle exceptions that get thrown and always check for memory errors and division by zero and all that. If you're writing code for a manned Mars mission, then please take the time to do it right. But for a personal tool or a prototype, it's okay if you don't. Really. It's better to focus on the fun parts and generating useful results quickly.
permalink March 12, 2013
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?