Knock Knock. Is there any programmer here?

[Tom_Hagen]

It often happens to me that I participate in a programming projects. Some of them last several months, are multi-threaded, require numerous consultations, analyzes and subsequent actions that are not entirely predictable. The result is a program consisting of many classes, functions, etc. The problem that I cannot fully solve is the granularity and precision of subsequent actions. The task: Write an XYZ program is too amorphous, while granulation at the level of classes or even their functions will result in hundreds of subsequent actions. I'm looking for some "golden mean". On the one hand, I don't want to get bogged down in details, on the other hand, I would like - by scanning the list of next actions - to have quite precise information about what I should do when programming. Does anyone have any experience in this regard?

PS. I suspect there are more professions with such problems: e.g. architects designing complex buildings, etc.

 

[mcogilvie]

I have often found that the best approach for me is to focus on a particular section or module and find a next action to act as a starting point in working on that section. This seems to work whether I am writing code or writing manuscripts: figure out a sub-goal, and figure out a reasonable place to start. An example “Revise section 4: fix logic of symmetry argument.” The key is that I do not list all the actions I may take on section 4, just a starting point. I often have annotations that note things to be worked on, but those mostly do not become actions on a list.

 

[Oogiem]

I would like - by scanning the list of next actions - to have quite precise information about what I should do when programming. Does anyone have any experience in this regard?

My system is a work in progress. My big programming projects have fairly well defined sections or modules. There are 6 main apps and the database schema. Within each app there are sections for certain functions. I have a project note in Obsidian for each app and the database and within that I have sections for the bugs or features I need to work on within a specific functional area. So I can fold the list and see the sections where I have stuff to do in the broad view or I can drill down and see the individual tasks. I typically pick an area to work in and try to knock out all those tasks in that area when I am in the context of programming mode. Here's a simple part of the task tree for Registry Web Interface for the Transfers function. In my case they are all pretty much independent next actions in that one does not depend on another. So all that are available are #tasks The code here is markdown

## Transfers Screen 2 New Member - [ ] #task In Transfer screen 2 make mandatory the required fields and show an error to ask for full info #Context/AnimalTrakker Use the validate in transfer if exists and use regex to get it correct see other useage - [ ] #task If the same mailing address box is checked need to fill in the info from the fields above and track if it changes. #Context/AnimalTrakker - [ ] #task In transfer screen 2 need data validation for proper format for post code #Context/AnimalTrakker - [ ] #task In transfer screen 2 need data validation for proper format for email #Context/AnimalTrakker - [ ] #task In transfer screen 2 need data validation for proper format for websites #Context/AnimalTrakker ## Transfers Staging File - [ ] #task **Bug** Missing the key for the buyer either an id_contactid or an id_companyid #Context/AnimalTrakker #Context/Bug - [ ] #task **Bug** Coat color coming in as unknown even when there is a correct record in the animal_genetic_characteristic_table #Context/AnimalTrakker #Context/Bug - [ ] #task **Bug** Need id_premiseid for the new owner added to the staging file #Context/AnimalTrakker #Context/Bug

 

[cfoley]

This is what I currently do:

In my projects list will be the overall outcome I am trying to achieve. eg:

• Program to do this amazing thing in production.
• Feature for that fun thing in production.

For me, the wild success outcome for writing software is that users can use the software, or at least that the software has been handed over to my clients. It's not just about writing code.

My next action list will typically contain one thing for that piece of software. I keep it at quite a high level but the main idea is that it is a reminder of where I was when I last stopped. If the next thing to do is a large chunk, then I will name that large chunk. If I was in the middle of something, I will write the detail I need when I come back. There is no specific formula. Examples include:

• Write the file parser for feature X.
• Feature X: Finish validation and error handling for field Y in the file parser.

Next, I try to maintain one file in Obsidian for each GTD project that involves code. In that file I will include:

• A list of all the outstanding work that I know about.
• Any terminal commands that are useful for working in the project.
• All emails between me and my client about the project, each one edited to be succinct, and continually edited so that obsolete details are removed. I include enough information to find the originals in my email client.
• Any other notes that might be useful to the project.

This file changes all the time. The goal of this file is not to serve as an audit log but to help my progress going forward. I will add information as I become aware of it and ruthlessly delete anything obsolete.

Finally, I have a pad of paper beside me to take ad-hoc notes as I am working. This lives in an Action Support folder on my desk. If I keep anything written down for too long then it makes its way into my Obsidian file.

 

[sdati]

For me, I am working within the context of larger organizations that have their own processes and tracking tools (Jira or similar, maybe some higher level product/project tracker, document system for design documents, etc.) for work. Since there are a lot of other people involved, I don't try to go overboard with integrating GTD to those systems, and generally keep things higher level - e.g., I will frequently have a project list for the major projects I'm involved in. Then sometimes next actions related to those projects that are not already defined in Jira - these are the less well-defined pieces like "determine how component X will interact with service Y" or "research if there's a common interface that can be extracted between services A, B, and C". Otherwise for a given project the next action is usually just "check what tickets are available for work in project X"

I also frequently use a waiting-for list and an agendas list - what lines of communication do I need reminding of, because I'm waiting on somebody else to give me an answer, or some small idea came up that I need to remember to bring up during a weekly meeting but it's not so important or relevant to interrupt people with right now. This helps me keep on track and not allow projects to fall behind when I'm blocked by someone else's work.

And I always have a someday/maybe list of cool new technologies to look at, and ways to refactor existing code or projects to improve them (some of these things are also captured in Jira or other tracking systems, but I frequently have ideas that don't rise to the level of sharing with the rest of the team because they're not fully formed; just random thoughts that I want to spend more time looking into)

 

[bishblaize]

Yeah this is a problem my best friend came across when trying out GTD. He's a data engineer of some type. As he puts it, he only has about 2 or 3 projects at a time, but each project has about 100 Next Actions at any give time. Many of those NAs have critical dependencies that he can't identify until he actually starts working on it. Plus of course they're all at a computer. So the classic paradigm of Projects with Next Actions divided by context is just a not a good fit.

I think the conclusion is that GTD is just not right for all types of work.

 

[cfoley]

My solution to that particular problem is put all those interdependent "Next Actions" in my project plan and select 1 or 2 for my actual Next Actions list.

 

[mcogilvie]

Yeah this is a problem my best friend came across when trying out GTD. He's a data engineer of some type. As he puts it, he only has about 2 or 3 projects at a time, but each project has about 100 Next Actions at any give time. Many of those NAs have critical dependencies that he can't identify until he actually starts working on it. Plus of course they're all at a computer. So the classic paradigm of Projects with Next Actions divided by context is just a not a good fit.

I think the conclusion is that GTD is just not right for all types of work.

I think a lot of people get hung up on the context list idea. It works for a lot of people a lot of the time, but it’s not the essential core of GTD. In my daily life, the five phases of workflow are much more important. It’s also what DavidCo showcases on their website. Beyond that, there’s a lot more: the natural planning model, the horizons of focus, all the great material in the Ready for Anything book. Although I do use contexts (as tags), my life is such that I don’t filter by context much.

 

[Oogiem]

Many of those NAs have critical dependencies that he can't identify until he actually starts working on it. Plus of course they're all at a computer. So the classic paradigm of Projects with Next Actions divided by context is just a not a good fit.

My solution is look at contexts more granularly. For example I'm moving some critical things to a context of Bugs. I'm also exploring contexts for the section or area of code where they occur or need to be fixed by module name or package or whatever makes sense in my IDE. Once I'm already working there I can often clean up all sorts of things at the same time.

 

[Tom_Hagen]

Thank you very much for all your answers. From what I see, most of the answers match my practice. I don't entirely agree with @bishblaize. I think GTD fits everywhere - it's just more challenging to implement in some situations. We all know the standard example of changing a tire - these are simple to implement situations. Some - especially in hmm... more creative professions - require rethinking. In programming, the problem comes down to two things: we need to have a list of things to code - as mentioned by, among others, @Oogiem or @cfoley and often such a list is both reference material and a list of next actions or its inspiration. We do not move some items directly to our list of next actions because they fall under the 2-minute or more-minute rule (Allen set 2 minutes arbitrarily, but he admits that for other people it may be longer). In my opinion, regardless of whether someone consciously uses GTD or not, they still have to follow the same rules - sometimes just in a very ineffective way. If we do not use GTD, we store amorphous ideas in our heads and when we take action, we still have to clarify them and divide them into subsequent actions. But with much more effort and the risk of forgetting something.
I also agree with @Oogiem about contexts. When Allen wrote the book, there were no smartphones, remote work was not that popular and the last dinosaurs lived in the world Hence, the contexts were closely related to the physical place and device. In my opinion, the emphasis today falls not so much on the physical place, although it still counts (e.g. office, errands) or device, but on a certain abstract concept connecting several "ancient" contexts. Take, for example, reading a book on Kindle. I have a reader, I have an application on my smartphone and on my computer. I can have the following contexts: computer, smartphone and reader. Or I can combine them into one: Kindle under which the three above will be included. The context may also be a certain thematic area: the application we are writing, the room we are renovating or a group of people we meet or work with. The beautiful thing about GTD is that it is so flexible and unorthodox that it can be used practically everywhere.

Thanks again for all your replies.

 

[gtdstudente]

Thank you very much for all your answers. From what I see, most of the answers match my practice. I don't entirely agree with @bishblaize. I think GTD fits everywhere - it's just more challenging to implement in some situations. We all know the standard example of changing a tire - these are simple to implement situations. Some - especially in hmm... more creative professions - require rethinking. In programming, the problem comes down to two things: we need to have a list of things to code - as mentioned by, among others, @Oogiem or @cfoley and often such a list is both reference material and a list of next actions or its inspiration. We do not move some items directly to our list of next actions because they fall under the 2-minute or more-minute rule (Allen set 2 minutes arbitrarily, but he admits that for other people it may be longer). In my opinion, regardless of whether someone consciously uses GTD or not, they still have to follow the same rules - sometimes just in a very ineffective way. If we do not use GTD, we store amorphous ideas in our heads and when we take action, we still have to clarify them and divide them into subsequent actions. But with much more effort and the risk of forgetting something.
I also agree with @Oogiem about contexts. When Allen wrote the book, there were no smartphones, remote work was not that popular and the last dinosaurs lived in the world Hence, the contexts were closely related to the physical place and device. In my opinion, the emphasis today falls not so much on the physical place, although it still counts (e.g. office, errands) or device, but on a certain abstract concept connecting several "ancient" contexts. Take, for example, reading a book on Kindle. I have a reader, I have an application on my smartphone and on my computer. I can have the following contexts: computer, smartphone and reader. Or I can combine them into one: Kindle under which the three above will be included. The context may also be a certain thematic area: the application we are writing, the room we are renovating or a group of people we meet or work with. The beautiful thing about GTD is that it is so flexible and unorthodox that it can be used practically everywhere.

Thanks again for all your replies.

Thank you for your GTD post

 

[Shady Waxwing]

Yeah this is a problem my best friend came across when trying out GTD. He's a data engineer of some type. As he puts it, he only has about 2 or 3 projects at a time, but each project has about 100 Next Actions at any give time. Many of those NAs have critical dependencies that he can't identify until he actually starts working on it. Plus of course they're all at a computer. So the classic paradigm of Projects with Next Actions divided by context is just a not a good fit.

I think the conclusion is that GTD is just not right for all types of work.

Maybe your friend has misunderstood GTD's concept of next actions. If a next action has critical dependencies, it's not a next action, it's a dependent action. Putting dependent actions on a next actions list will clutter the list and his thinking when he's trying to work. If he doesn't know the action is dependent until working on it, he hasn't made the action granular enough. If he's listing 100 next actions for a project without knowing if they're dependent, no wonder he would conclude GTD isn't right for his work.

 

[Tom_Hagen]

Maybe your friend has misunderstood GTD's concept of next actions. If a next action has critical dependencies, it's not a next action, it's a dependent action. Putting dependent actions on a next actions list will clutter the list and his thinking when he's trying to work. If he doesn't know the action is dependent until working on it, he hasn't made the action granular enough. If he's listing 100 next actions for a project without knowing if they're dependent, no wonder he would conclude GTD isn't right for his work.

Hmm... Can you expand on this thought? In my opinion, the next action may be a dependent action. Let's say I need my tires replaced and my mechanic won't take anyone off the street without an appointment. Then I have a project consisting of the next two activities:
* Call the mechanic (tel. 123456) and arrange a tire replacement appointment
* Go to a mechanic to replace tires
The second action of which depends on the first one. But that's still the next action.

 

[cfoley]

My understanding is that the second action there is not a next action because you cannot do it next. It might be a future action, but the very next thing you need to do is make a phone call.

I would:

• Put "call the mechanic" on my next actions list.
• Consider putting "go to mechanic" in my project support, although for this simple project I might not have any project support at all. In fact, in this example, I would imagine that "go to the mechanic" would never end up on my actions list. Either the mechanic will tell me to bring the car right now, in which case it is work done as it shows up, or they will give me an appointment which I would put on my calendar.

 

[DKPhoto]

Hmm... Can you expand on this thought? In my opinion, the next action may be a dependent action. Let's say I need my tires replaced and my mechanic won't take anyone off the street without an appointment. Then I have a project consisting of the next two activities:
* Call the mechanic (tel. 123456) and arrange a tire replacement appointment
* Go to a mechanic to replace tires
The second action of which depends on the first one. But that's still the next action.

I agree with @cfoley-you can’t do the second without completing the first action.

The outcome of the next action, in your example, is an appointment which really goes in your calendar, so not even on your next actions list.

Granted that wasn’t the original example given at the start post, but hopefully a useful point.

 

[Gardener]

Hmm... Can you expand on this thought? In my opinion, the next action may be a dependent action. Let's say I need my tires replaced and my mechanic won't take anyone off the street without an appointment. Then I have a project consisting of the next two activities:
* Call the mechanic (tel. 123456) and arrange a tire replacement appointment
* Go to a mechanic to replace tires
The second action of which depends on the first one. But that's still the next action.

In my view, a next action is something that you can do right now. So your second action is not a next action--by my definition--at the same time that your first action is a next action. It's just an action.

Now, I do often put a second, dependent, action in my projects, so that when I finish the actual next action, the project is still represented in my action lists. Edited to add: And OmniFocus has options that allow me to hide those actions--either I choose a sequential project type, or I choose a view that shows me only the first action in a project. If I didn't have that, I would probably break myself of the habit of adding dependent actions.

But to me, for a project to have more than one "next action", all of those actions could be done right now. So if I'm going to make a frittata in two days, that project can have "Take two packs of frozen eggs out to thaw" and "Take half pound of bacon out to thaw" and "Ask Joe to get the frittata pan out of the high cabinet," and they're all next actions, because those can all be done now, and in any order.

 

[Oogiem]

In my opinion, the next action may be a dependent action.

No a dependent action is not a next action. The very definition of a Next action is th eone you can do right now next or with all the information and data you have available right now.

I agree with @Gardener It might be project support but it is NOT on my context lists as a next action.

 

[Shady Waxwing]

Hmm... Can you expand on this thought? In my opinion, the next action may be a dependent action. Let's say I need my tires replaced and my mechanic won't take anyone off the street without an appointment. Then I have a project consisting of the next two activities:
* Call the mechanic (tel. 123456) and arrange a tire replacement appointment
* Go to a mechanic to replace tires
The second action of which depends on the first one. But that's still the next action.

Good answers already from @cfoley @Gardener @DKPhoto and @Oogiem . Since you asked me I will add my personal experience that putting only next actions on the Next Actions lists has made a big difference in moving projects forward. The next action doesn't make me re-think. But if I see an item that might be dependent, I have to think and disregard that item, when I'm in the doing mode.

 

[Tom_Hagen]

The conclusion is that a person learns throughout his life. You are right.

 

[Oogiem]

The next action doesn't make me re-think. But if I see an item that might be dependent, I have to think and disregard that item, when I'm in the doing mode.

YES, That is why dependent actions do not belong on the next action list. I might see it and have to think to remember or realize that it can't be done until I finish X.