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.
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%
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...
>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.
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 know if Paul G has ever been a leader of a large organization, but he gets it wrong when it comes to managers. Managers and executives need deep work time as well, they just have higher demands to context switch more frequently than ICs.
If you do go into management, learn to protect enough time for deep work, you need it too.
Edit: "They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started."
This right here is frankly bullshit, and it's wrong on two levels. 1. You absolutely can get into coding or writing in chunks of less than half a day. Second, thinking strategically as a leader is just as hard to get into as coding and/or writing. Leaders/managers have the same challenge, they just have busier calendars.
> I am curious how others have solved this dilemma in a very business driven world where things are to be managed.
As an engineer-turned-manager, I try to be respectful of people's time when it comes to meetings.
Basic meeting courtesy is mandatory:
- Schedule meetings at convenient times for everyone, preferably around natural breaks like lunch time. 1PM meeting after lunch before everyone gets back to work is good. 10:30AM meetings that break up people's morning are bad.
- Send a short agenda for the meeting in the invite. No agenda = no meeting is a good rule. Request agendas from others when invited to a meeting.
- Stick to the agenda and respect people's time. If a conversation goes on more than a few minutes but only concerns a few people, either have them take it offline or add it to the bottom of the agenda so you can cover it after everyone else has been dismissed.
- Keep things as predictable as possible. It's much better if everyone knows that meetings are generally scheduled around lunch time, always come with an agenda, and that off-topic discussions will be discouraged. Don't keep people guessing about whether or not a meeting will be productive.
Finally, some employees can benefit from a little coaching and mentoring about how to get back in the groove. If someone is struggling to get anything done on days with meetings, they will likely benefit from some coaching about how to best manage interruptions and get back into the workflow. They can also benefit from increased accountability around those days, which doesn't have to be painful if handled correctly. Some people have some "learned helplessness" around interruptions at other companies where they don't bother doing anything on days where meetings are on their calendar. Training this out of employees and setting healthy but reasonable expectations is very important.
- Get rid of as many standing meetings as you can, and then get rid of more of them (1 a week is max)
- At the end of every standing meeting, ask the group "Do we still need this meeting?"
- If you feel you need a regular standup, do it on slack/whatever-you-use instead and asynchronous
- The non-makers still need to be able to communicate with the makers, provide a clear chain of communication so that the smallest number of makers are disturbed in an ad-hoc fashion, preferably only 1 (usually a tech lead / engineering manager)
For any meeting I schedule, in addition to having sent the agenda over email, I always kick off the meeting with "Here's what I want to get out of our time together: <spiel goes here>..." and then some variation of "Does that seem like the right set of things to talk about?"
The last 2 VPs I've been under have had similar takes on meeting attendance: don't feel obliged to continue in a meeting if it's not providing value to you and you aren't providing value to it. This is, admittedly, way easier in COVID, where you can just drop off without much notice. But there's a polite way to do this in person (send an IM message to the meeting organizer politely saying you have other commitment/need to work on a near term delivery, and excuse yourself from the room).
Depending on the situation, I've found your-mileage-may-vary with trying no meeting days. Currently, as a principal engineer at a big tech company, it pretty much doesn't work. At smaller companies (or in smaller teams) I've found it works better.
For devs looking for "good" management (and for existing managers that don't know what they are doing but are willing to let go of their ego), here are a few questions to ask
- Is the manager reducing bureaucracy for you or increasing it? Reducing is better
- Is the manager able to solve people challenges or is he shoving it down to you? Politics is strictly a management domain. They should be able to talk around the org and get shit done, even when someone not on their team is impeding progress
- Does the manager take ownership of failures of the team or does he shove down the failure to ICs? For those uninitiated, the manager takes responsibility of failed projects
- Does the manager celebrate your achievements and success or do they just paper over it? The manager should be the biggest cheerleader of successes of their engineers. If they don't highlight your work to upper management, that will impede your growth in the career ladder. DO NOT WORK TOO HARD for such lazy, incompetent managers. Your work is not appreciated
- Does you manager lie? Should be obvious, but a lying manager will lie to save themselves, even if they are only lying to others today.
Is this checklist large? Not really considering how much impact a manager can have on an ICs career.
ICs should be aware of these traits and should hold their managers to high standards. If manager cannot do even this much, quit asap.
> When we were working on our own startup, back in the 90s, I evolved another trick for partitioning the day. I used to program from dinner till about 3 am every day, because at night no one could interrupt me. Then I'd sleep till about 11 am, and come in and work until dinner on what I called "business stuff." I never thought of it in these terms, but in effect I had two workdays each day, one on the manager's schedule and one on the maker's.
Co-incidentally I found myself working this same schedule at my first full-time job in the 90s. The 11am slipped into mid-afternoon and there was a period where an all-hands/devs meeting (I think it was for deciding the release details of our shrink-wrap physically shipped software) was set for 6pm to be certain I'd be present. It certainly was productive. Sometimes I'd have a vague idea in the afternoon and have a prototype running demos the next day that became a shipping feature within a week.
We're actually working on a product to help with this. More generally, we're focused on the massive impact meetings have on our day/team and how we can get the most from them. One of our main benefits to start is that we automatically send a simple prompt to meeting attendees after a recurring meetings to rate the meeting, and then give you a view of that rating over time. You can log in and view the most time consuming meetings for the team and how their ratings are changing over time. This way, if a recurring meeting started as useful but is no longer serving it's purpose, it becomes easy to detect and eliminate. If anyone would be interested in joining our beta program, we're offering the tool completely free in exchange for feedback. Let me know!
When you love what you're making, you can do it in small increments amid interruptions, and pick up right where you left off. Your brain never leaves "maker mode"; the gears keep spinning in the background while you're away from it.
That's how it's been on my side projects for years.
You might get large blocks of uninterrupted time at a job during weekday office hours, but not in side projects evenings and weekends. Not if you have a family.
When you love the project, you will be surprised at how well you can progress in 5, 10, 15-minute intervals virtually as if they were a single block of time.
I've returned to half-done code (not even syntactically valid), half-written commit messages, debug sessions, and picked it up without skipping a beat.
I think the interruptions are harmful when you're working on something you don't fully understand. You had to ramp up on it quickly, and to get through the task, you're juggling a whole clump of new, unfamiliar information in your short-term memory --- some of it not even proper information, but unconfirmed, competing hypotheses on how various things work. You have to work hard just to build that up so you can navigate and contextualize what you're doing. Much of that short term information can vaporize if you are interrupted.
But that's not exactly the situation of maker. The maker knows what he or she is making. He or she understands the existing thing, inside out; none of that vaporizes due to an interruption.
So how can someone deal with interruptions who is in this situation? I think: write stuff down! Don't carry it all in your head. Document. Open a "knowledge file" and type. If you have three competing, unconfirmed hypotheses about how something works, write them out. After an interruption, you can reload the context by re-reading that file. If you have a plan about what your next steps are, write those steps down. Write down what you've already tried and the results.
Whenever I control or can influence a meeting time, I find the earliest time of day I can. That way, whatever time is left in the workday, it's mine to focus on whatever project is at hand.
However the advantage (at least to me) of meeting later in the day is that I may well be flagging anyway, and meetings tend to require less concentration. My preference is therefore to try and group meetings together and block out one or more afternoons for them as necessary.
The switching cost is real. I explained this to folks at Microsoft. Microsoft is kind of bad at allowing for focused work in the scenarios I've observed (not necessarily a universal paradigm).
I also once kept the "dinner to 3 am" schedule with 10-4 meetings at Microsoft and it was very effective for everything except my personal life.
I've lived this both as an engineer and a PM. I tried to set aside at least 4 hrs focus time for people that reported to me, no matter their role. Not many others respect those boundaries.
A trap that I've been caught in repeatedly over the years is the 10AM, 3PM daily standing meeting pattern, which is almost uniquely capable of preventing any actual work from being done.
It often manifests as an Agile/Scrum standup at 10AM that balloons into an hour-long status meeting. This effect worsens as people start to treat that meeting as the beginning of the work-day, and increasingly show up later, and more unprepared.
Then, after that meeting completes, there is a brief flurry to handle any follow-ups generated by the morning meetings, and then it is lunch time.
People drag back in from lunch, and maybe handle some responses from their pre-lunch follow-ups, and then it is time for the standing afternoon meeting. Usually this just recapitulates everything that was discussed in the morning, since no one has had any time to actually do anything. By the time it finally wraps up at 4:30 PM, everyone's brains have utterly dissolved, and they go home.
I agree with all the points about context switching and managing the right schedule, but I'm getting slightly exhausted with this divide between "managers" and "makers". It feels like managers are indirectly getting demonized as some bloated overhead.
I'd like to see an org function long term with no managers - I'll bet good money it can't be done.
[+] [-] PragmaticPulp|4 years ago|reply
> 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.
[+] [-] NikolaNovak|4 years ago|reply
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|4 years ago|reply
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.
[+] [-] malfist|4 years ago|reply
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%
[+] [-] only_as_i_fall|4 years ago|reply
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...
[+] [-] coldtea|4 years ago|reply
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 :-)
[+] [-] civilized|4 years ago|reply
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)
[+] [-] thrower123|4 years ago|reply
It's of a piece with the impulse I see so often to also downplay and denigrate the difficulty of doing engineering work.
[+] [-] sillysaurusx|4 years ago|reply
Where did the time go?
[+] [-] username90|4 years ago|reply
[+] [-] jshen|4 years ago|reply
If you do go into management, learn to protect enough time for deep work, you need it too.
Edit: "They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started."
This right here is frankly bullshit, and it's wrong on two levels. 1. You absolutely can get into coding or writing in chunks of less than half a day. Second, thinking strategically as a leader is just as hard to get into as coding and/or writing. Leaders/managers have the same challenge, they just have busier calendars.
[+] [-] kokanator|4 years ago|reply
We have tried various things, work blocks, no meeting days, etc. without ever really understand what the true root of the issue is.
I am curious how others have solved this dilemma in a very business driven world where things are to be managed.
[+] [-] PragmaticPulp|4 years ago|reply
As an engineer-turned-manager, I try to be respectful of people's time when it comes to meetings.
Basic meeting courtesy is mandatory:
- Schedule meetings at convenient times for everyone, preferably around natural breaks like lunch time. 1PM meeting after lunch before everyone gets back to work is good. 10:30AM meetings that break up people's morning are bad.
- Send a short agenda for the meeting in the invite. No agenda = no meeting is a good rule. Request agendas from others when invited to a meeting.
- Stick to the agenda and respect people's time. If a conversation goes on more than a few minutes but only concerns a few people, either have them take it offline or add it to the bottom of the agenda so you can cover it after everyone else has been dismissed.
- Keep things as predictable as possible. It's much better if everyone knows that meetings are generally scheduled around lunch time, always come with an agenda, and that off-topic discussions will be discouraged. Don't keep people guessing about whether or not a meeting will be productive.
Finally, some employees can benefit from a little coaching and mentoring about how to get back in the groove. If someone is struggling to get anything done on days with meetings, they will likely benefit from some coaching about how to best manage interruptions and get back into the workflow. They can also benefit from increased accountability around those days, which doesn't have to be painful if handled correctly. Some people have some "learned helplessness" around interruptions at other companies where they don't bother doing anything on days where meetings are on their calendar. Training this out of employees and setting healthy but reasonable expectations is very important.
[+] [-] briandilley|4 years ago|reply
- Get rid of as many standing meetings as you can, and then get rid of more of them (1 a week is max)
- At the end of every standing meeting, ask the group "Do we still need this meeting?"
- If you feel you need a regular standup, do it on slack/whatever-you-use instead and asynchronous
- The non-makers still need to be able to communicate with the makers, provide a clear chain of communication so that the smallest number of makers are disturbed in an ad-hoc fashion, preferably only 1 (usually a tech lead / engineering manager)
[+] [-] jkingsbery|4 years ago|reply
The last 2 VPs I've been under have had similar takes on meeting attendance: don't feel obliged to continue in a meeting if it's not providing value to you and you aren't providing value to it. This is, admittedly, way easier in COVID, where you can just drop off without much notice. But there's a polite way to do this in person (send an IM message to the meeting organizer politely saying you have other commitment/need to work on a near term delivery, and excuse yourself from the room).
Depending on the situation, I've found your-mileage-may-vary with trying no meeting days. Currently, as a principal engineer at a big tech company, it pretty much doesn't work. At smaller companies (or in smaller teams) I've found it works better.
[+] [-] nine_zeros|4 years ago|reply
- Is the manager reducing bureaucracy for you or increasing it? Reducing is better
- Is the manager able to solve people challenges or is he shoving it down to you? Politics is strictly a management domain. They should be able to talk around the org and get shit done, even when someone not on their team is impeding progress
- Does the manager take ownership of failures of the team or does he shove down the failure to ICs? For those uninitiated, the manager takes responsibility of failed projects
- Does the manager celebrate your achievements and success or do they just paper over it? The manager should be the biggest cheerleader of successes of their engineers. If they don't highlight your work to upper management, that will impede your growth in the career ladder. DO NOT WORK TOO HARD for such lazy, incompetent managers. Your work is not appreciated
- Does you manager lie? Should be obvious, but a lying manager will lie to save themselves, even if they are only lying to others today.
Is this checklist large? Not really considering how much impact a manager can have on an ICs career.
ICs should be aware of these traits and should hold their managers to high standards. If manager cannot do even this much, quit asap.
[+] [-] karmakaze|4 years ago|reply
Co-incidentally I found myself working this same schedule at my first full-time job in the 90s. The 11am slipped into mid-afternoon and there was a period where an all-hands/devs meeting (I think it was for deciding the release details of our shrink-wrap physically shipped software) was set for 6pm to be certain I'd be present. It certainly was productive. Sometimes I'd have a vague idea in the afternoon and have a prototype running demos the next day that became a shipping feature within a week.
[+] [-] CuriousPerson23|4 years ago|reply
[+] [-] CuriousPerson23|4 years ago|reply
[+] [-] kazinator|4 years ago|reply
When you love what you're making, you can do it in small increments amid interruptions, and pick up right where you left off. Your brain never leaves "maker mode"; the gears keep spinning in the background while you're away from it.
That's how it's been on my side projects for years.
You might get large blocks of uninterrupted time at a job during weekday office hours, but not in side projects evenings and weekends. Not if you have a family.
When you love the project, you will be surprised at how well you can progress in 5, 10, 15-minute intervals virtually as if they were a single block of time.
I've returned to half-done code (not even syntactically valid), half-written commit messages, debug sessions, and picked it up without skipping a beat.
I think the interruptions are harmful when you're working on something you don't fully understand. You had to ramp up on it quickly, and to get through the task, you're juggling a whole clump of new, unfamiliar information in your short-term memory --- some of it not even proper information, but unconfirmed, competing hypotheses on how various things work. You have to work hard just to build that up so you can navigate and contextualize what you're doing. Much of that short term information can vaporize if you are interrupted.
But that's not exactly the situation of maker. The maker knows what he or she is making. He or she understands the existing thing, inside out; none of that vaporizes due to an interruption.
So how can someone deal with interruptions who is in this situation? I think: write stuff down! Don't carry it all in your head. Document. Open a "knowledge file" and type. If you have three competing, unconfirmed hypotheses about how something works, write them out. After an interruption, you can reload the context by re-reading that file. If you have a plan about what your next steps are, write those steps down. Write down what you've already tried and the results.
[+] [-] ineedasername|4 years ago|reply
[+] [-] indigomm|4 years ago|reply
[+] [-] l8rpeace|4 years ago|reply
I also once kept the "dinner to 3 am" schedule with 10-4 meetings at Microsoft and it was very effective for everything except my personal life.
I've lived this both as an engineer and a PM. I tried to set aside at least 4 hrs focus time for people that reported to me, no matter their role. Not many others respect those boundaries.
[+] [-] thrower123|4 years ago|reply
It often manifests as an Agile/Scrum standup at 10AM that balloons into an hour-long status meeting. This effect worsens as people start to treat that meeting as the beginning of the work-day, and increasingly show up later, and more unprepared.
Then, after that meeting completes, there is a brief flurry to handle any follow-ups generated by the morning meetings, and then it is lunch time.
People drag back in from lunch, and maybe handle some responses from their pre-lunch follow-ups, and then it is time for the standing afternoon meeting. Usually this just recapitulates everything that was discussed in the morning, since no one has had any time to actually do anything. By the time it finally wraps up at 4:30 PM, everyone's brains have utterly dissolved, and they go home.
And then it starts again.
[+] [-] nooyurrsdey|4 years ago|reply
I'd like to see an org function long term with no managers - I'll bet good money it can't be done.