Working on multiple unrelated tasks and code reviews

Question

When I'm developing, I like to jump back and forth between doing 2 (or more) things at the same time, even if those things are unrelated. I am able to get my mind focused very quickly, so "warm up" time isn't a concern for me. The reason I like to jump between two tasks is that I often find that I can solve problems faster that way.

The downside to this is that I end up completing the two tasks at the same time, and when Code Review comes around, I find myself having to explain two separate ideas to the reviewer. Also, the reviewer must view more code each time I ask for a review than if I were to do one task at a time.

Do you have any suggestions for helping me maintain my preference of jumping between tasks while making it easier on the reviewer?

Some options I've thought of so far are:

1. Make intermediate check-ins, even if the functionality is incomplete. (tracer bullet code)
2. Try to work on tasks that have a clear separation of source files, so that code can be delivered independently.

Answer 1

Both your suggestions are good.

I'd also suggest actually measuring your productivity jumping around like that; it probably won't be as good as you think. I'm prepared to think you could be right, but do actually test your assumption.

Answer 2

My suggestion: Have two separate checked-out copies of code, two IDEs, etc.

Regardless of how good you are in your head at keeping them separate, it undermines some benefits of SCM if you are doing this:

• If you check in a fix (or new feature) for two issues in one checkin, you are making it much harder to revert one of the issues, or for example, merge the fix to another branch without copying the feature. As you point out, you're also making it difficult for code review, and it will also make it harder in the future if something breaks as a result of your code, because now someone may be unsure of which issue that piece of code is related to.
• If you are checking in incomplete functionality, that could break the build. It also again, makes it harder to trace back in the future.
• Even with clear separation of source files, by doing two unrelated changes at once, you are introducing the possibility that there is some interdependency -- so while the code may work with both issues, it may fail if either one or both code changes are there by themselves.