Chapter 26. Relish the Challenge

Success is not final, failure is not fatal: it is the courage to continue that counts.

Winston Churchill

We are “knowledge workers.” We employ our skill and knowledge of technology to make good things happen. Or to fix it when they don’t. This is our joy. It’s what we live for. We revel in the chance to build things, to solve problems, to work on new technologies, and to assemble pieces that complete interesting puzzles.

We’re wired that way. We relish the challenge.

The engaged, active programmer is constantly looking for a new, exciting challenge.

Take a look at yourself now. Do you actively seek out new challenges in your programming life? Do you hunt for the novel problems, or for the things that you’re really interested in? Or are you just coasting from one assignment to the next without much of a thought for what would motivate you?

Can you do anything about it?

It’s the Motivation

Working on something stimulating, something challenging, on something that you enjoy getting into helps keep you motivated.

If, instead, you get stuck in the coding “sausage factory”—just churning out the same tired code on demand—you will stop paying attention. You will stop learning. You will stop caring and investing in crafting the best code you can. The quality of your work will suffer. And your passion will wane.

You will stop becoming better.

Conversely, actively working on coding problems that challenge you will encourage you, excite you, and help you to learn and develop. It will stop you from becoming staid and stale.

Nobody likes a stale programmer. Least of all, yourself.

What’s the Challenge?

So what is it that particularly interests you?

It might be that new language you’ve been reading about. Or it might be working on a different platform. It might just be trying out a new algorithm or library. Or to kick off that pet project you thought about a while ago. It might even be attempting an optimisation or refactor of your current system; just because it looks elegant, even if—shudder to think—it doesn’t actually provide business value.

Often this kind of personal challenge can only be gained on a side project; something you work on alongside the more mundane day-to-day tasks. And that’s perfect—it’s the antidote to dull “professional” development. A programming panacea. The crap code cure.

What excites you about programming? Think about what you’d like to work on right now, and why:

  • Are you happy to be paid for producing any old code, or do you want to be paid because you produce particularly exceptional work?

  • Are you performing tasks for the kudos; do you seek the recognition of your peers or the plaudits of managers?

  • Do you want to work on an open source project; would sharing your code give you a sense of satisfaction?

  • Do you want to be the first person to provide a solution in a new niche, or to a tricky new problem?

  • Do you solve problems for the joy of the intellectual exercise?

  • Do you like working on a particular kind of project, or do certain technologies suit your strange peccadilloes?

  • Do you want to work alongside and learn from certain types of developers?

  • Do you look at projects with an entrepreneurial eye—seeking something you think will one day make you millions?

As I look back over my career, I can see that I’ve tried to work on things in many of those camps. But I’ve had the most fun, and produced the best software, when working on projects that I’ve been invested in; where I’ve cared about the project itself, as well as wanting to write exceptional code.

Don’t Do It!

Of course, there are potential downsides to seeking out cool coding problems for “the fun of it.” There are perfectly valid reasons not to:

  • It’s selfish to steer yourself towards exciting things all the time, leaving boring stuff for other programmers to pick up.

  • It’s dangerous to “tinker” a working system just for the sake of the tweak, if it’s not introducing real business value. You’re adding unnecessary change and risk. In a commercial environment, it’s a waste of time that could be invested elsewhere more profitably.

  • If you get sidetracked on pet projects or little “science experiments,” then you’ll never get any “real” work done.

  • Remember: not every programming task is going to be glamorous or exciting. A lot of our day-to-day tasks are mundane plumbing. That’s just the nature of programming in the real world.

  • Life is too short. I don’t want to waste my spare time working on code as well!

  • Rewriting something that already exists is a gross waste of effort. You are not contributing to our profession’s corpus of knowledge. You are likely to just re-create something that already exists, possibly not as good as the existing implementations, and full of new terrible bugs. What a waste of time!

Yada. Yada. Yada.

These positions do have some merit. But they should not become excuses that prevent us from becoming better programmers.

It is exactly because we have to perform dull tasks all day that we should also seek to balance them with the exciting challenges. We must be responsible in how we use our time do this, and whether we use the resulting code or throw it away.

Get Challenged

So work out what you’d like to do. And then do it:

  • Perform some code katas—short practice exercises—that will provide valuable deliberate practice. Throw the code away afterwards.

  • Find a coding problem you’d like to solve, just for the fun of it.

  • Kick off a personal project. Don’t waste all your spare time on it, but find something you can invest effort in that will teach you something new.

  • Maintain a broad field of personal interest, so you have good ideas of other things to investigate and learn from.

  • Don’t ignore other platforms and paradigms. Try rewriting something you know and love on another platform or in another kind of programming language. Compare and contrast the outcome. Which environment lent itself better to that kind of problem?

  • Consider looking for a new job if you’re not being stretched and challenged where you’re currently working. Don’t blindly accept the status quo! Sometimes the boat needs to be rocked.

  • Work with, or meet up with other motivated programmers. Try going to programming conferences, or join local user groups. Attendees come back with a head full of new ideas, and invigorated from the enthusiasm of their peers.

  • Make sure you can see the progress you’re making. Review source control logs to see what you’ve achieved. Keep a daily log, or a to-do list. Enjoy knocking off items as you make headway.

  • Keep it fresh: take breaks so you don’t get overwhelmed, stifled, or bored by bits of code.

  • Don’t be afraid of reinventing the wheel! Write something that has already been done before. There is no harm in trying to write your own linked-list, or standard GUI component. It’s a really good exercise to see how yours compares to existing ones. (Just be careful how you employ them in practice.)