Savouring queues

At a recent talk in work we were presented with some of the ideas behind mindfulness. It was a high level introduction into it, but I still came away with some new perspectives. One of them is from the video below, which was played at the start to set the context of a core idea in mindfulness. The idea that, as individuals, we have a choice in the way that we view the world, we simply need to recognise the choice is there and utilise it. As a lapsing practitioner of mindfulness I’m pretty familiar with this concept. I shared the video around the office pointing out the key message that I took from it; to see the choice. However after doing so I started to think on it a bit more concretely.

The concrete example I started to look at was in how we in modern software companies are surrounded by queues. Queues that inevitably bring frustrations with them. We have them in our backlogs, our code reviews and nearly every Agile process. I started to question, given that we have them everywhere how could we view the time spent in these queues as sacred?

These are some of the areas where I feel we could view queues differently and some options that could be probable.

PR Reviews

Depending on your mindset these can be enormous sources of frustration. You write a piece of beautiful code and suddenly a number of people swarm around it, asking stupid questions about the way you chose to write it, whether it is secure or if there is sufficient test coverage in it. What a pain in the ass! “Why is everyone getting in my way, preventing me from merging my code?”

Taking learnings from the video, there is no reason to think this way. The person asking why you didn’t write the code their way likely came from a different background to you, so learned to code in a different style. If you take the time to engage with them, you may learn something or potentially even teach them something. Questioning the code may be their way of looking for advice, they simply want to understand your thought process. The person asking if it is secure is likely just doing their job or may have a strong interest in security. They may be prompting you to find the security issues in your code, that they have already spotted but they believe in people finding their own mistakes. The person commenting on code coverage may be the same, simply guiding you to stop and question the quality of your code.

These may not always be probable. In many cases you’ll know the person and could understand their motivations, they could just be blindly commenting to seem productive. However you should never close yourself to the likelihood that they have the best of intentions in mind and may actually have spotted an issue.

Taking time during a PR review to be mindful of this possibility leaves the door open to new learning opportunities. By seeing the time spent reviewing the code as an opportunity to learn, rather than as a delay in getting code to master, not only can our time be enriched with learning but we can be less frustrated doing so.

Build and Deploy Queues

This is another great source of frustration. My beautiful code has been picked apart by the knights of standards and practices. It survived the trials and is finally in master. Now I have to wait for it to be built and then deployed. Here we run into one of the classic traps in Lean. What to do next?

If we assume a highly optimised cycle time, you should have feedback in the time it takes to get a coffee. Surely no room for any mindfulness here. But therein lies the trap! Once the code is committed you can start writing the next bit of code or move onto the next task in the backlog. Right?

This is context switching, where you change focus from what you are working on, to something new, despite the work not being fully done. Context switching is great if you are infalible. If every line of code works first time, every time. You jump from task to task writing perfect code. Reality is often disappointing though, code does not always work first time, or every time, even when what you have written is in fact perfect. Maybe it doesn’t play well with other code, maybe the build system is having network issues, or maybe you just missed something. Regardless of the cause, the end result will always be the same. If you context switched away from the code being built, you will be frustrated having to go back to fix an issue.

This is where as an SM I extol the virtues of WIP. Not starting something new until you have finished the task at hand. In this situation WIP and mindfulness go hand in hand. Rather than jumping onto the next task, you could use the cycle time, no matter how long, to reflect on what it is that you just committed to build. While it is building, there are a number of possibilities that may present themselves.

One of the most common I find is as soon as I hit commit, I reread the code and spot an error. Generally something obscure, a mixed up variable name or logic error, it might pass tests but won’t do what it is supposed to. There is always potential for housekeeping; improved logging, comments or documentation updates. Some quick refactoring of a neighbouring method or class might be handy.

All of these things keep you focused on the present task, they keep you mindful of what you are doing. Now, when the build breaks, your head is still in the same problem space, there is no need to context switch back, so there can be much less frustration in the failure. If the issue you spotted happens to be the cause, you may already have fixed it. In writing comments or documentation you may have gained a deeper understanding of the code and figured out the external component that is not playing nice with yours. If the build system is broken, you could alert others to help resolve the issue and alleviate frustration for many other developers.

These may not always be doable, but it is unlikely that every line of code is perfect or every system is infallible. Using build time to reflect on the code under development can help deepen your understanding of it, in doing so finding ways to reduce the cycle time through optimisations. This should be much more preferable to constantly skimming from one area to the next, getting frustrated at how long each section takes to build and not fully understanding why.

Backlogs

One of the main sources of self-centred frustrations almost always comes from reviewing the backlog. A not uncommon thought is “Why is this stupid feature ahead of my one, do you not understand how critical it is to get my work done and how inconsequential your work is!!?”.

Having a shared backlog, especially with other teams, is a fantastic window into the horror show that is Agile in a large complex organisation. Every team I have ever been a part of, has backlogs going into the far distant future. I rarely ever agree with all of it, there is always something that could be done differently. If only they would get out of my way and just let my work progress, the whole company would be better off. Wouldn’t it?

Do I alone understand all the complexities of what is going on around me. Do I understand what it is that other teams are going through. The video talks of the woman screaming at her child, that there may be some tragedy in her life, causing her to run short on patience. It is not improbable that there can be tragedies in other teams. They may be struggling under a weight of complex technologies or bureaucratic red tape. They may have lost a team member with critical knowledge, someone that once enabled them to operate efficiently. Where now they are just keeping their heads above water and their backlog is growing out of control, bleeding into other teams.

Again by taking the time to look beyond ourselves and ask the question, “What non-me-centered things could be going on?”, we could find untold opportunities staring us in the face. If we question whether other teams are struggling, we may find that our “important” work pales in comparison to theirs. Where critical knowledge has been lost, we could fill the gap with our own or seize an opportunity to learn something new.

Again, these are not very probable. We could just be wasting our time looking at what others have well at hand. Alternatively, we could discover something new.

Savor them

In an industry that is eternally cranking up the tempo, demanding more and more from its “resources”, stepping back and being mindful when we are stuck in a queue seems like career suicide. “Why would I step back to smell the roses, when I could be 100% utilised?”. This thought process is exactly why mindfulness is becoming so prevalent, people are burning out. This is happening because we can’t be 100% utilised all of the time, it is simply not possible! Not only is it not possible it is severely detrimental.

Considering code review comments as stupid or snarky, can make us ignore constructive criticism, because they are just in our way. That is until we get hacked, because someone left a security vulnerability in their code.

Constantly flicking between segments of code as each build fails, jumbles our brain as to what each section does and denies us the time to become an expert in one area. So our technical debt increases because our codebase is just a patchwork of sloppy, hurried code, written to make the build pass because someone needed to finish one of their dozen tasks in progress.

Assuming that all the other work in the backlog is just meaningless noise, robs us of insights into what is really going on with our coworkers and where our efforts could be better spent. Until one day when we are told we are no longer needed, as we have been working on a dead product for months, as we didn’t stop to question where the real value was.

Simply put, not taking the time to stop and be mindful in a queue is something we can’t afford. But hey, maybe all of this is just not probable…