Geekflex

In yesterday’s post I wrote about why I don’t program in my free time. There’s an interesting question that comes up as a result: What do I do when the job stops challenging me?

In an older comment on this blog, Roo said:

Maybe initially it is your workplace (boss/manager) who’s got the responsibility of the care and feeding of your growing career/skills. However, if you take a close look around – it may take some careful observation – you will notice that the hierarchy doesn’t rise very far when it comes to technical skills. In the end, every geek ends up owning the problem of keeping themselves challenged.

I don’t have a satisfactory answer. I already know that I don’t deal well with this situation when it inevitably comes up. Still, here are some the ideas I’ve thought of.

The naïve answer is to find a new job or seek out more challenges at my current job; this is obviously not a sustainable solution.¹ You’ll have to constantly move around; would even be able to stay in the same place long enough to contribute something meaningful? How long can you continue to ad responsibilities at your current job and still expect to fulfill them?

As Simon Law pointed out quite simply, “There is a big problem of skill plateau with this strategy. I prefer constant self-directed learning.”

What are your solutions?

When learning any skill, the key is to practice. Whether it’s programming, playing an instrument, playing a sport or yodeling, practice makes perfect. You start off with something small, like “Hello, World” or playing a single note, then you practice until you understand it well and it becomes second nature. To grow the skill, you need to add to that small part. You take what you’ve learned from writing “Hello, World” and you rearrange the commands, or add new ones. You take that single note you learned how to play and you add some more, learning a scale or a chord. Then these new tasks become second nature. You understand them and you’ve learned them. You can play scales with your eyes closed, and write programs without looking at a reference.

If you keep repeating this process, you’ll notice a pattern. Each time you start learning a new technique, built upon an old technique, there’s a lot of work involved. You focus your mental energy on understanding the differences. Eventually you become comfortable with the new technique, and it no longer requires much effort. You can perform it without thinking. Once you can perform without thinking, you’re not growing that skill anymore; the thing you’ve just learned becomes another tool on your bat-belt which can be used to learn and grow newer, more challenging techniques. In order to grow and become better at something, you must keep learning new things, applying the techniques you’ve mastered and developing new ones.

Streets of Rage was a series of beat-’em-up games for the Sega Genesis. One of the most interesting features of its gameplay was that the bosses at the end of a level became standard enemies in the following levels. In order to continue through the game you were forced to trivialize the enemies that at one time provided a significant challenge. Next thing you know, you’re fighting six of them at once and you can do it while yawning.

What kept the game interesting is that you’d have to keep growing your bad-guy-fighting skills. Each level introduced new mini-bosses and bosses that prepared you for the later bosses. How boring do you think Streets of Rage would be if, after beating the first boss, that boss was the only enemy you fought for the rest of the game? It wouldn’t matter if he came at you in swarms, eventually you’d become so comfortable and efficient at defeating him that the game wouldn’t be challenging anymore.

This same concept is something I look for in my professional life. I want bigger and better challenges. If I keep fixing the same kinds of bugs day-in and day-out, using the same tools, performing the same tasks, I’m not growing as a software developer. Skills which have become trivial for me are tools that I can use to learn more complex skills.

The ideal challenge is something that’s just beyond my abilities. Close enough that I’m confident enough to do it, and far enough away that I need to really stretch on tip-toes to reach it. Eventually I’ll get comfortable with it, I’ll be a little taller, and I can reach a little higher.

Okay, there are really two hardest parts about blogging.

The most obvious one is actually sitting down to do it on a regular basis and not letting it stagnate. There’s an easy solution for that, and it’s the same one every blogger will you: make a regular schedule and stick to it. Then it becomes routine. It’s just like going to the gym. That’s a horrible analogy because I hate going to the gym. But I love writing.

The more subtle quirk to blogging has more to do with the writing process itself — something I know very little about. The last time I received any kind of formal education in “Creative Writing” was probably in high school. The hard part for me isn’t in translating my thoughts into words, but in knowing when to stop and just click “Publish”.

If I’m left to my own devices, I might just ramble on into eternity flitting from topic to tangent in some kind of endless pattern. If I’m not careful, a post about code could end up with unicorns and rainbows. I need to be able to realize when I’ve said my piece and move on — and not end up in a situation where I’ve combined several unrelated blog post ideas into one massively incoherent post.

And here’s the worst part: once my post is done, I’ll read it over. That’s where insecurity kicks in and I begin to second-guess myself. It’s like going over a final exam to double-check all my math, and then asking myself if I really solved the problem using the right method. Often, my first instinct is correct — but looking over the same problem again I start doubting myself. At this juncture in the writing process I feel like I’m faced with three choices:

• Publish now and release something imperfect on the world
• Revise and edit, running the risk of obscuring my original point
• Discard the post entirely and it will never see the light of day

It’s more like a flow-chart, really:

It was my leaning towards that last option that caused my previous blog to fail more than anything else. There were a number of posts that I’d written which never made it out of the Revise <-> Publish loop, and many more that were written and then discarded.

Publishing takes a combination of guts and apathy. You have to realize that no matter what you release, it will never be perfect. The Revise <-> Publish loop is more likely to just dull down your point until it becomes a softened nub and loses its impact. Each iteration will remove some of the edginess and replace it with something more politically correct, more agreeable, more average. The post ceases to become an expression of original thought, and ends up being a reflection of everyone else’s thoughts. And that’s how I lost my voice in the noise.

In Elizabeth Gilbert’s recent TED talk, she talks about a disembodied “genius” that provides creativity as a “psychological construct that protects you from the result of your work.” This is why I was motivated into starting a new blog instead of reviving the old one. Calling the blog by something other than my name allows me to distance myself from what I write. I can establish an identity that is mostly-me-but-not-entirely and be far removed from it enough to release something that isn’t perfect. Now when I see something I can think “this is a topic that would be great for Geekflex” as oppose to “this is something that I should blog about sometime.” As for those things that don’t fit on Geekflex, that’s what twitter is for.