GTD and Computer Programming

[cfoley]

Programming has been my hobby for as long as I can remember. It's a large part of my day job, I moonlight as a freelance programmer and I have several hobby projects. However, I can't seem to organise the projects and actions into my GTD system in a way that helps me.

Software codebases generally have desired features and bugs (collectively issues). Some issues are quick and easy. Others will take several steps and resolving most issues will uncover more actions or even new issues. This sounds a lot like GTD projects and that is how it is currently implemented on my system. This leaves the question of what to do with contexts. At the moment, I have @Work Code and @Code Personal (which includes my freelance work). I find these to be insufficient.

The nature of my work means that I manage multiple codebases. Some are huge and are nearly a decade old. Others are tiny and short-lived. I don't want to create a context for each since there would be an explosion of contexts, yet I think that may represent the reality (one of the biggest complaints of software developers is context switching).

An option I might explore is to use issue trackers for all my projects. I have that for some codebases already and I'm thinking it might be the best way to go. However, I don't know what my context and action lists would look like then.

Any thoughts or ideas?

 

[Oogiem]

I'll offer several ideas and then tell you what I am doing.

Do you use different development environments for the different codebases? Currently on LambTracker I use both Eclipse and Netbeans for different pieces of the code. So I can sort my contexts into those two options if I choose to. I also have 2 different machines I use and so that is a way to sort them as well.

Another way would be to sort by basic module. Again for me I have database stuff, handheld stuff and desktop stuff. Perhaps you can make contexts by module?

Finally is the code used in a specific place or time? In LambTracker there is a natural division of stuff to be used in the fall, Sprin, Summer and Winter. SO I can focus on tasks related to the

With those as options here is what I am doing:

First I keep the software development tasks outside my main GTD system.

I set up a separate machine that is the main development machine with both development environments on it. I Use the second machine as a backup and when I need to look at 2 different module at the same time. The "How did I code that over there so I can adapt that same code for here" type questions.

I have my issues sorted by module. Mine are simple 3 inch square post-it notes, 1 issue per note. My modules are plain pieces of paper labeled with the module title onto which I post the notes. Some modules have several pages and I sometimes layer the notes on them.

I work by module usually based on what module I need to do whatever task is coming up next for the sheep flock. That by default makes it by time so right now I am debugging tasks associated with mating plans, breeding, collecting insemination data, semen counts and related functions. I am actually hitting several code modules, sheep management, set and remove alerts, create ram breeding record, create ewe breeding record and evaluate sheep but the tasks are all related to the same flock function. As soon as that task is done with the flock I'll stop development in the those modules and move to the next flock tasks. Before I move on I document what issues remain, what thoughts I have on it and try to update the user manual/novel with how my fictional shepherds used LambTracker to do the same tasks I am using it for.

Not sure if any of this will help you with your development tracking but that is how I am doing it.

 

[cfoley]

Thanks for the great reply. My setup is slightly different from yours. My code lives in a central repository and I can check out a working copy for any project on any computer I use. I set up a seperate Eclipse or Visual Studio environment for every working copy. This works for me very well as it doesn't tie me to any particular hardware, operating system or even location. I have been known to check out two working copies on the same computer just to set up two different environments.

My coding isn't seasonal in the same way yours it. At work, I have a couple of big projects that are all ongoing and have been for years. Most of the work is in the form of new features that each have their own deadlines. Because these projects have been going so long, they generate a lot of someday-maybe feature ideas, desired refactorings, minor bugfixes, etc. These are conceptually different to me than features that come in via requests form clients or my employer. Some are things I would like to do opportunistically as I work on something else (refactorings and minor bugfxes). Others are things I want to suggest as future features.

My freelance work is quite sporadic. Projects will lie dormant for a long time until some thing comes in. It's a healthy mix between new utilities and features for old codebases. The sporadic nature has been problematic for me in terms of GTD. Often I don't know if the someday-maybe list is something I should keep. It will only be needed if the client reacitvates the project.

My hobby projets often get neglected since I have other demands on my time. However, it is very important to me both in terms of personal satisfaction and probessional development. For example, I want to set aside the time to learn Prolog since I think I can learn a lot from its programming model. For fun I want to write a program that animates the object graph of another running program. Both of these would be valuable for different reasons but it's difficult to make the time to do them.

I find it interesting that you uses paper and post its for your issue tracker, and that you keep your code issues outside your main GTD system. Do you also have a placeholder in your GTD system?

 

[Oogiem]

My code lives in a central repository and I can check out a working copy for any project on any computer I use. I set up a seperate Eclipse or Visual Studio environment for every working copy. This works for me very well as it doesn't tie me to any particular hardware, operating system or even location. I have been known to check out two working copies on the same computer just to set up two different environments.

What a cool idea! My coding is a work in progress. I do keep all code up on Github so it is in a separate repository. I am not very good at checking out or creating branches like I should for different features as I still don't quite grok Git. My husband uses it a lot so that is why I am using it, it means he can do work on the code as well but usually only when it's something that is talking to the hardware. I never even thought about making separate working environments for different projects or parts. That might really help right now for me when I am overwhelmed with stuff to do and stuff I want to add.

At work, I have a couple of big projects that are all ongoing and have been for years. Most of the work is in the form of new features that each have their own deadlines. Because these projects have been going so long, they generate a lot of someday-maybe feature ideas, desired refactorings, minor bugfixes, etc. These are conceptually different to me than features that come in via requests form clients or my employer. Some are things I would like to do opportunistically as I work on something else (refactorings and minor bugfxes). Others are things I want to suggest as future features.

I'd separate those into different lists. The paid for work gets a different context compared to the be nice to do work. I'd also separate out features from bugs from code clean-up. I tend to focus on bugs first, then code clean-up then add features. I also do a feature freeze before each major flock task if I have the module working "good enough". No code ever survives first contact with the sheep. From bad button placement, to bad workflow issues, to too much for the user to do while holding a wriggling sheep, I've always had something not work right whenever I introduce a new feature or new module or task. So for me getting something I think will work, getting it out there and testing it and then coming back in to try to fix the issues (sometimes while sheep are standing in the chute) has been critical. I've even been known to take my main development computer out to the sheep chute and work the problems right then and there. That rapid step-wise refinement of the code is something that GTD and even most code systems doesn't handle really well.

My freelance work is quite sporadic. Projects will lie dormant for a long time until some thing comes in. It's a healthy mix between new utilities and features for old codebases. The sporadic nature has been problematic for me in terms of GTD. Often I don't know if the someday-maybe list is something I should keep. It will only be needed if the client reacitvates the project.

I've got separate paper file folders for each potential future revision of LambTracker and then I put my post-it notes for future features into those folders. For example right now I am on Rev 3 of LambTracker. Rev 1 was proof of concept, rev 2 had a poorly designed database and rev 3 is the first real functional one. I didn't want to deal with 0.x revs and consider nearly everything beta code so the numbering works for me. I already have a Rev 4 and a Rev 5 folder of stuff. In Rev 4 the plan is to add genetic calculations for Wrights inbreeding, coefficient of relationship and Ward's clustering by distance. Rev 5 is going to be adding tools so LambTracker can run a sheep registry, creating and printing registration papers with pedigrees and managing ownership histories. I often get ideas about those areas now but I can safely write them down and put them in the proper folder and forget them. My equivalent of the someday/maybe list.

My hobby projects often get neglected since I have other demands on my time. However, it is very important to me both in terms of personal satisfaction and probessional development.

I'd put those things under a separate AOF, Personal Development, and probably actually include them into my main GTD system as they are learning not coding. I put my learning Java, SQLite and Git, all ongoing projects, into that in my GTD system. While I learn by coding they are really not part of the LambTracker development per se. I just use LambTracker as the vehicle to practice the stuff I am learning.

I find it interesting that you uses paper and post its for your issue tracker, and that you keep your code issues outside your main GTD system. Do you also have a placeholder in your GTD system?

I found I needed the feedback of taking a red pen and writing DONE across a post-it note or I felt I didn't accomplish anything. Especially when some tasks can take me days to actually code I really appreciated the more tactile checkoff compared to clicking a box in Omnifocus. Not sure why, I hate paper for the rest of my GTD system but it's working for this.

I do have projects in my GTD system for some parts of the development but not all. For example right now I have a project LambTracker Database and an action in there is Update the demo database with the new tables created for breeding. Another action is create a checklist for adding new tables to demo database and verifying old ones. Those are sort of ancillary to the code working and seem to fit ok into my GTD system. The documentation project is totally within my standard GTD system. It's writing the user manual. I have major tasks in Omnifocus but the manual itself is being written as a novel in Scrivener. I have next actions related to writing scenes or chapters that explain why you might choose this or that LambTracker option or how to set things up and then do the work. In a few cases I've written the scenes for my fictional shepherds using LambTracker and in the process of writing the scene discovered that my planned way to do it in the program wouldn't work in practice so changed the code to match the manual. A somewhat different way of dealing with writing code I think.

I also have a project for LambTracker Mobile and an action under that is try to figure out how to make an adjustable table in XML for sheep evaluations. It's something that I need to do in lots of places but also I can get away with the system the way it is now so it's not a bug but not quite a feature either. For some reason that more learning task seems to fit in my GTD system rather than in my paper issue tracker.

I have a project LambTracker Historical Data Input and actions include making spreadsheets to enter in all historical flock data and Add all past sheep drug records. Those are more user or flock management things not coding though. Again, they fit into my GTD system easily so that's where they are.

Not sure if my ramblings made any sense to you but maybe you can glean something useful from them.

 

[cfoley]

What a cool idea! My coding is a work in progress. I do keep all code up on Github so it is in a separate repository. I am not very good at checking out or creating branches like I should for different features as I still don't quite grok Git.

This is exactly how I started. I use git from the command line which keeps things low-level enough to learn how it works. The utility gitk shows a nice graphical diagram of your commits and branches. Updating the display as I use git helps me understand what's going on. To show all branches and let you keep using the command line:

gitk --all &

I use this workflow. It's designed for groups but I find it works really well for this lone developer:
http://nvie.com/posts/a-successful-git-branching-model/

I'd separate those into different lists. The paid for work gets a different context compared to the be nice to do work. I'd also separate out features from bugs from code clean-up. I tend to focus on bugs first, then code clean-up then add features.

Haha. Changing requirements has made all of it legacy code! But yes, I agree bugs should be fixed before features whenever possible. I'll try keeping them on different lists but wonder if that will make the "nice to do" work forever on hold.

No code ever survives first contact with the sheep.

I love this. Do you mind if I borrow it?

So for me getting something I think will work, getting it out there and testing it and then coming back in to try to fix the issues (sometimes while sheep are standing in the chute) has been critical. I've even been known to take my main development computer out to the sheep chute and work the problems right then and there. That rapid step-wise refinement of the code is something that GTD and even most code systems doesn't handle really well.

I also love this. Talk about eating your own dog food!

I've got separate paper file folders for each potential future revision of LambTracker and then...

I have an amorphous mass of notes, ideas and scribbles. In the absence of anything else, I'll try reorganising it along the lines of your system and see how it works out.

I'd put those things [hobby projects] under a separate AOF, Personal Development, and probably actually include them into my main GTD system as they are learning not coding.

I'll give this a shot too. They certainly aren't getting completed where they are now.

Thanks for another detailed reply. It's very helpful and the examples really make your points clear.

 

[Oogiem]

I'm using the GitHub application on the Mac to do most of my stuff. I tend to get totally lost in the command line so try to find other ways to do stuff when I can. My husband is on Linux and command line all the time so sometimes we don't exactly communicate well.

My husband found this set of podcast things and said it really helped him. They are now in my GTD system as an action of make a list of episode to listen to in order and then do it.

http://www.gitminutes.com/

Feel free to borrow the sheep phrase, that and "sheep happens" get used a lot around here I do think the fact that I am both a user of and the writer of the code makes a difference. No need for detailed collection of user requirement data, Get it running go try to do the task and suddenly discover that stuff doesn't necessarily work well. When I was coding for other customers getting what they really wanted/needed written in a way we could work to was always a hassle. At least with LambTracker I am the user and I know what I need to do and just have to figure out how to make the program help me do it.

 

[cfoley]

I think I have achieved some clarity on this.

I am rereading Making it all Work. Near the start, David Allen says the calendar is a great example of a list that relieves stress for one aspect of our lives and that we need lists for other aspects of our lives -- as many lists as it takes.

In a simpler existence, I might have one codebase to maintain. I might spend several hours a day working on it. Any programmer will tell you it's a huge mental adjustment to switch from coding to other tasks, even other tasks at your desk such as email. The language used is "context" switching, and I don't think it's mere coincidence that the same terminology is used in GTD. Programming is a context, one I might call @Coding.

Back in the real world I maintain several codebases but I am trying to shoehorn them all into @Coding because the kinds of tasks are similar. The problem is that going from one codebase to another is an even bigger mental shift than from going between code and email. I know this intuitively because I don't constantly jump between projects. Each codebase is its own context. This obviously gives me more contexts than most but that reflects the reality of my life.

One thing that was confusing is codebases becoming active and inactive as my freelance and hobby work ebbs and flows. I'm happy to add and remove contexts in other aspects of my life. For example, I attend two three-day martial arts seminars regularly each year. I always have some things to take care of so I create a temporary context. It should be the same for codebases. I should add and remove their contexts to reflect the changing circumstances of my life.

Another failure I was making is that I have to review my lists. I know I have to review my lists but I wasn't considering all those programming issues as items on a list. I don't know why not. It's seems so obvious now. The issue lists were going stale with items that were losing their relevance. We all know that causes mistrust of our systems.

I have also been using the wrong language to refer to the contents of the lists. Talking about programming issues is the language of amorphous "stuff". No, I need to process them properly: decide which are actions, which are projects, which are for someday/maybe and which are trash.

Programming is strange that the work is linear and each task takes a long time. I may only manage one feature a week, or a difficult feature might take longer. Lots of contexts with only a few current next actions would look pretty strange in Toodledo and might distract me from my other contexts. Organising the processed issues into an issue tracker (either software or post its) might be the best way of organising these lists. But I still have to think of all the items in GTD terms.

Thanks again for all your help Oogiem.

 

[Oogiem]

I am rereading Making it all Work. Near the start, David Allen says the calendar is a great example of a list that relieves stress for one aspect of our lives and that we need lists for other aspects of our lives -- as many lists as it takes.

Re-reading that is high on my list of TTD, it's actually in the stack of books to read sitting on my desk. Thanks for the additional kick that I might really need it again now.

Any programmer will tell you it's a huge mental adjustment to switch from coding to other tasks, even other tasks at your desk such as email.

Boy is that the truth!

The problem is that going from one codebase to another is an even bigger mental shift than from going between code and email. I

I've been finding that even going from one module to another in the same codebase can be wrenching mentally. I've started sorting my tasks by module but hadn't yet made the leap into making contexts for them but it makes perfect sense now that you mention it.

I always have some things to take care of so I create a temporary context. It should be the same for codebases. I should add and remove their contexts to reflect the changing circumstances of my life.

What a brilliant solution! I add and create contexts as I need them a lot as well but just never really extended it to my programming as a conscious thing. OTOH I think that by collecting bugs, features and so on onto a single or several sheets of paper with post-it notes means I am in fact creating contexts. I tend to grab one of those module papers and work on that unless it's a specific task that I need to fix that hits several modules.

I also just realized that in Omnifocus you can put an entire context on hold aka someday/maybe and then re-activate it. HMM. Now you have me thinking that perhasp I can bring the LambTracker paper system into my main GTD system.

I've already added some projects back into OF, specifically ones about re-organizing my repositories on GitHub to implement the elegant branching model you pointed me to. http://nvie.com/posts/a-successful-git-branching-model/ That is really helpful.

I also realized that I can add a repository for my user manual and one for my query code and that too will help others working on the program. Esp. now that I've got several more shepherd/programmers looking at it.

Talking about programming issues is the language of amorphous "stuff". No, I need to process them properly: decide which are actions, which are projects, which are for someday/maybe and which are trash.

Programming is strange that the work is linear and each task takes a long time. I may only manage one feature a week, or a difficult feature might take longer. Lots of contexts with only a few current next actions would look pretty strange in Toodledo and might distract me from my other contexts. Organising the processed issues into an issue tracker (either software or post its) might be the best way of organising these lists. But I still have to think of all the items in GTD terms.

Me too, I just realized that my paper post-its haven't really been processed either. I'm treating my module papers like an inbox and an action list and a project list. No wonder it's confusing when I pick one up to work on, I have stuff I haven't clarified yet in there as well as stuff that I already have well defined and know how to proceed on.

This has been a very useful and enlightening conversation, thanks so much!

 

[cfoley]

Useful and enlightening for me too! I have just gone over it again to make sure I had captured everything, and in the process came up with an idea that might breathe life into an old project for one of my freelance clients. Thanks for being so forthcoming with ideas and comments.