I'm a recovering programmer who has been designing video games since the 1980s, doing things that seem baroquely hardcore in retrospect, like writing Super Nintendo games entirely in assembly language. These days I use whatever tools are the most fun and give me the biggest advantage.
james.hague @ gmail.com
Where are the comments?
Expertise, the Death of Fun, and What to Do About ItI'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
returnstatements right there in the middle of it all.
Consciously set aside 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.