Non-stop Action!

Cover me, I'm going in!

Maybe I just watch too much television, but it seems to me like every doctor, lawyer, and policeman (or woman) has an incredibly complicated and exciting career. Almost every one of them also has a deeply complicated personal life, perhaps accompanied by a serious personality flaw or internal conflict. On the other hand, every time I go to the doctor it’s about something mundane that involves listening to me breathe, poking a Q-tip down my throat, or examining other things I’ve since repressed, but will doubtless come out in a revealing and exciting therapy session with my TV psychologist. I swear that doctors just use cold stethoscopes on purpose so they can share a laugh with their colleagues later about how a patient screamed, just to relieve the sameness of every day work.

The same is true about life in software development. Some days are great, some are dull. The fun can go on for weeks, but so can the dullness. Few things are more boring than the days between the final testing of the software, when you’re not even allowed to fix a bug (even if you have an easy fix for it), and the new feature coding of the next release. The marketing and product design people are always running so far behind that you can spend a couple of months without coding anything real.

The fact is that not all of the things you do in software development are fun. Some people love bug fixing time while others hate it. Some people love spending months doing up-front design work with little coding,
while some people would rather be doing incremental prototyping and design.

What can you do to make every day a little more exciting when things are slow? Here are a few ideas.

  1. In a branch project, fix some of the bugs you want to fix and prepare them for integration in the next release.
  2. Clean up some code you hated in the previous release.
  3. Read up on something you might be able to use in the next release and experiment with it.
  4. Refactor some code into a toolkit that might be useful to other developers. This is especially valuable if you’ve got lots of code that was cut and pasted out of expedience.
  5. Do some experiments with features that you’d personally like to have in the software. You might
    end up with something really cool or it may get tossed in the wasted basket. Either way, you’ll keep up your coding chops and may end up with some useful code you can use or reuse later.
  6. Investigate the functionality of other similar software. Maybe you’ll think of a way to trump the
    competition.
  7. Learn a new programming language or technology. Even if it has nothing to do with what you’re doing, you may get some brilliant ideas about your code, code designs, or functionality for your software.
  8. Build a small application. Several times, I’ve used slow times to build myself a little application that does something that I found personally useful, like my own sticky note application. I wrote the first one in 1990 on my SparcStation (a Sun Unix workstation) and wrote a Windows version years later.
    Why? First, I thought it would be useful. Second, I learned about pieces of the technology that I might not have otherwise learned. If you spend most of your time working on the internals of your code,
    how much time do you get to spend learning about user interface development? You might find it fun or may at least learn why some of the code in your system looks the way it does.