I do web app development and bash scripting and I usually work on several projects at once in different contexts and languages and often return to a project after a few months absence.
When I return to a project there are always fragments of code that are incomplete and I have trouble "re-familiarising" myself with what I was doing and what I was trying to acheive.
I use version control and can look at the history, but that only gives a backward look at what happened in the past.

Regarding outright breaking code

I use version control "topic" branches to isolate any code that outright breaks functionality, Im more struggling with trying to understand the state of affairs of the little bits of incomplete, but "non-breaking" work.

Does anyone have any suggestions on how I might manage these items in a "forward looking" way? , possibly along the lines of

  • TODO's
  • issues in github/bitbucket
  • commenting out code
  • have the code run an alert - in the app - to say I need to be finished
  • write unit test definitions which explains what you are trying to achieve - even if the unit test wont be written till later
  • etc

Each new feature should have an issue in your tracker. Whenever you're working on the feature, keep the issue open in a browser window.

Before you start work on the feature, map out what you think you need to do to make the feature work. Check them off (but don't delete them) as you complete them. Keep adding to this list when you see new things, before you start coding.

Some issue trackers let you track to-do items or even nested issues. Use whatever's appropriate to the scope, but remember you need to be able to quickly drop in and add your todo in the issue.

That way when you return to the issue you can see progress, outstanding work blockers, etc. at a glance before you decide to restart, without you having to dig up your code and analyse it.

Other things you might consider:

  • git hooks which will look for the string "todo" and refuse to commit if any are present
  • See if your testing suite supports to-do items like Perl's Test::More
  • write explanatory code comments and commented-out code lines differently so you can grep for them separately (e.g. make all your comment lines begin //:: or #~)
| improve this answer | |

The best way to manage such incomplete changes/additions is to avoid having them in the first place. Try to make your features small enough that you can completely implement them in the time span that you are typically able to work on a single project.
If you can typically work on a project for 4 or 5 hours, spread over a few days, before life kicks in or you have to switch to another project, then you should try to size your work packages to be no more than those 4 to 5 hours.

For the longer term plans you have with a project (all the work you want to do on it, but haven't got around to yet), you can use several methods ranging from a simple bullet-list on paper to a full-fledged issue tracking system. There you should just use what works best for you personally.

| improve this answer | |
  • Try to make your features small enough that you can completely implement them in the time span that you are typically able to work on a single project - requires some self-discipline but yes I imagine that will clear up a good amount of loose ends. thanks (have registered an upvote - which stackexchange should apply when I gain 15rep points) – the_velour_fog Jul 11 '15 at 6:08

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