Forum

  • If you are new to these Forums, please take a moment to register using the fields above.

Announcement

Announcement Module
Collapse
No announcement yet.

Physical next action on computer

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Physical next action on computer

    I'm a computer programmer, so most of my work involves writing code on the computer. One thing that trips me up about GTD is the idea of the Next Action being the next physical action. Is designing a function or class or writing code a physical action? It doesn't seem that way to me, but maybe I'm just thinking about it too literally. Seeing a piece of code in an editor window doesn't seem physical to me.

    How should these next actions be worded so that they describe a physical action?

  • #2
    One way to look at it is that actions involve active verbs. So "think," "design," and "write" are all actions. As opposed to "new tires," "database schema," or "first chapter," which, as nouns with no action attached, just sort of hover on your list.

    Another way to look at it is that staring at your computer screen, sketching an outline, and typing *are* physical actions: synapses in your brain are firing, your hands are moving, etc. You're *doing* something, even if it isn't as overtly "physical" as walking up the hall to talk to someone.

    Katherine
    Last edited by kewms; 07-21-2005, 07:24 AM.

    Comment


    • #3
      Physical next action on computer

      I won’t claim to be a GTD expert but I am a programmer and I have spent a long time ‘thinking’ about how to get my GTD ‘system’ off the ground. Probably more time thinking about it than just doing it to be honest. My take on how to handle NA’s in a programming context is to use them as a starting point only. I start with a list of all my projects and then I brainstorm several NA’s that I know need to happen to move each along. I typical list of NA’s might be
      · List fields with datatypes
      · Fix cmdGO on form X
      · Write function to get from X to Y

      I write these NA’s sort of as a springboard knowing that the list is not complete. I’ve found that if I try to capture every possible next action for each project I waste a huge amount of time because when I get going the work usually ends up taking me in unexpected directions. I find it’s better to just give myself a starting point so I know I won’t forget that I wanted to move forward on a given project and then let the work take me where it will. Then when I’ve reached a stopping point I go back to my project list and either add another next action (starting point) to the list or take the project off the list (if it’s complete or no longer an active priority).

      I’ve found that NA’s in coding projects are more like thoughts that I want to follow up on or explore than actual physical next actions. You couldn’t really call ‘Noodle out a way to get function A working’ a physical action, but if function A doesn’t work your project won’t go forward.

      Just my two cents … I hope others with more time using their own GTD systems will share their experience also.

      Tim

      Comment


      • #4
        Originally posted by gnu grep
        I'm a computer programmer, so most of my work involves writing code on the computer. One thing that trips me up about GTD is the idea of the Next Action being the next physical action. Is designing a function or class or writing code a physical action? It doesn't seem that way to me, but maybe I'm just thinking about it too literally. Seeing a piece of code in an editor window doesn't seem physical to me.

        How should these next actions be worded so that they describe a physical action?
        True... but writing the code is physical! Where this comes in handy is if you're not going to be writing the code right now, however, it's the next physical action required to move the project forward.

        So, when you do get around to working on the project, you look at your context list and see "write code for X function" and say, "hey, that's where I left off!"

        What helped me was to stop thinking of NA's as "to do's" and start thinking of them as "reminders". The job of the NA is to remind you that the next thing you need to do to move the project forward is to write the code... not to just give you something "to do". See the distinction?

        Comment


        • #5
          Originally posted by TimCost
          I won’t claim to be a GTD expert but I am a programmer and I have spent a long time ‘thinking’ about how to get my GTD ‘system’ off the ground. Probably more time thinking about it than just doing it to be honest. My take on how to handle NA’s in a programming context is to use them as a starting point only. I start with a list of all my projects and then I brainstorm several NA’s that I know need to happen to move each along. I typical list of NA’s might be
          · List fields with datatypes
          · Fix cmdGO on form X
          · Write function to get from X to Y

          I write these NA’s sort of as a springboard knowing that the list is not complete. I’ve found that if I try to capture every possible next action for each project I waste a huge amount of time because when I get going the work usually ends up taking me in unexpected directions. I find it’s better to just give myself a starting point so I know I won’t forget that I wanted to move forward on a given project and then let the work take me where it will. Then when I’ve reached a stopping point I go back to my project list and either add another next action (starting point) to the list or take the project off the list (if it’s complete or no longer an active priority).

          I’ve found that NA’s in coding projects are more like thoughts that I want to follow up on or explore than actual physical next actions. You couldn't’t really call ‘Noodle out a way to get function A working’ a physical action, but if function A doesn’t work your project won’t go forward.

          Just my two cents … I hope others with more time using their own GTD systems will share their experience also.

          Tim
          Maybe you need to think about whether or not you need that level of granularity...

          For example, if:
          · List fields with datatypes
          · Fix cmdGO on form X
          · Write function to get from X to Y

          is typically part of writing code and you don't need to be reminded of the steps, perhaps "write code" might be a better NA. Or, if you left off at "List fields with data types" and need to be reminded of the fact that has been done and you're up to the next step, maybe at that point you need "fix cmdGo on form X" to remind you of where you're at.

          So for me, what I would do in this case is this:

          1. If I haven't started writing the code, I'd make "Write code" my NA, or
          2. If I've started writing the code but stopped in the middle, I'd make the next physical step in the writing of the code my NA, so that I'm reminded of where I left off.

          Just my $.02....

          Comment


          • #6
            Originally posted by jkgrossi
            I'd make the next physical step in the writing of the code my NA, so that I'm reminded of where I left off.
            I agree. I think the next action as a reminder of where I left off is what I've been trying to get to but I hadn't thought of it in that way yet. So many times the hardest part of picking up a project after a couple days (or longer) on something else is remembering where I left off.

            Thanks for the tip.

            Comment

            Working...
            X