Minimize Context Switching

I very rarely get to work on only a single project at a time when I'm writing code. Normally I have a couple projects going on at work plus a few extra at home. Add in a few blog posts and bug fixes in the mix and it starts to get really difficult to remember where you were at when you sit down to start working. Most people refer to switching between projects as context switching which normally has a very expensive cost in mental resources.

However, it really doesn't have to be that way. You can minimize, and sometimes completely eliminate, the cost associated with context switching. Here are some ways I have found that has transformed my ability to work on multiple projects at once.

Minimize Complexity, Increase Clarity

Whenever I'm talking code with other beginning developers, this is the first point I start with. Complexity and clarity is one of the most difficult battles for a developer since the definition of 'complex' and 'clear' constantly changes.

Remember when reading contents a text file was difficult for you to understand? Now you can write an entire content management system in a single lambda expression. The perception of complex code diminishes over time for a developer but complexity of code never changes (too philosophical?)

The point is that just because you can understand large chunks of code doesn't mean that it isn't complex. Large blocks of code require a lot of time to read and comprehend, even if they are well documented -- which adds significant context switching costs. Here are a few of the main points I like to discuss.

• Always use clear names for classes, functions and variables -- You'll never regret naming a function employeeTotalSalary instead of just x
• Keep functions short and specific. Limit the responsibility of a function to a single purpose. If you have a function that has multiple steps, then it ought to be in its own class.
• Using named enumerated types as a return value from a function are often more clear than other responses such as booleans or nulls.

Be Consistent

Another point is to keep the way you code your project consistent. If a style of an project changes from class to class and function to function, then you can expect the cost of context switching to be dramatic.

For example, what if you chose to return 'null' in functions that encountered an error -- but for only half of your project. Then, the other half of the project you threw exceptions. Each time you opened that project you would be forced to read code and remember all of the little details for each class and function you were working with.

On the other hand, if you were consistent with your approach, then after the first error you encountered you would remember how to deal with the rest of the project without needing to open a single file.

• Be consistent with your approach to handling errors, passing arguments, cleaning user input.
• Remember the 'DRY' Principle -- Repeated code leads to inconsistent code. If you're doing it more than once then you need to move your code into a single, well named function.

Test Driven Development

I'm not a huge advocate of Test Driven Development - I don't think it solves nearly as much as many people suggest it does. There is a lot more to if an application is working than a series of tests can prove (for example, a website and browser rendering issues). However, TDD can go a long way to make you confident that your changes aren't breaking existing functionality.

Because a single change could potentially break an entire system, you can't just modify some code and then hope for the best. Instead, you have to spend a lot of time reading code and finding possible errors and then testing them.

Even if you aren't an expert at the methodologies behind TDD, using Tests in a project is a great way to minimize the context switching costs. You can focus on making a change and verifying that you didn't break any existing functionality.

• Using tests is a good way to minimize context switching because you don't need to understand the project to make a change.
• You don't need to be an expert to write tests -- Just spending an afternoon researching TDD can go a long way

Don't Stop Here Though...

Context switching is a difficult thing to deal with, but reducing complexity and improving your confidence in a project is a great way to make switching between projects easier than before.

These are just a few ideas that I wanted to type about tonight. I have a lot of other suggestions that I share with developers that I've learned over the years. Additionally, there is a lot of great information about managing code complexity on the web.

If you aren't doing anything to reduce the complexity of your projects then you can always expect your context switching time to be a difficult transition -- but the good news is that it doesn't take much to reduce that cost and make your life easier.