I see this kind of rhetoric often, whether at work or here on HN. I think some important factors are typically left out, however:
1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
2. The ability to work in a way that allows for interruption is a skill that can be learned.
As a younger programmer who loved nothing more than to sling vast amounts of code, interruptions were killers. Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities. I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity.
I’m not going to try and say these are universal principles or that any business can apply them, but as highly skilled workers I think this is an area where we tend to put in relatively little effort to overcome obstacles.
These factors are left out because they're rarely relevant.
> 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
Yes, there's a known partitioning between design and implementation, and it's very difficult to do both at once. Those "business value" decisions usually occur in the design phase, when you're not being precluded by implementation. However, interruptions are not the right way of doing the design phase.
Interruptions, by definition, occur when you were in the middle of some work, and if you were doing implementation work, result in you losing context (and therefore productivity) for something that is rarely design-related - and even relying on this for design/"business value" guidance is a hack, because you should be purposefully allocating some dedicated time to take a break from implementing and instead design and strategize.
Replying on unplanned interruptions to do this for you is suboptimal from every perspective and will be difficult and frustrating.
> 2. The ability to work in a way that allows for interruption is a skill that can be learned.
Absolutely - and yet, someone who has this skill and is interrupted is still less productive than someone who has the skill and isn't productive. Unless every one of your interruptions is essential (which isn't true for the vast majority of developers, including me), then learning the skill alone is just a hack, because the root problem is that you're being unnecessarily interrupted in the first place.
That isn’t the root problem. Ask why fives times. Why are you being interrupted? Often it is because management would prefer less development if they have more control over the development. I have worked at places where the management genuinely trusted developers and said and did: go forth and make great products for people. (Subscriptions paid the bills). This is rare these days, they, the management structure, often prefer no work being done to work that wasn’t “prioritized.” Often they are aware of a problem but don’t understand how to fix it systemically (if you mention it, the response is, you don’t have to attend these meetings (where decisions affecting you and your work are made), not, let’s see if we can have no Meeting Days once a week. Some bosses want to prove they are tough and in charge and force meetings doe that. Some bosses want to bypass the normal scheduling process for sprint work and have working sessions to do a thing immediately. Perhaps the system is not designed with good layers of isolation and good documentation so you have to commonicate between different people a lot. To reduce the interruptions you have to go back deeper.
Author here: I agree with number 2. My intention was to show how context can pile up and that it decays over time. So in tip number 4, I show how I record context as I go. Think of recording context as archiving your focus towers.
I'm my own worst enemy when it comes to interruptions, which is why I kept 2 of my 4 tips aimed directly at myself for how I improve my focus.
At a team level, I made a clarifying point that small interruptions are okay, but often not worth it. While I can bounce back, there's a high risk I won't. I'm my own worst enemy (not passing the blame to anyone, I personally need to work on my habits to be better at bouncing back to what I was doing). So it's important our teams work together to make sure the interruptions are worth it. One way my team helps each other is we setup a @mention rotation in Slack (see tip 1). It allows us to schedule shifts daily, so only one person has to plan on their day being interrupted with brush fires. It's a win-win, because we share the load, but we also make it so frontline support knows who to contact (we use @devs).
I feel it's unfortunate the title made it come off as just another article whining about interruptions, that wasn't my intention, I'll do better on my next title.
Valid points. I probably came on a bit strong as well. My comments weren’t directed at your title or even content so much as the discussion I’m seeing both here and in my own workplace. I have managers who (God bless them) spend a lot of effort reducing interruptions, and I think that’s a valid effort.
That said, over the years I’ve learned to recognize that when I’m buried deeply enough in anything for an interruption to be particularly disruptive, I’m setting myself and whoever has to deal with my work next up for failure.
Even more so, working from home with 4 kids who homeschool, it just wouldn’t work if I couldn’t find a way to deal with urgent and jarring interruptions haha.
> 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
The value isn't in the interruptions itself, but rather in the injection of context and perspective to the work being done.
Those can be delivered through interruptions like email and chat, but it is by no means necessary. Relying on interruptions is just a lazy default that results in much less real value delivery than could be achieved with a more thoughtful approach to organization design and workflows.
> 2. The ability to work in a way that allows for interruption is a skill that can be learned.
Working deeply on a problem without interruption (no checking email, HN, etc.) is the real skill, and one that is getting increasingly difficult to practice.
> Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities.
That's a good habit, but it would probably be better to just minimize interruptions and set aside time for such reflection.
> I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity.
This seems promising, but I would be willing to be that the benefits of reducing cognitive load would be even greater in an environment of minimal interruptions.
I don’t think we actually disagree. I was merely pointing out a couple factors I don’t think are emphasized enough. More often I see people characterize interruptions as show-stoppers. The reality is these things will happen, thus I would just argue that it is worthwhile to learn to deal with interruptions as efficiently as we can.
Fair enough. I might still disagree about the shape of the discourse (which things are emphasized too much or too little). I think interruptions are not as inevitable as people make them out to be.
However, I do agree that it is good to be prepared to handle interruptions well.
I'll be very interested to hear what you have to say on the subject of minimizing cognitive load.
Not OP, but much of it boils down to partition the work into smaller, simpler chunks. So if you do lose all your context when QA has a nerf war, you haven't lost much.
I’m in the process of designing talks outlining the general architecture of the platform my team has spent the last few years building. Minimizing cognitive load is a guiding principle of ours (and for our platform—payroll processing—it’s a necessity).
It is BS -- you can't split some work into smaller parts. If you interrupt pregnancy at 3 months, you likely won't get a baby in 6. Deep work may take time.
I don't believe it. Most of the most complex code I have found, when I needle the author about it, it turns out they don't really understand it either.
It genuinely seems to me that the Feynman Hypothesis holds true: If you can't explain it simply, then we don't really understand it.
And for certain if you can't explain the code simply, there's no way to make the code simple.
You certainly do! The variable we tend to be rigid about is whatever our idea of expectation is for our progress. It’s worth it to you and your employer both to be well organized in the way you approach legacy code. If you’re actively turning rotten stuff into tested, reliable code then you can organize yourself in a way that doesn’t require you to eat the whole elephant at once.
It may take some creativity, and I won’t claim this is universally true, but in all but the most exceptional of circumstances understanding of even an ugly codebase can be accomplished in bite-sized pieces.
I don’t think XP could have worked at all without Refactoring, because everyone is sitting together and asking questions.
With conventional coding, if your house of mental cards falls, you may potentially lose all of your work. By working from working code to working code, even if you lose your train of thought you get to keep most of your work so far.
A number of other techniques also allow you to work more from working memory than memorization. This helps when writing code a little bit, but most of the payoff is for readers or subsequent additions.
The thing with DRY is that code reuse means that a breakpoint most likely can fire from multiple paths, which makes it hard to trace why you’re getting null/undefined instead of an empty array as your second argument. Conditional breakpoints can help for some of these scenarios, but it’s better if the code in the middle of the call stack tries to be as contained and organized as leaf node methods eventually become.
You can’t modify code if you can’t read it, and if it’s difficult to read then interruptions become more problematic, because both the cost of interruption and the likelihood of interruption go up when thinking time increases.
The cleverest code is the code which is easiest to understand.
I like what you say. I also think once you are used to an environment, you can type in such a way as to make errors that will be caught by the compiler/linter/tests. So once it compiles it works. Sort of leaning more into the design side and less into the is this variable defined side. How ever, in my experience, there are design points you won’t get to without building up state in you thoughts for hours and hours. Deep focus can give you diamonds that cut thru the thousand little decisions that you encounter during implementation. That is why for big projects I don’t like to really start typing till I have the three or for maxims for the project.
No links, but I've seen the change in myself and others I've known for a while. A few examples I suppose might be helpful:
Things I used to do 10 years ago:
- launch headlong into a task as soon as I understand the problem statement
- pick up a ticket/bug, quickly attempt to do as little as possible to make it go away
- unit tests/integration tests pretty much never
- lots of (many times unnecessarily) complex SQL
These habits led me away from a place of understanding an overall system and towards a place of adding lots of entropy to the codebase. In an ideal world, every time you touch a codebase you should be trying to remove entropy. If ever you introduce new rules or ideas into a codebase, it should be like pulling teeth because every time this happens the cognitive model you have to hold onto just to work on the project increases, which slows down the entire team. Being contemplative about the repercussions of a change (especially its impact on cognitive load) can help steer a team as a whole toward better decisions. Being quick to point these factors out in kick-offs and PRs helps protect the codebase as well. It's a lot of work, but when a project operates under this kind of structure there just aren't that many things that require a large amount of focus. And those that do don't necessarily require active focus.
Having a variety of things to do helps. If I start to death spiral on a problem (which is how I describe the feeling that I'm overloading my mental map), I'll put the problem down for a bit and work on something else.
Having a strong grasp of the subject matter is also a huge help. E.g. I work on a payroll platform. Learning how payroll should ideally work while at the same time writing code for the platform wouldn't be an ideal scenario (we definitely had to do this at times, but most of us had at least a few years background around payroll-related business functions). I've found this to be the biggest blocker to my productivity whenever I start a job in a new field.
Over the last 10 years I've worked in:
- Payroll/HR
- Luxury/Athletic Clubs
- Autism care providers
- Workers' Compensation Insurance
- Financial Performance Reporting
I've done the above using probably half a dozen different programming languages, team sizes everywhere from 2 to 50+, and (I believe) because of the way I approach my work that there's really never been a time in that period where I couldn't hit pause and pick it up later.
1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
2. The ability to work in a way that allows for interruption is a skill that can be learned.
As a younger programmer who loved nothing more than to sling vast amounts of code, interruptions were killers. Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities. I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity.
I’m not going to try and say these are universal principles or that any business can apply them, but as highly skilled workers I think this is an area where we tend to put in relatively little effort to overcome obstacles.