Ok, so we know what we have to do now, and know which repos and plans to use (or we have GTD tasks to create them). Let’s get coding! Now a few things get in the way of our coding flow in my experience:
- Lack of clarity on what to do next – usually with a tendency to procrastinate as a result.
- You’re stuck debugging or troubleshooting something.
- Something you didn’t anticipate – this happens all the time, no dramas!
The key thing here is that coding is our day job, and hopefully our strength, and we want to preserve our flow. Let’s look at these problems individually.
Dealing with Lack of Clarity
As a first resort, go back to your mind map if you feel you lack the big picture. Are there any dots in your mind map you can now connect? In other words, has the world moved on since you created the map? Maybe you just need to sync your understanding of the code with your understanding of the mind map.
If you don’t still don’t have clarity, look at your GTD list. Just like an algorithm, can you break something you don’t get into smaller blocks? Perhaps just identifying ‘what’ the smaller steps are is enough to keep you moving. You don’t need to enter every coding task in OmniFocus by the way. A set of comments or high level methods in your IDE can be enough. The point is just working out a logical sequence of steps is often enough to get you unstuck. Remember we’re decoupling the ‘what’ from the ‘how’ – so embrace approaching things with differing levels of detail.
If you’re still stuck after that, then it’s time to approach your teammates. A conversation with someone might unlock what you need. One specific lack of clarity can be in debugging and troubleshooting. Let’s look at that next.
Dealing with Troubleshooting and Debugging
If you’re stuck debugging or troubleshooting something you have a few options. The easiest way to preserve flow is often to temporarily hard-code something and set a reminder to fix it later. If that sounds like heresy, remember that something Test Driven Development often starts with a hard coded solution that works for one case and gradually expands into something more general. Maybe you could use it as a tool to preserve your flow.
If that isn’t suitable maybe slow down and type out your problem in a message to a colleague. But do it offline on a text editor. Before you approach anyone does the following:
- Type out the problem you're experiencing.
- Type out what you expect vs you get. If you don’t know what to expect, what can you do about that?
- Type out what you’ve already tried in a decent level of detail.
This is often enough to get the problem solved in your own head, If it hasn’t you’ve still respected your colleagues’ time by getting straight to the point, and pre-empted what they might ask you.
Sometimes of course your flow is derailed by unexpected work. Let’s tackle that.
Dealing with Tasks You Didn’t Anticipate
Something you didn't anticipate eh? Welcome to life as a developer! This is where our magic 2 minute rule comes in. As a reminder, the GTD methodology stipulates that if something can be done in under 2 mins it should be done there and then. The idea is that it’s not worth the overhead to classify and organise a task of that size.
I would apply one caveat here though. In this context this 2 ‘minutes to do rule’ – had better be relevant to what you’re writing now. Coding is our day job, so protect your flow when you get it. Preserve that ‘do in 2 mins’ rule for when you’re in a ‘GTD sweep’ not a coding one.
So when we get thrown a task that we didn’t anticipate, an entry in OmniFocus or a quick post on your monitor is enough. Keep moving on to what you currently have. Even if your boss asks, you can politely explain you're in the middle of something and keep your promise to get to them later. Only if the task blocks you now should you stop what you’re doing and switch direction.
If you absolutely must change direction and fix this, then off you go. But think back to our lesson on the Pomodoro Technique. If this work is unplanned and urgent, then let’s try and stop that from happening next time. The onus is on us to try and improve planning.
As I said, unanticipated tasks are part and parcel of development. But stopping what you're doing to accommodate it shouldn't be the norm. If you get good at breaking your work out well enough, then very few surprises should derail a 25 min unit of work. Most things can wait, if not be predicted in advance.
These steps should keep you moving with coding. But as developers we have to embrace the agile ways of collaboration and renegotiation of priorities. (Within reasonable limits of course).
Using Your System When Priorities Change
Boy does this happen a lot! It’s as if people (looking at you, marketing department) forget that the Agile Manifesto isn’t a free lunch. The ability to pivot and change based on priorities isn’t a license to do all the old work too. By bringing something new in, something else must get parked. Often it’s a combination of these. Some tasks of our current work get parked as it’s now less essential than these new requirements.
When I do park a project or task, I leave a task in OmniFocus on ‘how to resume’. A little note there tells me where I got up and what I was doing. I have a consistent approach for knowing how to resume work. Incidentally, you don’t need to get too clever, and set a reminder date on when to resume work. If it is important enough, it will come back on your radar.
Planning for the next Day
Work often overlaps overnight. How many times have you finished some work dead on your schedule leaving time? Not often I’d wager. Either set a daily goal for tomorrow or spend 5 mins before you pack up sorting tomorrow’s to-do list. Once you’re in the habit, your brain knows that it can trust the morning list because you sorted it last night.
When You Complete a Piece of Work
Take a couple of minutes to review and retro your work. Make a note of anything you could improve – such as unplanned and urgent work. I have a separate ‘Upskill’ project where I create tasks related to areas I could improve in. As an example, recently I had a problem with certificates in an API gateway tool. I got the job done with some help, but still had an upskill task for learning the fundamentals of certificate issuers so I could do it myself next time.
Conclusion of Techniques
I hope that you can see that there are very definite ways of applying the right tools and techniques. You don’t have to take what I’ve said as gospel, but try them out and refine according to your preference and ways of working. Next I’ll cover the idea of continuous improvement, sharpening your saw. Ok, so we know what we have to do now, and know which repos and plans to use (or we have GTD tasks to create them). Let’s get coding! Now a few things get in the way of our coding flow in my experience:
- Lack of clarity on what to do next – usually with a tendency to procrastinate as a result.
- You’re stuck debugging or troubleshooting something.
- Something you didn’t anticipate – this happens all the time, no dramas!
The key thing here is that coding is our day job, and hopefully our strength, and we want to preserve our flow. Let’s look at these problems individually.
Dealing with Lack of Clarity
As a first resort, go back to your mind map if you feel you lack the big picture. Are there any dots in your mind map you can now connect? In other words, has the world moved on since you created the map? Maybe you just need to sync your understanding of the code with your understanding of the mind map.
If you don’t still don’t have clarity, look at your GTD list. Just like an algorithm, can you break something you don’t get into smaller blocks? Perhaps just identifying ‘what’ the smaller steps are is enough to keep you moving. You don’t need to enter every coding task in OmniFocus by the way. A set of comments or high level methods in your IDE can be enough. The point is just working out a logical sequence of steps is often enough to get you unstuck. Remember we’re decoupling the ‘what’ from the ‘how’ – so embrace approaching things with differing levels of detail.
If you’re still stuck after that, then it’s time to approach your teammates. A conversation with someone might unlock what you need. One specific lack of clarity can be in debugging and troubleshooting. Let’s look at that next.
Dealing with Troubleshooting and Debugging
If you’re stuck debugging or troubleshooting something you have a few options. The easiest way to preserve flow is often to temporarily hard-code something and set a reminder to fix it later. If that sounds like heresy, remember that something Test Driven Development often starts with a hard coded solution that works for one case and gradually expands into something more general. Maybe you could use it as a tool to preserve your flow.
If that isn’t suitable maybe slow down and type out your problem in a message to a colleague. But do it offline on a text editor. Before you approach anyone does the following:
- Type out the problem you're experiencing.
- Type out what you expect vs you get. If you don’t know what to expect, what can you do about that?
- Type out what you’ve already tried in a decent level of detail.
This is often enough to get the problem solved in your own head, If it hasn’t you’ve still respected your colleagues’ time by getting straight to the point, and pre-empted what they might ask you.
Sometimes of course your flow is derailed by unexpected work. Let’s tackle that.
Dealing with Tasks You Didn’t Anticipate
Something you didn't anticipate eh? Welcome to life as a developer! This is where our magic 2 minute rule comes in. As a reminder, the GTD methodology stipulates that if something can be done in under 2 mins it should be done there and then. The idea is that it’s not worth the overhead to classify and organise a task of that size.
I would apply one caveat here though. In this context this 2 ‘minutes to do rule’ – had better be relevant to what you’re writing now. Coding is our day job, so protect your flow when you get it. Preserve that ‘do in 2 mins’ rule for when you’re in a ‘GTD sweep’ not a coding one.
So when we get thrown a task that we didn’t anticipate, an entry in OmniFocus or a quick post on your monitor is enough. Keep moving on to what you currently have. Even if your boss asks, you can politely explain you're in the middle of something and keep your promise to get to them later. Only if the task blocks you now should you stop what you’re doing and switch direction.
If you absolutely must change direction and fix this, then off you go. But think back to our lesson on the Pomodoro Technique. If this work is unplanned and urgent, then let’s try and stop that from happening next time. The onus is on us to try and improve planning.
As I said, unanticipated tasks are part and parcel of development. But stopping what you're doing to accommodate it shouldn't be the norm. If you get good at breaking your work out well enough, then very few surprises should derail a 25 min unit of work. Most things can wait, if not be predicted in advance.
These steps should keep you moving with coding. But as developers we have to embrace the agile ways of collaboration and renegotiation of priorities. (Within reasonable limits of course).
Using Your System When Priorities Change
Boy does this happen a lot! It’s as if people (looking at you, marketing department) forget that the Agile Manifesto isn’t a free lunch. The ability to pivot and change based on priorities isn’t a license to do all the old work too. By bringing something new in, something else must get parked. Often it’s a combination of these. Some tasks of our current work get parked as it’s now less essential than these new requirements.
When I do park a project or task, I leave a task in OmniFocus on ‘how to resume’. A little note there tells me where I got up and what I was doing. I have a consistent approach for knowing how to resume work. Incidentally, you don’t need to get too clever, and set a reminder date on when to resume work. If it is important enough, it will come back on your radar.
Planning for the next Day
Work often overlaps overnight. How many times have you finished some work dead on your schedule leaving time? Not often I’d wager. Either set a daily goal for tomorrow or spend 5 mins before you pack up sorting tomorrow’s to-do list. Once you’re in the habit, your brain knows that it can trust the morning list because you sorted it last night.
When You Complete a Piece of Work
Take a couple of minutes to review and retro your work. Make a note of anything you could improve – such as unplanned and urgent work. I have a separate ‘Upskill’ project where I create tasks related to areas I could improve in. As an example, recently I had a problem with certificates in an API gateway tool. I got the job done with some help, but still had an upskill task for learning the fundamentals of certificate issuers so I could do it myself next time.
Conclusion of Techniques
I hope that you can see that there are very definite ways of applying the right tools and techniques. You don’t have to take what I’ve said as gospel, but try them out and refine according to your preference and ways of working. Next I’ll cover the idea of continuous improvement, sharpening your saw.
