Staying on the horse

Staying on the horse

Software development can be exciting. We learn new things. We get to explore new ideas and see them come to life.

Software allows us to share our talents with people from all over the world. We get to see the things we create  put to use sometimes in ways that we never considered.

But software isn’t all fun and games. Sometimes software development can be downright monotonous and annoying. For any project of sufficient size, we seem to start off excited, but then once we get far enough into it, it becomes work and takes a lot of willpower to want to continue. Time keeps ticking by, the project gets larger and larger. It gets more difficult to fit it all into your head, and development becomes “real”.

I was thinking about this today, and trying to enumerate all the times that I felt like I didn’t want to touch a particular project ever again. I came up with a few suggestions on preventing project burnout that I hope can be useful to some of you out there working long hours in software.

Change code that is causing repetitive typing

If you find yourself frequently having to type some kind of boilerplate code, or typing the same basic pattern of code over and over again, it’s time to take a look at a refactoring to remove the cause of your pain. Over time, this will sap your willpower to continue on the project since most of your time will be spent pounding out pages and pages of nothing but supporting structure, without getting any forward moving work done.

If refactoring doesn’t work for one reason or another, or the cause for the repetition is beyond the builtin power of your language to solve, try code generation. Use something like Cog to make your life easier and get back to actually making progress on your code instead of doing the boring work yourself.

Refactor confusing code

If you keep bumping into a chunk of code that is confusing or that you always have to think about before you can make changes, it might be time to refactor and come up with a simpler way of doing the task. For example, you might have a class where in each method callback you need to check the status of a connection or other object before proceeding. Over time when adding new methods eventually this is going to be forgotten introducing subtle bugs into your code. If you have to keep remembering things, find a way so that those memories are embedded in your code.

Encapsulate behaviors

If you have to remember to “do X” before each call to a certain library, see if you can encapsulate the doing of X into an easy to reuse chunk. For example, if you’re using a C library and you keep having to remember to do your own cleanups, use a unique_ptr with a custom deleter to create RAII objects. Just because a library didn’t come with an easier way to use it, doesn’t mean you shouldn’t build one.

Don’t just code. Write unit tests

If you’re not into test driven development, or are adverse to the extra coding that unit testing creates, you are missing out on an opportunity to pull yourself from “programmers writers block”. Completing and executing unit tests regularly while creating software  is a great way to pull yourself out of the code code code code cycle for a bit and creates a higher quality product in the end. It also will end up saving you debugging time.

I hope this post can help you to prevent coding burnout. Remember that if you’re starting to feel like you don’t want to work on a project, many times there is a problem causing it that you can take steps to resolve. Do your best to finish the projects that you start. Programming is more rewarding that way.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s