If I know I am going to have my day broken into sub 1hr chunks thanks to meetings and such, I pretty much write off the day entirely. It takes time to get into the flow state, some studies cite over 20 minutes, and once you are in it you want to stay in it for like four hours. No emails to follow up with, no slack, no zooms, no one tapping your shoulder, no conversations about the weekend distracting you on the periphery, just you and your task at hand.
It's pretty ironic, because this is how a lot of people study in the library at college,show up and stay all night grinding in the flow state with your phone shut off. Yet when you graduate to the work place, you seldom have the opportunity to work like how you've been training to work for all your advanced schooling ever again.
With respect to the article and maintaining context while coding for different projects, I find having a tmux session for each individual project super helpful.
> no slack, no zooms, no one tapping your shoulder, no conversations about the weekend distracting you on the periphery
My teen jobs were in stores, restaurants, and manufacturing. In those contexts, everybody understands that when you're working, you're actually working. Even managers understand that even small discussions need to be fit neatly into the flow of the work, and actual meetings require careful planning to not disrupt operations. The space too was carefully designed to maximize effectiveness.
So American office culture seems absolutely wild to me. Especially in software, where we are expected to fit our actual work into a sort of calendar Tetris. Oh, a grand poobah would like another status meeting, plus a lot of time spent coming up with estimates that are not going to change anybody's behavior in the slightest? Gosh, do you think that might have an effect on the completion date? And sure, why don't you put me next to the salespeople making calls all day. I'm not making any progress anyhow.
The only conclusion I can come to is that in a lot of places, productivity is much lower on the list of observed priorities than stated priorities.
> It's pretty ironic, because this is how a lot of people study in the library at college,show up and stay all night grinding in the flow state with your phone shut off. Yet when you graduate to the work place, you seldom have the opportunity to work like how you've been training to work for all your advanced schooling ever again.
To be fair, I think staying up all night trying to be productive instead of getting a good night's sleep also makes it hard for most people during the day. As someone who consistently got 6-8 hours of sleep every night in college before a day with classes, I've always been mildly horrified by the fact that "staying up all night studying" is somehow considered a good thing.
I also do much better with long chunks of time, but it should be possible to make meaningful progress on most programming tasks in a true 1-hour block. It’s common for people to use the Pomodoro technique to great success with blocks of work half that size.
Often, the real problem is that people don’t actually have 1 hour of working time in between meetings. We sit at our desks and feel obligated to respond to e-mails and Slack messages. Our Slack responses turn into conversations that consume 5-20 minutes without a clear end. We need to spend 5-10 minutes reading backlog to catch up. We need to get a drink or use the restroom. That 1-hour chunk of free time on your calendar may only have 10-15 minutes of concentration time, which is the real problem.
I’ve had some success with blocking off calendar time to mark 1-2 hours of focus time. Having something on your calendar makes delayed responses in Slack socially acceptable.
I think this is the mindset that a lot of people have, but always keep in mind, the meetings is part of your job, and writing code is also only one aspect of your job.
What I'm trying to say is that don't let the meetings frustrate you, instead just accept them and the distractions. Few people get to do what they really want to do all the time, and it does often seem that software developers show some prima donna behaviour in that they just want to stay in their flow and the other aspects of their job should be dismissed.
I mean I get it, writing code / flow state is enjoyable and makes you feel productive, but you get paid for the full package.
I have the unfortunate privilege to work at a firm where the senior engineering leaders believe context switching is a requirement. They judge people on whether they can do it.
I find that this leads everyone to constantly do multiple concurrent tasks. After a long day I often have a headache from having to concentrate on both my coding task, an operations task, a meeting, and a new request at the same time.
Ultimately, as you would expect - productivity is awful. They then have lengthy discussions on how to improve productivity by every mechanism other than what’s known to work (faster builds, faster tests, increased focus time)
Having tmux sessions for each open task is a life-saver, especially in an environment where I do all my work on a remote server. Now I can close the laptop lid and never lose work. Simply reopen the ssh connection and keep going.
From Paul Graham's Maker's Schedule, Manager's Schedule essay:
> (programmers) 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.
> meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.
> I find one meeting can sometimes affect a whole day.
> I know this may sound oversensitive, but ... don't your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don't. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.
Sadly, the cost of context switching is well-known, and has been proven, over and over again, for decades.
But managers don't care (and many co-workers also).
A quick shufti at most modern open-plan offices, shows the contempt that managers have for developer context. They know better, and have made the conscious decision to go open, anyway.
I remember visiting the Facebook/Instagram building, in NYC, and was aghast at the huge, noisy, crowded office. I would not be able to get any work done, in that environment.
I'm grateful to be in a position, where I work alone (mostly), as I can keep all those balls in the air, and the difference in productivity is amazing.
This killed me my last few years at Apple in the spaceship. Everything in the fucking building is a distraction and most of it is constantly in your line of sight at all times.
Even if I managed to angle my monitor right, put on headphones, and pull my hoodie up to reduce distractions some side conversation or impromptu stand up would inevitably distract me and pull me out of my flow. I tried to come in as late as practical in order to stay late so I could get work done for a few uninterrupted hours. I found myself going in a day on the weekend to actually get the previous week's work finished. Unfortunately management doesn't like people coming in "late" because they can't lord over them from their offices during the day and constantly interrupt them with meetings.
It was downright insulting that a $5b building intended for professionals didn't have real offices with fucking doors. At the upper management level the fact the company worked as well if not better with WFH policies must be incensing. It makes plain the insipid claims about "collaboration" in that stupid building. Collaboration happens when engineers want to share ideas, not because they're imprisoned in a glorified fish tank for eight hours a day.
> But managers don't care (and many co-workers also).
For the majority, the cost is not that well known and in general they are not the ones paying for it, you are.
In particular for your colleagues it may be beneficial to disturb you because when they disturb you, you may lose concentration but the may in fact avoid losing it by quickly get an answer to their pending problem.
This is one aspect where LLMs may be very useful: asking something to a tool like ChatGPT may not be faster than asking a colleague, but if it avoids ruining the colleague's concentration it will be a net positive for the company. This is even more true if/when those model will incorporate specific internal knowledge (code, documentation) of the company.
Huh, I really thought `shufti` was a typo in this context, and one that sounded funny to my Middle Eastern ears, so I was surprised to discover it's a real word, albeit with Middle Eastern origins [1].
I'm really grateful to have a non-obtrusive work environment as well.
I check in with the team once a week and make sure the task tracking system is updated. Everyone is happy and stuff gets done.
We're going to have to do some more hands-on work down the line where we're going to need physical presence working with hardware which is going to be an interesting shift, but I still think that we're going to mostly adhere to the usual workflow.
Not that I like to be interrupted, but if it’s inevitable, here is my method. I’m using it when interruptions are planned, when a task is complex by itself, at refactorings and on bad/lazy days.
Log all your key thoughts, realizations, decisions and taken steps on paper. It shouldn’t be long or long-term clear, only clear to today’s you. Gibberish to a bystander. Text, bullets, arrows, acronyms, verbs, marks, anything that works. Lists, trees, graphs, outlines.
It’s your L2 cache. L1 is fast but short and prone to distraction. If you log everything into L2, then returning to the task becomes much easier, because the whole context is right there.
The downside is you have to spend time drawing. The unintuitive upside is that by writing you may make it clear to yourself what maybe wasn’t clear.
IDE may be good at where you were, but it doesn’t know what you thought.
Stuff like this is why I love Hacker News. Rather than making up abstract, weird analogies between a thing, and another very abstract thing I find even more difficult to understand, we can make analogies to technical terms which most people here understand [citation needed], and which anyone who doesn't can easily look up.
> Log all your key thoughts, realizations, decisions and taken steps on paper... Text, bullets, arrows, acronyms, verbs, marks, anything that works. Lists, trees, graphs, outlines ... It’s your L2 cache.
This works out nice for using GPT4. If you prepare project information beforehand you can use it in your prompts. I am working on a way to structure my notes to be AI compatible. We can benefit from having to keep prompt materials for GPT, a good reason to have detailed notes in the first place and it's exactly the diff between general knowledge and project knowledge.
I’ve done this but it’s about 7 times slower than keeping stuff in my head.
My mental state isn’t easily capturable on paper since I use visual/spartial memory for programming. Witting it down requires enormous amounts of translation.
I don't remember where I read it, in a book or on HN or even if someone told it to me. But I learned that when requesting time or disruption: certain positions need specialised handling.
An example:
A receptionist does not necessarily need focus time, and is interrupt driven, so their work should not stretch to more than 5 minute intervals; if something takes more than 5 minutes it must be filed for someone else.
A manager manages their time in 30 minute increments, anything that can't reasonably be done inside a meeting is unfortunately unlikely to happen. This is stupid, but it's unfortunately true; you might sometimes experience other situations but I think that's not the common case.
A programmer (or, researcher, etc;etc) books time in half-day increments. If you must have a meeting with programmers, it's often better to book events in serial but only consume half a day.
I've been practising this methodology for 8 or so months in my org and it does seem to hold true in the general case, there are some minor exceptions but most people do seem to he happy.
EDIT: It was the "Makers Schedule" by PG; Serves me right not to read the comments[0] before commenting.
I feel that this is extremely dismissive of the reality that other people do in fact have similar focus requirements, but simply have learned to take notes or otherwise deal with interruptions.
There are more demand driven roles but probably every person you interface with on a day to day basis professionally has hard work to do. Sales copy? Focus. Figuring out some accounting discrepancy? Focus. Trying to actually plan out the next quarters projects in a decent way? Focus. Trying to find a good place for a year end party? Focus!
The reality is that everyone has similar interruption issues, but understands the existence of needs beyond themselves when working on a team. Programmers are maybe special in the level of coddling gotten on this topic. Along with a dose of having people more likely to have general executive control issues.
This mythologizing gets in the way of trying to tactically improve things. Real things programmers can do, such as take notes on paper, documenting ideas, writing exit/entry notes, and many other things people do to be able to come back into a project after interruptions.
It’s very liberating to find workflows where you can actually get stuff done even in small increments, because you are not relying on this idea of doing a hard reset of your mind every time you switch tasks
EDIT: to be clear, it’s good to let people work uninterrupted. Sometimes interruptions are needed because of working in a company where other people also have needs. This is true of many people working at a company, and so we should operate understanding interruptions exist and we are the same as other people.
For me it's not really to do with how much stuff is on the screen. It's more that when you're doing creative work, the intermediate state is a bunch of maybe-graphs. Maybe the bug is a->b->c, maybe the bug is caused by d + e -> c, etc. Once you find it, you know what it is and you can discard the explanations that are wrong. But before that, you have a bunch of hypotheses. Plus your mind knows that you intend to forget the details.
When you're interrupted, you forget a bunch of the maybes and you have to rebuild them. This is because your evidence is not strong enough yet to have a small graph, it needs to be a big graph (or set).
Main advice is to take small steps. Little pieces that are easily recoverable. Things like unit tests help to establish the facts, allowing you to push some things out of your own memory. Also take some notes to jig your memory.
Sometimes you can't take small steps, because it just happens that you didn't consider something and now there's a large surface to think about. For those times, make sure you're not interrupted.
Now I have a family I often can't choose the end of my working day so it coincides with a natural break in my work. In those circumstances, when I know they're going to arrive back in less than 30 minutes, I stop working and do a brain dump of everything that's going on in my head into a plain text file. With that I can pick things up much faster the next morning. I've even started doing it during the day when both my wife and I are working from home and we're about to have lunch together. I'd seriously recommend it.
It somewhat reminds me of this Hemingway quote "You read what you have written and, as you always stop when you know what is going to happen next, you go on from there. You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again." I think there's an art to stopping at the right time, even if it's within constraints that aren't in your control.
Yeah, in the last few years I've started keeping a work log for projects. It's mostly a way to externalize and clarify thoughts. But I'll definitely use it for an end-of-session record of where I'm leaving off and where to pick up.
And where it's possible, I love unit tests for this. Starting off in the morning with a failing unit test from yesterday's close gets me right back into it.
I remember reading an article long time ago, written by an engineer in India. He became famous in India(or at least in my city, Pune, where he lived) for reverse engineering Windows NT. He along with his friends later on wrote the book "Undocumented Windows NT". He was promptly hired by Microsoft, and moved to the US. He later wrote an article on his experience working for Microsoft. One thing I vividly remember from that article was his experience the very first day at work. He observed that every engineer had a separate room. He was not used to this luxury. He was awed. During the day, he had a question on some aspect of the project he was assigned, and he immediately went to the next room where one of his colleagues was working. His colleague instead frowned and asked him to first send a meeting request, and then he will alot him a time. This surprised the new employee. He was not used to this way of "team work". He went back and sent a formal request and later there was a meeting to resolve the project issue.
Afterwards, he enquired why engineers were kept separate in their own rooms? And why does one have to be so formal in requesting a meeting even to discuss project issues? It takes lot of time to resolve issues. Why this inefficiency? And the reply he got was, engineers when they are working, they get into a zone. It is very difficult to get into a zone, but very easy to get out of it even with a slightest distraction or interruption. Hence Microsoft provides separate rooms for engineers and meetings are available only when the engineer is free.
If you're having a huge issue with this, I suggest trying to find ways to hold less context at one time.
Write stuff down & get it out of your head more often. Write down all of your ideas & break down your tasks into smaller tasks. Don't try & solve a giant problem all at once without writing down what you're going to do. You may also discover issues earlier.
It doesn't get rid of the issue 100% but it helps a lot. I say this as a dev who has to do a lot of context switching.
Do you write it down to read it? Or write it down just to write it down? I find myself doing the latter a lot lately- synthesizing rough ideas to a couple approaches or components and prob a little sketch. I feel a bit guilty that I toss them without reading but for me I think the value is it crystalizes my thinking by putting a pen to paper.
My company likes to schedule at least 20 hours of meetings spread across the week in such a way that you rarely get more than 30 minutes in between two. Then management wonders why it takes so long to get anything done. Guess its a mystery. Let’s schedule a recurring meeting to discuss it…
I wonder why it is not acceptable in many companies to skip meetings as you see fit. I can do that at my workplace, with the possible exceptions of a 1:1 with my manager (30 minutes once a month) and the main team meeting (1-2 hours every other month, usually).
And I still can skip those meetings just by telling my manager that I have something quite urgent to do and that I will come back to them later (in case of the 1:1) or read the meeting minutes (in case of the team meeting).
On the other hand we have an "open office" layout here. But I am 99% working from home, so I am "skipping" that as well, mostly.
I actively like being distracted when I'm programming. I tend to approach a problem from lots of different directions, each time fizzling out, hitting a block or having some sort of mental reset, until something unconsciously clicks and an overall structure, understanding or solution emerges. Continually leaving and returning to the problem is a part of that process, so I tend to find someone walking up with a question rather welcome. The biggest and most effective leave-and-return is of course to sleep on it, and it's rare that I go to bed with a problem at the back of my mind and don't wake up with at least a new approach or insight.
I have to be careful, though, as I'm aware most of my colleagues don't feel the same way about interruptions.
Indeed, this seems unusual in programmer land. As evidence we have a thread like the current one reaching the front page several times a day.
But your way is also my way. I am active in a very wide array of topics, and happy to flit between them. Sometimes I dive deep, but it's usually in a critical moment of synthesis when ideas developed over months or years come to clarity and I put them to action. This is working extremely well for me. I lack nothing and am at the absolute cutting edge in every topic I'm pursuing. Of course this is my opinion but it's sufficient to say that I'm happy.
It is sad to see how many people are made uncomfortable by interruption. It's the stuff of life, social life at least, and exactly what makes being human in a dense society so wonderful. I feel it represents a fundamental discomfort with being in situations out of one's control. But, that's the core of life. And for me it's where all the creative energy comes from.
edit: Reflecting on John Carmack and his big monitor. I habitually work in single window terminals with relatively low row counts and big fonts. I seem to be unable to get a benefit from seeing more stuff all at once.
edit2: And in terms of getting into flow state, for me it is always basically instantaneous. The flow is just sitting there under a few seconds of pause. Of course sitting at a computer or phone will cause wandering distraction at times, but if work is in play I can start driving at full speed in what would typically be seen as a horrifically uncomfortable position. Imagine a long distance train with two children jumping on you... If I can see my laptop and the kids at the same time, I'm flowing. I think this might be neurological somehow, due to training or genetics. It's unclear.
Have you considered a leadership role? It occurs to me that if flow is the natural state of programming, and interruption the natural state of business, then someone has to be able to bridge those states. Preferably someone who understands the subject matter and can prevent the software team from becoming an isolated silo.
I also do OK with interruptions, and have found a role where I'm not programming 100% of the time, and the subject matter itself -- doing experiments and hardware testing -- doesn't really lend itself to flow anyway. But being able to program means that I don't have to interrupt the programmers every time my requirements change, which can happen on an hourly basis.
Same. If I stare at the same issue for more than 15 minutes I'm probably going in loops and not recognizing it. Get up, walk around, go outside even. Answer will frequently present itself the minute I get back into it.
I am trying to explain it to my wife (using the cartoon on the article) but she says I am always busy.
Which is probably true, but somehow she manages to interrupt my thoughts right when I was holding the whole heap in one hand, reaching for the duct tape with the other and pushing the keyboard with the nose.
Reading through the comments here, and in the ton of similar threads on this subject, I feel I must be such an outlier...
For me there are different tasks and different days. Some days I want uninterrupted flow. But some days I feel more productive by chopping it up with a few meetings and some office trash talk. A laugh every now and then, teasing a co-worker for screaming at his code - it gives energy to me. Talking through a problem or pausing for a while in a meeting and then returning to it - that can be a great way to see new things.
Now don't get me wrong here, I am not saying meetings and distractions are good for everybody. But it's just that for me at least the picture is not as clear. Some days I feel I would have been more productive if I had had some meetings to distract me.
I usually split my work-week in office and remote work. When I am in office I plan for having meetings with stakeholders, architecture/mob coding with my coworkers, etc.
But when I am at home I can focus on the projects I need to execute on, fairly uninterrupted.
It is not perfect and isn't quite as black and white as it may seem, and it is difficult to communicate that this is how you're working, but just doing it in my org has been pretty good.
I probably have one of the more outreaching roles, some mix between an architect and devrel with a sprinkle of actual execution, so even if it is an outreach kind of role it actually works pretty well.
I have a similar feeling. For some work I need to focus, but the "why don't we scrap this idea for one that does the same thing in 1/10 the code"-moments have mostly been in and between meetings and office chatter.
I view coding as creative work not that different from writing or drawing. Sure there are techniques and rules to follow, but to do great work you need to get in the flow of things until your creative brain figures stuff out on its own. It takes time to warm up and any interruption destroys the momentum you had. I put my phone on airplane mode for most of the work day because of this.
The problem is not that some managers think that it’s OK for software engineers to be interrupted frequently. The problem is that some managers think that frequently interrupting software engineers is a feature of startup culture. I once worked for a startup where I was interrupted frequently. My boss often worked remotely, while I was in the office every day. If I tried to carve out periods to write code where I ignored slack and text messages, my boss would call people in the office to interrupt me. If I put on headphones to isolate from the sound, people would come wave their hands in my face or tap me on the shoulder. When I explained that I needed periods where I was not interrupted, I was told by the director of software that I “didn’t understand how startups work” and that I was “acting like a girl”. I quit, and shortly after I quit the company went out of business.
At a job I had they wanted me to install an instant messaging app on my compute! I refused point blank. I said they could email me and I'd look at he email every so often. If it was really important they could get up and walk to see me. If it wasn't important enough for others to walk then it definitely wasn't important enough to interrupt me.
Before that I was at a place where they had tannoys. I moved the tannoys away from me but they were still annoying. I tried showuing that they were losing the place millions. It would have been far cheaper to have somebody employed to walk around looking for people. They only got rid of them when marketing got in and the first thing they said was to et rid of the tannoy.
One of the most elegant ways I have heard "flow" explained was by an old colleague of mine. He called it "balancing the chandelier". Don't know if it's his thought originally or if he heard it some where but it always stuck with me.
But yeah, sometimes find it almost violating in a way, especially when its that typical PM line "hey did you read my email?" (that was literally sent 10 seconds ago).
It just feels like someone coming over to my desk and pushing, monitors, scopes, everything off and smashing it on the floor, then walking off.
Now I have both unrealistic deadline AND a mess to clean up.
I don't know where I'm going with this comment. Just venting I guess :)
One of the perks of growing up in a huge family is that you learn how to work in an noisy environment while being constantly interrupted. Never occurred to me one day I will count that as a skill.
[+] [-] asdff|2 years ago|reply
It's pretty ironic, because this is how a lot of people study in the library at college,show up and stay all night grinding in the flow state with your phone shut off. Yet when you graduate to the work place, you seldom have the opportunity to work like how you've been training to work for all your advanced schooling ever again.
With respect to the article and maintaining context while coding for different projects, I find having a tmux session for each individual project super helpful.
[+] [-] wpietri|2 years ago|reply
My teen jobs were in stores, restaurants, and manufacturing. In those contexts, everybody understands that when you're working, you're actually working. Even managers understand that even small discussions need to be fit neatly into the flow of the work, and actual meetings require careful planning to not disrupt operations. The space too was carefully designed to maximize effectiveness.
So American office culture seems absolutely wild to me. Especially in software, where we are expected to fit our actual work into a sort of calendar Tetris. Oh, a grand poobah would like another status meeting, plus a lot of time spent coming up with estimates that are not going to change anybody's behavior in the slightest? Gosh, do you think that might have an effect on the completion date? And sure, why don't you put me next to the salespeople making calls all day. I'm not making any progress anyhow.
The only conclusion I can come to is that in a lot of places, productivity is much lower on the list of observed priorities than stated priorities.
[+] [-] saghm|2 years ago|reply
To be fair, I think staying up all night trying to be productive instead of getting a good night's sleep also makes it hard for most people during the day. As someone who consistently got 6-8 hours of sleep every night in college before a day with classes, I've always been mildly horrified by the fact that "staying up all night studying" is somehow considered a good thing.
[+] [-] PragmaticPulp|2 years ago|reply
Often, the real problem is that people don’t actually have 1 hour of working time in between meetings. We sit at our desks and feel obligated to respond to e-mails and Slack messages. Our Slack responses turn into conversations that consume 5-20 minutes without a clear end. We need to spend 5-10 minutes reading backlog to catch up. We need to get a drink or use the restroom. That 1-hour chunk of free time on your calendar may only have 10-15 minutes of concentration time, which is the real problem.
I’ve had some success with blocking off calendar time to mark 1-2 hours of focus time. Having something on your calendar makes delayed responses in Slack socially acceptable.
[+] [-] Cthulhu_|2 years ago|reply
I think this is the mindset that a lot of people have, but always keep in mind, the meetings is part of your job, and writing code is also only one aspect of your job.
What I'm trying to say is that don't let the meetings frustrate you, instead just accept them and the distractions. Few people get to do what they really want to do all the time, and it does often seem that software developers show some prima donna behaviour in that they just want to stay in their flow and the other aspects of their job should be dismissed.
I mean I get it, writing code / flow state is enjoyable and makes you feel productive, but you get paid for the full package.
[+] [-] lumost|2 years ago|reply
I find that this leads everyone to constantly do multiple concurrent tasks. After a long day I often have a headache from having to concentrate on both my coding task, an operations task, a meeting, and a new request at the same time.
Ultimately, as you would expect - productivity is awful. They then have lengthy discussions on how to improve productivity by every mechanism other than what’s known to work (faster builds, faster tests, increased focus time)
[+] [-] MH15|2 years ago|reply
[+] [-] nomilk|2 years ago|reply
> (programmers) 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.
> meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.
> I find one meeting can sometimes affect a whole day.
> I know this may sound oversensitive, but ... don't your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don't. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.
http://www.paulgraham.com/makersschedule.html
[+] [-] ChrisMarshallNY|2 years ago|reply
But managers don't care (and many co-workers also).
A quick shufti at most modern open-plan offices, shows the contempt that managers have for developer context. They know better, and have made the conscious decision to go open, anyway.
I remember visiting the Facebook/Instagram building, in NYC, and was aghast at the huge, noisy, crowded office. I would not be able to get any work done, in that environment.
I'm grateful to be in a position, where I work alone (mostly), as I can keep all those balls in the air, and the difference in productivity is amazing.
[+] [-] giantrobot|2 years ago|reply
Even if I managed to angle my monitor right, put on headphones, and pull my hoodie up to reduce distractions some side conversation or impromptu stand up would inevitably distract me and pull me out of my flow. I tried to come in as late as practical in order to stay late so I could get work done for a few uninterrupted hours. I found myself going in a day on the weekend to actually get the previous week's work finished. Unfortunately management doesn't like people coming in "late" because they can't lord over them from their offices during the day and constantly interrupt them with meetings.
It was downright insulting that a $5b building intended for professionals didn't have real offices with fucking doors. At the upper management level the fact the company worked as well if not better with WFH policies must be incensing. It makes plain the insipid claims about "collaboration" in that stupid building. Collaboration happens when engineers want to share ideas, not because they're imprisoned in a glorified fish tank for eight hours a day.
[+] [-] mrighele|2 years ago|reply
For the majority, the cost is not that well known and in general they are not the ones paying for it, you are.
In particular for your colleagues it may be beneficial to disturb you because when they disturb you, you may lose concentration but the may in fact avoid losing it by quickly get an answer to their pending problem.
This is one aspect where LLMs may be very useful: asking something to a tool like ChatGPT may not be faster than asking a colleague, but if it avoids ruining the colleague's concentration it will be a net positive for the company. This is even more true if/when those model will incorporate specific internal knowledge (code, documentation) of the company.
[+] [-] whoisburbansky|2 years ago|reply
1. https://en.wiktionary.org/wiki/shufti
[+] [-] dangwhy|2 years ago|reply
i bet 99% of time people are interrupting themselves. Like i just did to browse HN.
[+] [-] jamal-kumar|2 years ago|reply
I check in with the team once a week and make sure the task tracking system is updated. Everyone is happy and stuff gets done.
We're going to have to do some more hands-on work down the line where we're going to need physical presence working with hardware which is going to be an interesting shift, but I still think that we're going to mostly adhere to the usual workflow.
[+] [-] marsven_422|2 years ago|reply
[+] [-] wruza|2 years ago|reply
Log all your key thoughts, realizations, decisions and taken steps on paper. It shouldn’t be long or long-term clear, only clear to today’s you. Gibberish to a bystander. Text, bullets, arrows, acronyms, verbs, marks, anything that works. Lists, trees, graphs, outlines.
It’s your L2 cache. L1 is fast but short and prone to distraction. If you log everything into L2, then returning to the task becomes much easier, because the whole context is right there.
The downside is you have to spend time drawing. The unintuitive upside is that by writing you may make it clear to yourself what maybe wasn’t clear.
IDE may be good at where you were, but it doesn’t know what you thought.
[+] [-] askiiart|2 years ago|reply
Stuff like this is why I love Hacker News. Rather than making up abstract, weird analogies between a thing, and another very abstract thing I find even more difficult to understand, we can make analogies to technical terms which most people here understand [citation needed], and which anyone who doesn't can easily look up.
[+] [-] visarga|2 years ago|reply
This works out nice for using GPT4. If you prepare project information beforehand you can use it in your prompts. I am working on a way to structure my notes to be AI compatible. We can benefit from having to keep prompt materials for GPT, a good reason to have detailed notes in the first place and it's exactly the diff between general knowledge and project knowledge.
[+] [-] kayodelycaon|2 years ago|reply
My mental state isn’t easily capturable on paper since I use visual/spartial memory for programming. Witting it down requires enormous amounts of translation.
[+] [-] chinabot|2 years ago|reply
[+] [-] dijit|2 years ago|reply
An example:
A receptionist does not necessarily need focus time, and is interrupt driven, so their work should not stretch to more than 5 minute intervals; if something takes more than 5 minutes it must be filed for someone else.
A manager manages their time in 30 minute increments, anything that can't reasonably be done inside a meeting is unfortunately unlikely to happen. This is stupid, but it's unfortunately true; you might sometimes experience other situations but I think that's not the common case.
A programmer (or, researcher, etc;etc) books time in half-day increments. If you must have a meeting with programmers, it's often better to book events in serial but only consume half a day.
I've been practising this methodology for 8 or so months in my org and it does seem to hold true in the general case, there are some minor exceptions but most people do seem to he happy.
EDIT: It was the "Makers Schedule" by PG; Serves me right not to read the comments[0] before commenting.
[0]: https://news.ycombinator.com/item?id=35462780
[+] [-] rtpg|2 years ago|reply
There are more demand driven roles but probably every person you interface with on a day to day basis professionally has hard work to do. Sales copy? Focus. Figuring out some accounting discrepancy? Focus. Trying to actually plan out the next quarters projects in a decent way? Focus. Trying to find a good place for a year end party? Focus!
The reality is that everyone has similar interruption issues, but understands the existence of needs beyond themselves when working on a team. Programmers are maybe special in the level of coddling gotten on this topic. Along with a dose of having people more likely to have general executive control issues.
This mythologizing gets in the way of trying to tactically improve things. Real things programmers can do, such as take notes on paper, documenting ideas, writing exit/entry notes, and many other things people do to be able to come back into a project after interruptions.
It’s very liberating to find workflows where you can actually get stuff done even in small increments, because you are not relying on this idea of doing a hard reset of your mind every time you switch tasks
EDIT: to be clear, it’s good to let people work uninterrupted. Sometimes interruptions are needed because of working in a company where other people also have needs. This is true of many people working at a company, and so we should operate understanding interruptions exist and we are the same as other people.
[+] [-] lordnacho|2 years ago|reply
When you're interrupted, you forget a bunch of the maybes and you have to rebuild them. This is because your evidence is not strong enough yet to have a small graph, it needs to be a big graph (or set).
Main advice is to take small steps. Little pieces that are easily recoverable. Things like unit tests help to establish the facts, allowing you to push some things out of your own memory. Also take some notes to jig your memory.
Sometimes you can't take small steps, because it just happens that you didn't consider something and now there's a large surface to think about. For those times, make sure you're not interrupted.
[+] [-] frereubu|2 years ago|reply
It somewhat reminds me of this Hemingway quote "You read what you have written and, as you always stop when you know what is going to happen next, you go on from there. You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again." I think there's an art to stopping at the right time, even if it's within constraints that aren't in your control.
[+] [-] wpietri|2 years ago|reply
And where it's possible, I love unit tests for this. Starting off in the morning with a failing unit test from yesterday's close gets me right back into it.
[+] [-] _448|2 years ago|reply
Afterwards, he enquired why engineers were kept separate in their own rooms? And why does one have to be so formal in requesting a meeting even to discuss project issues? It takes lot of time to resolve issues. Why this inefficiency? And the reply he got was, engineers when they are working, they get into a zone. It is very difficult to get into a zone, but very easy to get out of it even with a slightest distraction or interruption. Hence Microsoft provides separate rooms for engineers and meetings are available only when the engineer is free.
[+] [-] mattferderer|2 years ago|reply
If you're having a huge issue with this, I suggest trying to find ways to hold less context at one time.
Write stuff down & get it out of your head more often. Write down all of your ideas & break down your tasks into smaller tasks. Don't try & solve a giant problem all at once without writing down what you're going to do. You may also discover issues earlier.
It doesn't get rid of the issue 100% but it helps a lot. I say this as a dev who has to do a lot of context switching.
[+] [-] Casteil|2 years ago|reply
For many who experience this regularly, that basically means leaving/finding a new job.
With many employers, it's very difficult to escape being spread thin once you've proven your competence and they lean on you hard as a result.
[+] [-] runlaszlorun|2 years ago|reply
[+] [-] time0ut|2 years ago|reply
[+] [-] Arrath|2 years ago|reply
A meeting to discuss why we're behind schedule.
A meeting to put together a task group to put together a recovery schedule.
A task group meeting to put together the recovery schedule.
A management meeting to review the recovery schedule.
n bounces between management and the TG to revise the recovery schedule.
A meeting with staff to discuss the recovery schedule
A meeting to assign duties towards the goals of the recovery schedule.
[+] [-] generic92034|2 years ago|reply
And I still can skip those meetings just by telling my manager that I have something quite urgent to do and that I will come back to them later (in case of the 1:1) or read the meeting minutes (in case of the team meeting).
On the other hand we have an "open office" layout here. But I am 99% working from home, so I am "skipping" that as well, mostly.
[+] [-] omnicognate|2 years ago|reply
I have to be careful, though, as I'm aware most of my colleagues don't feel the same way about interruptions.
[+] [-] inciampati|2 years ago|reply
But your way is also my way. I am active in a very wide array of topics, and happy to flit between them. Sometimes I dive deep, but it's usually in a critical moment of synthesis when ideas developed over months or years come to clarity and I put them to action. This is working extremely well for me. I lack nothing and am at the absolute cutting edge in every topic I'm pursuing. Of course this is my opinion but it's sufficient to say that I'm happy.
It is sad to see how many people are made uncomfortable by interruption. It's the stuff of life, social life at least, and exactly what makes being human in a dense society so wonderful. I feel it represents a fundamental discomfort with being in situations out of one's control. But, that's the core of life. And for me it's where all the creative energy comes from.
edit: Reflecting on John Carmack and his big monitor. I habitually work in single window terminals with relatively low row counts and big fonts. I seem to be unable to get a benefit from seeing more stuff all at once.
edit2: And in terms of getting into flow state, for me it is always basically instantaneous. The flow is just sitting there under a few seconds of pause. Of course sitting at a computer or phone will cause wandering distraction at times, but if work is in play I can start driving at full speed in what would typically be seen as a horrifically uncomfortable position. Imagine a long distance train with two children jumping on you... If I can see my laptop and the kids at the same time, I'm flowing. I think this might be neurological somehow, due to training or genetics. It's unclear.
[+] [-] analog31|2 years ago|reply
I also do OK with interruptions, and have found a role where I'm not programming 100% of the time, and the subject matter itself -- doing experiments and hardware testing -- doesn't really lend itself to flow anyway. But being able to program means that I don't have to interrupt the programmers every time my requirements change, which can happen on an hourly basis.
[+] [-] tootie|2 years ago|reply
[+] [-] BrandoElFollito|2 years ago|reply
I am trying to explain it to my wife (using the cartoon on the article) but she says I am always busy.
Which is probably true, but somehow she manages to interrupt my thoughts right when I was holding the whole heap in one hand, reaching for the duct tape with the other and pushing the keyboard with the nose.
Never when I just started vscode :)
[+] [-] Torkel|2 years ago|reply
For me there are different tasks and different days. Some days I want uninterrupted flow. But some days I feel more productive by chopping it up with a few meetings and some office trash talk. A laugh every now and then, teasing a co-worker for screaming at his code - it gives energy to me. Talking through a problem or pausing for a while in a meeting and then returning to it - that can be a great way to see new things.
Now don't get me wrong here, I am not saying meetings and distractions are good for everybody. But it's just that for me at least the picture is not as clear. Some days I feel I would have been more productive if I had had some meetings to distract me.
Am I really the only one to feel this way?
[+] [-] kjuulh|2 years ago|reply
I usually split my work-week in office and remote work. When I am in office I plan for having meetings with stakeholders, architecture/mob coding with my coworkers, etc.
But when I am at home I can focus on the projects I need to execute on, fairly uninterrupted.
It is not perfect and isn't quite as black and white as it may seem, and it is difficult to communicate that this is how you're working, but just doing it in my org has been pretty good.
I probably have one of the more outreaching roles, some mix between an architect and devrel with a sprinkle of actual execution, so even if it is an outreach kind of role it actually works pretty well.
[+] [-] catears|2 years ago|reply
[+] [-] rqtwteye|2 years ago|reply
[+] [-] dagorenouf|2 years ago|reply
[+] [-] chester_the_dog|2 years ago|reply
[+] [-] tegiddrone|2 years ago|reply
[+] [-] pokepim|2 years ago|reply
[deleted]
[+] [-] dmcq2|2 years ago|reply
[+] [-] negative_zero|2 years ago|reply
But yeah, sometimes find it almost violating in a way, especially when its that typical PM line "hey did you read my email?" (that was literally sent 10 seconds ago).
It just feels like someone coming over to my desk and pushing, monitors, scopes, everything off and smashing it on the floor, then walking off.
Now I have both unrealistic deadline AND a mess to clean up.
I don't know where I'm going with this comment. Just venting I guess :)
[+] [-] osdoorp|2 years ago|reply
[+] [-] Mizoguchi|2 years ago|reply
[+] [-] wellanyway|2 years ago|reply