4 ms·

I remember this article being very influential to me when I read it over a decade ago. This entry in particular resonated with my younger self: > I find one me

I remember this article being very influential to me when I read it over a decade ago. This entry in particular resonated with my younger self: > I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there's sometimes a cascading effect. If I know the afternoon is going to be broken up, I'm slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you're a maker, think of your own case. Over the years as I've gone back and forth between IC and management, adjusted my working schedule after having kids, and generally improved my self-control habits, I no longer identify with this part of the essay. In retrospect, this essay told me what I wanted to hear at the time: That I was a maker and that my managers just didn't understand that my lack of productivity was actually their fault for scheduling a single 1-hour meeting in the middle of the day. I thought meetings should be someone else's job, not mine, and I ate up every excuse to despise them. This essay included. The reality was that my company at the time didn't have an excessive number of meetings, nor were they poorly run. Some companies really do have a ridiculous number of poorly-run meetings, but it's not the norm at well-run engineering companies in my experience. (If your company is all meetings and no work, it's time to change jobs). 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. I decide what I'm going to work on before I unlock the screen. I resist the urge to pull up my e-mail or HN or Twitter or Instagram for "just a few minutes" before getting back to work. And to my surprise, it worked! 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. PG talking about "spirits" dictating our productivity now reminds me of a famous quote that has been attributed to various authors at different times: > I write when I’m inspired, and I see to it that I’m inspired at nine o’clock every morning.

only_as_i_fall 5y ago
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...
- cacois 5y ago
  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.
- majormajor 5y ago
  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. ;)
  - ftkftk 5y ago
    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).
  - username90 5y ago
thrower123 5y ago
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.
- majormajor 5y ago
  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.
  - username90 5y ago
    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.
- dasil003 5y ago
  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).
malfist 5y ago
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%
- w4llstr33t 5y ago
  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.
civilized 5y ago
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)
sillysaurusx 5y ago
It wasn't over a decade ago, don't lie, oh gosh it was over a decade ago. Where did the time go?
NikolaNovak 5y ago
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.
Hermitian909 5y ago
> 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.
username90 5y ago
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?
- username90 5y ago
  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!
coldtea 5y ago
>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 :-)

only_as_i_fall 5y ago

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...

cacois 5y ago
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.
majormajor 5y ago
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. ;)
- ftkftk 5y ago
  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).
- username90 5y ago

thrower123 5y ago

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.

majormajor 5y ago
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.
- username90 5y ago
  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.
dasil003 5y ago
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).

malfist 5y ago

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%

w4llstr33t 5y ago
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.

civilized 5y ago

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)

sillysaurusx 5y ago

It wasn't over a decade ago, don't lie, oh gosh it was over a decade ago. Where did the time go?

NikolaNovak 5y ago

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.

Hermitian909 5y ago

> 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.

username90 5y ago

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?

username90 5y ago
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!

coldtea 5y ago

>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 :-)