Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm doing a full-time job (developer) and at the end of the day, I work on my part-time job (developer).

How do you work, with different projects, without loosing focus? Often, my focus on the full-time job still remains at my head when working on my part-time job or the other way around.

share|improve this question

closed as off topic by Walter, Glenn Nelson, Kilian Foth, MichaelT, Eric King Feb 10 '13 at 18:27

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

1 Answer

up vote 6 down vote accepted

IMO, the best recipe is to make a habit out of always leaving your projects in a state that allows you to drop them on a moment's notice and pick them up six months later, with very little delay. This means:

  • Work in super-short iterations - not months, not weeks, not even work days, but hours or even less. Aim for a working, bug-free, useful build after each such iteration (even if this may mean that the code you wrote in the current session is inaccessible to anything but your unit tests right now: the important thing is that it compiles, passes the tests, and doesn't break anything).
  • Document everything you do, while you do it.
  • Don't leave uncommitted changes around: commit early, commit often.
  • If you have to work on different features in parallel, use feature branches.
  • Always leave your code in a readable state. Refactor early, refactor often.
  • Write automated tests right now. Automated tests are an integral part of the development cycle, not a separate feature.
  • Be consistent. The more consistent you are, the less you have to remember - if, for example, all the getter methods in your project follow the naming convention getFieldName, and you know you can be 100% sure that there are no exceptions, you never have to look up the name of a getter.
  • Be religious about readability.
  • Design your internal APIs and libraries according to the principle of least surprise. Less exceptions means less time required to consult the documentation.
  • Use a bug tracker, wiki, ticket system, or even a plain old text file, anything that helps you organize and prioritize your thoughts. It doesn't need a lot of bells and whistles, as long as you can easily throw random pieces of information at it and retrieve them quickly and efficiently.

The central idea is "fire-and-forget": Make it so that each project requires minimum brain resources for any given task, and that as much information as possible can be outsourced to your tools - a wiki, source control, and of course the source code itself. That way, the amount of thoughts in your brain that you need to swap out when switching between projects is minimal; ideally, all you need to do is point your development environment (whether this is an IDE or a command line doesn't really matter) to the current project, maybe issue one or two commands, and you'll have all the hints you need to dive back in.

share|improve this answer
    
+1 "And this month's 'employee best suited to be hit by a bus' award goes to ... tdammers." –  Pete Kirkham Feb 10 '13 at 23:29
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.