Why interruptions are frustrating to developers
tellspin.app
tellspin.app
Now I'm realizing my job is actually to attend meetings. I should ask for a raise! Though in reality I'm just going to quit soon.
The sweet irony is that this meeting heavy company of 50ish people uses Zoom without pro accounts...it's enough to make a grown man cry.
It's probably not, though - or, at least one of those meetings is the one where you have to showcase/demonstrate what you "accomplished" in spite of all the interruptions. You do have to produce something in spite of all the time wasted in meetings. I've unironically been told that that's what the weekends are for.
> I've unironically been told that that's what the weekends are for.
This kind of rings true, I've only been here around 3 months. I did spend a couple of weekends on code in the first month, but overall this company (and my comp) really isn't worth that kind of effort, so I've stopped.
I really only joined this company because I wanted a better work life balance (joke's on me) and my business isn't yet profitable, but I'm actually financially independent so it's tough to muster up motivation to work overtime for free.
Or pitting two managers against each other? I would love to attend your meeting but this other team needs this. Let them schedule it out for you?
And sometimes with an agenda, I will try to reply and resolve whatever it was about asynchronously. There have been several meetings avoided when I replied with something like "this sounds like known bug #1234" or "here's the wiki page documenting this: is there something else not covered?".
My # meetings went down after I started doing this. Maybe it changed the culture in a good way, or maybe people got tired of me and stopped inviting me to meetings.. but either way seems like success.
How doesn't that make sense? If you want to compress all your meetings into one day for every two-week sprint (ten working days), you only need to average 48 minutes a day of meetings to fill that day. That's not an obscene amount.
It just sounds like a combination of lazy scheduling and no desire to improve dev experience.
I have a plan for this. I'm writing a small program to move certain meetings to an auto-scheduled state. You pick some blocks on your calendar where you'll accept auto-scheduled meetings. You then say "I want to have a meeting with X, Y, and Z", and the system will use a constraint solver to find a time. The cost function favors bin-packed meetings, keeping entire days free, etc. If existing meetings have to move to optimize the cost function, so be it.
I don't actually know if people will tolerate this. People are creatures of habit, so if you're used to a biweekly team meeting on Monday, it will be weird when it gets replaced with a postmortem review that starts 30 minutes earlier and the team meeting moves to Thursday or whatever. I also think it will be hard to get people to commit to giving the bot a slot to work with. We shall see. If anything interesting comes of this I'll write up something about how it went.
Edit: I see what you're saying, that makes perfect sense.
> Finding time for six one-[unit] [block]s is by definition easier than finding time for one six-[unit] [block] of meetings.
that you responded to. As long as there's anything at all with fixed position, you can end up with fragmentation, and even when (you can guarantee) there isn't, the former is just "exactly as easy" as the latter, so the general case degrades to "is by definition at least as easy as".
My manager absolutely has more than 8 hours of meetings ina given week, and not jut useless ones. I've seen calendars of people a level or two above me where several days a week are wall-to-wall meetings. I don't think it's all that uncommon either. At some point, your job is coordinating and strategizing and communicating what needs to be done, and after a while, beyond meetings being an unfortunate nesesity, the meetings are the work
Unfortunately, they are. Largely due to inexperience and incompetence at the managerial level (zero technical chops once you go any level above IC).
I'm well aware most software companies aren't like this, though. They'd go out of business, like this one will. Almost every key engineer (including CTO) has left this company already - six of them in the three months since I joined. One of them wrote a 10 page open letter to the CEO on the way out. Things are a real mess...
Among other gems in that open letter was a link to this article [0].
[0] https://neilonsoftware.com/2020/09/08/non-technical-developm...
Federate your business today.
That's frustrating in its own right, but what's worse is that nobody ever factors it into scheduling estimates. If your team is getting 6 hours of work done in an 8 hour day, that's the equivalent of the whole team taking a day off every week and expecting everything to still get done on schedule. Except it's worse, because it makes you less efficient all the time rather than just one day a week.
On the other hand, I don't think that trying to fit all weekly meetings into a single day would solve the problem either. It's often the case that decision makers — the people you need to have at a lot of meetings — are involved in different areas of a business or product, so they'd have overlapping demands on their time. Where I work, there are a few people who are like this, and their schedule shapes how meetings are planned for everyone else. When any of these people have conflicting meetings scheduled, one or more of those meetings have to be rescheduled for another day.
So now everyone else has 2 half days of meetings a week, rather than one full day. And then, what happens if you learn new information and have to make a decision? Do you wait a week to talk about it? Probably not. So, you'd probably have a couple heavy meeting days, and then a number of ad hoc meetings scattered over the week. This is not the improvement we were looking for, and I think at a certain point the team would just drift away from the initial vision, and settle into the former pattern.
Not saying it's a good thing!
It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work hours after you started work. Everyone knows you have 80 hours in a two week period so they expect you do finish 10 of these 8 hour tickets.
Compare that to Story Points. Your velocity over a two week sprint is auto adjusting for the typical/average meeting load and other interruptions. If you estimate a ticket at 8 story points and your velocity is 24 story points then everyone should expect you to finish 3 of these tasks per sprint.
This is obviously all 'on average' and there might be a production incident that means this time you didn't get it all done or maybe the other way around, someone got sick and 3 large meetings didn't happen and you got a 4th ticket through.
Also note that I chose 8 story points at random. 8 story points is specifically NOT to be equated with 8 hours. Story points are just uses as a relative complexity measure, meaning something with 3 story points is roughly a third as complex as that 8 pointer.
Many managers and even people that claim to be Scrum Product Owner or even Scrum Masters don't really understand that.
I've been somewhere that did this, and it worked reasonably well.
Story points are not a cureall. But it can help shift the conversation even with the 'unreasonable' people that just look at the hours vs a 40 hour work week. As mentioned though it needs someone that really understands what story points are and that won't let "them" just equate story points to hours. Seen that too many times even from "Scrum Masters". If 2 Story Points always equal 16 hours then you don't need to use Story Points.
Back to the preciseness. You estimated 30 hours but it took 33? How dare you! You could try and only estimate in whole or half days to mitigate.
Story points? They have a built in jitter as estimates get larger. 0.5 1 2 3 5 8 13 20... Some unreasonable people will try to compute a number of hours from your velocity. Luckily it will usually at least be imprecise but really you should try to make them understand that it makes no sense to even do that. Also don't let them do math with story points. That's a try at making thing more precise again which just doesn't make sense. Jira for example only allowed whole numbers in the story point field. They were pressured by customers to allow/show floats. That make no sense!
Even with story points you should only take in 70-80% of your velocity into each sprint. I usually average the velocity over the last few sprints too. It all serves to make it 'less precise feeling'. Yes that's math but the only math I will allow: avg(last5SprintsVelocity)*0.75 is what we take in. Round about, a bit more or a bit less depending on how the team feels since this never matches 100% to what's in the sprint anyway.
So in this thread I comment to defend how demanding programming is on the intellect. Again, many downvotes.
I have no idea what this community is.
I have maybe downvoted a handful of times in a decade of being on this site: only for spam or grossly misleading comments.
Increasingly I see seas of downvoted comments as-if this were reddit. I think that might just be it: the community has grown so large, it has attracted enough of those types who vote-their-emotions.
My takeaway was that you were taking the unpopular opinion (programming is uniquely hard/creative/etc) and attempting to reinforce it by unfairly reducing the creative act of painting to no more than paint on a canvas. That's my best guess.
This is a startup/founder-centric forum, and creative people usually have less time for criticism and negative viewpoints, that then need to be translated into something worthwhile.
It is already worthwhile, since it is aiming at the truth: a comment is an invitation to revise your/my view.
It seems we're saying here that the community, generically, does not find that worthwhile. Rather we take as fixed a commenter's private interests, and commenting is merely an instrument for furthering those.
I understand that reasoning in selecting/voting posts; I dont have much sympathy with it in commenting.
It's easy to be liked saying what other people want to hear. When you have things to say that people generally don't want to hear, this needs refinement how to go about it. The best way is to make people realize it for themselves, even if you don't get credit.
How others hear you, matters.
It was more a musing about a weirdness in downvoting behaviour; and whether there was something unintentional I was doing as a cause.
I don't mind upsetting people where the upset is due to a view of mine conflicting with a view of theirs. In this way, I'm very comfortable being downvoted. A downvote here is a signal of saying something worthwhile.
I find people agreeing with each other, on mass, a bit alarming if anything.
The comments have inspired me to write a follow up, titled something like "My number one source of interruptions is myself", and maybe it'll avoid the mess of flame.
Microsoft had a culture of offices with a door, to allow more focus. But it's not the only thing they did differently (and the companies valuation speaks for itself).
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.
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.
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.
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.
Have you figured out how to explain this to others? Some people don’t seem to get why their amazing code is more of a dumpster fire.
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.
The term "deep work" is from here https://www.calnewport.com/blog/2012/11/21/knowledge-workers...
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.
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.
I have too, but sometimes I have to read other people's code, and I don't have any control over how difficult that is.
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.
> 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.
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.
Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.
They're also not typically creating things directly that provide as much business value as developers are.
Not that I’m particularly fond of this current incantation of Agile.
This is fairly unique. If you're painting a big oil painting, yes you need similar kinds of isolation to get it done. BUT you aren't really maintaining a deep conceptualisation of the whole thing in order to paint. Rather you can "let the canvas remember most of your thinking": ie., the painting is its own schematic, by the means of layering & outlining it.
Also, in social-creative work "flow states" arise more naturally. I think people working with people, on the whole, enter flow states. It's why managers struggle to see the issue with asocial-creative work.
The issue here is code by itself is nothing like a dress or a canvas: it doesn't encode much of our thinking. We have to rebuild an interior world when we encounter it.
It is for this reason "literate programming" is almost certainly an excellent way to program -- absent almost any tools or popular sentiment in support of it.
Code can be written more like paintings are painted, ie., "self-documenting" -- but this is very hard to do well.
Programming with jupyter notebooks, I'd guess, is more resilient to interruption -- it is more like making a dress or painting a painting. Yes, you need isolation and quiet -- but an interruption neednt be so fatal. You write in your thought process as part of the activity of making the code.
In my limited experience in the creative realm (music), it takes an incredible amount of flow and concentration to get a thought or feeling out of your head and into some form of recorded medium. I can't just stop cold, wake up the next morning, listen to what I was working on and pick up where I left off. The creation is a product of a fleeting experience that can't easily be recreated.
Programming, as practiced, is distinct from painting -- but this has more to do with the practice of each. Programming tools do not afford the same ability to externalise thinking.
Fundamentally, they are built to run the code. Not to assist the programmer.
Jupyter notebooks are, here, a notable exception.
I actually spent 6 hours on Saturday writing it and another 4 to 6 other days getting it to where I was happy with it. So I appreciate the kind words.
What is rarer is the moment of effective effort's nature, for many types of coding (to agree with your point).
The author's house of cards analogy trivializes it and makes it easier to dismiss as a rhetorical device. I'd use activation energy as a more apt comparison.
IOW, if you put in 30 minutes (or 3 days) understanding code, and do not make the correct 5 minute addition / change at the end of that, all that previous time is wasted. And moreover, that knowledge has some half life in my head, after which it must be reacquired.
And that correct addition / change cannot be made without first paying that cost.
This is not unique to coding, but is generally limited to professions involving the modification of dynamic complex systems. E.g. legal, biological, mathematical.
And I'd hazard to say of those, programming has a wider universe of possible approaches (aka "Why did the last person? Oh... Oh. Oh no."). Legal is probably the closest analogy.
But the question is where do the differences lie. My hypothesis for one difference is that we dont write code like painters paint.
That is bad. We should. Hence my advocacy for literate programming.
It isn't to be dismissive of painting, it is to say we put ourselves in a more precarious position by how little we support ourselves with our tools.
Painters (, mathematicians, etc.) are all working with pencil-and-paper in quite a radically different way.
I think this goes some way to saying, actually, there is a bit of a difference here.
Doctors and nurses, who also deal with complex systems, have gotten exceedingly good at this with charting.
We? Considerably less so. But I'd hazard improving every year.
Reduction of boilerplate and flexibility-for-the-sake-of-flexibility in languages has been a big win, IMHO.
From c. 1m30s to 5m30s
I was told they couldn't work well with constant interruptions like that. WTF? Probably was an extreme ... something going on on their end, but... wanting/needing some answers and waiting 4 days was, to me, being rather patient.
No one is expecting an NBA player to respond to texts during a game.
I think programmers bring this up because they think people aren’t aware that their flow state is a thing, too.
Perhaps it's different in modern web development, where you create free form monstrosities that change daily and you are paid by code churn.
As legend would have it, Archimedes was killed by a soldier because he angrily demanded "Noli turbare circulos meos!"
I guess that is what "whiny" mathematicians deserve ...
Edit: fix a typo
Development for me has the highest cost for task switching. The ramp up also takes longer. If I have 15 minutes before a meeting and I have not started writing code, I won't even bother starting.
If I compare that to being a Sr Manager, the cost of task switching is much lower, so was the ramp up time. Essentially it was a "let me get my notes, or the doc/email/presentation" and then I was set. That's maybe 1 minute.
I think the biggest difference is that as a developer you either have to come up with something that doesn't exist, or you have to read something that someone wrote that has never existed before and then you have to figure out what the mistake was.
The closet thing that resembles that for non developers is other abstract sciences, like Math, Chemistry, Physics or purely creative writers.
So imagine you are a creative ghost writer. You are asked to write Chapter 8 of this fantasy book. By the way Chapter 7 and Chapter 9 exist. Your writing has to match the style of chapter 7 and 9, including character names. Chapter 9 was written 16 months ago, and the guy left. Chapter 7 was never edited, but it will while you are working on chapter 8. You also wrote chapter 5 a month ago, but since then 4 other authors have updated chapter 5 to make it better. Do you think interruptions would help or hurt?
This is why developers complain about losing flow state. The cost of getting it back it too high.
Either I am doing something wrong/I'm stupid or not all coding jobs need the same kind if deep work.
Because more than 90% of my individual technical work requires me to be in a flow state. It takes a good 30 minutes to hold a really large thought in mhead, and I can't start coding until I feel like I'm mentally present.
Now I have actually done different jobs too. I have presided over clubs in school, I worked as a mechanical engineer for a while and I used to write comedy scripts for dramas. None of them required flow state to the same degree.
Math derivations required an even higher flow state, and that's the only exception. I mentioned writing scripts. It actually requires a flow state, but it is more like pair programming and a group activity, so if you lose context someone will quickly bring you back to where you were.
Maybe other roles are more easily chunkable or people just don't care about making sure that their work doesn't have side effects or how it fits into the whole. But, I've found this one complaint by developers to be quite genuine.
__________
One thing that has worked is to write down entire interfaces, contracts and explicit steps before I even start. This step absolutely needs deep work and usually take 7-8 hours at a time.
However, once it is done, you can address each step or class as if it is somewhat side effect free. As a tangent, this is also why I hate using classes when state doesn't exist. A function allows for so much better side-effect free mental compartmentalization than instance methods.
No one is saying that. Programming is plain hard work that requires deep concentration to keep a lot of parts in working memory, and is obviously more cognitively demanding than most other jobs. It appears you don't have experience with programming non-trivial things.
My intention of the article was to give a good visual of the complexity that gets built up while coding and some tips for how I've helped myself focus better.
It wasn't intended to come off as whining, it was more to help me recognize that there is a great deal of complexity that happens and it's easy for me to avoid facing complexity by doing less intense work.
3 of the 4 tips were targeted towards things I can do to protect myself, from well, myself. I'm my worst enemy when it comes to interruptions.
My other tip was how teams can work together to make sure an interruptions is worth it.
I'm certain, like you say, the need for flow or focus is not unique to developers, but can apply to many knowledge workers.
I would argue not just knowledge work. Imagine a painter or a tattoo artist or a pilot or many others who are trying to concentrate and someone constantly interrupts them.
It's the same frustration that people with ADHD experience regularly, because they have less available working memory in the first place.
Managing an inadequate amount of short term memory - whether caused by a deficiency in memory or overload of stimulus - is done mainly by restructuring your surroundings so they don't interrupt you.
Software development tends to be very appealing to neurodivergent people (including those with ADHD), so a strong distaste for interruption at work is to be expected.
I've wondered the same - though never been able to put it into such concise words. I formerly worked as a Mechanical/Controls engineer and did not feel the same frustration with interruptions at the time despite being an equally challenging industry (as far as my experience went). My conclusion is that the hard constraints of a physical system keep the problem space (and thus the required working memory) relatively small in the physical world. When you're writing software that has no physical manifestation, the problem space is typically massive since the constraints are fewer.
Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me.
I was diagnosed with ADHD this year out of other suspicions. (I've always suspected it, but avoided getting diagnosed because I thought I would use it as an excuse for being lazy).
My working memory also happens to be incredibly low, to the point that some of my friends call me a goldfish. (My long term memory is excellent in comparison)
I never put two and two together, but it makes so much sense.
I really should go for the long-overdue- prescription meeting I keep avoiding. :\
It was for me, too. I've recently been reading about ADHD and people's experience with it. I've always had my suspicions, but never in a serious enough context to make any decisions about it. Reading people's experiences feels like talking to a long lost friend from a parallel universe.
I certainly have had opportunities to get an actual diagnosis, especially during my childhood, but the onus was always placed on me or my parents to take action. My parents were unmotivated by stigma and I was unmotivated by my ADHD symptoms.
So here I am, 28 and trying to motivate my ADHD brain to navigate America's absurd - and unnecessarily confrontational - healthcare system so I can get a diagnosis and medication/therapy.
> I really should go for the long-overdue- prescription meeting I keep avoiding. :\
I can't speak for the experience of people who have been using medication, but as someone who has spent decades without it, I would strongly encourage you to do that.
Good luck getting your ADHD brain to do the follow through!
I have previously worked at places where I was interrupted several times a day, and I think it has a lot to do with a company's culture. Unfortunately, many companies in my country are dominated by sales people, and these people couldn't care less about software developers. Make sure you will be considered a first class citizen before accepting a job offer.
https://www.amazon.com/gp/product/0525536558/
He takes ideas from Deep Work and builds on them by scaling up the ideas to how an organization should work, coordinate, and collaborate. Specifically, he looks at how to build organizations that are designed to support how our brains have evolved to think & work (without frequent context switches!)
Author here: I really wanted to illustrate the "why" it's frustrating. A more complete visual of what is actually in my head.
Also I didn't get a chance to pull it out as much as I'd like, but I'm my own worst enemy when it comes to interruptions. So I broke my tips into 3 categories: 1. Protect against myself (2 tips) 2. Protect against day to day working cycle (1 tip) 3. Help teams work together to help each other (1 tip)
hence why I catered 2 of the 4 tips to myself.
* When dealing with Ops work or leadership, much of my work is thin and wide. In other words, I spend my time on a LOT of different things, but rarely need to deep dive. When I do need to deep dive, I'm looking at a timebox measured in hours. I can be interrupted because none of my thoughts are difficult to rebuild.
* When I'm programming, I'm working thin and deep. I have a very narrow problem that requires diving into something very deeply. There are often a lot of little details that are potentially blockers. All of that needs to be in active thinking memory - or at least very close to it. When I get interrupted while programming, those auxiliary details go "poof". Sometimes they're hard, if not impossible to get back.
So, instead of breaking my concentration on the loop itself, I just cache that knowledge and go back to it after I've finished the loop body. If I'm then interrupted, or worse, drawn away to something for a while, it's easy for that information to have fallen out by the time I return to finishing the code.
I ultimately need to keep a log of every single task (even if I plan on doing it in a minute) in order to thwart this. I don't like it, but that's just what I have to do to keep from introducing "interruption bugs" in my code.
I think another thing that is irksome is that the same people who are hounding you to finish some task in X amount of time are the ones making it go to 2X with their interruptions.
Rig up a precommit hook that rejects changes containing the string "FIXME"
That simple technique doesn't solve everything, but it goes a long way.
External stimuli is simply processed differently. There can even be a phone ringing for minutes, driving SO and kiddo mad. Yet I don't hear it: or at least it doesn't disturb me.
It even happens, rarely, that I get out of the zone and notice SO is gone and I'm a bit lost then I have to "focus" on the stack now: "ah yup, she said she went to pick her mom for she eats with us tonight".
I honestly don't know how to describe that as something else than being in some kind of zone.
I've seen friends studying for exams being in the same kind of state.
I like being there and I'm convinced I'm doing better work when I'm there.
EDIT: and there's something I do like in TFA: I separate my computer in "virtual desktops" assigned to different things. The main coding virtual desktop / workspace is ads-free for example (got a browser open but only for dev / for testing the (ad-free) thing I'm working on). I've got a "private email" virtual desktop, a "professional email" one (which is separate from the main coding virtual desktop), etc. It just makes sense to me.
My personal biggest issue is self interruptions. Mostly web sites that are distracting.
I'm in the mode where I can't even start programming anymore because interruptions have trained me it is useless to even try.
I'm gradually trying to re-train myself to be productive, but it requires extreme measures.
Just watch some coding streamers on twitch. They can start and stop their coding while interacting with their viewers.
In many ways it's the similar for gamers on twitch. Try holding a conversation while playing a game. Over time they learn to be good at both simultaneously.
There are going to be some programming tasks that are harder to start and stop. But for most programmers those are going to be the exception.
I laid out 4 tips that have helped me focus better.
I purposely made 2 of the 4 tips directed directly at myself. I create the most interruptions to my day.
My team has worked together to reduce unnecessary interruptions (see tip 1) as a courtesy to help me with my bad habits. The key point here is small interruptions are okay, but often not worth it, because I'll go off and do something else. If I could easily bounce back to what I was doing, I'd be much less frustrated at the interruption. My frustration lies with my inability to quickly go back to what I was working on, not the interruption itself.
Notice that I'm not passing the blame at others, I know my weakness. If I open chrome to check Slack, I'm gonna check HN, I'm gonna look at my email. This is something I need to work on personally
There really is a time and efficiency cost to all the task switching g.
But equally, and as another poster said already, software development really does require having meetings to get a good outcome.
I think it’s missed by many people that see meetings as an inconvenience, but very very often I have found that a meeting has radically altered the goal, or the plan, or the context. Pushing back against the meeting would be a crazy thing to do.
Edit: and they'll happily point out the hypocrisy of the sales, marketing, and executive teams on coffee walks.
I've been doing 30 minute standing meetings pretty much every day since the XP folks coined the term "stand up", which was about 20 years ago. Every single one has consisted of the boss talking for 28 minutes (sometimes back and forth with one team member) while everybody else stands around, followed by, "ok, does anybody else have anything?" If anybody says yes, it's "we're almost out of time for this meeting, so let's take it offline".
20 years, five different employers, exact same experience every time, every day. Human psychology doesn't fit this structure the way you want it to.
I remember reading once that Mike Myers, while filming the movie "Wayne's World", came out of his dressing room, found that there was no non-dairy butter for his bagel on the catering table, flipped the table over in anger and returned to his dressing room for the rest of the day.
That sounds like "immature diva" behavior to me. Saying "you want me to deliver the best product possible, and I want that too. In order to do that so that we can both come out ahead, I do my best when I can focus on making sure I get every detail right" seems far less immature. But maybe that's just me?
If you need extreme focus to work with your code, that code is garbage.
Well written and well factored code is easy to get work done in, and you don't need to keep a zillion things in mind to navigate it.
Of course, reality is that the code most people work in is some level of garbage, and maybe there isn't much you can do about that. Either because you're not in charge, or you don't have the skills to improve the code.
Don't have the skills or don't have the time? Predicting, down to the hour, how long every programming task will take before you undertake it has been a staple of programming professionally as long as I've been doing it. I have the skills to simplify a codebase to any level you can define, but I can't do it in an hour.
After I got into the agile/XP world ~15 years ago, there are no deadlines, and if I need to take a day to improve some code, I do.
I'm not saying this to brag about my great life, but to tell you there are other kinds of jobs out there.
That said, a good number of pro developers do not have the skills to write well factored code. Or the interest, frankly.
Maybe _i_ am garbage? Sometimes i need focus to solve the problem in a way that's easy to reason about. So no code exists, nothing you could critique, so perhaps your critique would be just about me?
Sometimes complex problems just require focused thought. Distractions detract focused thought. It's still possible to work through most problems when heavily distracted, but why the argument here? Legitimately, it baffles me. I do think devs over hype the importance of software development (generally speaking), but if an individual needs focus to solve a problem, be it math, software, economics, whatever - why would we argue that they don't actually need to be that focused?
But for anyone dealing with synchronization between threads/processes/machines, modeling engineering problems with large systems of equations, complex business domains, systems programming, actually implementing something from an algorithms textbook yourself, cryptography, or any problem that requires you to keep more than one or two things in your head at once to be solvable, focus is important.
And if the simple crud app mentioned before turns into spaghetti through no fault of your own, you'll still need to focus.
So I'm not going to shame anyone for saying they need to focus.