I don’t know what it is. Somehow sitting in front of the computer interferes with my thought process. This happens to me all the time. I’ll be sitting at my desk, thinking through some programming problem. I’m not getting anywhere. Then I do something that makes me get up from the desk, like walk over to a colleague’s office or walk down the hall to the restroom. Invariably the solution I was looking for pops into my head shortly after leaving my computer. This happens subconsciously - I’m not thinking about the problem at all when the solution suggests itself.

Today it happened again. I spent the last few hours at work trying to figure something out. Finally around 5:00 I gave up in disgust (I hate leaving on that note!) and headed home. About 2 minutes after leaving my desk (I was halfway through the parking lot) the solution I was searching for hits me.

I don’t know what it is, but somehow when you’re sitting in front of a computer for extended periods of time, your brain gets in a rut. It seems like all that’s needed to break out of the rut is to get away from the computer and stop thinking about the problem, even for a very short period of time (1-2 minutes). I’ve talked with other software professionals who’ve noticed basically the same thing.

So next time you’re blocked on a problem, try to stop thinking about the problem for a little while. Take a short walk or something. Don’t stay in front of the computer - checking email or blogs doesn’t get you out of the rut. You have to physically step away from the computer and completely take your mind off of the problem.

Stop whatever you’re doing for a moment, and take a look at the books on your bookshelf that you have to help you develop software. If you don’t have a bookshelf or aren’t a book kind of person, just play along anyway :).

There’s a book that should be on your bookshelf, and I think there’s a good chance it’s not. The purpose of this entry is to convince you to add this book to your bookshelf. It’s a book that you need to have close at hand, ready to pull out at a moment’s notice. It will be a help no matter what domain you work in, and is useful across programming languages.

The book is a thesaurus, and if you don’t currently use one when writing code I’m going to try to convince you to start.

It’s a well accepted and somewhat obvious fact that you’re not writing code solely for the benefit of the computer that will run it. In fact, the most important audience for your code is the programmers who will maintain it in the future (included your future self). The code should be optimized for reading. Write once, read many.

Coming up with good names for things in code is incredibly important. Good, of course, is subjective. Your domain, programming language, and team culture all play a part in deciding what “good” means for you. Spending a little extra time up front to come up with good names pays dividends down the road.

Here are two easy steps you can take, starting now, to improve the naming in the codebases you work on:

1) Take a little time to think of good names.
The more visible the thing you’re naming, the more important it is to have a good name for it. I’m thinking mostly about public, shared classes, as they are the most important things to create good names for. However, method names, variables, etc, are all very important too.

In order to come up with a good name, you need to have a clear understanding of the role of the class (or method name, etc. - from here on out I’ll just use class but feel free to substitute whatever construct you like) you’re naming. If the class doesn’t have a well defined role don’t waste time trying to name it. First refactor your code and split out responsibilities, and then come up with good names.

Be creative. This is where that thesaurus comes in. The English language has many ways of expressing a concept. Use them. Use them all, or make use of nuances. Whatever works well for your situation. There’s no reason that program code needs to have such a limited vocabulary as is often used.

2) Refactor mercilessly to keep names up to date.
Things change. Classes change behavior. Aspects are added or removed. Don’t be so in love with your names that you can’t change them when they’re no longer appropriate. Many modern IDEs have excellent refactoring support, allowing you to safely perform renames and automatically take care of updating references.

Whatever you do, don’t let names get out of date. There’s nothing worse than trying to make sense of unfamiliar code when the names don’t align with the functionality. Keep in mind that even though you may have a great understanding of the codebase, the newcomer to your team, the future maintenance programmer, or yourself down the road won’t necessarily have that same understanding.

Here are a few other things to keep in mind:

Good names should be unique, or close to it. This is especially important when you have a large codebase and people will often open types by doing a search (ctrl-T in Eclipse) by name. Here’s where that thesaurus comes in handy again. It should be relatively easy to come up with a name that’s unique enough to not get confused with other names that are important in your system. Here’s an Eclipse-specific tip: you can tell Eclipse to filter out certain packages when searching for classes by name. For instance, if you are not a Swing/AWT programmer and don’t want to see java.awt.List come up every time you search for “List”, you can filter out the java.awt package. Go to Window -> Preferences -> Java -> Appearance -> Type Filters.

As you name things in your codebase, you’re creating a taxonomy and a common nomenclature for your team. You will have to refer to these things by name to your team members, and they will come up in discussions, design meetings, support issues, etc. Are you choosing names that make sense in this context? Sit back from the keyboard for a moment, and try to talk about a class or several classes in complete English sentences. Assuming this works, many of those words you used are great candidates for names in your system. Choose names that are close to your domain and express what you’re trying to accomplish. A great name is better than a weak name with a large comment block that attempts to explain the role of the class.

A great book to check out along these lines is Domain Driven Design by Eric Evans. The book talks in great detail about focusing the development process around the concept of a strong domain. Choosing good names is a part of that.