I predict this post (like every other post about not interrupting programmers) is going to trigger an avalanche of "shut up and do your jobs and stop complaining, you spoiled lazy coddled whiny programmers". It seems to be lost on negative commenters that giving programmers (or anybody else for that matter) the freedom to do their jobs well benefits everybody. I sometimes suspect that the interruptions, like the horrible open offices and pointless standup meetings, are put in place not because anybody even perceives them to be a benefit, but as a "muscle flex" to remind the workers who's boss, regardless of how detrimental is it to everybody, including the boss.
I've got no problem with having standup and other such things, but wish that all meetings (standup, backlog refinement, brainstorming sessions, etc) were scheduled all in one morning or one whole day out of the week, so that I could then have good 4-5 hour uninterrupted blocks for the rest of the days, instead of having an hour to work, a 20 minute meeting, 40 minutes of work, a 45 minute meeting, 15 minutes of "work", lunch, 30 minutes of work, another meeting, etc.
I tried to advocate for this at my current workplace but got a lot of pushback from people who said they didn't want to spend their whole day in meetings (even if it's just one working day out of 10). Others said they had so many meetings they couldn't possibly find enough time to have that many meetings in a day (doesn't make sense to me but that's a direct quote). Clarified here: https://news.ycombinator.com/item?id=27316534
Now I'm realizing my job is actually to attend meetings. I should ask for a raise! Though in reality I'm just going to quit soon.
The sweet irony is that this meeting heavy company of 50ish people uses Zoom without pro accounts...it's enough to make a grown man cry.
It's probably not, though - or, at least one of those meetings is the one where you have to showcase/demonstrate what you "accomplished" in spite of all the interruptions. You do have to produce something in spite of all the time wasted in meetings. I've unironically been told that that's what the weekends are for.
The 'my job is actually to attend meetings' was tongue-in-cheek - perhaps that wasn't as obvious as I thought. These days I code during the meetings, since it doesn't seem to make a difference whether I pay attention.
> I've unironically been told that that's what the weekends are for.
This kind of rings true, I've only been here around 3 months. I did spend a couple of weekends on code in the first month, but overall this company (and my comp) really isn't worth that kind of effort, so I've stopped.
I really only joined this company because I wanted a better work life balance (joke's on me) and my business isn't yet profitable, but I'm actually financially independent so it's tough to muster up motivation to work overtime for free.
I went on a kick of replying (and sometimes declining) meetings without agendas, asking "what is the agenda for this?"
And sometimes with an agenda, I will try to reply and resolve whatever it was about asynchronously. There have been several meetings avoided when I replied with something like "this sounds like known bug #1234" or "here's the wiki page documenting this: is there something else not covered?".
My # meetings went down after I started doing this. Maybe it changed the culture in a good way, or maybe people got tired of me and stopped inviting me to meetings.. but either way seems like success.
> Others said they had so many meetings they couldn't possibly find enough time to have that many meetings in a day (doesn't make sense to me but that's a direct quote).
How doesn't that make sense? If you want to compress all your meetings into one day for every two-week sprint (ten working days), you only need to average 48 minutes a day of meetings to fill that day. That's not an obscene amount.
The scenario is thus: you have, say, 6 hours of meetings relevant to team X per week. However, you tell team X that you have too many meetings on your calendar (from teams A,B,C) and thus do not have room to move X meetings to one day (but you can have these meetings otherwise).
It just sounds like a combination of lazy scheduling and no desire to improve dev experience.
Yeah, lazy scheduling is an easy trap to fall into. People have the wrong cost optimization function in mind while scheduling meetings -- moving an existing meeting is too expensive to consider, while breaking up an engineer's 4 hour block of productivity into 2 1:30 minute blocks is considered totally okay. In reality, the actual cost is the opposite -- moving a meeting costs nothing, but breaking up that block of free time costs an entire day of an engineer's time (something like $1000).
I have a plan for this. I'm writing a small program to move certain meetings to an auto-scheduled state. You pick some blocks on your calendar where you'll accept auto-scheduled meetings. You then say "I want to have a meeting with X, Y, and Z", and the system will use a constraint solver to find a time. The cost function favors bin-packed meetings, keeping entire days free, etc. If existing meetings have to move to optimize the cost function, so be it.
I don't actually know if people will tolerate this. People are creatures of habit, so if you're used to a biweekly team meeting on Monday, it will be weird when it gets replaced with a postmortem review that starts 30 minutes earlier and the team meeting moves to Thursday or whatever. I also think it will be hard to get people to commit to giving the bot a slot to work with. We shall see. If anything interesting comes of this I'll write up something about how it went.
I don't see how it is lazy scheduling to have at least one meeting each day of the week that you cannot reschedule. Finding time for six one-hour meetings is by definition easier than finding time for one six-hour block of meetings.
If you have a 6-unit block, then by definition you can fit 6 1-unit items - by putting them in that block. On the other hand, if you don't have a contiguous 6-unit block, you might still be able fit 6 1-unit items in (for example) 2 3-unit blocks. Compare memory allocation for 6 1KB blocks versus 1 6KB block, and how it's affected by memory fragmentation.
> Finding time for six one-[unit] [block]s is by definition easier than finding time for one six-[unit] [block] of meetings.
that you responded to. As long as there's anything at all with fixed position, you can end up with fragmentation, and even when (you can guarantee) there isn't, the former is just "exactly as easy" as the latter, so the general case degrades to "is by definition at least as easy as".
> Others said they had so many meetings they couldn't possibly find enough time to have that many meetings in a day (doesn't make sense to me but that's a direct quote).
My manager absolutely has more than 8 hours of meetings ina given week, and not jut useless ones. I've seen calendars of people a level or two above me where several days a week are wall-to-wall meetings. I don't think it's all that uncommon either. At some point, your job is coordinating and strategizing and communicating what needs to be done, and after a while, beyond meetings being an unfortunate nesesity, the meetings are the work
That's all well and good, as long as people aren't expected to produce a month's worth of software from 40 hours of nothing but meetings.
Unfortunately, they are. Largely due to inexperience and incompetence at the managerial level (zero technical chops once you go any level above IC).
I'm well aware most software companies aren't like this, though. They'd go out of business, like this one will. Almost every key engineer (including CTO) has left this company already - six of them in the three months since I joined. One of them wrote a 10 page open letter to the CEO on the way out. Things are a real mess...
Among other gems in that open letter was a link to this article [0].
I think people forget that it's incredibly difficult to coordinate a group of people beyond a certain number. We're all walking, talking grey gooey blobs of personality, feelings, ambitions and stubbornness (even managers/leaders). To even attempt at mitigating and guiding such things to team or company-useful outcomes we have to have meetings. Sometimes lots of them. It's the unfortunate nature of such a dynamic and chaotic system.
My least favorite, and all too common, kind of day is one that gets bracketed with meetings. The most usual form of this is the 10:30 AM standup/status meeting, paired with the 3 pm also standup/status/testing session. Assuming that you eat lunch, this is almost perfectly designed to make sure that you can't actually accomplish anything in the course of a 9-5 work day.
Completely agree with this in principle. I've passive-aggressively kept a spreadsheet that tracks how much time I spend in meetings, and it's averaged between 25% and 30% over the course of a couple years.
That's frustrating in its own right, but what's worse is that nobody ever factors it into scheduling estimates. If your team is getting 6 hours of work done in an 8 hour day, that's the equivalent of the whole team taking a day off every week and expecting everything to still get done on schedule. Except it's worse, because it makes you less efficient all the time rather than just one day a week.
On the other hand, I don't think that trying to fit all weekly meetings into a single day would solve the problem either. It's often the case that decision makers — the people you need to have at a lot of meetings — are involved in different areas of a business or product, so they'd have overlapping demands on their time. Where I work, there are a few people who are like this, and their schedule shapes how meetings are planned for everyone else. When any of these people have conflicting meetings scheduled, one or more of those meetings have to be rescheduled for another day.
So now everyone else has 2 half days of meetings a week, rather than one full day. And then, what happens if you learn new information and have to make a decision? Do you wait a week to talk about it? Probably not. So, you'd probably have a couple heavy meeting days, and then a number of ad hoc meetings scattered over the week. This is not the improvement we were looking for, and I think at a certain point the team would just drift away from the initial vision, and settle into the former pattern.
I do, I'll add in meetings in the estimate you should too. I love contracting where you charge the client for each meeting, itemize the list by date/duration and suddenly meetings become shorter.
It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work hours after you started work. Everyone knows you have 80 hours in a two week period so they expect you do finish 10 of these 8 hour tickets.
Compare that to Story Points. Your velocity over a two week sprint is auto adjusting for the typical/average meeting load and other interruptions. If you estimate a ticket at 8 story points and your velocity is 24 story points then everyone should expect you to finish 3 of these tasks per sprint.
This is obviously all 'on average' and there might be a production incident that means this time you didn't get it all done or maybe the other way around, someone got sick and 3 large meetings didn't happen and you got a 4th ticket through.
Also note that I chose 8 story points at random. 8 story points is specifically NOT to be equated with 8 hours. Story points are just uses as a relative complexity measure, meaning something with 3 story points is roughly a third as complex as that 8 pointer.
Many managers and even people that claim to be Scrum Product Owner or even Scrum Masters don't really understand that.
If you only have reasonable people around you it can work. It still has a lot of things going against it like feeling quite 'precise'. That was not the situation described though anyway. The larger the company is the more likely it will be that you have these unreasonable people around you and up the chain.
Story points are not a cureall. But it can help shift the conversation even with the 'unreasonable' people that just look at the hours vs a 40 hour work week. As mentioned though it needs someone that really understands what story points are and that won't let "them" just equate story points to hours. Seen that too many times even from "Scrum Masters". If 2 Story Points always equal 16 hours then you don't need to use Story Points.
Back to the preciseness. You estimated 30 hours but it took 33? How dare you! You could try and only estimate in whole or half days to mitigate.
Story points? They have a built in jitter as estimates get larger. 0.5 1 2 3 5 8 13 20... Some unreasonable people will try to compute a number of hours from your velocity. Luckily it will usually at least be imprecise but really you should try to make them understand that it makes no sense to even do that. Also don't let them do math with story points. That's a try at making thing more precise again which just doesn't make sense. Jira for example only allowed whole numbers in the story point field. They were pressured by customers to allow/show floats. That make no sense!
Even with story points you should only take in 70-80% of your velocity into each sprint. I usually average the velocity over the last few sprints too. It all serves to make it 'less precise feeling'. Yes that's math but the only math I will allow: avg(last5SprintsVelocity)*0.75 is what we take in. Round about, a bit more or a bit less depending on how the team feels since this never matches 100% to what's in the sprint anyway.
The culture here is fascinating. I comment (sincerely, and thoughtfully) in one topic criticising naive interpretations of AI -- heavily downvoted. OK, we're AI fanatics here: programmers are gods. Intelligence is just a program we're yet to write.
So in this thread I comment to defend how demanding programming is on the intellect. Again, many downvotes.
Indeed: isn't that precisely a good reason to reply rather than downvote?
I have maybe downvoted a handful of times in a decade of being on this site: only for spam or grossly misleading comments.
Increasingly I see seas of downvoted comments as-if this were reddit. I think that might just be it: the community has grown so large, it has attracted enough of those types who vote-their-emotions.
I think I agree with you in general, and to be fair I didn't downvote your original comment.
My takeaway was that you were taking the unpopular opinion (programming is uniquely hard/creative/etc) and attempting to reinforce it by unfairly reducing the creative act of painting to no more than paint on a canvas. That's my best guess.
You'll fare much better trying for constructive and introspective perspectives. Often you'll receive downvotes immediately anyway, but the tide might turn as other people might recognize something in what you write over time.
This is a startup/founder-centric forum, and creative people usually have less time for criticism and negative viewpoints, that then need to be translated into something worthwhile.
Useful advice; I'm somewhat put-off by "translation into worthwhile".
It is already worthwhile, since it is aiming at the truth: a comment is an invitation to revise your/my view.
It seems we're saying here that the community, generically, does not find that worthwhile. Rather we take as fixed a commenter's private interests, and commenting is merely an instrument for furthering those.
I understand that reasoning in selecting/voting posts; I dont have much sympathy with it in commenting.
I take my initial comment as a bit of a vent. I don't really take my others as being -- unless I'm mistaken. If it is venting, then I have more sympathy with the downvote.
It doesn't matter so much wether you were venting or not, but how others perceive your output. Some people are great at that, while many of us are not. It's not about good or bad, skills, or anything like that. It's just, to get better results from communication, it requires anticipation how something will be received. There's often a gap between what others hear, and what someone else said. Many disagreements are just that. Often, just by replacing a word, something will be received differently. Though it's more about empathy and anticipation, being there for others and not expecting much.
It's easy to be liked saying what other people want to hear. When you have things to say that people generally don't want to hear, this needs refinement how to go about it. The best way is to make people realize it for themselves, even if you don't get credit.
Sure, as a side point I'm not exactly concerned about up/down votes.
It was more a musing about a weirdness in downvoting behaviour; and whether there was something unintentional I was doing as a cause.
I don't mind upsetting people where the upset is due to a view of mine conflicting with a view of theirs. In this way, I'm very comfortable being downvoted. A downvote here is a signal of saying something worthwhile.
I find people agreeing with each other, on mass, a bit alarming if anything.
Disagreement motivates downvotes more than agreement motivates upvotes. Given the two topics, you will have a sizable group that feels strongly against the conventional wisdom.
The "community" isn’t homogenous. Different topics will attract different people who comment. Time of day also affects the distribution of visitors from different time zones (and possibly age groups), changing the distribution of opinions.
Author here: My intention wasn't to whine or anything. In fact, 2 of the 4 tips I gave was how I protect against interruptions from myself.
The comments have inspired me to write a follow up, titled something like "My number one source of interruptions is myself", and maybe it'll avoid the mess of flame.
> I sometimes suspect that the interruptions, like the horrible open offices and pointless standup meetings, are put in place not because anybody even perceives them to be a benefit, but as a "muscle flex" to remind the workers who's boss, regardless of how detrimental is it to everybody, including the boss.
Microsoft had a culture of offices with a door, to allow more focus. But it's not the only thing they did differently (and the companies valuation speaks for itself).
That's not quite the data point you think it is. Their valuation stayed roughly constant from 2001-2016, and the huge spike since then corresponds to a huge shift away from offices with doors - all new buildings after 2010 or so were that way, and most of main campus has been torn down to be rebuilt as open office floorplans.
I did some cat herding in past and the sole reason I run morning stand-ups is to know what everyone is doing. In other words, I was afraid to appear clueless when higher ups ask me about progress. It wasn't a muscle flex, but it wasn't for the team's benefit either. And yes, open spaces are wonderful for such low-effort managing activity.
This is not just about developers; it's really true for many kinds of knowledge work - for example, writing. It's just that in most of the other disciplines where these concerns are relevant, no-one would think of constructing a work environment that was so incredibly distraction-filled.
> it's really true for many kinds of knowledge work
I would argue not just knowledge work. Imagine a painter or a tattoo artist or a pilot or many others who are trying to concentrate and someone constantly interrupts them.
I've always found the mental processes used in writing and coding are quite similar. Architecture as well. I'm sure it's not a coincidence that we borrowed from their disciplines' vocabularies to describe our work as well.
If you need extreme focus to work with your code, that code is garbage.
Well written and well factored code is easy to get work done in, and you don't need to keep a zillion things in mind to navigate it.
Of course, reality is that the code most people work in is some level of garbage, and maybe there isn't much you can do about that. Either because you're not in charge, or you don't have the skills to improve the code.
> or you don't have the skills to improve the code.
Don't have the skills or don't have the time? Predicting, down to the hour, how long every programming task will take before you undertake it has been a staple of programming professionally as long as I've been doing it. I have the skills to simplify a codebase to any level you can define, but I can't do it in an hour.
> If you need extreme focus to work with your code, that code is garbage.
Maybe _i_ am garbage? Sometimes i need focus to solve the problem in a way that's easy to reason about. So no code exists, nothing you could critique, so perhaps your critique would be just about me?
Maybe you should collaborate with someone instead of insisting that you must be left alone without interruptions to succeed. Or maybe you (aren't garbage but) need more practice.
I don't know - two people getting interrupted frequently seem to be multiplying by zero to me.
Sometimes complex problems just require focused thought. Distractions detract focused thought. It's still possible to work through most problems when heavily distracted, but why the argument here? Legitimately, it baffles me. I do think devs over hype the importance of software development (generally speaking), but if an individual needs focus to solve a problem, be it math, software, economics, whatever - why would we argue that they don't actually need to be that focused?
I'm not saying they don't need to be focused. There are lots of ways to proactively ask for what you need that are more likely to get you and your needs respected, rather than this very common expression of frustration.
For a very basic CRUD app I tend to agree with you.
But for anyone dealing with synchronization between threads/processes/machines, modeling engineering problems with large systems of equations, complex business domains, systems programming, actually implementing something from an algorithms textbook yourself, cryptography, or any problem that requires you to keep more than one or two things in your head at once to be solvable, focus is important.
And if the simple crud app mentioned before turns into spaghetti through no fault of your own, you'll still need to focus.
So I'm not going to shame anyone for saying they need to focus.
One of the dumbest comments I've read on HN. Congrats.
Not all programming work involves tweaking little bits and pieces of an existing basic web application. I'm working on low level stuff right now, in my own codebase which is very clear and well organized, and I really have to concentrate hard on solving problems I've never worked on before.
After sharing this view for many years, I now realize how selfish it is. Now that I am a consultant working directly for entrepreneurs, it's clear that my job is to both deliver software AND to be as available as possible. You can build tools and strategies to get back to what you were doing. If you are that fragile, you've got some growing to do.
There really is a time and efficiency cost to all the task switching g.
But equally, and as another poster said already, software development really does require having meetings to get a good outcome.
I think it’s missed by many people that see meetings as an inconvenience, but very very often I have found that a meeting has radically altered the goal, or the plan, or the context. Pushing back against the meeting would be a crazy thing to do.
Inevitably, the "no meetings, no interruptions" devs are the same people complaining they don't have a voice in the larger org and that business doesn't care about their opinions. But no, they can't do a weekly 30 minute standing meeting.
Edit: and they'll happily point out the hypocrisy of the sales, marketing, and executive teams on coffee walks.
I've been doing 30 minute standing meetings pretty much every day since the XP folks coined the term "stand up", which was about 20 years ago. Every single one has consisted of the boss talking for 28 minutes (sometimes back and forth with one team member) while everybody else stands around, followed by, "ok, does anybody else have anything?" If anybody says yes, it's "we're almost out of time for this meeting, so let's take it offline".
20 years, five different employers, exact same experience every time, every day. Human psychology doesn't fit this structure the way you want it to.
The people who pay you typically wants you to develop software though, so it is in their interest to try to make you as productive as possible. But of course it is in your interest to keep them happy so they keep giving you money, you don't care if you deliver good software or not as long as they are happy with you.
Something really annoys me about developers acting like we are the only people on earth who have to think and focus to get work done. I'm not convinced programming is sufficiently different from any other skilled job.
Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.
The difference is that writers and mathematicians aren't typically expected to stand up every morning and explain to their colleagues and a manager who never did their job what they did yesterday, what they will do today, and what their roadblocks are. They're given a task and allowed to work for days, weeks, even months, with little or no interruption and largely self-guided.
They're also not typically creating things directly that provide as much business value as developers are.
The distinction is that almost all of that work is purely cognitive, and it is very asocial / individual.
This is fairly unique. If you're painting a big oil painting, yes you need similar kinds of isolation to get it done. BUT you aren't really maintaining a deep conceptualisation of the whole thing in order to paint. Rather you can "let the canvas remember most of your thinking": ie., the painting is its own schematic, by the means of layering & outlining it.
Also, in social-creative work "flow states" arise more naturally. I think people working with people, on the whole, enter flow states. It's why managers struggle to see the issue with asocial-creative work.
The issue here is code by itself is nothing like a dress or a canvas: it doesn't encode much of our thinking. We have to rebuild an interior world when we encounter it.
It is for this reason "literate programming" is almost certainly an excellent way to program -- absent almost any tools or popular sentiment in support of it.
Code can be written more like paintings are painted, ie., "self-documenting" -- but this is very hard to do well.
Programming with jupyter notebooks, I'd guess, is more resilient to interruption -- it is more like making a dress or painting a painting. Yes, you need isolation and quiet -- but an interruption neednt be so fatal. You write in your thought process as part of the activity of making the code.
It might be thoughtful, but it is incredibly dismissive of what it takes to be creative in other disciplines, i.e. painting. It effectively reduces the work of the artist to simply the state of a canvas. As if what's on the canvas encompasses the entirety of what it means to be an artist.
In my limited experience in the creative realm (music), it takes an incredible amount of flow and concentration to get a thought or feeling out of your head and into some form of recorded medium. I can't just stop cold, wake up the next morning, listen to what I was working on and pick up where I left off. The creation is a product of a fleeting experience that can't easily be recreated.
If you look at my recommendation it is that programmers should program more like how painters paint. I don't think it's a virtue to have to hold everything in your head.
Programming, as practiced, is distinct from painting -- but this has more to do with the practice of each. Programming tools do not afford the same ability to externalise thinking.
Fundamentally, they are built to run the code. Not to assist the programmer.
I think the fundamental challenge of coding isn't that different from many other professions (to agree with GP's point).
What is rarer is the moment of effective effort's nature, for many types of coding (to agree with your point).
The author's house of cards analogy trivializes it and makes it easier to dismiss as a rhetorical device. I'd use activation energy as a more apt comparison.
IOW, if you put in 30 minutes (or 3 days) understanding code, and do not make the correct 5 minute addition / change at the end of that, all that previous time is wasted. And moreover, that knowledge has some half life in my head, after which it must be reacquired.
And that correct addition / change cannot be made without first paying that cost.
This is not unique to coding, but is generally limited to professions involving the modification of dynamic complex systems. E.g. legal, biological, mathematical.
And I'd hazard to say of those, programming has a wider universe of possible approaches (aka "Why did the last person? Oh... Oh. Oh no."). Legal is probably the closest analogy.
Well I think painting (or composition of any type) is a category of activity whose instances are all fairly alike: theory-building, mathematical modelling, painting, programming.
But the question is where do the differences lie. My hypothesis for one difference is that we dont write code like painters paint.
That is bad. We should. Hence my advocacy for literate programming.
It isn't to be dismissive of painting, it is to say we put ourselves in a more precarious position by how little we support ourselves with our tools.
Painters (, mathematicians, etc.) are all working with pencil-and-paper in quite a radically different way.
I think this goes some way to saying, actually, there is a bit of a difference here.
You're right, and that's why whenever I want really good legal work done, I make sure to walk in to my lawyer's office every five minutes to ask him about articles I read on CNN. I think white-collar professionals work best in an environment with loud noises and constant interruptions, with the exceptions of sales and business development who need to be kept in a state of silence and isolation.
Had an attorney doing some work for me a while back. Emailed 3 emails over 3 different days - wasn't hearing back after the first, so I emailed again, etc.
I was told they couldn't work well with constant interruptions like that. WTF? Probably was an extreme ... something going on on their end, but... wanting/needing some answers and waiting 4 days was, to me, being rather patient.
Well, it's impossible to tell one way or the other without knowing what those questions were, and also how many other people they needed to answer questions for.
The point is that the people who barge in and do the interruptions usually don't have jobs requiring "flow state" and therefore have no understanding of its value.
Sometimes the job of these people is actually to barge in, interrupt and strike up a conversation, eg: sales. For them, having smalltalk (building a relation with a customer) is being productive.
Barge in to a client meeting when they're trying to close a deal to talk about the latest Marvel movie. I'm confident the sales person will get frustrated with your actions real fast.
When you watch these reality shows built on the British Baking Show paradigm you can see how hard the contestants are often working to be polite during the mini interviews. Many are clearly thinking “get that camera out of my face and stop interrupting me, asshole!”
Something that really annoys me about hacker news commenters is that when someone says "this is why X bother developers," they write comments that claim the statement was a claim that X exclusively bothers developers.
How is this comment at all related to parent article? It isn't written to make programmers seem unique at all, and in fact explicitly states "Flow is not a concept unique to computer programming".
Author here: Whining wasn't my intention. In fact, 2 of the 4 tips I gave was how I protect from interruptions from myself. My intention was to illustrate that context decays over time, so it's important to either record context as you go or help yourself stay focused for longer periods of time by removing the things that distract you the most (twitter, HNs ;)).
Anecdotally, I've noticed that management tends to consider interruptions more acceptable for anything related to web development. It's usually not as bad for the web dev team to slip their schedule as for the hardware team or the legal department or whatever, so interruptions happen more often. I was briefly embedded in such a team and that aspect drove me nuts. You really have to enjoy being essentially a point of contact as part of the job.
I have been working since I was 13, since you said "skilled" I will count QA, Project Manager, Sr Manager, Developer, Dev Lead only.
Development for me has the highest cost for task switching. The ramp up also takes longer. If I have 15 minutes before a meeting and I have not started writing code, I won't even bother starting.
If I compare that to being a Sr Manager, the cost of task switching is much lower, so was the ramp up time. Essentially it was a "let me get my notes, or the doc/email/presentation" and then I was set. That's maybe 1 minute.
I think the biggest difference is that as a developer you either have to come up with something that doesn't exist, or you have to read something that someone wrote that has never existed before and then you have to figure out what the mistake was.
The closet thing that resembles that for non developers is other abstract sciences, like Math, Chemistry, Physics or purely creative writers.
So imagine you are a creative ghost writer. You are asked to write Chapter 8 of this fantasy book. By the way Chapter 7 and Chapter 9 exist. Your writing has to match the style of chapter 7 and 9, including character names. Chapter 9 was written 16 months ago, and the guy left. Chapter 7 was never edited, but it will while you are working on chapter 8. You also wrote chapter 5 a month ago, but since then 4 other authors have updated chapter 5 to make it better. Do you think interruptions would help or hurt?
This is why developers complain about losing flow state. The cost of getting it back it too high.
> Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.
Either I am doing something wrong/I'm stupid or not all coding jobs need the same kind if deep work.
Because more than 90% of my individual technical work requires me to be in a flow state. It takes a good 30 minutes to hold a really large thought in mhead, and I can't start coding until I feel like I'm mentally present.
Now I have actually done different jobs too. I have presided over clubs in school, I worked as a mechanical engineer for a while and I used to write comedy scripts for dramas. None of them required flow state to the same degree.
Math derivations required an even higher flow state, and that's the only exception. I mentioned writing scripts. It actually requires a flow state, but it is more like pair programming and a group activity, so if you lose context someone will quickly bring you back to where you were.
Maybe other roles are more easily chunkable or people just don't care about making sure that their work doesn't have side effects or how it fits into the whole. But, I've found this one complaint by developers to be quite genuine.
__________
One thing that has worked is to write down entire interfaces, contracts and explicit steps before I even start. This step absolutely needs deep work and usually take 7-8 hours at a time.
However, once it is done, you can address each step or class as if it is somewhat side effect free. As a tangent, this is also why I hate using classes when state doesn't exist. A function allows for so much better side-effect free mental compartmentalization than instance methods.
> Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.
No one is saying that. Programming is plain hard work that requires deep concentration to keep a lot of parts in working memory, and is obviously more cognitively demanding than most other jobs. It appears you don't have experience with programming non-trivial things.
Author here: I agree that what you're describing, if developers act that way it is really annoying.
My intention of the article was to give a good visual of the complexity that gets built up while coding and some tips for how I've helped myself focus better.
It wasn't intended to come off as whining, it was more to help me recognize that there is a great deal of complexity that happens and it's easy for me to avoid facing complexity by doing less intense work.
3 of the 4 tips were targeted towards things I can do to protect myself, from well, myself. I'm my worst enemy when it comes to interruptions.
My other tip was how teams can work together to make sure an interruptions is worth it.
I'm certain, like you say, the need for flow or focus is not unique to developers, but can apply to many knowledge workers.
He takes ideas from Deep Work and builds on them by scaling up the ideas to how an organization should work, coordinate, and collaborate. Specifically, he looks at how to build organizations that are designed to support how our brains have evolved to think & work (without frequent context switches!)
I mean, I check my email twice a day, once at the beginning and once right after lunch. Not usually a disruptive context switch. It's why I usually prefer it.
I work remotely 4 days a week these days. I only spend about 45 minutes a week in meetings, and interruptions are extremely rare. I'm happy and very productive.
I have previously worked at places where I was interrupted several times a day, and I think it has a lot to do with a company's culture. Unfortunately, many companies in my country are dominated by sales people, and these people couldn't care less about software developers. Make sure you will be considered a first class citizen before accepting a job offer.
I see this kind of rhetoric often, whether at work or here on HN. I think some important factors are typically left out, however:
1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
2. The ability to work in a way that allows for interruption is a skill that can be learned.
As a younger programmer who loved nothing more than to sling vast amounts of code, interruptions were killers. Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities. I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity.
I’m not going to try and say these are universal principles or that any business can apply them, but as highly skilled workers I think this is an area where we tend to put in relatively little effort to overcome obstacles.
I don’t think XP could have worked at all without Refactoring, because everyone is sitting together and asking questions.
With conventional coding, if your house of mental cards falls, you may potentially lose all of your work. By working from working code to working code, even if you lose your train of thought you get to keep most of your work so far.
A number of other techniques also allow you to work more from working memory than memorization. This helps when writing code a little bit, but most of the payoff is for readers or subsequent additions.
The thing with DRY is that code reuse means that a breakpoint most likely can fire from multiple paths, which makes it hard to trace why you’re getting null/undefined instead of an empty array as your second argument. Conditional breakpoints can help for some of these scenarios, but it’s better if the code in the middle of the call stack tries to be as contained and organized as leaf node methods eventually become.
You can’t modify code if you can’t read it, and if it’s difficult to read then interruptions become more problematic, because both the cost of interruption and the likelihood of interruption go up when thinking time increases.
The cleverest code is the code which is easiest to understand.
I like what you say. I also think once you are used to an environment, you can type in such a way as to make errors that will be caught by the compiler/linter/tests. So once it compiles it works. Sort of leaning more into the design side and less into the is this variable defined side. How ever, in my experience, there are design points you won’t get to without building up state in you thoughts for hours and hours. Deep focus can give you diamonds that cut thru the thousand little decisions that you encounter during implementation. That is why for big projects I don’t like to really start typing till I have the three or for maxims for the project.
No links, but I've seen the change in myself and others I've known for a while. A few examples I suppose might be helpful:
Things I used to do 10 years ago:
- launch headlong into a task as soon as I understand the problem statement
- pick up a ticket/bug, quickly attempt to do as little as possible to make it go away
- unit tests/integration tests pretty much never
- lots of (many times unnecessarily) complex SQL
These habits led me away from a place of understanding an overall system and towards a place of adding lots of entropy to the codebase. In an ideal world, every time you touch a codebase you should be trying to remove entropy. If ever you introduce new rules or ideas into a codebase, it should be like pulling teeth because every time this happens the cognitive model you have to hold onto just to work on the project increases, which slows down the entire team. Being contemplative about the repercussions of a change (especially its impact on cognitive load) can help steer a team as a whole toward better decisions. Being quick to point these factors out in kick-offs and PRs helps protect the codebase as well. It's a lot of work, but when a project operates under this kind of structure there just aren't that many things that require a large amount of focus. And those that do don't necessarily require active focus.
Having a variety of things to do helps. If I start to death spiral on a problem (which is how I describe the feeling that I'm overloading my mental map), I'll put the problem down for a bit and work on something else.
Having a strong grasp of the subject matter is also a huge help. E.g. I work on a payroll platform. Learning how payroll should ideally work while at the same time writing code for the platform wouldn't be an ideal scenario (we definitely had to do this at times, but most of us had at least a few years background around payroll-related business functions). I've found this to be the biggest blocker to my productivity whenever I start a job in a new field.
Over the last 10 years I've worked in:
- Payroll/HR
- Luxury/Athletic Clubs
- Autism care providers
- Workers' Compensation Insurance
- Financial Performance Reporting
I've done the above using probably half a dozen different programming languages, team sizes everywhere from 2 to 50+, and (I believe) because of the way I approach my work that there's really never been a time in that period where I couldn't hit pause and pick it up later.
These factors are left out because they're rarely relevant.
> 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
Yes, there's a known partitioning between design and implementation, and it's very difficult to do both at once. Those "business value" decisions usually occur in the design phase, when you're not being precluded by implementation. However, interruptions are not the right way of doing the design phase.
Interruptions, by definition, occur when you were in the middle of some work, and if you were doing implementation work, result in you losing context (and therefore productivity) for something that is rarely design-related - and even relying on this for design/"business value" guidance is a hack, because you should be purposefully allocating some dedicated time to take a break from implementing and instead design and strategize.
Replying on unplanned interruptions to do this for you is suboptimal from every perspective and will be difficult and frustrating.
> 2. The ability to work in a way that allows for interruption is a skill that can be learned.
Absolutely - and yet, someone who has this skill and is interrupted is still less productive than someone who has the skill and isn't productive. Unless every one of your interruptions is essential (which isn't true for the vast majority of developers, including me), then learning the skill alone is just a hack, because the root problem is that you're being unnecessarily interrupted in the first place.
That isn’t the root problem. Ask why fives times. Why are you being interrupted? Often it is because management would prefer less development if they have more control over the development. I have worked at places where the management genuinely trusted developers and said and did: go forth and make great products for people. (Subscriptions paid the bills). This is rare these days, they, the management structure, often prefer no work being done to work that wasn’t “prioritized.” Often they are aware of a problem but don’t understand how to fix it systemically (if you mention it, the response is, you don’t have to attend these meetings (where decisions affecting you and your work are made), not, let’s see if we can have no Meeting Days once a week. Some bosses want to prove they are tough and in charge and force meetings doe that. Some bosses want to bypass the normal scheduling process for sprint work and have working sessions to do a thing immediately. Perhaps the system is not designed with good layers of isolation and good documentation so you have to commonicate between different people a lot. To reduce the interruptions you have to go back deeper.
Not OP, but much of it boils down to partition the work into smaller, simpler chunks. So if you do lose all your context when QA has a nerf war, you haven't lost much.
I’m in the process of designing talks outlining the general architecture of the platform my team has spent the last few years building. Minimizing cognitive load is a guiding principle of ours (and for our platform—payroll processing—it’s a necessity).
It is BS -- you can't split some work into smaller parts. If you interrupt pregnancy at 3 months, you likely won't get a baby in 6. Deep work may take time.
I don't believe it. Most of the most complex code I have found, when I needle the author about it, it turns out they don't really understand it either.
It genuinely seems to me that the Feynman Hypothesis holds true: If you can't explain it simply, then we don't really understand it.
And for certain if you can't explain the code simply, there's no way to make the code simple.
Author here: I agree with number 2. My intention was to show how context can pile up and that it decays over time. So in tip number 4, I show how I record context as I go. Think of recording context as archiving your focus towers.
I'm my own worst enemy when it comes to interruptions, which is why I kept 2 of my 4 tips aimed directly at myself for how I improve my focus.
At a team level, I made a clarifying point that small interruptions are okay, but often not worth it. While I can bounce back, there's a high risk I won't. I'm my own worst enemy (not passing the blame to anyone, I personally need to work on my habits to be better at bouncing back to what I was doing). So it's important our teams work together to make sure the interruptions are worth it. One way my team helps each other is we setup a @mention rotation in Slack (see tip 1). It allows us to schedule shifts daily, so only one person has to plan on their day being interrupted with brush fires. It's a win-win, because we share the load, but we also make it so frontline support knows who to contact (we use @devs).
I feel it's unfortunate the title made it come off as just another article whining about interruptions, that wasn't my intention, I'll do better on my next title.
Valid points. I probably came on a bit strong as well. My comments weren’t directed at your title or even content so much as the discussion I’m seeing both here and in my own workplace. I have managers who (God bless them) spend a lot of effort reducing interruptions, and I think that’s a valid effort.
That said, over the years I’ve learned to recognize that when I’m buried deeply enough in anything for an interruption to be particularly disruptive, I’m setting myself and whoever has to deal with my work next up for failure.
Even more so, working from home with 4 kids who homeschool, it just wouldn’t work if I couldn’t find a way to deal with urgent and jarring interruptions haha.
You certainly do! The variable we tend to be rigid about is whatever our idea of expectation is for our progress. It’s worth it to you and your employer both to be well organized in the way you approach legacy code. If you’re actively turning rotten stuff into tested, reliable code then you can organize yourself in a way that doesn’t require you to eat the whole elephant at once.
It may take some creativity, and I won’t claim this is universally true, but in all but the most exceptional of circumstances understanding of even an ugly codebase can be accomplished in bite-sized pieces.
> 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
The value isn't in the interruptions itself, but rather in the injection of context and perspective to the work being done.
Those can be delivered through interruptions like email and chat, but it is by no means necessary. Relying on interruptions is just a lazy default that results in much less real value delivery than could be achieved with a more thoughtful approach to organization design and workflows.
> 2. The ability to work in a way that allows for interruption is a skill that can be learned.
Working deeply on a problem without interruption (no checking email, HN, etc.) is the real skill, and one that is getting increasingly difficult to practice.
> Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities.
That's a good habit, but it would probably be better to just minimize interruptions and set aside time for such reflection.
> I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity.
This seems promising, but I would be willing to be that the benefits of reducing cognitive load would be even greater in an environment of minimal interruptions.
I don’t think we actually disagree. I was merely pointing out a couple factors I don’t think are emphasized enough. More often I see people characterize interruptions as show-stoppers. The reality is these things will happen, thus I would just argue that it is worthwhile to learn to deal with interruptions as efficiently as we can.
Fair enough. I might still disagree about the shape of the discourse (which things are emphasized too much or too little). I think interruptions are not as inevitable as people make them out to be.
However, I do agree that it is good to be prepared to handle interruptions well.
I'll be very interested to hear what you have to say on the subject of minimizing cognitive load.
Wow thanks for the surprise in traffic this morning.
Author here: I really wanted to illustrate the "why" it's frustrating. A more complete visual of what is actually in my head.
Also I didn't get a chance to pull it out as much as I'd like, but I'm my own worst enemy when it comes to interruptions. So I broke my tips into 3 categories:
1. Protect against myself (2 tips)
2. Protect against day to day working cycle (1 tip)
3. Help teams work together to help each other (1 tip)
As I suspected, your post has brought a barrage of "deal with it" dissenters. This is as predictable as it is frustrating: the contrarians themselves seem to accept that an uninterrupted programmer is a better programmer and that an uninterrupted programmer will produce a better result - but they _still_ insist that we just deal with the (mostly unnecessary, non-value-add, easy to remove) interruptions anyway.
My hope was that it would cause self reflection on what types of interruptions are causing us the most grief. For example, in tip 3, I realized I obsessively check my business metrics to the point where I could never lay the foundation of a focus tower. So I decided to put it in a red tab group in chrome to remind myself not to go there.
If I am 'in the zone' and someone walks up to me I hold up my hand and say 'wait a min I need to get this down'. Then I write a note to myself to myself back where I was. I then help them. If someone says 'can you come back later' I always respect it. I also sometimes just tell people 'not right now I will get back to you in a bit' and it works surprising well. But make sure you come back to them at some point or they will not respect it next time.
My personal biggest issue is self interruptions. Mostly web sites that are distracting.
Interruptions are so frustrating to developers in particular because their skills are in sufficiently high demand that they can behave like immature divas.
I remember reading once that Mike Myers, while filming the movie "Wayne's World", came out of his dressing room, found that there was no non-dairy butter for his bagel on the catering table, flipped the table over in anger and returned to his dressing room for the rest of the day.
That sounds like "immature diva" behavior to me. Saying "you want me to deliver the best product possible, and I want that too. In order to do that so that we can both come out ahead, I do my best when I can focus on making sure I get every detail right" seems far less immature. But maybe that's just me?
I feel like this misses the point of why interruptions are frustrating to me. To me, I have so many things that I'm cramming into my short-term memory that I need to have access to while doing a certain task. If I'm in the middle of writing the contents of a loop, and then I note that I'm operating in row-major, and I need to go make sure that the inputs are row-major and that this is documented.
So, instead of breaking my concentration on the loop itself, I just cache that knowledge and go back to it after I've finished the loop body. If I'm then interrupted, or worse, drawn away to something for a while, it's easy for that information to have fallen out by the time I return to finishing the code.
I ultimately need to keep a log of every single task (even if I plan on doing it in a minute) in order to thwart this. I don't like it, but that's just what I have to do to keep from introducing "interruption bugs" in my code.
I think another thing that is irksome is that the same people who are hounding you to finish some task in X amount of time are the ones making it go to 2X with their interruptions.
Author here: I totally agree! That's why I wrote tip number 4 "Record context as you go". I have a bash script that has the current command I'm working on (usually it's running a single test). I use it as a way to record notes and to quickly pick up where I left off.
Also record context as the last thing you do before you go out the door at the end of the workday. Makes it much easier the next day to pick up where you left off. A quickie brain dump - a couple of lines, a couple of paragraphs.
There are tools that can help with reducing the amount of working memory you need, but it’s a bit like kerning, in that once you see it you can’t unsee it, and your peers won’t understand why you are upset with their work.
I think learning to work around interruptions is a skill that can be developed over time.
Just watch some coding streamers on twitch. They can start and stop their coding while interacting with their viewers.
In many ways it's the similar for gamers on twitch. Try holding a conversation while playing a game. Over time they learn to be good at both simultaneously.
There are going to be some programming tasks that are harder to start and stop. But for most programmers those are going to be the exception.
This applies only to routine tasks. Those coding a game while streaming, do a known type of app. But when you do something new, which requires focus, research, it's a different story. IMO.
I laid out 4 tips that have helped me focus better.
I purposely made 2 of the 4 tips directed directly at myself. I create the most interruptions to my day.
My team has worked together to reduce unnecessary interruptions (see tip 1) as a courtesy to help me with my bad habits. The key point here is small interruptions are okay, but often not worth it, because I'll go off and do something else. If I could easily bounce back to what I was doing, I'd be much less frustrated at the interruption. My frustration lies with my inability to quickly go back to what I was working on, not the interruption itself.
Notice that I'm not passing the blame at others, I know my weakness. If I open chrome to check Slack, I'm gonna check HN, I'm gonna look at my email. This is something I need to work on personally
When I'm in the zone, here's something that happens: SO asks a question and somehow I hear the question but I don't process it, the question/event goes on some kind of stack. Then 5 or 15 minutes later I answer the question.
External stimuli is simply processed differently. There can even be a phone ringing for minutes, driving SO and kiddo mad. Yet I don't hear it: or at least it doesn't disturb me.
It even happens, rarely, that I get out of the zone and notice SO is gone and I'm a bit lost then I have to "focus" on the stack now: "ah yup, she said she went to pick her mom for she eats with us tonight".
I honestly don't know how to describe that as something else than being in some kind of zone.
I've seen friends studying for exams being in the same kind of state.
I like being there and I'm convinced I'm doing better work when I'm there.
EDIT: and there's something I do like in TFA: I separate my computer in "virtual desktops" assigned to different things. The main coding virtual desktop / workspace is ads-free for example (got a browser open but only for dev / for testing the (ad-free) thing I'm working on). I've got a "private email" virtual desktop, a "professional email" one (which is separate from the main coding virtual desktop), etc. It just makes sense to me.
The metaphor of the cards is spot on. But the Flow has its own Rhythm, and there are Very Bad times to interrupt and then there are Merely-OK times to interrupt. But what I found after many years of coding for a living is that the drive to reach a checkpoint and push context spills over into private life. I catch myself snarling at my SO if I'm not given a minute or two to finish whatever it is I'm in the middle of. Even when doing everyday things like making food or doing housework. Is this typical ? Is this sort-of OK, or just self-absorbed and conceited ?
The frustration with interruptions is that they introduce a sudden increase in required working memory.
It's the same frustration that people with ADHD experience regularly, because they have less available working memory in the first place.
Managing an inadequate amount of short term memory - whether caused by a deficiency in memory or overload of stimulus - is done mainly by restructuring your surroundings so they don't interrupt you.
Software development tends to be very appealing to neurodivergent people (including those with ADHD), so a strong distaste for interruption at work is to be expected.
> The frustration with interruptions is that they introduce a sudden increase in required working memory
I've wondered the same - though never been able to put it into such concise words. I formerly worked as a Mechanical/Controls engineer and did not feel the same frustration with interruptions at the time despite being an equally challenging industry (as far as my experience went). My conclusion is that the hard constraints of a physical system keep the problem space (and thus the required working memory) relatively small in the physical world. When you're writing software that has no physical manifestation, the problem space is typically massive since the constraints are fewer.
Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me.
I was diagnosed with ADHD this year out of other suspicions. (I've always suspected it, but avoided getting diagnosed because I thought I would use it as an excuse for being lazy).
My working memory also happens to be incredibly low, to the point that some of my friends call me a goldfish. (My long term memory is excellent in comparison)
I never put two and two together, but it makes so much sense.
I really should go for the long-overdue- prescription meeting I keep avoiding. :\",
> Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me.
It was for me, too. I've recently been reading about ADHD and people's experience with it. I've always had my suspicions, but never in a serious enough context to make any decisions about it. Reading people's experiences feels like talking to a long lost friend from a parallel universe.
I certainly have had opportunities to get an actual diagnosis, especially during my childhood, but the onus was always placed on me or my parents to take action. My parents were unmotivated by stigma and I was unmotivated by my ADHD symptoms.
So here I am, 28 and trying to motivate my ADHD brain to navigate America's absurd - and unnecessarily confrontational - healthcare system so I can get a diagnosis and medication/therapy.
> I really should go for the long-overdue- prescription meeting I keep avoiding. :\
I can't speak for the experience of people who have been using medication, but as someone who has spent decades without it, I would strongly encourage you to do that.
Good luck getting your ADHD brain to do the follow through!
I don't mind interruptions, unless I've been working on something for a couple hours and I can't figure out what could be going wrong with it - then I'm a real jerk!
I have recently stepped back into the realm of dealing with leadership and executives. The juxtaposition relative to a bunch of recent programming has made me realize why leaders don't fully understand why interruptions are so difficult - the type of work is fundamentally different.
* When dealing with Ops work or leadership, much of my work is thin and wide. In other words, I spend my time on a LOT of different things, but rarely need to deep dive. When I do need to deep dive, I'm looking at a timebox measured in hours. I can be interrupted because none of my thoughts are difficult to rebuild.
* When I'm programming, I'm working thin and deep. I have a very narrow problem that requires diving into something very deeply. There are often a lot of little details that are potentially blockers. All of that needs to be in active thinking memory - or at least very close to it. When I get interrupted while programming, those auxiliary details go "poof". Sometimes they're hard, if not impossible to get back.
It's amazing when pair programming in-person with the same person for a couple weeks how easy it is to resume working state after an interuption or lunch break. Same goes for much less lull time being unproductive, even if not doing something else but unconsciously working quite slowly.
174 comments
[ 2.5 ms ] story [ 230 ms ] threadNow I'm realizing my job is actually to attend meetings. I should ask for a raise! Though in reality I'm just going to quit soon.
The sweet irony is that this meeting heavy company of 50ish people uses Zoom without pro accounts...it's enough to make a grown man cry.
It's probably not, though - or, at least one of those meetings is the one where you have to showcase/demonstrate what you "accomplished" in spite of all the interruptions. You do have to produce something in spite of all the time wasted in meetings. I've unironically been told that that's what the weekends are for.
> I've unironically been told that that's what the weekends are for.
This kind of rings true, I've only been here around 3 months. I did spend a couple of weekends on code in the first month, but overall this company (and my comp) really isn't worth that kind of effort, so I've stopped.
I really only joined this company because I wanted a better work life balance (joke's on me) and my business isn't yet profitable, but I'm actually financially independent so it's tough to muster up motivation to work overtime for free.
Or pitting two managers against each other? I would love to attend your meeting but this other team needs this. Let them schedule it out for you?
And sometimes with an agenda, I will try to reply and resolve whatever it was about asynchronously. There have been several meetings avoided when I replied with something like "this sounds like known bug #1234" or "here's the wiki page documenting this: is there something else not covered?".
My # meetings went down after I started doing this. Maybe it changed the culture in a good way, or maybe people got tired of me and stopped inviting me to meetings.. but either way seems like success.
How doesn't that make sense? If you want to compress all your meetings into one day for every two-week sprint (ten working days), you only need to average 48 minutes a day of meetings to fill that day. That's not an obscene amount.
It just sounds like a combination of lazy scheduling and no desire to improve dev experience.
I have a plan for this. I'm writing a small program to move certain meetings to an auto-scheduled state. You pick some blocks on your calendar where you'll accept auto-scheduled meetings. You then say "I want to have a meeting with X, Y, and Z", and the system will use a constraint solver to find a time. The cost function favors bin-packed meetings, keeping entire days free, etc. If existing meetings have to move to optimize the cost function, so be it.
I don't actually know if people will tolerate this. People are creatures of habit, so if you're used to a biweekly team meeting on Monday, it will be weird when it gets replaced with a postmortem review that starts 30 minutes earlier and the team meeting moves to Thursday or whatever. I also think it will be hard to get people to commit to giving the bot a slot to work with. We shall see. If anything interesting comes of this I'll write up something about how it went.
https://www.getclockwise.com/
Edit: I see what you're saying, that makes perfect sense.
> Finding time for six one-[unit] [block]s is by definition easier than finding time for one six-[unit] [block] of meetings.
that you responded to. As long as there's anything at all with fixed position, you can end up with fragmentation, and even when (you can guarantee) there isn't, the former is just "exactly as easy" as the latter, so the general case degrades to "is by definition at least as easy as".
My manager absolutely has more than 8 hours of meetings ina given week, and not jut useless ones. I've seen calendars of people a level or two above me where several days a week are wall-to-wall meetings. I don't think it's all that uncommon either. At some point, your job is coordinating and strategizing and communicating what needs to be done, and after a while, beyond meetings being an unfortunate nesesity, the meetings are the work
Unfortunately, they are. Largely due to inexperience and incompetence at the managerial level (zero technical chops once you go any level above IC).
I'm well aware most software companies aren't like this, though. They'd go out of business, like this one will. Almost every key engineer (including CTO) has left this company already - six of them in the three months since I joined. One of them wrote a 10 page open letter to the CEO on the way out. Things are a real mess...
Among other gems in that open letter was a link to this article [0].
[0] https://neilonsoftware.com/2020/09/08/non-technical-developm...
Federate your business today.
That's frustrating in its own right, but what's worse is that nobody ever factors it into scheduling estimates. If your team is getting 6 hours of work done in an 8 hour day, that's the equivalent of the whole team taking a day off every week and expecting everything to still get done on schedule. Except it's worse, because it makes you less efficient all the time rather than just one day a week.
On the other hand, I don't think that trying to fit all weekly meetings into a single day would solve the problem either. It's often the case that decision makers — the people you need to have at a lot of meetings — are involved in different areas of a business or product, so they'd have overlapping demands on their time. Where I work, there are a few people who are like this, and their schedule shapes how meetings are planned for everyone else. When any of these people have conflicting meetings scheduled, one or more of those meetings have to be rescheduled for another day.
So now everyone else has 2 half days of meetings a week, rather than one full day. And then, what happens if you learn new information and have to make a decision? Do you wait a week to talk about it? Probably not. So, you'd probably have a couple heavy meeting days, and then a number of ad hoc meetings scattered over the week. This is not the improvement we were looking for, and I think at a certain point the team would just drift away from the initial vision, and settle into the former pattern.
Not saying it's a good thing!
It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work hours after you started work. Everyone knows you have 80 hours in a two week period so they expect you do finish 10 of these 8 hour tickets.
Compare that to Story Points. Your velocity over a two week sprint is auto adjusting for the typical/average meeting load and other interruptions. If you estimate a ticket at 8 story points and your velocity is 24 story points then everyone should expect you to finish 3 of these tasks per sprint.
This is obviously all 'on average' and there might be a production incident that means this time you didn't get it all done or maybe the other way around, someone got sick and 3 large meetings didn't happen and you got a 4th ticket through.
Also note that I chose 8 story points at random. 8 story points is specifically NOT to be equated with 8 hours. Story points are just uses as a relative complexity measure, meaning something with 3 story points is roughly a third as complex as that 8 pointer.
Many managers and even people that claim to be Scrum Product Owner or even Scrum Masters don't really understand that.
I've been somewhere that did this, and it worked reasonably well.
Story points are not a cureall. But it can help shift the conversation even with the 'unreasonable' people that just look at the hours vs a 40 hour work week. As mentioned though it needs someone that really understands what story points are and that won't let "them" just equate story points to hours. Seen that too many times even from "Scrum Masters". If 2 Story Points always equal 16 hours then you don't need to use Story Points.
Back to the preciseness. You estimated 30 hours but it took 33? How dare you! You could try and only estimate in whole or half days to mitigate.
Story points? They have a built in jitter as estimates get larger. 0.5 1 2 3 5 8 13 20... Some unreasonable people will try to compute a number of hours from your velocity. Luckily it will usually at least be imprecise but really you should try to make them understand that it makes no sense to even do that. Also don't let them do math with story points. That's a try at making thing more precise again which just doesn't make sense. Jira for example only allowed whole numbers in the story point field. They were pressured by customers to allow/show floats. That make no sense!
Even with story points you should only take in 70-80% of your velocity into each sprint. I usually average the velocity over the last few sprints too. It all serves to make it 'less precise feeling'. Yes that's math but the only math I will allow: avg(last5SprintsVelocity)*0.75 is what we take in. Round about, a bit more or a bit less depending on how the team feels since this never matches 100% to what's in the sprint anyway.
So in this thread I comment to defend how demanding programming is on the intellect. Again, many downvotes.
I have no idea what this community is.
I have maybe downvoted a handful of times in a decade of being on this site: only for spam or grossly misleading comments.
Increasingly I see seas of downvoted comments as-if this were reddit. I think that might just be it: the community has grown so large, it has attracted enough of those types who vote-their-emotions.
My takeaway was that you were taking the unpopular opinion (programming is uniquely hard/creative/etc) and attempting to reinforce it by unfairly reducing the creative act of painting to no more than paint on a canvas. That's my best guess.
This is a startup/founder-centric forum, and creative people usually have less time for criticism and negative viewpoints, that then need to be translated into something worthwhile.
It is already worthwhile, since it is aiming at the truth: a comment is an invitation to revise your/my view.
It seems we're saying here that the community, generically, does not find that worthwhile. Rather we take as fixed a commenter's private interests, and commenting is merely an instrument for furthering those.
I understand that reasoning in selecting/voting posts; I dont have much sympathy with it in commenting.
It's easy to be liked saying what other people want to hear. When you have things to say that people generally don't want to hear, this needs refinement how to go about it. The best way is to make people realize it for themselves, even if you don't get credit.
How others hear you, matters.
It was more a musing about a weirdness in downvoting behaviour; and whether there was something unintentional I was doing as a cause.
I don't mind upsetting people where the upset is due to a view of mine conflicting with a view of theirs. In this way, I'm very comfortable being downvoted. A downvote here is a signal of saying something worthwhile.
I find people agreeing with each other, on mass, a bit alarming if anything.
The comments have inspired me to write a follow up, titled something like "My number one source of interruptions is myself", and maybe it'll avoid the mess of flame.
Microsoft had a culture of offices with a door, to allow more focus. But it's not the only thing they did differently (and the companies valuation speaks for itself).
I would argue not just knowledge work. Imagine a painter or a tattoo artist or a pilot or many others who are trying to concentrate and someone constantly interrupts them.
If you need extreme focus to work with your code, that code is garbage.
Well written and well factored code is easy to get work done in, and you don't need to keep a zillion things in mind to navigate it.
Of course, reality is that the code most people work in is some level of garbage, and maybe there isn't much you can do about that. Either because you're not in charge, or you don't have the skills to improve the code.
Don't have the skills or don't have the time? Predicting, down to the hour, how long every programming task will take before you undertake it has been a staple of programming professionally as long as I've been doing it. I have the skills to simplify a codebase to any level you can define, but I can't do it in an hour.
After I got into the agile/XP world ~15 years ago, there are no deadlines, and if I need to take a day to improve some code, I do.
I'm not saying this to brag about my great life, but to tell you there are other kinds of jobs out there.
That said, a good number of pro developers do not have the skills to write well factored code. Or the interest, frankly.
Maybe _i_ am garbage? Sometimes i need focus to solve the problem in a way that's easy to reason about. So no code exists, nothing you could critique, so perhaps your critique would be just about me?
Sometimes complex problems just require focused thought. Distractions detract focused thought. It's still possible to work through most problems when heavily distracted, but why the argument here? Legitimately, it baffles me. I do think devs over hype the importance of software development (generally speaking), but if an individual needs focus to solve a problem, be it math, software, economics, whatever - why would we argue that they don't actually need to be that focused?
But for anyone dealing with synchronization between threads/processes/machines, modeling engineering problems with large systems of equations, complex business domains, systems programming, actually implementing something from an algorithms textbook yourself, cryptography, or any problem that requires you to keep more than one or two things in your head at once to be solvable, focus is important.
And if the simple crud app mentioned before turns into spaghetti through no fault of your own, you'll still need to focus.
So I'm not going to shame anyone for saying they need to focus.
Not all programming work involves tweaking little bits and pieces of an existing basic web application. I'm working on low level stuff right now, in my own codebase which is very clear and well organized, and I really have to concentrate hard on solving problems I've never worked on before.
There really is a time and efficiency cost to all the task switching g.
But equally, and as another poster said already, software development really does require having meetings to get a good outcome.
I think it’s missed by many people that see meetings as an inconvenience, but very very often I have found that a meeting has radically altered the goal, or the plan, or the context. Pushing back against the meeting would be a crazy thing to do.
Edit: and they'll happily point out the hypocrisy of the sales, marketing, and executive teams on coffee walks.
I've been doing 30 minute standing meetings pretty much every day since the XP folks coined the term "stand up", which was about 20 years ago. Every single one has consisted of the boss talking for 28 minutes (sometimes back and forth with one team member) while everybody else stands around, followed by, "ok, does anybody else have anything?" If anybody says yes, it's "we're almost out of time for this meeting, so let's take it offline".
20 years, five different employers, exact same experience every time, every day. Human psychology doesn't fit this structure the way you want it to.
Whining about how your "flow state" can't be interrupted because of how extraordinarily creative and artistic you are is just pretentious.
They're also not typically creating things directly that provide as much business value as developers are.
Not that I’m particularly fond of this current incantation of Agile.
This is fairly unique. If you're painting a big oil painting, yes you need similar kinds of isolation to get it done. BUT you aren't really maintaining a deep conceptualisation of the whole thing in order to paint. Rather you can "let the canvas remember most of your thinking": ie., the painting is its own schematic, by the means of layering & outlining it.
Also, in social-creative work "flow states" arise more naturally. I think people working with people, on the whole, enter flow states. It's why managers struggle to see the issue with asocial-creative work.
The issue here is code by itself is nothing like a dress or a canvas: it doesn't encode much of our thinking. We have to rebuild an interior world when we encounter it.
It is for this reason "literate programming" is almost certainly an excellent way to program -- absent almost any tools or popular sentiment in support of it.
Code can be written more like paintings are painted, ie., "self-documenting" -- but this is very hard to do well.
Programming with jupyter notebooks, I'd guess, is more resilient to interruption -- it is more like making a dress or painting a painting. Yes, you need isolation and quiet -- but an interruption neednt be so fatal. You write in your thought process as part of the activity of making the code.
In my limited experience in the creative realm (music), it takes an incredible amount of flow and concentration to get a thought or feeling out of your head and into some form of recorded medium. I can't just stop cold, wake up the next morning, listen to what I was working on and pick up where I left off. The creation is a product of a fleeting experience that can't easily be recreated.
Programming, as practiced, is distinct from painting -- but this has more to do with the practice of each. Programming tools do not afford the same ability to externalise thinking.
Fundamentally, they are built to run the code. Not to assist the programmer.
Jupyter notebooks are, here, a notable exception.
I actually spent 6 hours on Saturday writing it and another 4 to 6 other days getting it to where I was happy with it. So I appreciate the kind words.
What is rarer is the moment of effective effort's nature, for many types of coding (to agree with your point).
The author's house of cards analogy trivializes it and makes it easier to dismiss as a rhetorical device. I'd use activation energy as a more apt comparison.
IOW, if you put in 30 minutes (or 3 days) understanding code, and do not make the correct 5 minute addition / change at the end of that, all that previous time is wasted. And moreover, that knowledge has some half life in my head, after which it must be reacquired.
And that correct addition / change cannot be made without first paying that cost.
This is not unique to coding, but is generally limited to professions involving the modification of dynamic complex systems. E.g. legal, biological, mathematical.
And I'd hazard to say of those, programming has a wider universe of possible approaches (aka "Why did the last person? Oh... Oh. Oh no."). Legal is probably the closest analogy.
But the question is where do the differences lie. My hypothesis for one difference is that we dont write code like painters paint.
That is bad. We should. Hence my advocacy for literate programming.
It isn't to be dismissive of painting, it is to say we put ourselves in a more precarious position by how little we support ourselves with our tools.
Painters (, mathematicians, etc.) are all working with pencil-and-paper in quite a radically different way.
I think this goes some way to saying, actually, there is a bit of a difference here.
Doctors and nurses, who also deal with complex systems, have gotten exceedingly good at this with charting.
We? Considerably less so. But I'd hazard improving every year.
Reduction of boilerplate and flexibility-for-the-sake-of-flexibility in languages has been a big win, IMHO.
[0] https://en.m.wikipedia.org/wiki/Memoization
From c. 1m30s to 5m30s
I was told they couldn't work well with constant interruptions like that. WTF? Probably was an extreme ... something going on on their end, but... wanting/needing some answers and waiting 4 days was, to me, being rather patient.
No one is expecting an NBA player to respond to texts during a game.
I think programmers bring this up because they think people aren’t aware that their flow state is a thing, too.
Perhaps it's different in modern web development, where you create free form monstrosities that change daily and you are paid by code churn.
As legend would have it, Archimedes was killed by a soldier because he angrily demanded "Noli turbare circulos meos!"
I guess that is what "whiny" mathematicians deserve ...
Edit: fix a typo
Development for me has the highest cost for task switching. The ramp up also takes longer. If I have 15 minutes before a meeting and I have not started writing code, I won't even bother starting.
If I compare that to being a Sr Manager, the cost of task switching is much lower, so was the ramp up time. Essentially it was a "let me get my notes, or the doc/email/presentation" and then I was set. That's maybe 1 minute.
I think the biggest difference is that as a developer you either have to come up with something that doesn't exist, or you have to read something that someone wrote that has never existed before and then you have to figure out what the mistake was.
The closet thing that resembles that for non developers is other abstract sciences, like Math, Chemistry, Physics or purely creative writers.
So imagine you are a creative ghost writer. You are asked to write Chapter 8 of this fantasy book. By the way Chapter 7 and Chapter 9 exist. Your writing has to match the style of chapter 7 and 9, including character names. Chapter 9 was written 16 months ago, and the guy left. Chapter 7 was never edited, but it will while you are working on chapter 8. You also wrote chapter 5 a month ago, but since then 4 other authors have updated chapter 5 to make it better. Do you think interruptions would help or hurt?
This is why developers complain about losing flow state. The cost of getting it back it too high.
Either I am doing something wrong/I'm stupid or not all coding jobs need the same kind if deep work.
Because more than 90% of my individual technical work requires me to be in a flow state. It takes a good 30 minutes to hold a really large thought in mhead, and I can't start coding until I feel like I'm mentally present.
Now I have actually done different jobs too. I have presided over clubs in school, I worked as a mechanical engineer for a while and I used to write comedy scripts for dramas. None of them required flow state to the same degree.
Math derivations required an even higher flow state, and that's the only exception. I mentioned writing scripts. It actually requires a flow state, but it is more like pair programming and a group activity, so if you lose context someone will quickly bring you back to where you were.
Maybe other roles are more easily chunkable or people just don't care about making sure that their work doesn't have side effects or how it fits into the whole. But, I've found this one complaint by developers to be quite genuine.
__________
One thing that has worked is to write down entire interfaces, contracts and explicit steps before I even start. This step absolutely needs deep work and usually take 7-8 hours at a time.
However, once it is done, you can address each step or class as if it is somewhat side effect free. As a tangent, this is also why I hate using classes when state doesn't exist. A function allows for so much better side-effect free mental compartmentalization than instance methods.
No one is saying that. Programming is plain hard work that requires deep concentration to keep a lot of parts in working memory, and is obviously more cognitively demanding than most other jobs. It appears you don't have experience with programming non-trivial things.
My intention of the article was to give a good visual of the complexity that gets built up while coding and some tips for how I've helped myself focus better.
It wasn't intended to come off as whining, it was more to help me recognize that there is a great deal of complexity that happens and it's easy for me to avoid facing complexity by doing less intense work.
3 of the 4 tips were targeted towards things I can do to protect myself, from well, myself. I'm my worst enemy when it comes to interruptions.
My other tip was how teams can work together to make sure an interruptions is worth it.
I'm certain, like you say, the need for flow or focus is not unique to developers, but can apply to many knowledge workers.
https://www.amazon.com/gp/product/0525536558/
He takes ideas from Deep Work and builds on them by scaling up the ideas to how an organization should work, coordinate, and collaborate. Specifically, he looks at how to build organizations that are designed to support how our brains have evolved to think & work (without frequent context switches!)
I have previously worked at places where I was interrupted several times a day, and I think it has a lot to do with a company's culture. Unfortunately, many companies in my country are dominated by sales people, and these people couldn't care less about software developers. Make sure you will be considered a first class citizen before accepting a job offer.
1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
2. The ability to work in a way that allows for interruption is a skill that can be learned.
As a younger programmer who loved nothing more than to sling vast amounts of code, interruptions were killers. Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities. I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity.
I’m not going to try and say these are universal principles or that any business can apply them, but as highly skilled workers I think this is an area where we tend to put in relatively little effort to overcome obstacles.
With conventional coding, if your house of mental cards falls, you may potentially lose all of your work. By working from working code to working code, even if you lose your train of thought you get to keep most of your work so far.
A number of other techniques also allow you to work more from working memory than memorization. This helps when writing code a little bit, but most of the payoff is for readers or subsequent additions.
The thing with DRY is that code reuse means that a breakpoint most likely can fire from multiple paths, which makes it hard to trace why you’re getting null/undefined instead of an empty array as your second argument. Conditional breakpoints can help for some of these scenarios, but it’s better if the code in the middle of the call stack tries to be as contained and organized as leaf node methods eventually become.
You can’t modify code if you can’t read it, and if it’s difficult to read then interruptions become more problematic, because both the cost of interruption and the likelihood of interruption go up when thinking time increases.
The cleverest code is the code which is easiest to understand.
Things I used to do 10 years ago:
- launch headlong into a task as soon as I understand the problem statement
- pick up a ticket/bug, quickly attempt to do as little as possible to make it go away
- unit tests/integration tests pretty much never
- lots of (many times unnecessarily) complex SQL
These habits led me away from a place of understanding an overall system and towards a place of adding lots of entropy to the codebase. In an ideal world, every time you touch a codebase you should be trying to remove entropy. If ever you introduce new rules or ideas into a codebase, it should be like pulling teeth because every time this happens the cognitive model you have to hold onto just to work on the project increases, which slows down the entire team. Being contemplative about the repercussions of a change (especially its impact on cognitive load) can help steer a team as a whole toward better decisions. Being quick to point these factors out in kick-offs and PRs helps protect the codebase as well. It's a lot of work, but when a project operates under this kind of structure there just aren't that many things that require a large amount of focus. And those that do don't necessarily require active focus.
Having a variety of things to do helps. If I start to death spiral on a problem (which is how I describe the feeling that I'm overloading my mental map), I'll put the problem down for a bit and work on something else.
Having a strong grasp of the subject matter is also a huge help. E.g. I work on a payroll platform. Learning how payroll should ideally work while at the same time writing code for the platform wouldn't be an ideal scenario (we definitely had to do this at times, but most of us had at least a few years background around payroll-related business functions). I've found this to be the biggest blocker to my productivity whenever I start a job in a new field.
Over the last 10 years I've worked in:
- Payroll/HR
- Luxury/Athletic Clubs
- Autism care providers
- Workers' Compensation Insurance
- Financial Performance Reporting
I've done the above using probably half a dozen different programming languages, team sizes everywhere from 2 to 50+, and (I believe) because of the way I approach my work that there's really never been a time in that period where I couldn't hit pause and pick it up later.
> 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
Yes, there's a known partitioning between design and implementation, and it's very difficult to do both at once. Those "business value" decisions usually occur in the design phase, when you're not being precluded by implementation. However, interruptions are not the right way of doing the design phase.
Interruptions, by definition, occur when you were in the middle of some work, and if you were doing implementation work, result in you losing context (and therefore productivity) for something that is rarely design-related - and even relying on this for design/"business value" guidance is a hack, because you should be purposefully allocating some dedicated time to take a break from implementing and instead design and strategize.
Replying on unplanned interruptions to do this for you is suboptimal from every perspective and will be difficult and frustrating.
> 2. The ability to work in a way that allows for interruption is a skill that can be learned.
Absolutely - and yet, someone who has this skill and is interrupted is still less productive than someone who has the skill and isn't productive. Unless every one of your interruptions is essential (which isn't true for the vast majority of developers, including me), then learning the skill alone is just a hack, because the root problem is that you're being unnecessarily interrupted in the first place.
Have you figured out how to explain this to others? Some people don’t seem to get why their amazing code is more of a dumpster fire.
It genuinely seems to me that the Feynman Hypothesis holds true: If you can't explain it simply, then we don't really understand it.
And for certain if you can't explain the code simply, there's no way to make the code simple.
The term "deep work" is from here https://www.calnewport.com/blog/2012/11/21/knowledge-workers...
I'm my own worst enemy when it comes to interruptions, which is why I kept 2 of my 4 tips aimed directly at myself for how I improve my focus.
At a team level, I made a clarifying point that small interruptions are okay, but often not worth it. While I can bounce back, there's a high risk I won't. I'm my own worst enemy (not passing the blame to anyone, I personally need to work on my habits to be better at bouncing back to what I was doing). So it's important our teams work together to make sure the interruptions are worth it. One way my team helps each other is we setup a @mention rotation in Slack (see tip 1). It allows us to schedule shifts daily, so only one person has to plan on their day being interrupted with brush fires. It's a win-win, because we share the load, but we also make it so frontline support knows who to contact (we use @devs).
I feel it's unfortunate the title made it come off as just another article whining about interruptions, that wasn't my intention, I'll do better on my next title.
That said, over the years I’ve learned to recognize that when I’m buried deeply enough in anything for an interruption to be particularly disruptive, I’m setting myself and whoever has to deal with my work next up for failure.
Even more so, working from home with 4 kids who homeschool, it just wouldn’t work if I couldn’t find a way to deal with urgent and jarring interruptions haha.
I have too, but sometimes I have to read other people's code, and I don't have any control over how difficult that is.
It may take some creativity, and I won’t claim this is universally true, but in all but the most exceptional of circumstances understanding of even an ugly codebase can be accomplished in bite-sized pieces.
> 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise.
The value isn't in the interruptions itself, but rather in the injection of context and perspective to the work being done.
Those can be delivered through interruptions like email and chat, but it is by no means necessary. Relying on interruptions is just a lazy default that results in much less real value delivery than could be achieved with a more thoughtful approach to organization design and workflows.
> 2. The ability to work in a way that allows for interruption is a skill that can be learned.
Working deeply on a problem without interruption (no checking email, HN, etc.) is the real skill, and one that is getting increasingly difficult to practice.
> Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities.
That's a good habit, but it would probably be better to just minimize interruptions and set aside time for such reflection.
> I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity.
This seems promising, but I would be willing to be that the benefits of reducing cognitive load would be even greater in an environment of minimal interruptions.
https://www.bp-3.com/blog/a-fun-context-switching-game
However, I do agree that it is good to be prepared to handle interruptions well.
I'll be very interested to hear what you have to say on the subject of minimizing cognitive load.
Author here: I really wanted to illustrate the "why" it's frustrating. A more complete visual of what is actually in my head.
Also I didn't get a chance to pull it out as much as I'd like, but I'm my own worst enemy when it comes to interruptions. So I broke my tips into 3 categories: 1. Protect against myself (2 tips) 2. Protect against day to day working cycle (1 tip) 3. Help teams work together to help each other (1 tip)
hence why I catered 2 of the 4 tips to myself.
My personal biggest issue is self interruptions. Mostly web sites that are distracting.
I remember reading once that Mike Myers, while filming the movie "Wayne's World", came out of his dressing room, found that there was no non-dairy butter for his bagel on the catering table, flipped the table over in anger and returned to his dressing room for the rest of the day.
That sounds like "immature diva" behavior to me. Saying "you want me to deliver the best product possible, and I want that too. In order to do that so that we can both come out ahead, I do my best when I can focus on making sure I get every detail right" seems far less immature. But maybe that's just me?
So, instead of breaking my concentration on the loop itself, I just cache that knowledge and go back to it after I've finished the loop body. If I'm then interrupted, or worse, drawn away to something for a while, it's easy for that information to have fallen out by the time I return to finishing the code.
I ultimately need to keep a log of every single task (even if I plan on doing it in a minute) in order to thwart this. I don't like it, but that's just what I have to do to keep from introducing "interruption bugs" in my code.
I think another thing that is irksome is that the same people who are hounding you to finish some task in X amount of time are the ones making it go to 2X with their interruptions.
Rig up a precommit hook that rejects changes containing the string "FIXME"
That simple technique doesn't solve everything, but it goes a long way.
Just watch some coding streamers on twitch. They can start and stop their coding while interacting with their viewers.
In many ways it's the similar for gamers on twitch. Try holding a conversation while playing a game. Over time they learn to be good at both simultaneously.
There are going to be some programming tasks that are harder to start and stop. But for most programmers those are going to be the exception.
I laid out 4 tips that have helped me focus better.
I purposely made 2 of the 4 tips directed directly at myself. I create the most interruptions to my day.
My team has worked together to reduce unnecessary interruptions (see tip 1) as a courtesy to help me with my bad habits. The key point here is small interruptions are okay, but often not worth it, because I'll go off and do something else. If I could easily bounce back to what I was doing, I'd be much less frustrated at the interruption. My frustration lies with my inability to quickly go back to what I was working on, not the interruption itself.
Notice that I'm not passing the blame at others, I know my weakness. If I open chrome to check Slack, I'm gonna check HN, I'm gonna look at my email. This is something I need to work on personally
External stimuli is simply processed differently. There can even be a phone ringing for minutes, driving SO and kiddo mad. Yet I don't hear it: or at least it doesn't disturb me.
It even happens, rarely, that I get out of the zone and notice SO is gone and I'm a bit lost then I have to "focus" on the stack now: "ah yup, she said she went to pick her mom for she eats with us tonight".
I honestly don't know how to describe that as something else than being in some kind of zone.
I've seen friends studying for exams being in the same kind of state.
I like being there and I'm convinced I'm doing better work when I'm there.
EDIT: and there's something I do like in TFA: I separate my computer in "virtual desktops" assigned to different things. The main coding virtual desktop / workspace is ads-free for example (got a browser open but only for dev / for testing the (ad-free) thing I'm working on). I've got a "private email" virtual desktop, a "professional email" one (which is separate from the main coding virtual desktop), etc. It just makes sense to me.
It's the same frustration that people with ADHD experience regularly, because they have less available working memory in the first place.
Managing an inadequate amount of short term memory - whether caused by a deficiency in memory or overload of stimulus - is done mainly by restructuring your surroundings so they don't interrupt you.
Software development tends to be very appealing to neurodivergent people (including those with ADHD), so a strong distaste for interruption at work is to be expected.
I've wondered the same - though never been able to put it into such concise words. I formerly worked as a Mechanical/Controls engineer and did not feel the same frustration with interruptions at the time despite being an equally challenging industry (as far as my experience went). My conclusion is that the hard constraints of a physical system keep the problem space (and thus the required working memory) relatively small in the physical world. When you're writing software that has no physical manifestation, the problem space is typically massive since the constraints are fewer.
Tangential, but you contextualization ADHD as the lack of working memory is a light bulb moment for me.
I was diagnosed with ADHD this year out of other suspicions. (I've always suspected it, but avoided getting diagnosed because I thought I would use it as an excuse for being lazy).
My working memory also happens to be incredibly low, to the point that some of my friends call me a goldfish. (My long term memory is excellent in comparison)
I never put two and two together, but it makes so much sense.
I really should go for the long-overdue- prescription meeting I keep avoiding. :\",
It was for me, too. I've recently been reading about ADHD and people's experience with it. I've always had my suspicions, but never in a serious enough context to make any decisions about it. Reading people's experiences feels like talking to a long lost friend from a parallel universe.
I certainly have had opportunities to get an actual diagnosis, especially during my childhood, but the onus was always placed on me or my parents to take action. My parents were unmotivated by stigma and I was unmotivated by my ADHD symptoms.
So here I am, 28 and trying to motivate my ADHD brain to navigate America's absurd - and unnecessarily confrontational - healthcare system so I can get a diagnosis and medication/therapy.
> I really should go for the long-overdue- prescription meeting I keep avoiding. :\
I can't speak for the experience of people who have been using medication, but as someone who has spent decades without it, I would strongly encourage you to do that.
Good luck getting your ADHD brain to do the follow through!
* When dealing with Ops work or leadership, much of my work is thin and wide. In other words, I spend my time on a LOT of different things, but rarely need to deep dive. When I do need to deep dive, I'm looking at a timebox measured in hours. I can be interrupted because none of my thoughts are difficult to rebuild.
* When I'm programming, I'm working thin and deep. I have a very narrow problem that requires diving into something very deeply. There are often a lot of little details that are potentially blockers. All of that needs to be in active thinking memory - or at least very close to it. When I get interrupted while programming, those auxiliary details go "poof". Sometimes they're hard, if not impossible to get back.
I'm in the mode where I can't even start programming anymore because interruptions have trained me it is useless to even try.
I'm gradually trying to re-train myself to be productive, but it requires extreme measures.