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.
And then you're finally fed up with all this and go full remote, if the company allows it. Congrats, now you lost access to 80% of what is going on and fell out of the loop for anything important, and you're now guaranteed to lose in any power struggle that could happen.
In one of the companies I worked for, it was comfortable in the beginning - there were offices, 2-3 programmers in each, not too crowded, but close enough to see when the coworkers were focusing on something and when it would be ok to do a quick "hey, do you know how to...". The company grew, moved to a bigger building, rooms became larger, now there were 4-5 programmers in each. It was still OK then. Calls and longer talks were done in separate rooms, and a quick chat with the guy next to you could be done like you'd do it in a cinema - quietly.
When I was leaving the company years later, it was after it moved to a place with one huge open space and a set of rooms that you needed to book days in advance to use. Some of them were permanently occupied by "important" people even though they had their own offices. That resulted in everybody and they're cat making calls and meetings and sometimes even plannings right in the middle of the open space or in the kitchen. Finally, a "hot desk" system was implemented, and you had to book your desk days in advance.
I asked the CTO who I've know for quite some time - WTF man? He said that he likes it, because he can see at a glance that everybody is working. I was reminded of storehouses with special elevated rooms that had a view on all that happens on the floor. Saying that I got disillusioned doesn't even begin to describe what I've felt then...
> I asked the CTO who I've know for quite some time - WTF man? He said that he likes it, because he can see at a glance that everybody is working. I was reminded of storehouses with special elevated rooms that had a view on all that happens on the floor.
This kind of panopticon is how prisons are often organized.
I can be lying on a couch working hard. How does the CTO see that? The typing part is just the tip of the iceberg.
> I can be lying on a couch working hard. How does the CTO see that? The typing part is just the tip of the iceberg.
It is amazing that most knowledge worker management does not understand how knowledge workers work. Most of our hardest work does not involve hands on a keyboard.
I've been full remove for a decade. There's no way I could work in an office where "butts in chairs" was the way. I guess I would just have a notepad and a pencil and just sort of move my hand back and forth on it while I was in my head solving the real problems.
Similar raising. At one point I was ASE certified, at another I was a landscaper.
The first thing I noticed about white collar work was how gossipy and lazy everyone was. We didn't have time for that in blue collar work. I had no idea how these people were useful to work or society.
It seems so bizarre to me, even today, that most white collar jobs make more money. It's like they took the people who couldn't work physically, made them feel superior, and for some reason paid them unreasonable wages.
It's not really a secret that a lot of white collar jobs are bullshit jobs - if all blue collar jobs were to stop working, society would collapse overnight. Not so much with white collar jobs.
We got a taste of that with the various lockdowns during covid : only the truly essential jobs must be done live and cannot be done remote.
Aye, same. The level at which my time was structured and accounted for on the blue collar level would astound the white collar folks. Entirely directed vs. entirely self-directed.
> It's like they took the people who couldn't work physically, made them feel superior, and for some reason paid them unreasonable wages.
Easy killer, you're projecting.
I could go back to being a bartender today, and could do 90% of the job (I'd have to refresh my memory how to mix a few drinks, but most of em are still there). I could probably go back to Private Investigator, or food truck work too.
But it took a whole lotta learning to get to the point where I can do my current white collar job. No one I bartended with could stay sober 4+ days a week or avoid DUIs; no way in hell I'd trust them with a production GCP cluster.
IMO you work harder in blue collar but its less stress because people don't expect you to hustle to meet a deadline.. I was also a landscaper for a while. Labor is labor in that sort of job, it marches at an expected rate and is dependent on how many hands are working. You often cannot just work for longer, either, if you are bound by the constraints of daylight, or having to clear out of the area by a certain time due to noise perhaps. There is also no way to weed, mow, or lay sod faster than you are already doing it. The deadlines end up moving to fit the realities of the speed of labor against the realities, rather than what happens in white collar work where labor being expected to meet self imposed rigid deadlines, which leads to burnout and poor quality work, and still missing deadlines.
I'm old enough that I remember a time when developers had offices... sometimes private, sometimes 2 to a large office, but usually shared with other developers who generally also understood the benefit of not being interrupted so it worked out fine.
Young me's head would explode if I got a glimpse into a future where cubicles are now looked at as the good old days.
And the progression keeps going with a lot of companies that have open office "hot desking" where not only are you working in a chaotic open environment, but you don't even have your own little space there from day to day.
All of this makes it seem increasingly bizarre to me that a lot of the industry was forced to make remote work viable through the pandemic and many companies saw productivity go up and now a lot of them are trying to claw back on remote as quickly as possible.
There was a lot of “hurry up and wait” at my last job, so I had time to reflect on the hotdesking there.
And I theorized that one aspect of hotdesking is absolute control over employees by having them go through the experience of “clearing their desk” every day so they feel like they’re fired every day. This puts the grunts back in their place and keeps everyone docile because you know you’re just a cog and your job is not a permanent thing at all but rather something that you must work hard at earning again for the next day, lest today’s daily desk clearing be your last one.
The cause of all this is the grafted on management caste, that does not code. For them the whole endavour suspicously looks like not doing a thing, for to do a thing, there needs to be communication, information flowing up and down the hierarchy. Not some dude sitting there like a zen monk, reading, ocassionally typing. Slackers! Best load there calendars, to get them going..
I'd say the cause of this is the developers can't explain themselves, cannot defend why they need isolation, why they should not be interrupted, and more often than not can't explain what they do, what their jobs are and why they are required, in an understandable manner to the management caste. They act as they do because the developers are an opaque pool who talk nonsense when asked questions. Of course they/we get treated poorly.
Nah. I am extremely good at explaining these things. At this point I have a deep grounding in the theory of work. Explaining isn't enough, because the people with power don't care about the same things. Productivity is just not that important at most companies. Conformance to the feelings of the people at the top of the primate dominance hierarchy is generally what matters most.
If I walked into a foreign profession, with no clue, no previous research and assumed to be in command, with the base assumption that its the task of the surrounding eco-system to explain my job to me..
Lets say it that way, such a mindset ought to be valuable to the extreme. Thats why we see a constant stream of meddle-managers, setting out to make compliance and "apply presure" startups. Its definatly at the core of value generation.
ChatGPT: Ask me on the hour, every hour for my status and remind me of the deadline..
We share an old (1960's) building with our research department. Almost everyone has an office, except for contractors and administrative assistants who are in cubes.
This building is scheduled for demolition and we're being moved to an open-area workspace in a new building.
At least it's above trendy retail so we can get overpriced coffee and sushi on our lunch breaks.
My internship at IBM twenty years ago was like that. A fellow intern and I shared an office (and an apartment—we were sick of each other after a while), but the FTEs all had their own offices. No idea if it was the norm for IBM at the time (my team was part of an acquisition that was still mostly isolated from the wider company), but it was extremely conducive to productivity.
> I decided there and then that cubicles has material benefits over open offices.
The cubicle was invented in the 60s as a way to liberate people from the tyranny of the open plan office (just look at film from before then — say, “The Apartment” —- and you’ll see the open plan was the norm.
It’s a shame that the cubicle itself became a tool and exemplar of anomie.
I think the distractbility and the opportunity to just sit in meetings and chats all day is an example of the priviledge that we as white collar workers enjoy. Our productivity isn't measured in output, in number of pallets cleared, in end of day take, it often feels like it's measured in just time spent under a contract.
It feels like I can get away with only a few hours of what to me feels like productive work a week. Actually, I had a really good day last week, but then it takes days for the feature to pass review, rework for said review (often trivial remarks), and to end up in the main branch ready for deployment.
Wait, are you me? I’ve had the exact same experiences! Especially being sat next to sales people. Even when they are not on the phone, they tend to be very loud, outgoing, exuberant, extroverted, etc. and are constantly chatting.
> 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 think you're still missing the point. It isn't that you need to stay up all night, but rather the flow state. In college you typically have classes during the day so you aren't going to get it then. That doesn't make it a great thing but it also isn't exactly relevant to this conversation.
I understand the point they're making, but I'm not sure you understand mine though. If someone talking about weight loss suggested that people should just never eat breakfast to reduce the amount of eating they do in a given day, it would be relevant to offer a critique this may end up being counterproductive overall to the goal due to it just pushing the issue into another part of the day; this is basically the same thing.
Yeah, but the point you missed was about the uninterruptedness of studying for an exam — a student might be able to dedicate a whole week to learning for an exam and then study each day with minor interruptions.
That those studying session can sometimes be too long to be healthy is certainly true, but was not the point argued here.
When someone argues that a Ferrari is a fast car and you criticize that not all red cars are fast, you are arguing against a statement nobody made while still saying something true.
> Yeah, but the point you missed was about the uninterruptedness of studying for an exam — a student might be able to dedicate a whole week to learning for an exam and then study each day with minor interruptions.
I don't know why you assume that I don't understand that they're saying that their studying is uninterrupted when it's overnight. That doesn't change the fact that sleep deprivation is also something that makes any sort of studying less effective.
> When someone argues that a Ferrari is a fast car and you criticize that not all red cars are fast, you are arguing against a statement nobody made while still saying something true.
In this case, it feels more like someone said that Ferrari is a fast car, and I mentioned that some people can't afford Ferrari's and might find a different car a better fit, and then you came in extremely unhappy with the fact that I dared to mention anything other than a Ferrari because that's the only car OP mentioned. It's extremely common for people to reply to comments making a tangential point, and doing so doesn't at all take away from other people's abilities to have parallel discussions in other subthreads about different points; that's kind of the whole point of this style of forum.
I guess that's possible. I don't tend to spend a lot of time thinking about introductory phrases like that either when reading or writing; they mostly convey tone and flow to me rather than being super meaningful, but I could see other people focusing on them more causing a disconnect.
A tip for your future: if someone doesn't understand what you write, say, or draw, that is squarely on you. "I don't tend to spend a lot of time thinking about... ". Putting information or statements into context is a key, core part of effectively communicating. "I guess thats possible" -- no, you don't guess, several people just TOLD you that is how they interpreted your words. Your response can't be indignance or ignorance. Your response must be "I will endeavour to communicate better next time, and clarify my message for you."
The rest of the world calls this lack of readily access to food.
First world problems; there is so much food that we can make lifestyle choices around it. You can pretend to be a caveman and eat "paleo" since meat is neatly wrapped in plastic at the store and you didn't have to hunt it down. (And if you study the Hadza tribe who are one of the last paleo-bros on the planet you'll find that meat is a small part of their diet). You can forgo certain meats and call your self pescatarian since you can find fish in the middle of a city. And you can intermittently fast since you know that you can quit anytime and stuff yourself full of food.
We as a modern society have to be the most smug of all. Think about every predator in the world. We constantly pay to exercise, to burn off EXTRA calories, where as every other animal on the planet conserves them or expends a vast amount to obtain more.
> If someone talking about weight loss suggested that people should just never eat breakfast to reduce the amount of eating they do in a given day, it would be relevant to offer a critique[...]
Tangential, but might be interesting to some:
sometime before the pandemic, after (I think) 30 years of always eating some kind of breakfast, I accidentally missed breakfast once and that day I felt I had significantly less brain fog after lunch.
So I tried again to see if it was just a coincidence, but it had happened again and again.
And, I realized, as long as I don't start to mentally prepare for breakfast I don't start feeling hunger either.
I'm not suggesting this is a good idea for everyone, only that for people like me who has followed "best practice" for decades and doesn't feel too enthusiastic about it, testing out alternative approaches might be a good idea.
PS: the total amount of hunger I feel in a day seems to have gone down too.
When I do not eat breakfast, I am unable to focus on work. It does not matter when I am in dysfunctional team (so I was actually not eating breakfast), but the moment I needed to produce, I had to eat.
That's very unusual. Your brain needs ready supplies of glucose to function. Not eating breakfast is forcing your body to turn energy stores into glucose in a way that it tries to avoid and probably doesn't give your brain ample supply, or just not function well.
Do you actually work better, or have you decided that you work better?
Many well functioning people, including IIRC navy attack divers, live on a glucose free diet for a long time, so I am not alone.
As for if I work better or just have decided I work better, I only have 4 or 5 years of experience with this but despite the fact that I love breakfast and lunch I still skip them because the brain fog I seem to get between 1200 and 1400 on days when I eat breakfast just isn't worth it.
I noticed that too. I also started skipping lunch for the same reason. If I do eat lunch, it’s only on days with a lot of meetings in the afternoon. If I want focused work, I skip it.
It's possible that my example might not be up to date. In the past I've been given advice that trying to just skip eating an entire meal at a time when one normally would makes someone less likely to be able to follow through with being as strict later in the day. Assuming that this isn't an outdated misconception, I think the comparison still somewhat holds. Studying all night and not sleeping is totally fine if you're able to function fine without sleep, but it's counterproductive if you're not. In the same way, "just eat less" works as long as you're able to follow it, but for some people, trying to follow that strategy without any other caveats might not be particularly effective.
Fad diets like intermittent fasting or any kind of major lifestyle change like that take a lot of willpower and self-discipline, which is also why most diets fail long term.
Better thing to do is have a routine first. A lot of people don't have any eating habits, it's more of an afterthought or a "whenever I'm hungry I'll eat" kinda thing. You can't base a diet off of that.
If you fix your diet by just eating at the same moments, roughly the same amount of time, only then do you have a baseline. Then make tweaks on that baseline. Evolution instead of revolution, only that will be sustainable.
Even in college with classes, overnight studying is one of the least effective way of studying. And no, you don not need 6-8 hours of consecutive flow to learn anything.
Whatever the reason for celebrating overnights, effectivity of it is not it.
I don't think the parent was suggesting overnights to be celebrated. In my group of high achievers, we joked about all nighters but anytime it actually happened, it was always treated as "we fucked up and were lazy and should have done this ages ago and this is our penance to attempt to claw back some almost positive outcome and passable grade from really poor planning"
Years later some of those kinds of situations were bonding moments, but none of them are considered a good thing.
There is a general accepted "healthy pattern", but I think there more to it:
- not everyone has the same sleep patterns, and while it can usually be coherced, for some that doesn't work or has too many downsides.
- some people have straight sleep issues and, sleeping in 6-8h blocks doesn't help. "then fix the issues" could be the basic advice, but again, that's usually easier said than done, or has worse side effects.
In that respect I agree with parent that it would be nice if "weirs" work patterns were more accepted
Indeed I am night owl. I tried to accommodate myself to go to bad early sleep 8-9h, het up early. Nevertheless, I am energized and happy only when I can get up between 8-9 (Morning;)) Which usually contradicts the social and work expectations…
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 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.
Pomodoro does not need context switching.
Breaks without loading up a different context gives the brain time to bring back the body into a less tense state, so the next cycle can be more energetic/productive than a continuous one. In many cases it lets some ideas run their courses and save time by solving conflicting thought forces.
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.
This would be a valid way of thinking about it, but programmers aren't generally judged on their meeting attendance but rather their code output. More meetings == less code == worse perceived performance == fewer opportunities for pay increases and promotions
> More meetings == less code == worse perceived performance == fewer opportunities for pay increases and promotions
That's a rather junior mentality. When one is junior, yeah, usually the most one can do is moving Jira tickets to Done (which means merging code usually). But when one is senior, the pay increases and promotions come from other activities: mentoring, handling technical topics between teams (usually via meetings), etc.
> This would be a valid way of thinking about it, but programmers aren't generally judged on their meeting attendance but rather their code output.
Not universally. Programmers are judged by overall success or failure of the project they are working on. And those ones who can take credit for a success or who can effectively deflect blame for failure are the ones who got promoted. Being in the meetings with the decision makers provides the forum for self-promotion and controlling the message. This does not always mean that they did most of the work. More code or less code is unfortunately secondary.
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)
Heh. The same at my workplace, except that build times suck, tests take a long time to run (and are not dependable), and you're expected to be on an electronic leash -- namely, one of the worst possible instant messengers.
I would rank Slack above Teams in nefariousness, because it's a better tool, so people like it more, use the shit out of it, and inundate you with so much more noise.
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.
Its especially helpful for stuff where I haven't touched it in a while too. One alias and boom, I'm back in a session with a pane with my editor open, a pane with the log, a pane with some notes, and a pane with the shell displaying the last line of code I ran from when I was last working on this pet project over six months ago. Right where I left everything and I can jump back in as if I was working on it an hour ago.
I have a separate VS Code window connected to a dev container for each project that stays open for days, weeks or months at a time. Does the tmux approach materially improve upon that setup? Genuinely curious if I’m missing out on something here.
You can end up pretty deep down the rabbit hole with tmux and configuring it in different ways. One thing you can do that you might not be able to do with your vscode set up is have a script, written in tmux commands, that generates a complicated windowing environment. I am not familiar with the capabilities of your setup though, since I don't use vscode. I would guess tmux is more comfortable than vscode for using it with just the keyboard too.
There's a ton written on tmux as you can imagine by this point. This page seems pretty comprehensive on the advanced features including tmux scripting:
Maybe, you can SSH to GNU Screen and attach where you were, perhaps from your phone to just read. You could do the same with rdesktop to something x11, but you'd need more than a 256MB VM for that. If you have this running 24x365 then you'd spend more energy/money.
To all above: but machines reboot, also, not? Even our coorp Linuxes now succumb to ugly IT update reboot cycles, Cloud VMs even more ephemeral, and lets not even start with dev containers... One can script tmux sessions to some degree, but still loosing a lot of state (editor open ther, shell history here..).
Rebooting my dev boxes for security updates or kernel upgrades once every few months/year isn't a big deal, and I generally know when it's going down. The laptop is an ssh terminal/browser/doc reader only!
Do you exclusively work on remote servers? I love tmux, but I have the issue that I also use it locally, and to my knowledge, you can't have local and remote sessions in one tmux daemon. So I either have to open tmux in tmux, or open it in a separate terminal window.
You mentioned your editor on the remote server. Does everyone have their own account with their own settings on all remote servers? We're still at a point where everyone accesses servers via the one shared "root-ish" user.
Everyone has their own account with their own home folder containing their dotfiles. There are shared project and scratch drives. I do all my work on this server, nothing is done locally other than ssh into the server.
For what you are describing the best practice is a nested tmux session with tmux running locally and on the remote server. So you would open tmux locally, then in one of the windows or panes you ssh into your machine, then open tmux on that machine. This will require you to press the tmux prefix (ctrl+b or however you've set it) twice to do the commands on the remote tmux instance. However you can get around this with some configuration (1).
I think certain certain terminal emulaters like iterm2 have tmux specific features that could also be helpful, but I don't use that software so I am not as familiar.
How viable this is probably depends on what you study, but I skipped most of the scheduled meetings (lectures) during college. At the most prestigious of the 3 universities I've attended (which seemed to have more respect for their students than the other 2) this was actually encouraged if you felt you had better ways to make use of your time.
Im a manager now, and I've accepted these days as a reality. I block book time on my calendar in 2 hour chunks (4 pomodoros) so that week on week I'm consistent.
Ive got some tasks that I can fit in those in between slots. As an IC I would do them at the start/end of the day, but now I do them during those blocks of time. For me, it's things like smaller code reviews, reviewing design docs or triaging issues.
For me it's much worse. If most of my days are reacting to outside signals, it takes me at least a week to get back to the mode where I rely on my own motivation.
I've been in jobs where that happens only for a few weeks in a year, after major vacations.
I collected all my meetings into "meeting thursday". A dump day - typically from 9-2, sometimes 9-5. Sometimes I cancel or reschedule everything if another "dump cluster" forms.
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.
> 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.
That‘s an interesting bit of information. Maybe this is one of reasons in the decline of quality at Apple - at least in temporal terms it could correlate.
I'd put the source of a quality decline as the cumulative effect of the yearly OS release cadence. The schedule doesn't leave nearly enough time for feature development, testing, and then bug fixes based on the testing. At the end of the summer the OSes get declared "zero bugs" which really just means a bunch of bugs get punted back to the originator asking for reproduction or extra documentation. By this time no one has time for try reproducing the bug unless it's really egregious. So the new OS just has a bunch of new bugs and rarely do any of the bugs from the previous release get fixed unless they're particularly egregious or security issues.
This leaves a lot of little bugs sitting around that might only affect say 1% of the user base but every bug is usually a different 1%. So almost everyone ends up running into annoying bugs for their particular usage/workflow. A secondary effect are big mid-cycle releases like iOS 16.4 which end up bundling features likely meant for the 16.0 release in the fall but slipped. Unfortunately due to the crunch they get the same level of testing/bug fixing as the fall point releases.
The building doesn't lead to poor software quality, that's a failure of scheduling/planning on the part of management. The shitty building just puts the software development on Hard Mode.
> 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.
> 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 true, but the people getting asked are usually the ones doing (much) more delicate work, so it’s their concentration that should be protected.
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].
If you don't get up and walk around, at least 15 minutes of light to moderate exercise per hour seated, you will suffer bad health effects. Stuff that can end your life early and in painful ways.
I find walking around every hour or two for a while to collect my thoughts about what I'm working on is still something I can make productive. I bring a notebook with me to do some notes if there's more than I can fit in my head, which is pretty usual. It's a good way to get some planning in.
A momentary distraction like a quick HN check is not the same as the context switching of, for example, going to a budget meeting while in the middle of trying to figure out some technical detail. Very different things.
The difference is scheduling and autonomy. If you had "HN Time" blocked out in your calendar it'd be just as distracting as a budgeting meeting. HN only is different because you can choose when to be distracted by it, and you're happy to say no to it.
If you could control when the budget meeting happens, or if you could decline it, you'd have far fewer issues with it.
People definitely need some distractions but for me it's definitely not 99% of the time. Also, I could argue sometimes the solitaire game between coding stints is actually loading up your brain with some software thoughts, and then giving it a little break to process. Sometimes it takes a day for me to come back and feel like my brain has reconciled some details of a hard problem and only then can I make progress.
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.
My department head has openly told us to do this. He knows a distracted engineer is a bad engineer. He knows that most meetings don't need all the people in them. He told us to block off parts of the day that we COULD NOT be interrupted, and told us to reject meetings that aren't productive or valuable. He is also encouraging people to shorten meetings. He told us that if a manager expects you to work outside your normal hours, that is a bad manager.
"This will get you trapped as a junior" is just "All managers are terrible and we should never expect more". It's bad-manager apologism.
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.
I feel in turn that this comment is the dismissive one, and in fact extremely so.
The issue is not that programmers need to focus, is that they need to focus on deep, complex work. At least a few of those other tasks you mention (don’t have much experience with sales copy, and in rather terrible with both sales and copy) do require focus but have smaller reasonable increments of progress.
Stop thinking about the workplace for a moment and think more broadly of tasks throughout the entire day. Some of those are more easily put down and returned to than others.
Some examples of tasks which require focus but interrupt well: formatting meeting notes into minutes, simple accounting (paying bills, reconciling a ledger). The main point with these are that the individual units of work are small, and don’t generally require a lot of mental preloading to begin/resume working on. So if I am interrupted it can be irritating but I don’t really lose much.
Programming generally involves a lot of mental state that needs to be preloaded, and the Subtask units are often not small. That’s all.
Regarding the insinuation that this “myth” is the result of coddling at the professional level: if this were true, then non-professionals would not discover this independently for themselves…
As someone who's had to come up with product copy and have had to fix bugs, people trying to interrupt me writing a long e-mail gets me way more than people interrupting me while trying to fix a bug where I already "know" the issue and I'm just doing the cleanup/test writing.
I am being too glib. But the sort of "focus broken, can't move forward" feeling is something I constantly have felt in many non-programming tasks. Granted this blocking is also due to the nebulous nature of those tasks vs, say, fixing a bug. Most bugs (not all!) at least have some sort of definitiveness to them.
The coddling I talk about is stuff like other staff members being told to "not bother the coders", something I've seen first and second hand. That, along with many programmer's (myself included) habit of generating endless excuses for why something is not happening and it being more or less accepted as a given. But as someone who struggles with this stuff, I also know that a large percentage of it is due to my own behavior! And changing that has improved things.
My post is combatative, but mainly because I really want people who read this stuff to introspect on their own behavior, and _improve_, instead of assuming that the task is impossible due to some intrinsicc nature of the work that is overestimated
Are you sure this isn’t because you have more talent/competence for programming than writing? Or that you haven’t set the bars differently?
Writing is a daunting task for me, but that has more to do with my own talents and experience than anything. Not implying anything about yours, just something to consider.
Most programmers are just code plumbers. It's not like most of you are some research scientists breaking into the unknown. In fact for most jobs I've held programming has been by far the easiest part of the job. Understanding the 'real' requirements from the client (not what they think they want but what they actually want) and many other things are on a completely different level of complexity. Computers are the most basic parts of a business. I've also noticed that most software people are horrible at understanding the business that they are operating in. And think that management is the one that doesn't understand things. Except it's the other way around. Engineers are optimizing the parts that don't need optimizing and don't focus on bringing value to the business.
Maybe the difference between programming and most other office activities, for me at least, is that I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it.
I don't think that's at all comparable with writing sales copy or finding a venue.
Figuring out an accounting discrepancy might be harder for a junior auditor than a senior one, because competence grows but the problems remain a similar size. (Or I'm talking out of my ass, I only have second-hand knowledge of audit and I'm led to believe that the attitude of big firms is that if something is very hard to find, it's not worth finding because nobody else will find it later!)
Planning the next quarters projects tends to be a collaborative activity rather than one requiring deep individual flow state, I think.
> I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it.
I think that's an interesting way of putting it. I've seen coworkers in non-tech positions go through this. There is a scope expansion (though of a bit of a different flavor) going on often. Many people go to their 1-on-1s and talk about wanting to be challenged more, and looking for new problems to tackle.
But I do think that a lot of stuff, including "collaborative" things, do end up with similar mental blockage. How many times does your manager tell you "I wanted to get back to this message, but I had so much come up all day", even though the final response was maybe only a paragraph or two long? Especially in more chaotic environments people are facing unique flavors of problems pretty often in my opinion.
At one point the systems being juggled are probably very complex, and perhaps the ceiling of problem is highest for programmers. But I think it's important to not underestimate the difficulties and intractability of things other people are working on (since the intractability is ultimately what generates this whole issue with 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.
Sure everyone deals with interruptions. But the real question is how deeply focused do they need to be to operate? How many variables to they need to keep in their head so to speak, to do effective work? Is it the same for engineers vs other disciplines?
> 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.
Question is: are you willing to foot the bill? This extra reading/writing/documenting takes time. Is it worth it to get a more responsive engineer? It's really the same constrains as in operating system design; you can context switch endlessly by restoring state, but you'll pay with disk access time.
> 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
That's assuming you can break down tasks that way. Deep engineering work often doesn't work that way.
I fully agree with you. I’ve been a software developer, a customer support engineer, and a product manager. My focus is also distracted by meetings and urgent things. My work is also best done when I have some time to focus. Everyone else in the professional world learns to defend their time, turn off interruptions, say no to meetings or decline them and ask for a reschedule. I actually view this as an undervaluing of communication and teamwork skills in the way we educate and hire software engineers.
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.
It’s good to have something like org-journal set up so you can write down arbitrary stuff without having to decide where to put it or remember where you probably put it later (I think GTD calls this “capture”).
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.
Write it down because the process often helps me better think about the problem & reasons my initial assumptions were wrong. Can't tell you how many times my clever initial idea becomes terrible rather quickly.
Also if it's something that's going to exist over multiple days, writing it down & coming back to it at least a day later is a great way to re-approach the solution & idea.
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.
> It is sad to see how many people are made uncomfortable by interruption. It's the stuff of life, social life at least
A key concept from the book "A Mind for Numbers" is the difference between "focus mode" and "diffuse mode" thinking.
Focus mode is essentially a concentrated flow state and diffuse mode is a relaxed state, open to distraction and creativity.
Both modes are necessary for effective problem solving but my issue is an abundance of distractions which keep most of us stuck in the diffuse state and no time in the focused state.
> 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.
Rare, for most people it takes 20 minutes.
If I get equally spaced out distracting emails I will spend no time in the flow state at all.
> 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.
I think this may be a variation on the "same" thing. For me, I only look at code or the UI output, or the requirements, or a database query at any one time.
But... I really like if the code is always in the same place, and the output is always in the same place, and I can just look between them if I'm thinking about how and why the code is resulting in the thing it is. But I know where each of those things is at any time, and it might only be a glance away, or an alt-tab away.
(For me, it's 2 27" QHD monitors rather than one big or small monitor.)
That’s quite the claim regarding flow. Invaluable to you if so, but my question would be, how are you defining it? You mention having an eye on your kids, but flow should completely tune out everything other than the precise problem at hand.
I wanted to reply to this because I'm similar. I don't mind distractions, they don't really cause me issues, and it's always part of the job!
I haven't been in a programming 'flow state' for many years, maybe last in college. It just doesn't happen to me anymore. Programming for me has changed a lot in that time. Most of the typing work is done by an LLM or a contractor/jr. I suppose the opportunity for 'flow' is gone or much less. Additionally, well designed code is easier to reason about and requires less context in most cases.
I think many people are too rigid in their meta-thinking. No, not all programmers fall into flow, not all programmers hate distraction, not all programmers have the "standard" deep/shallow thinking dichotomy. Each of these is probably a spectrum, and are effected by changes based on too many factors to enumerate.
Do what works for you, and read these kind of articles with a skeptical eye. Especially since this article is from "contextkeeper.io" and "Rebuilding the Context" heading is just an ad lmao
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.
Programmers is not the only profession that has a high cost of context switching. Scientists, lawyers, engineers, writers - pretty much anyone doing intellectual work would understand.
Now let's look back at the list provided:
-Scientists
-lawyers
-engineers
-artists
-doctors
-nurses
And compare it to programmers and writers. The non-programmer/non-writer world think programmers "just play on the computer" all day. So I think GP is spot on, non-programmers don't get how interrupting flow is catastrophic to what we do.
Writing code is not so different from writing long reports. When I am writing a long report, I need to focus as well and do not want to be interrupted.
Programming is not the only job that requires deep thought and concentration.
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.
At one worksite I did raise the issue of there being too many meetings. The response was "Can we call a huddle sometime this week to discuss this issue?"
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.
"Instant messaging" doesn't have to be "instant". You can just close the program and open it every other hour, just like with email (which also trigger notifications). Or better yet: don't even install the chat app. Just use it in the browser and open as needed.
The expectation that you always have to be online is also unreasonable. But if you're still required to put out a show for an unreasonable employer, you can always set it to "Busy" and disable notifications. This also signals to people that you won't reply immediately.
Of course some co-workers will want to "chat" when you answer them, but this is where you must set limits and say you'll only have time for chat outside your busy hours. This is normally perfectly acceptable IME.
"Instant messaging" is just as disruptive as email if you have notifications turned on. There is zero difference between your email program going dingdingding on every incoming email vs slack/teams/whatever doing the same.
My current company has _all_ of their communication on Slack, the only emails I get are meeting invitations and status emails from automated systems that haven't been integrated to Slack yet.
I can easily click to pause notifications on Slack if I don't want to get interrupted - or I can just close it and read the backlog when I have time to focus on it.
I would not hire you if you refused to use instant messaging (my enterprise uses Slack and gChat). You would be unable to do the job- you wouldn't be able to contribute to decision making, or would miss out on all sort of information. We (our department) has moved out of email with the exception of formal requests and things that cost more than a few tens of thousands of dollars.
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.
Since several years ago I was starting to have health issues that if I sat still for too long my eyes/arms/legs/waist would feel pain, sometimes fiercely. So I set a timer to remind me to stop staring at the monitor and stand up to do some light exercise, at first the timer was 40 minutes and in recent years it became 20 minutes as my body wears.
So now my work is interrupted every 20 minutes, at first the timer was annoying but after several months I got used to it completely and I don’t think it affects my productivity. And actually I wish I could do it from the begining so I wouldn’t have the health issues at all.
However my interruption is short and during it I was uaually just thinking about my work while stretching my body, so it is no compare to hard context switches like being dragged to a conversation.
Sorry to hear about the need to take breaks; that sucks. Glad you’re able to work around it, though.
I suspect the physical exercise is key to your effectiveness there. There’s a big difference between a pause for a stretch and a pause for a message about an entirely different workstream.
People are different. I can usually even answer a question on Slack without breaking concentration but if someone is talking to me everything's gone. Same as going to fetch a glass of water. In the office? Locking the computer and walking kinda far, maybe even locking/unlocking a door, meeting people? A real interruption. At home, 3m to the tap? Not losing a thought. But I do know other people who can talk between writing code and not be interrupted but if they have to answer on Slack they have the same problem.
I'm not a programmer but always tried to be one. Now in middle age I know I could have been one there's nothing amazing about it you just practice with guidance. Like playing a musical instrument very few people can play instantly unless they practice. Sure there are Mozarts but 99.999% of musicians are not.
I went to school a few years ago and we had programming. I was able to do it but my younger classmates were better. A few were savants I think done in 5 minutes what it took the others an hour.
For me I had to use white noise and earbuds. Even someone walking by on the other side of the row of desks would make me lose focus. I got tests done not all perfect, some half, some not at all.
While I don’t know how I feel about the word “savant”, I do seem to match your idea of the few, and in that regard I have two things to say here…
* Interruptions affect me just as the article describes. I have my suspicions about those who claim to be unaffected.
* Talent may indeed play a role, but what you probably aren’t seeing behind the apparent talent is the self-driven obsession. Behind those 5 minutes is a mountain of self-obtained experience. As I understand it, even Mozart was no different…
Expanding on that slightly, when considering if I was special compared to the average individual: I self-taught myself from the age of 8, so yeah, probably something different about me that enabled that. On the other hand, I self-taught myself from the age of 8, spending nearly every free moment with computers. How messed up would it be if I didn’t end up with a massive lead over those just starting out?
Of course it was effortless in 5 minutes: I’d already put in more effort by that point than many would in a lifetime…
I guess the moral is, try to consider what it might be that you aren’t seeing.
ContextKeeper sounds interesting. Can anyone here recommend a similar extension for VSCode? Ideally would offer a way to stash and unstash code and tab metadata (cursor position, undo state, etc) with one IDE keystroke.
ContextKeeper's founder here. VSCode plugin is on the roadmap and hopefully it will be available before the end of 2023.
Both plugins, for VSCode and Visual Studio, will be using the same JSON format for storing "contexts". In other words it will be possible to share "contexts" between teammates, no matter which IDE they are using personally. There are multiple scenarios where it could be useful and improve sharing technical knowledge, such as, faster bug fixing and better understanding of large system architecture, within an organization.
Why did we ask ?
Say I'm a programmer and looking at screen one hour, is it a crime ?
Time management ?
Resource management ?
Do I have to sit that desk and be productive, and compete my friends?
Is the context we perceive, all about resources, material ?
Where is my mind ?
I'm here, writing these, but where is my mind, where is my will, am I the person who I want to be ?
Why I'm not best programmer of the world ?
Is it about multi tasking, or will to be on that desk, or will to be in that person, me, myself, you, they ?
Am I really here ?
I would ask myself - I feel lucky - do I want to be on this desk ?
I would ask my supervisor, I need to go out, I cant be here now ?
Do we really love coding, or current state of business consume our love ?
I left my job 20 years a go. I feel regret whenever I need some resources - say money, credibility, being a man, ... -
But I still love coding.
And I'm almost completely there when I code,
"multi tasking", it just a thought since we started to see our brain like PUs.
We are constantly multitasking, I can not name it like that but it is as it is.
Our brain is not a PU.
You're going to be interrupted, so you better learn to do it efficiently.
Learn not to have some flow state that takes a half hour to get into.
That flow state is bullshit. You get so absorbed into the work that you do stupid things a mile a minute. Sometimes it takes an interruption to get you to see it. Let's see, where was I. Ah I was doing that, for such and such reason, and ... wait what? That's stupid. Let's scrap 75% of it and do it in this better way ...
If it takes a long time to get into flow states, it could indicate that you have some problem in the project. To be able to do anything, you have to boostrap various bits of information into your head, and keep juggling it. Then have it all vaporize upon interruption. Maybe there are better ways. Some tooling or documentation strategy, or automation of this or that. Try to have it so that someone with anterograde amnesia could use your environment to get stuff done.
Then you can only get trivial work done. Which is probably OK for most jobs to be honest. But imagine making design decisions in 10 minute chunks with less context than a ChatGPT prompt.
a design decision would come from collaboration, sure you can get 1st draft ready in 10-15 mins then re iterate it 1 or 2 times to see all of its pro's and cons are visible to you but then you would need all stakeholder's time to get it through
The book “the myth of multitasking” is maybe worth a read, althought it’s a bit repetitive . It hammers home the point this article is trying to make where task switching costs are high and productivity nosedives with interruptions, and there really is no such thing as “multitasking,” but instead, just switching tasks quickly.
It is the intensity of distraction that creates the gap for the serenity of concentration: -
One way to "survive" is to logically separate the work into two different workflows. The "interrupt" workflow is where you are constantly doing trivial things, odd bits of admin, forms, chatting, and interacting in meetings. The trick is to deliberately cram as much of your interrupt-related work into the same half-day segment. The other workflow, the "deep work" workflow is where you do the design and complex coding work. You allocate such periods in 3 hour segments.
For example you could do the morning in the interrupt workflow, the first part of the afternoon in the deep work workflow, and then end the day with interruptions.
Important topic! Totally agree that context switching has a heavier cost than most people realize. That's also why so many product/dev teams are optimizing for tools that improve dev productivity and collaboration.
Here are a few other links that you might find interesting:
https://livecycle.io/blogs/humanitec-dx-study/https://livecycle.io/blogs/context-switch/
that is one of the arguments in favor of the pomodoro productivity technique. For the unaware, pomodoro says to set a timer and do 25min of non-distracted work. Come up for air (mandatory stop) for 5 minutes. Rinse and repeat a few times. Some studies claim it takes 20min to get into the zone, but pomodoro insists on breaking that flow about 5 minutes later. The end result is training yourself to pick back up where you were at. I don't do pomodoro any longer but it was reasonably effective back when I tried it years ago.
This doesn’t really invalidate those studies. What it does do, is force you to restructure your work so that you can get work done anyway.
Whether it’s more or less effective than interrupted, “zoned” work is going to depend on the individual and the circumstances, but it is certainly a way to work.
I do something very similar - I didn’t realise this had a name. I plan that I will essentially have to context change in a short amount of time, so try to achieve some tiny thing before that.
Agreed. I work at a hedge fund and we are constantly interrupted from programming, but we still manage to make a product that consistently generates profit. I feel like people are being a bit too dramatic, here.
Is it hard? Yes, very, but it’s just a matter of discipline and determination, in my opinion.
I'd say it mostly depends on what you work on, and that is not "a field" or "a job". I've had jobs where yes, I could easily be on phone support during the tasks and I've had projects that were usually hours long deep thinking where you had to have a huge system + 10 classes in your head at the same time, but most jobs and projects were a mix. And then you simply may have a bad day and need deep thinking mode for relatively modest work, but yo won't notice the other way round if you build something great and bug free and it seemed easy.
I kinda don't believe the people who say they 100% have this job, all the time - but you also don't know beforehand when you need your interrupt-free time. Some days are just cursed and you get nothing done, even if they only interrupted you 3 times, but it was the important 15min block. And I've had those jobs as well. If someone (different people) interrupts you every 15min, when the day is cluttered up with 3 meetings anyway... I think it scales exponentially.
For me the worst part is how "let me check that email again for context" becomes a 2-minute exercise in 2FA juggling, at the end of which I've already forgotten what I opened my email for and need a coffee break just to calm my nerves.
The worst for me is how the 2FA requires me to use my personal phone. That phone is filled to the brim with notifications from apps and games that were designed to be addictive. I avoid logging into anything because I know it will ruin my day.
Before the era of mandatory 2FA the first thing I did when I arrived at the office was turn off my phone and lock it away.
I need 2fa just to log into my local machine!!!! Which actually makes it 3 factor: I need to know my password, have my macbook, and have my 2fa device.... and also know the password to that. Literally 4 factor?
Seems like most projects end up so bloated that you need 20 minutes to get back to understanding what you were working on. I tend to avoid "clever" code as much as I can, so it is quite obvious what stuff does. Can get right back into it in matters of minutes.
It's the shadow work of programming I never liked.
- Setting up boilerplate code
- Configuring my IDE
- Configuring special browsers (for web development) with no addons or tweaks done so it appears like an average person is using the browser
- Configuring the OS
- Separating work from play. Keeping separate machines strictly for programming
- Tests
- Reading best practice material
- Researching if other people have written the exact same thing as you and uploaded it to GitHub (or don't repeat what other's have coded already).
All that can be set-and-forget but I periodically have to do it all again because requirements change, or I get a new machine or I simply want to re-configure my development environment for minor (or major) gains in productivity.
My most imporant learning for my self is simply to not book meetings in the beginning of the day. It sets the tone for how I am working, and I have difficulties focus if I am in "meeting" mode.
I have solved this in multiple ways, getting into work before others (not that early but just a few hours before our first planned meetings). Second, reaching an agreement with the team to push standup and such to after lunch. This basically gives me the entire morning free to focus and sets me off to a great start.
Anyone interested in sharing what tactics they use to get back into flow?
For interruptions (meetings or discussion) while coding I'll write a sentence or two directly in the file I'm working in - not comments, actual text. I'll explain what I'm doing and what the next step is, then close the IDE. When I come back nothing compiles and I'm forced to delete the text I added, which gives me a chance to read it and refresh my brain of where I left off. It's been one of the best approaches I've adopted over the past few years.
The article title correctly talks about a "programmer".
But professional software development is much more than just programming, just as sales is much more than signing contracts. Sure, signing contracts is what every sale agent looks for, but their actual job is getting to sign a contract. And writing correct code is the goal of every software developer, but his true job is finding out what such code is supposed to do.
Writing one more CRUD information system is just a part of the whole software development trade.
I thought this was going to be about program performance and how to reduce the impact of interrupts and context switching on performance in your software. How disappointing.
XCode tip: if you open a new tab, your current tab is copied to the new tab. It allows you to branch off from your current tab if you don’t want to mess it up.
My code editing style definitely has changed since the 90s when one-file-at-a-time without Intellisense was the norm. Jumping to compile errors was about the only automated thing.
Now I just expect my IDEs, be it VS, VSCode, Eclipse to do a lot of heavy lifting for me.
I wonder, though, whether I was more disciplined and kept a lot more context in my head back in those days. I'm also a lot older so I really don't want to go back to the old days.
Now java developers can't possibly write an hello world in less than 60 classes and interfaces. Without an ide to keep track of the com.path.that.i.made.up.for.my.package.because.it.has.to.be.at.least.three.pages.long they'd never be able to code like that.
I don't doubt the cost of context switching. However I also think there's noticeable value in time-boxing. If I split my day into 3 chunks of two hours, with each block allotted to one task/project, I end the day with a feeling of having made more progress, and I do, because I sense the limited time, and therefore execute more efficiently.
> The Law of Context Density: A larger context naturally emerges with a bigger screen real estate.
This is so true. It's why I naturally feel dumber when I switch from a desktop computer to a laptop computer, and very stupid when working on a smartphone. I need my multiple tabs, big windows of text, etc. to get things done intelligently.
My code is usually well documented because I write what I'm about to do before I do it... Because otherwise I know I'll probably be interrupted and forget (I also have a memory issue, don't tell anyone!)
I think you don't need to have deep flow state to make progress at work.
For me I think flow state is more about how interested I am about the task than how much time I have. And frankly many tasks at work aren't that interesting so even if I have half of day uninterrupted time, I don't get into flow state.
Entering a flow state is a combination of multiple things IMO.
The amount of challenge needs to be challenging enough for your skill level, not too easy (boring) or not too hard (can't flow because you get stuck).
And (at least for me) I need to have the knowledge that I can focus on the task and not be interrupted. If I have a meeting in 30 minutes, there's exactly zero chance I'll enter a flow state because I'm expecting the meeting to start. And if I accidentally enter flow, I either work past the meeting or my flow is interrupted by a calendar alarm.
Interruptions during flow state are really damaging (for me) because I'm juggling a huge amount of context and data in my head that's not yet exported to any external medium. If I get interrupted a large-ish segment of that data will disappear and I need to spend time gathering it after the interruption has passed.
I get big screens but multiple screens gives diminished returns vs tab/spaces switching. Laying out the windows across different screens is always a pain in the ass
Here's an idea. Buy the office some poker chips. Everybody gets a few and writes their initials on them in marker. (Maybe a manager gets a few more than his direct reports do.)
Complexity values: White 1. Red 5. Blue 10. Grey 20.
When you want to ask a question of someone who looks deep in flow, just lay the appropriate chip on their desk. They can glance at it and balance the complexity versus their mental/work state and decide to either engage at once or defer it. Maybe mumble an ETA.
People will have to use the various chip values wisely if they want to be taken seriously.
That’s the same misconception about programming that people had decades ago. People thought the same thing when we introduced 5GLs back in the 1980s, and there was a lot of hype, and programming became more accessible, but demand for programmers increased rather than decreasing. People thought the same thing back when Fortran was introduced in the 1950s, and programming became more accessible, but the demand for programmers increased rather than decreasing.
The trick is that you need to hire someone to come up with a description of the problem which is precise enough that a computer can handle the rest. That person is the programmer.
If you’re being sarcastic, it’s not clear, just put a /s on the end or something.
Same with SQL, which was promised as a way for data processing managers to get rid of expensive programmers as the managers would now be able to get whatever information they wanted from their databases using an easy to understand, English like language. All it did was change the nature of the job of retrieving and storing database information but didn't actually get rid of the programmers.
Would you fire a brain surgeon if he's not willing to stop and provide a consult while he's operating? There's even robots who are equally as capable of surgery as AI are of software development.
The person who does not do any deep work probably gets automated away first. Doing simpler office tasks with a lot of context switching sounds like something for an LLM.
>why would I hire a programmer and pay them 200k a year when they cannot handle basic communication without becoming unproductive?
As entrepreneur myself, the main reason I pay someone 200K is because I can make this person generate more than 200k in profit.
The fact that someone have flaws, like any human being has, is an opportunity for me as I can make those flaws irrelevant by providing the environment where a team could be extra productive.
That means the team needs me and my company. If they were perfect on their own, they would not need me or my company at all and would be able to compete with my company.
If robots could one day do the work of programmers, they would be able to do the work of managers and entrepreneurs as well, which is way easier(I am engineer too).
>Are humans still necessary when robots are able to understand humans and become fluent ESLs?
You won’t use AI to replace a programmer because you likely wouldn’t have any job left to do, meaning either your boss will replace you with AI or AI will replace your company altogether
> From a risk management perspective, why would I hire a programmer and pay them 200k a year when they cannot handle basic communication without becoming unproductive?
Do you actually hire programmers (people just transforming detailed spec into code) at 200K/y? Or do you hire Engineers for 200K + Stock to transform uncertain requirements and constraints into a working solution? If the former, you are overpaying a lot.
> Are humans still necessary when robots are able to understand humans and become fluent ESLs?
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.