Re:A response to “How to never complete anything”
by vinceguidry on Saturday March 11, 2017 @04:36AM
(#13844920)
When I'm working, I'm constantly aware of which stage of flow I'm in. I can work outside of flow, or inside of flow, the difference is how productive I am. I am only extremely rarely called on to produce massive volumes of code, I mostly do maintenance and feature development, not greenfielding.
So I've cobbled together a workflow that doesn't require massive blocks of uninterrupted time to drive results. It mostly revolves around the concepts of imperative, recognition, and refinement.
When I'm working, I'm either moving through an imperative, recognizing what the imperative is, or refining the system. Each of these steps has a well-defined mental workflow. I can put down the work at any time, then come pick it up later after the interruption is gone, quickly re-recognizing the imperative so I can start moving forward again.
Refinement is crucial to the system and allows for quicker recognition. For example, years of experience have taught me to always start with a clear workspace. If I can't recognize an imperative, then I start cleaning. Once everything's clean, I go look to repositories of the state of the project, such as the tracker, to get a high-level overview.
There I can see I already have a story open. By looking at the story, my familiarity and past refinements lead me to a structured way of developing the feature or fixing the bug. If I can't see a clear path forward, then I don't have an imperative and I need to design a new workflow. I used to try to put workflows down on paper, but these days I only do it for edge cases that I don't see very often, but are still really important. For example fixing mobile-only display bugs, my normal workflow of reproducing the issue from the test server locally doesn't work.
By enforcing a fairly rigid structure to my workflow and refining as needed, I can keep my mind free to wander while I'm working through imperatives. This means I can put the whole thing down, go play ping pong or grab lunch, and pick right back up where I left off when I get back. It's not perfect, but it doesn't need to be perfect.
So I've cobbled together a workflow that doesn't require massive blocks of uninterrupted time to drive results. It mostly revolves around the concepts of imperative, recognition, and refinement.
When I'm working, I'm either moving through an imperative, recognizing what the imperative is, or refining the system. Each of these steps has a well-defined mental workflow. I can put down the work at any time, then come pick it up later after the interruption is gone, quickly re-recognizing the imperative so I can start moving forward again.
Refinement is crucial to the system and allows for quicker recognition. For example, years of experience have taught me to always start with a clear workspace. If I can't recognize an imperative, then I start cleaning. Once everything's clean, I go look to repositories of the state of the project, such as the tracker, to get a high-level overview.
There I can see I already have a story open. By looking at the story, my familiarity and past refinements lead me to a structured way of developing the feature or fixing the bug. If I can't see a clear path forward, then I don't have an imperative and I need to design a new workflow. I used to try to put workflows down on paper, but these days I only do it for edge cases that I don't see very often, but are still really important. For example fixing mobile-only display bugs, my normal workflow of reproducing the issue from the test server locally doesn't work.
By enforcing a fairly rigid structure to my workflow and refining as needed, I can keep my mind free to wander while I'm working through imperatives. This means I can put the whole thing down, go play ping pong or grab lunch, and pick right back up where I left off when I get back. It's not perfect, but it doesn't need to be perfect.