Hacker News Reader

I've started paying more attention to myself and other people recently (as opposed to singular focus on technology and architecture), and my opinions and thoughts these days tend to include a nod to the emotional realities as well:

I think how you approach this maker vs manager time / schedule interruptions may also be heavily influenced by whether you see meetings as productive (chance to align, ensure your work is in right direction, get and provide answers and tips, etc); or obstructive (changing what you're doing, wasting your time, interrupting your flow, etc).

Not only will you view the interruption differently, I think it will also genuinely alter how quickly and efficiently you actually return to productive state of mind. If you resent a meeting, the emotional state of your brain will actively (even if subconsciously) work to prevent you efficiently returning to your problem.

I've started actively trying to not resent even meetings that I personally find unproductive; looking for charitable angles such as "This may feel like waste of 30min to me, but it'll save many hours to many other attendees so it's a good thing overall" or "it'll accomplish these goals of client/business/management, and they're the ones writing the cheques, we are here in their service"; and I've found with some planning focus and discipline, I don't lose as much time as I did before.

> I write when I’m inspired, and I see to it that I’m inspired at nine o’clock every morning.

I feel like this undersells the problem, in part because writing does not perfectly match onto software engineering.

I've been working on my productivity for years and I've found how much I'm impacted by interruptions is directly proportional to how hard I need to concentrate to get the work done.

Occasionally my work really pushes up against the limit of how much cognitive load I can handle at which point if the problem required me to track a single more moving piece it would fall apart and I'd fail to solve the problem. At the level of concentration required for that kind of cognitive load I find that on most days I have 2-4 hours of work in me and it must be in a single continuous stream. If I'm interrupted after the first half hour I can still work but I can't get back to that level no matter how hard I try.

Most work doesn't push me that hard. If I'm writing a simple database query or a form in React interruptions are still bad but not so much they ruin my productivity.

I've found this pattern holds true for a goodly number of other engineers as well and think managers should be cognizant of how hard their engineers find their work and plan accordingly. The impact will be different on different teams e.g. my experience would suggest minor interruptions are far less ruinous for web dev teams than those working hard systems work.

Totally agree with what you said here. There's no reason you can't start something ambitious in the morning even with a meeting in a few hours.

Sure you'll pay the cost of context switching, but that's 15 minutes at the max.

Not working because you've got a meeting in the near future is just not working. You don't have to do everything all at once. You don't have to have 100% efficiency or 0%

I've found that it can take longer than 15 minutes to get back in the groove. There is certainly something that happens while coding, i.e. "being in the zone". In my experience, it can take some time to get back to that high productivity, high focus zone. Getting back to a low or medium productivity is easier.

Although I agree that just because there's a meeting in the afternoon, it's not like you can't start something big (could also start something small, or chunk up the big task), however, I think the article still has something useful to remind managers, even today.

Isn't the problem really about cognitive load though?

I agree with you that a 1 hour meeting probably shouldn't ruin your whole day, but I also feel like it can take a fair bit of time to essentially reload the problem I've been working on back into my brain if it happens to be a fairly complex one. This is compounded if it's an actual meaty technical meeting because not only do I lose my train of thought but I have to start a while bunch of other ones and also attempt to jot them down before returning to where I was.

Sounds like you've been at this significantly longer than me, maybe context switching is a skill I just haven't acquired yet...

Its not easy, but I agree with the above poster on this - it can be learned. Maybe we all have different approaches. Here's one of my tricks:

When stepping away from a technical task, I often jot down a bunch of notes that really only I could ever comprehend - words, doodles, whatever scrawl. Usually its related to the problem I'm trying to solve, but I often suspect it doesn't even matter what I wrote down. Because of the fact that I wrote it down while my brain was steeped in the technical task, reviewing the notes helps me get back into that headspace.

You learn to do what you need to, in time.

The truly astoundingly productive engineers I've worked with have been masters of context-switching and gaining expertise in multiple domains. I believe the latter comes from the first: if you can switch domains quickly, you can more rapidly put in more hours of useful experience in multiple domains.

So I largely agree with the OP here: you can either use this as an excuse - "I'm just not that good at context switching, so it's out of my control, if only my manger understood!" - or you can take it as a growth opportunity and decide to try to get better at it. For me, that's looked like a lot more note-taking (I can use this to "reload" my previous context later) and a lot of practice at discipline at just getting back to work even if it means I have to duplicate some steps from before.

The note-taking, it's turned out, has also helped massively, since it makes it easier to bring other people up to speed on what I learned and all the nuances of it.

But obviously this is a work in progress, since I'm here on HN instead of immediately jumping back in to the previous context I had before getting lunch. ;)

Additionally note taking helps (me at least, YMMV) with effectively flushing your buffer and allowing you to switch into the previous problem very quickly. There is almost an anxiety of holding on to/not forgetting some kind of information from a meeting or conversation that immediately vanishes as soon as I commit the thoughts to a medium other than my brain (paper or electronic).

I've found the reverse, it is easy to context switch between tasks you have practiced a lot with. But you still need to practice a lot at doing them, making someone now and then do a task they aren't good at and evaluating them at that task will absolutely ruin their productivity. In this case we are talking about meetings for software engineers who haven't been managers.

>Eventually I started making an effort to get back into the groove quickly after interruptions. When I get back to my desk, I pause for a moment and make a deliberate effort to recall where I left off. (...) If I put some minimal effort into it, I can get right back into the task I was working on, even complex ones like debugging complicated programs.

Nobody argued you can't "go right back into it" (e.g. instead of going to check your email or Facebook, or whatever). The problem is not being able to "go back into it", but to "go back into it without having blown mental state".

"Going back right into it" is easy for simple tasks, which don't require building and following an elaborate mental model. It's bad for implementing subtle or complex behavior, debugging, (re-)architecting a system, and so on.

That it's a problem it has been known for half a century, and it's not just about meetings, all kinds of "context switching" hurt developers.

And perhaps it's not that the essay told you "what you wanted to hear at the time", but that it tells you what you don't want to hear at this time :-)

I tend to agree. And it may vary by person. A lot of people can't truly work for hours on end. A bit of variety in the day can be good.

I wouldn't say that "meetings" are by any means the only or most helpful kind of variety, but if you need to do them anyway, a few per week is not the worst thing in the world.

(And by a few I do mean a few... less than 10 definitely, and ideally well under)

I find it very odd that there is so much push-back these days on here about this idea that engineers actually need to be able to concentrate and that the typical modern workplace is the absolute worst possible conditions for this to occur.

It's of a piece with the impulse I see so often to also downplay and denigrate the difficulty of doing engineering work.

It's a question of skill vs talent. Software needs both, but you can practice and get better at the skill aspects. Having the discipline to start something big in the morning despite knowing there is a meeting in the afternoon is absolutely a practicable skill.

Nah, people falls somewhere on the adhd spectrum and people further in on that will have a harder time focusing when a big thing is coming up. That isn't a skill you train, but a thing you are born with. You can make it look like you are less distracted, and it isn't like managers notice your productivity, but you can't really be less distracted.

You can however practice a specific thing so it no longer feels like a big deal. If you have gone to a thousand meetings then having another one wont be distracting. But most software engineers don't do enough management work to get over that hurdle.

I wouldn't conflate all the different talking points. Environments are different, the number and scope of interruptions are different.

No one who knows what they're talking about would debate that engineers need large blocks of uninterrupted time to get anything done.

But at the same time, not all software projects can be divided up in such a way that individual engineers can just do their thing without frequent communication. This is the whole art of large scale software development, and it is incredibly difficult to get right. Minimizing overall meeting time so ICs can focus is just one consideration, you also need to make sure the right people have a seat at the table for certain decisions or you run the risk of building entirely the wrong thing.

As an engineer you have to fight for your own time, but also trade off against the greater good. If you put your work on a pedestal above everyone else around you (designers and product managers are also ICs that need focus time) then you'll hit a ceiling in terms of the impact you can drive (unless you are a researcher or deep specialist, but those roles are comparatively rare).

I think there are two big flaws in PGs essay.

1. This problem of constant interruptions through email, slack, etc affects everyone. It's extremely arrogant to pretend that it's primarily a problem for the special engineers. (I'm an engineer).

2. The idea that you can't be effective if you don't have half a day free everyday is frankly bullshit, and it gives people a victims mentality if they accept it. Yes, people need uninterrupted time. I assure you that I can code effectively in blocks of 2 hours. It may be slightly less efficient if the only thing that matters is coding, but a lot more matters that pure coding.

It wasn't over a decade ago, don't lie, oh gosh it was over a decade ago.

Where did the time go?

So you spent years practicing being a manager and now you no longer think meetings are a big deal. But how does that help all the software engineers who didn't practice being a manager for many years and therefore still gets very distracted by meetings?

I don't understand the downvotes, are managers really fine with ruining the productivity of their reports just because their own performance wouldn't be hurt in the same scenario? Or don't they recognize that switching to a task you have had a lot of deliberate practice doing costs a lot less than switching to a task you know you are bad at?

Engineer: I would be more productive if we changed X.

Manager: You are lying, I am not hurt by X, you shouldn't be either!!! Just try harder and you will be just as productive!