Actions for Programming/Development

H

High

0
I have used GTD for a while now, and have experienced that it helps me, but I haven't found the "GTD flow" yet, but I'm trying. I'm moving to have GTD handle all my inputs, including my work as a web developer.

One problem that I have is that often I have actions that looks something like this:

"Fix the occurring transaction bug in library X"

This is not a good action because it is not well defined. I mean that it is done when the bug is fixed, but I don't know the timeframe for the action. This makes me don't want to do the actions because I don't know when I'll be done with it.

Do you guys have any tips in how to define this type of actions?

// Johan
 
Where I work we've found that it's impossible to put a time estimate on a bug we haven't investigated. In which case your next action is probably "Spend 15 minutes investigating and estimating the the occurring transaction bug in library X".

One outcome is that you might estimate it needs another 2 hours investigation before you can estimate the fix time.

Depending upon your role and team you might have to estimate for the fix, writing unit tests, getting peer code reviews and putting it through change control and QA before closing the bug.

In GTD terms, that's a project. But with several products and databases of hundreds of bugs, I don't track them as GTD projects or I would explode. Where I work, we are developing on a scale where we use a bug database with a defined work flow that all the developers use. Thus I don't GTD my bugs, as they already have a defined process.

I have however used the "Spend 15 minutes investigating X" over and over again to great effect!
 
Is there a series of steps that you usually go through to fix certain types of issues?

-check thing A
-check thing B
-if thing A and thing B are okay, talk to Bob about what to check next

Something like that?

Or if you're not sure, if you can force yourself to write EVERYTHING down you do on one of your similar tasks, then you know for next time. Then it's just a matter of repeating it and tweaking it.

I'm struggling with this at my work too. I've tried in the past to implement GTD in my personal and work sphere's all at once in the past and given up. Twice that I can think of.

This time, I've got it going pretty well for my personal stuff and I'm SLOWLY seeing what it will look like to implement it at work. I'm really good at keeping my inboxes empty there (not so much at home). But I struggle with the facet of my job that's similar to what you asked about. The repetitive projects that all always get done, but I haven't had a clear idea of all the steps. When I set them up in a digital GTD system in the past and the system was telling me that I "had to" do all the steps and they kept adding up and adding up because I didn't get to them (I had built the projects with all the ultimate 'nice to' steps, not just with the 'need to' steps), I folded. This time at work I'm still using paper and I'm just doing my regular projects the way I do them and they're getting done. But I'm recording what I'm doing so that when I'm ready, I can let GTD help get me to the 'nice to' steps.

Probably a bit too much on me and my issues, but realizing that the 'system' doesn't have to be perfect from day one, and that time to let it grow and evolve is good/expected was very helpful to me.
 
For me, "Fix the occurring transaction bug in library X" is a Project. My Actions are closer to:

Search header_include.h for orphan macros
Add case for "RX-78" to switch block in device_handler()

Very specific.
 
High;76318 said:
One problem that I have is that often I have actions that looks something like this:

"Fix the occurring transaction bug in library X"

This is not a good action because it is not well defined. I mean that it is done when the bug is fixed, but I don't know the timeframe for the action. This makes me don't want to do the actions because I don't know when I'll be done with it.

Do you guys have any tips in how to define this type of actions?

// Johan
Click to expand...

I'm a software developer, too. I often track defect fixes as projects and use established defect tracking and management practices in our IT shop. Processes aside, the action that you've posted is really a project, and it's not considered resolved until the fix has been implemented in the level of testing in which the defect was reported. So, if this transaction bug is in your production environment, the "project" is not done until a fix is implemented into production.

Think of the next action as a bookmark. If your life purpose revolved around fixing this defect, where would you go and what would you do? Assuming you have the latest source code on your developer workstation, the next action might be "Debug transaction code in library x" (i.e. running the application in debug mode) or "Analyze transaction code in library x" (open it, review it, see if something jumps out at you). Or maybe it might be "Download latest production code for library x from source control".

Often times when I'm working on software I don't define every single action and put it on a list; I fly by the seat of my pants after the first action. At the end of the day or when I know I'm not going to work on the project anymore, I define a next action as my bookmark for tomorrow. I also do that at Weekly Review time.

In short, don't worry about precisely tracking every action you make on a software project; track the project and bookmark at least one action that you can perform when you're ready to set it aside for the day.

I hope that helps,

-Luke
 
High;76318 said:
"Fix the occurring transaction bug in library X"
Click to expand...

For me that would be a full project. I agree that it's not a clear action.

It's been a while since I dealt with computer bugs instead of insect ones but for me I'd have things like:
Find source code for transaction subroutine and check out of development system
Write shell program to call transaction subroutine to duplicate bug
Write tracer code to follow transaction writing system and so on.

IOW I'd spend a bit more time figuring out exactly what I do to trace and fix a bug like that and use those as next actions.

I also agree that making a bug fix checklist would be a good idea. Keep adding to it as you develop faster methods of dealing with the bugs over time.

Now in my current life my usual next action for dealing with bugs is actually written like this:

Get ivomec dewormer and drench pregnant ewes for nose bots

A whole lot easier to define and track ;-)
 
I am not a programmer but i have similar experience when i was doing on going projects. things keep coming in and changing so fast that inputing steps in digital list is clumbersome and time-consuming.

So, my method is very simple. i write the steps out on a piece of paper. when finish a step and i crossed it off. if there is any changes and update, i just scribble on it. that way, everything is recorded and not to be forgotten. :)

by end of the day, when the work is finish (or your working hour is done), track it in your digital list :D

i find doing this way is more productive. at least for me :)
 
I am a programmer. This is what has worked for me when I get one of those 'fix this' projects (even though every one above me thinks they are tasks)

I do treat them as projects, but unlike my more traditional development projects, I don't know all the steps. And I do not worry about that. What I put on my NA list is just the very first thing to do. Where I work, that is often "find out how to reproduce the problem', which may in some cases, turn out to be a sub-project of it's own, or it may just be reading the attachment.

Again, I don't worry if what I thought was a next action turns out to be a sub-project. If I figure out there's going to be more than one step, well, that is one thing learned, and if my lists are current, and my schedule free, I just start working the steps. If there is more to do than I can do now, I write down the next action, and note the actions that follow it in my project notes.

I keep all my project notes in a Circa binder, so I can move notes around. I may use scratch paper if I expect to complete all the steps, but if I have to leave the project for something else, the scraps go into the binder.
 
I like the idea that the next action is a bookmark. It sounds natural. I think that I need to loosen up the idea that a action needs to be totally well-defined, and just add actions as they come along.

Then, a process for handling problems sounds like something i may need to look into for personal use. Now, I'm the only developer so Bugzilla and whatnot sounds overkill at the moment.

I'm just afraid that I'll never trust my GTD-system :/
 
High;76318 said:
One problem that I have is that often I have actions that looks something like this:

"Fix the occurring transaction bug in library X"
Click to expand...

I agree that that's a project, not an action:

Project: Fix the occurring transaction bug in library X

I might work through the following actions, though I wouldn't have them all planned in advance:

Next Action: Find and re-read Joe's email reporting transaction bug.
Next Action: Call Joe for more details about circumstances of bug. Get date of occurrence.
Next Action: Try to obtain data set that was current when bug happened.
Next Action: Schedule access to test system.
Next Action: Try to duplicate bug in test system using historical data set.
Next Action: See if bug occurs with previous delivery.
Next Action: Spend twenty minutes brainstorming possible causes for bug.

If the original action was in a larger project, I would rephrase the action in that project to

Next Action: WAITING FOR: Completion of "Fix the occuring transaction bug in library X" project.

Editing to add: I quite often have a Next Action like:

Next Action: Create a project for fixing transaction bug in library X.

My context for these is "meta", since they're GTD actions about creating GTD actions.

Gardener
 
High;76406 said:
I'm just afraid that I'll never trust my GTD-system :/
Click to expand...

I certainly appreciate that!

Your mind needs time to adjust to this new way of doing things. It won't trust a new system on day one; it needs evidence. Provide that evidence, and your mind will relax.
 
Brent;76446 said:
I certainly appreciate that!

Your mind needs time to adjust to this new way of doing things. It won't trust a new system on day one; it needs evidence. Provide that evidence, and your mind will relax.
Click to expand...

Yes, and that can take several weeks. Just keep working the habits. My mind didn't trust my system for an entire month because it was so used to holding on to stuff.
 
You must log in or register to reply here.
Top