[HN Gopher] Programmers, teach non-geeks the true cost of interr...
___________________________________________________________________
Programmers, teach non-geeks the true cost of interruptions (2014)
Author : davikrr
Score : 114 points
Date : 2021-07-09 19:32 UTC (3 hours ago)
(HTM) web link (daedtech.com)
(TXT) w3m dump (daedtech.com)
| eggy wrote:
| I have been programming since 1977/78, and sometimes for work,
| but most of the time for fun. As someone who does technical work
| at heights with rope access, and many years of technical diving
| on hydraulics, pneumatic, and electrical equipment, I can say it
| all depends on your ability to shut out interruptions and get to
| a good stopping point. I get frustrated when I am programming and
| I am interrupted, but my most frustrating experience was
| troubleshooting a technical issue at heights, underwater, or on
| the deck during a show with almost 2000 patrons getting
| impatient, while a COO/CFO wants an estimate on when you will
| solve the as-yet-unidentified issue. They call the show off if
| you can't get an estimate to repair or resume after 15 min. and
| they expect you to hold to your time-to-repair or resume
| estimate. Oh, and half a million to one million USD are at stake!
| You might be standing in front of a controls cabinet with
| hundreds of wires and devices and some indications of where to
| look, or 10m underwater trying to find a source of the fault. I
| think interruptions suck for any person who is focused on doing a
| good job - bus drivers, pilots (yes, I know - autopilot!),
| soldiers in combat, air traffic controllers, chefs, almost any
| job. This is why I never took a job coding full time. It is
| always secondary to my actual job even if it is important. And, I
| like J and APL for the very reason that you are looking at a few
| lines of code vs. a few pages of for loops ;)
|
| I code in C and other languages as well, so no offense to those
| who work mainly with scalars ;)
| aroundtown wrote:
| You know what helps:
|
| 1. Stop being passive aggressive about being interrupted.
|
| 2. Take notes.
|
| Dealing with [1]: it is ok, to interrupt some one who starts
| talking to you, tell them "Hang on", "Just a minute", "Come back
| in an hour". You have to put your foot down if you are working,
| even with bosses.
|
| Note taking[2]: early in my career I kept too much information in
| my head, including debugging. Life is so much better with notes.
| Nowadays, I work problems out on the paper and not in my head.
| It's harder to start doing, but once you start you have a paper
| trail of where you have been and where you are going. Sometimes,
| you do need to drop everything and go be part of the action. When
| that happens, notes will get you back where you were quickly.
| aynsof wrote:
| I agree on note taking.
|
| On putting your foot down - some bosses react really badly to
| that. I choose not to work for bosses like that anymore, but
| I'm in a position where I can do that. Not everyone is, though.
| avmich wrote:
| Nah, you don't understand. Even saying "get lost, I'm thinking"
| requires focus of Feynman, so by that time many already
| suffered. Keeping notes - good luck with that, if you thinking
| about something sufficiently vague, as in like 90+% cases
| happens to many - programmers. So stopping being passive
| aggressive is tantamount to cleverly preventing those
| distractions from happening in the first place - see e.g.
| Graham's piece with different time of work advice. And in those
| rare cases when you do need to drop everything - well, that'd
| better happen at most once a year, or you'll lose more than a
| few hours each time.
| bob1029 wrote:
| Taking notes is the superweapon for mitigating distractions in
| my experience. It doesnt eliminate the immediate impact, but it
| allows you to get back to a productive state so much more
| quickly.
|
| As a team leader in a 7 person company, I am not entitled to
| any degree of dedicated focus time during the work week.
| Everything is ultimately my responsibility and I have to answer
| some important questions immediately. Being aware that you are
| going to be disrupted and building in some mechanisms to deal
| with this reality is probably the more practical path.
|
| Trying to convince your PMs that distractions are lethal and
| that developers need to be protected in some anechoic chamber 8
| hours a day is never going to fly. It is total fantasy. I
| personally try to minimize the distractions that I as a
| developer incur upon other developers, but I cannot change the
| natures of other team members or artificially inhibit their
| interactions. People are just going to have to learn to get
| along and develop boundaries naturally. Don't be afraid to
| stand up for yourself, but also realize you are almost
| certainly not a special unicorn and that eventually you will
| have to interact with your teammates (the ones who don't browse
| HN) for the business to extract any value out of you.
|
| An additional strategy is to try and decompose your work effort
| into smaller steps before you begin. Trying to eat the whole
| elephant in 1 sitting is how you wind up in a lot of these
| "interrupted" situations to begin with.
| arthurjj wrote:
| Note taking is underrated especially because when you're junior
| you don't get interrupted and you can keep everything in your
| head. People think "If I could just not get interrupted" I
| wouldn't need to take notes.
|
| It has the added benefit of day to day it can help you remember
| what you're doing. Also if you save your notes if you come back
| to the project in a few months you have a refresher.
|
| Besides basic note taking I suggest two additions to it.
|
| 1. Keep it in reverse chronological order. For multiday or
| multiweek projects this makes it easier
|
| 2. Add the links to sites you were using instead of trusting
| browsing history
| PragmaticPulp wrote:
| > Your non-techie peers just don't get it, no matter how many
| times you try to make them understand.
|
| We really need to get past this smug idea that tech work is
| uniquely difficult in a way that no one else can understand. Any
| deep work suffers from interruptions, and programming isn't the
| only type of work that has significant mental context. This idea
| that programmers are uniquely vulnerable does no favors when
| trying to address the problem.
|
| Interrupted work is common to everyone, so use that commonality
| to your advantage when politely navigating interruptions.
|
| Also, I hope nobody takes the author's fantasy literally:
|
| > Well, worry not, because I think I have a way that you can
| actually demonstrate to them just how devastating interruptions
| are to your productivity compared to, say, theirs. In other
| words, here's how to make someone understand that, for you, an
| interruption isn't just a delay after which you can get right
| back to work but a complete total of your efforts up to that
| point. Here's how. Invite the PM/manager/sales/whatever person to
| sit at his desk and tell him to humor you. Open up notepad and
| type a series of 3 or 4 digit numbers in sequence, like so:
|
| Better advice is to learn how to communicate professionally. Real
| adults don't sit each other down and force them to add up a long
| list of 3-digit numbers while peppering them with interruptions
| to make a point.
|
| Instead, communicate like peers: "Sorry, I'm in the middle of
| something important. Can you come back at lunch time?"
|
| Or: "Is this urgent? I can't really stop what I'm doing right
| now, but I can stop by your office around 3PM. Will that work?"
|
| Don't be afraid to assert yourself in the conversation.
| Communicate the concern ("I'm in the middle of something
| important") and propose an alternative that would work better for
| you ("Can this wait until lunch time?"). Scale the assertiveness
| up or down depending on who's interrupting you. We all know some
| people who will take the hint and disappear, and we all know
| other people who will try to ignore your concerns and press
| forward anyway. Adjust accordingly.
|
| Finally - Recovering quickly from interruptions is a skill that
| can be developed and learned. Obviously, you can't negate the
| damage of interruptions entirely. However, making an effort to
| gather your thoughts and return to work after interruptions goes
| a long way to limiting the damage. The worst thing you can do is
| pop open HN or Reddit or Twitter after an interruption because
| you're already out of the groove. Knowing how to manage yourself
| and get back into the groove as quickly as possible is a valuable
| skill.
| randomdata wrote:
| _> Any deep work suffers from interruptions, and programming
| isn 't the only type of work that has significant mental
| context._
|
| Seems to be the only one that is both deep work and treated
| like an assembly line, though.
|
| Interruptions aren't that bothersome when you aren't under that
| kind of pressure to produce.
| xwdv wrote:
| > _We really need to get past this smug idea that tech work is
| uniquely difficult in a way that no one else can understand.
| Any deep work suffers from interruptions, and programming isn
| 't the only type of work that has significant mental context.
| This idea that programmers are uniquely vulnerable does no
| favors when trying to address the problem._
|
| We don't really have to. It is far better for us to keep
| selling the image that programming is something tantamount to
| wizardry than to make it seem like it can be understood on the
| same level with other kinds of work. For one, it's not really
| true. Programming requires a depth of focus you don't find in
| most other fields, and certainly within a single company no one
| has to work as deeply in their minds as the programmers do.
| lowercased wrote:
| > and certainly within a single company no one has to work as
| deeply in their minds as the programmers do.
|
| I sort of agree, but... I do think there are orgs where folks
| do deep thought work who aren't labelled 'programmers',
| but... they're probably doing the same 'type' of thinking, at
| some level, as folks doing coding.
|
| I'm certain 'developers' aren't the only folks who do deep
| thinking work, but we seem to be ... the ones treated the
| most like we're not, at various companies. In law firms I've
| been in, all the lawyers get doors, and those doors are
| closed when they're doing 'deep work' (planning, writing,
| talking to clients, etc). That's ... deep work, and they're
| getting billed out at hundreds of dollars per hour.
|
| 20+ years ago, I was doing dev work getting billed out at
| $180/hr, and was stuck in a cube next to project managers who
| were on the phone all the time. Wearing headphones was seen
| as "rude" by colleagues around me, but them talking on the
| phone for 5+ hours per day 6 feet from me was... totally AOK.
| MattGaiser wrote:
| > Any deep work suffers from interruptions, and programming
| isn't the only type of work that has significant mental
| context. This idea that programmers are uniquely vulnerable and
| no one else can understand doesn't help the situation.
|
| We seem to be the only profession that cares then. It is only
| developers who get why you Slack people you are sitting next
| to.
| uxp100 wrote:
| I guess I consider it part of my Job to be there and answer
| questions, assist other developers, etc.
|
| (Also please do not slack me when you're sitting right next
| to me, it's like, more disruptive and annoying than just
| talking to me. But mostly just use Email, please.)
| MattGaiser wrote:
| I am fine with that, just not immediately that second.
|
| And do you enable Slack notifications? I don't. I just look
| for the glow of the icon.
| gopalv wrote:
| > We seem to be the only profession that cares then.
|
| Our profession seems to be one where it is not obvious to
| others that we're in a flow or in deep working mode, since
| there is no visible difference between work-isolation mode,
| browsing the internet for random programming or browsing for
| fun, from four feet away.
|
| My uncle is a neuro plastic surgeon, he is prone to
| disruptions in more ways than I am (if I talk to him while
| he's cooking about a decision he needs to make, he loses
| track of the recipe), but I assume he is never disrupted by
| someone asking something unrelated while he's working.
|
| My partner too is clearly in an uninterruptible state when
| practicing the piano or painting something, even writing
| skeleton work is done on a book instead of a computer.
|
| But I get why it is hard to notice a programmer in isolation
| over other professions of deep work - I don't put on a lab
| coat or scrubs , to communicate that clearly to others in a
| familiar "at work" situation.
|
| I'm trying with a "at work" desk light, but I'm still not
| consistent enough with it & this is very much forced.
| ViViDboarder wrote:
| I think we're one of the few that requires nearly entirely
| deep work yet also often work in an environment that isn't
| conducive to it.
|
| Many other professionals that do this kind of work have
| private offices. Painters, architects, lawyers, etc.
| Meanwhile we cram ourselves together, surround ourselves with
| physical and digital distractions, and expect near
| immediately responsiveness from peers.
|
| I'm glad to have my team working from home now.
| MattGaiser wrote:
| I forget where I read it, but there was a blog post that
| mentioned how open offices basically turn developers into
| furniture as part of the job is appearing busy like bees.
|
| This actually happened to me once. Some big investor was
| coming one day, so we were all to be in our seats for a
| certain time to show that we were productive.
| GuB-42 wrote:
| I think development is a profession where it is not obvious
| when you are interruptible. In fact one of the best manager I
| had outright ask me "are you interruptible?", because she
| doesn't know if I am deep into a complex problem or just
| cleaning up stuff or waiting for my code to compile.
|
| Manual labor also require focus, but when you are occupied
| tends to be obvious. If you are under a car, messing around
| with a tool in your hand, everyone knows it is not the best
| time to interrupt you. In safety-critical jobs, like in the
| case of pilots, there are mandatory protocols that explicitly
| forbit interruptions during critical moments.
|
| People usually know enough not to barge in when the manager
| is having an talk with his higher up or when the salesman is
| negotiating with a customer unless it really is urgent.
|
| But programmers just stare at the screen all day, and most of
| the work happens in their head, so how do you know if they
| can be interrupted or not. Bad managers assume "always",
| because themselves only stare at the screen during their
| "off" time, so they assume programmers are always "off".
| Crespyl wrote:
| At a prior job we actually little LED RGB light tabs that
| would stick on our monitors, and set them to red or green
| to indicate exactly this. Uptake and responses were
| somewhat mixed, but it was nice to have an explicit signal,
| beyond just putting my headphones on, that I was not going
| to be welcoming of interruptions for the next few hours.
|
| At the time we were in a pretty cramped office in a co-
| working space, so I appreciated anything that could help
| cut down on distractions even a little.
| leephillips wrote:
| I think the issue is that, in a typical workplace that employs
| some programmers, they are in fact the only ones who will be
| doing deep work that requires sustained focus. The typical
| office does not contain, in addition to programmers, poets,
| painters, and mathematicians. If it did, those people would
| understand. Instead, aside from the programmers, you have
| mostly salesdroids and managers, who have absolutely no
| concept, because they have never done any real work.
| rhyswallace wrote:
| > Instead, aside from the programmers, you have mostly
| salesdroids and managers, who have absolutely no concept,
| because they have never done any real work.
|
| And this helps the argument not one bit. I'm sure it's very
| comforting to condescendingly look down on other professions,
| but you're doing nothing but further proving the point in the
| comment above.
| stingraycharles wrote:
| I agreed with you until your last sentence. I think the goal
| we want to achieve here is to be more understanding of what
| each other's work involves; I absolutely don't envy the
| manager who is constantly being interrupted, or the sales
| person who is doing some next level persuasion and working
| months to get this customer to sign that contract.
|
| If you're dismissive of their work, how can you ever expect
| them to be understanding of yours?
| testudovictoria wrote:
| > _Instead, aside from the programmers, you have mostly
| salesdroids and managers, who have absolutely no concept,
| because they have never done any real work._
|
| Wow. This is exactly what the top comment was talking about
| with the opening sentence. These people may not need deep
| concentration to be successful, but that doesn't mean they
| don't do real work.
| a1369209993 wrote:
| > These people may not need deep concentration to be
| successful, but that doesn't mean they don't do real work.
|
| They didn't claim that. They claimed that the fact that
| these people don't do real work means that they don't need
| deep concentration to be successful. A implies B, not B
| implies A. (For example, off the top of my head, plumbers
| (unlike salesdroids and managers) clearly do real work, but
| very little if any of it involves a deep mental model that
| would take significant time to rebuild if interrupted.)
|
| FWIW, I don't actually agree with that implication as such
| - it would imply that, eg, playing Factorio is "real work"
| - but the problem is less stupid than "doesn't need deep
| concentration => doesn't do real work".
| leephillips wrote:
| Thank you.
| haswell wrote:
| Which, interestingly shines a light on just now reductive
| the original comment was.
|
| Parent comment's take was actually more charitable to the
| GP by at least leaving room for the possibility that
| managers do real work (they do, and hopefully this isn't
| controversial).
|
| And I'd go a step further and argue that even within the
| managerial role, there are tasks that demand focus and
| deep work.
| a1369209993 wrote:
| > the possibility that managers do real work (they do,
| and hopefully this isn't controversial).
|
| I mean, I'd hope it's uncontroversial that _any_ general
| statement about people has exceptions, but I assumed it
| was clear that we were talking about _typical_ managers
| and salesdroids, not making blanket universalisms. If it
| wasn 't I apologize for the confusion.
| haswell wrote:
| > _Instead, aside from the programmers, you have mostly
| salesdroids and managers, who have absolutely no concept,
| because they have never done any real work._
|
| Honest question - how many years of professional experience
| do you have?
|
| Have you ever been on a team that didn't have enough devs and
| needed to grow? Have you been on a team that addressed that
| by hiring more devs? What about funding for software and
| other tools to do your job?
|
| This obviously varies from company to company, but often,
| especially at companies that promote from within, the
| managers around you very likely started doing exactly what
| you're doing.
|
| Managers also have their own kinds of deep work, like careful
| and detailed proposals to increase funding so your team can
| grow, just to name one.
|
| If you expect the people you work with / who manage you to
| understand you and the challenges posed by distractions,
| taking some time yourself to truly understand _them_ is just
| as important.
|
| I should add a disclaimer: I'm not a people manager.
| juliansimioni wrote:
| >because they have never done any real work
|
| A good sales person can make the business money (you know,
| the thing that keeps them from disappearing) without _any_
| product yet existing at all. Programmers who build something
| rarely bring in money by its mere existence.
|
| Be careful who you insult because its unlikely you could do
| what they do, and it's not guaranteed that you'd keep your
| job ahead of them if it comes to it.
| a1369209993 wrote:
| > A good sales person can make the business money
|
| A good 419 scammer can make the business money without any
| product ever existing at _any_ point in time - that doesn
| 't mean they're doing anything useful.
| leephillips wrote:
| "it[']s unlikely you could do what they do"
|
| Not just unlikely--practically impossible. I don't have the
| skills of a good salesperson or manager1. But that's
| orthogonal to what I was talking about, and to the subject
| of the fine article.
|
| [1] And neither do most people employed in these positions.
| lmilcin wrote:
| I think the reason this is more damaging to developers because
| as a developer you probably can't produce anything without
| focusing.
|
| As to communicating when you don't want to be interrupted -- I
| am still working from home, and even my kids know that when the
| door to the office is closed they can't interrupt.
|
| When I was still working at the office I was telling people
| that headphones == do not disturb.
|
| Obviously, you need to provide them some way to send you the
| message. I try to keep my office doors open and headphones off
| when not necessary. I also tell people shoot an email and I
| will respond when I can.
| hinkley wrote:
| I think I'd mostly be okay going back to in-office work if I
| had an office door, which of course I won't.
| Zababa wrote:
| > Instead, communicate like peers: "Sorry, I'm in the middle of
| something important. Can you come back at lunch time?"
|
| That's already too late though. At this point I've already lost
| what I was doing.
| SamBam wrote:
| I feel like if your mental model of the program is so fragile
| that even saying "Sorry, I'm in the middle of something
| important" breaks it, then it may be worth working out how to
| ground more of it.
|
| When I find myself six or seven levels deep in a stack, I
| often realize I need to open up a new coding window and write
| myself some quick notes.
| Zababa wrote:
| That's a fair point and good advice, however the full quote
| was "Sorry, I'm in the middle of something important. Can
| you come back at lunch time?", which can then start being a
| full conversation to find a time that fits both of you. I
| think a good way to respect other people time is to use
| asynchronous means of communication as long as what you ask
| isn't urgent.
| [deleted]
| dkarl wrote:
| > We really need to get past this smug idea that tech work is
| uniquely difficult in a way that no one else can understand
|
| Is that the only possible reason they wouldn't understand? The
| etiquette around interruption is different in different
| professions, and programming seems to be on an extreme edge of
| a spectrum. There are professions where people work together in
| offices and interrupt each other all the time, without
| restraint. I am not smarter than them. They are doing jobs I
| would not be good at. Something must be different.
|
| Maybe the work is different in some way than most other jobs,
| or maybe we're defective. Honestly, I think the people who are
| best at accommodating this difference are alpha management
| types who look down on programmers. They aren't surprised that
| we don't cope well with interruptions, just like they're not
| surprised that their dog is afraid of fireworks. "Stay away
| from my programmers. They work better when nobody talks to
| them."
|
| It's people who think we're really smart, or who rely on
| empathy to relate to us, who keep interrupting, because they
| can't wrap their heads around the idea that it's hard for us.
| Good communication is not a magic solution for this. Every time
| you try to explain, they'll translate it into something that
| feels reasonable and relatable to them. PragmaticPulp told me
| that interruptions are super bad for his productivity... so
| whenever I have questions I'll just pop in and out really
| quickly. PragmaticPulp told me that interruptions are super bad
| for his productivity... because I should have taken that
| question to John instead. PragmaticPulp told me that
| interruptions are super bad for his productivity... because
| he's been under a lot of stress this week. PragmaticPulp told
| me that interruptions are super bad for his productivity...
| because he doesn't like me and doesn't like talking to me.
|
| The idea that what we're saying is a straightforward expression
| of something we actually experience is way more bizarre and
| unlikely to them than the idea that we're trying to say
| something else and it's coming out in a garbled or passive-
| aggressive way.
|
| I think that's why, as misguided as the article's suggestion
| is, the idea of allowing people to experience what we
| experience is so appealing. If they could experience it
| firsthand, then when we talked to them about it, they could
| accept it at face value.
| lordnacho wrote:
| I agree with the general point of the article. When you're deep
| coding you have a tentative model containing a lot of variables
| about the problem. You haven't committed them to memory yet,
| because it's all workings out that are undecided. Once you make
| some conclusions, that can be remembered because the end theory
| is simpler than the path to get there.
|
| Nobody else constructs models in their minds that are almost
| purely mechanical and specific to a small problem. Every model
| the sales guy or manager uses has very few knobs to twist and
| are mostly intuitive models for which everyone has a template
| and practices use of every day: emotions, status, hierarchy,
| urgency, etc.
|
| The programmer is building a house of cards and startling him
| means he needs to start over.
|
| I agree if you're not deep coding, eg doing a bit of cleanup or
| documenting, it's not such a big problem.
|
| EDIT
|
| I seem to have ruffled some feathers with the absolute sounding
| "nobody else" phrasing.
|
| I'm sure you'll run into someone else who has to think like a
| programmer, but I also tend to think such people to the extent
| they exist actually are programmers in some sense: either they
| happen to have a different title, or under the hood they are
| pretty much doing the same thing.
|
| Now for some more about the nature of programmer's complexity.
| The thing about being a coder is you end up working on multiple
| abstraction levels, and they are all still your domain. If your
| app has some networking issue and you're wiresharking the
| packets, that's still you. If the front end is slow because
| you're calculating a lot on the GUI thread, that's still you.
| If the database is returning strange results, that's still
| programming. These are all areas that require a huge amount of
| work, in particular reading about existing conventions and
| tools, to understand.
|
| In addition, programming has the capacity for you to create
| your own, local abstractions. Not only is the computer capable
| of remembering everything you made up, it also computes the
| interactions that you didn't consider. You have to interface
| these with the firmament. It is this creation of your own
| little menagerie and connecting it to the existing world that
| throws up an enormously large space for weird things to happen.
|
| The thing that I need to point out is that there's no general
| human intuition for a lot of these things. Yes, you can use a
| bit of drawing diagrams to help you. But we don't get that
| intuitive, natural feel that you get in the rest of your life,
| particularly around emotions, that is I think called system 1
| somewhere.
|
| I also don't mean domain specific intuition, which is really
| just a form of learned knowledge.
| jolmg wrote:
| > Nobody else constructs models in their minds that are
| almost purely mechanical and specific to a small problem.
| Every model the sales guy or manager uses has very few knobs
| to twist
|
| What about mechanical engineers, electronic engineers, etc.?
| lordnacho wrote:
| They are programmers. They even use programming tools to do
| their work.
| jolmg wrote:
| Architects, lawyers...
|
| EDIT: Removed writers. Architects and lawyers don't have
| as much room for mistakes and technical detail matters
| more in their work.
| lordnacho wrote:
| Intuitivists. They might take their time to refine their
| thoughts but they aren't programmers.
|
| Type one thing wrong and your novel is still a novel.
| lowercased wrote:
| type one thing wrong and my code is still code, but the
| meaning changes, just like the meaning in the novel
| changes.
|
| with many novels, the author may have intended X, but
| readers are often encouraged to bring their own views and
| interpretations to the work, and those may often be
| useful to others in understanding the work. that's not as
| true for most software I've worked on though.
| jolmg wrote:
| And when I mentioned writers, I was thinking of the work
| that's probably required to build the plot, even before
| writing it. I'm not a writer, but I would imagine it
| involves holding a world and timeline in their head and
| tweak it while making sure they're not introducing plot-
| holes. I imagine quite a bit of research is involved,
| too.
| [deleted]
| lelandbatey wrote:
| Describing a _lawyer_ as an "intuitivist" is pretty
| hilarious. Their work, especially surrounding contract
| work, can be extremely programming like, with very
| particular language, highly technical and specific
| terms/wording, and there absolutely are _many_ cases
| where typing one thing wrong (such as a misplaced comma)
| can (and has[1]) completely change the meaning of crucial
| sections of contracts.
|
| [1] - https://www.bbc.com/worklife/article/20180723-the-
| commas-tha...
| lordnacho wrote:
| The list was different earlier.
|
| Obviously I can't know about what every profession does,
| not even my own. But I've interacted with enough
| professionals of various sorts to say I don't think the
| intricacy is the same.
|
| Ymmv
| jolmg wrote:
| As if programming can't involve intuition. There isn't
| one way to do things nor do we operate with strictly
| defined rules to follow. We need a fair amount of
| intuition from experience to make the decisions that will
| be more beneficial for the future development of our
| projects.
| lordnacho wrote:
| The point is others tend to rely more on intuitive
| structures that are everyday. Crystallised intuition
| about a specific domain doesn't count because of course
| everyone who is a specialist is going to have their own
| local knowledge. Calling it domain intuition might make
| more sense.
| jolmg wrote:
| What kind of intuition do they rely so much on to call
| them intuitionists that is everyday in nature rather
| particular to their domain, but that programmers don't
| also rely on? Are we talking "everyday" like "I need to
| buy groceries" type of intuition? I don't understand what
| you're trying to say.
| MattGaiser wrote:
| The comment could probably apply to every form of
| engineering if we want to look at things broadly.
| caconym_ wrote:
| > Nobody else
|
| Programmers are far from the only people who do creative work
| that involves building complex models in a mental "buffer"
| and then streaming them out into some persistent form.
|
| Maybe most people on HN _are_ programmers, and maybe most
| programmers work in offices where they 're the only people
| who do this kind of work. But that's the kind of
| exceptionalist tech-centric point of view that can only make
| it more difficult to communicate our struggles to our non-
| programmer co-workers, who might actually be _very_ familiar
| with similar struggles in different (possibly non-
| professional) contexts.
| haswell wrote:
| > _Every model the sales guy or manager uses has very few
| knobs to twist and are mostly intuitive models for which
| everyone has a template and practices use of every day:
| emotions, status, hierarchy, urgency, etc._
|
| The fundamental issue I have with this argument is that it
| assumes the role of "sales guy" and "manager" are always the
| same.
|
| I've spent quite a few years in the Enterprise software
| space, and I can assure you that the knobs to twist on a
| massive deal are numerous, highly complex, and would paralyze
| some devs in their tracks.
|
| It's easy to trivialize these roles because they often appear
| to be full of "busy work". If you have the opportunity, go
| spend some time with the sales team! Listen in on some calls.
| Get involved in a hiring round. Participate in a marketing
| meeting about establishing positioning for your next
| product/feature.
| inglor_cz wrote:
| I basically switched from programming to writing (= for
| humans) and the need for concentration is rather similar. The
| model of the text-to-be is not as mechanic, but consists of
| so many threads that need to be woven together that you can
| easily lose track.
| camjohnson26 wrote:
| I've noticed that I have a lot less trouble with
| interruptions deeper in my career than starting out because
| those mental models are refined and intuitive now. The
| example presented in the article where the programmer has a
| carefully constructed recreation of a null reference bug
| could probably be broken up into a series of steps that don't
| require keeping as many variables in your head.
|
| I agree that interruptions are annoying but they're
| unavoidable, and we can develop strategies to make them less
| impactful. Passive aggressively trying to make somebody else
| feel your pain is guaranteed not to work and will just make
| them resentful and make you look petty.
| lordnacho wrote:
| I agree it's silly to hit back at people.
|
| As for managing the interruptions, I tend to think of it
| that a deep session needs maybe 3 hours from one end of the
| pool to the other. Break it and you might need to start
| over, depends on how checkpointy you can make it, so try to
| make a way to not get interrupted for that length of time.
| That's a real senior coder skill BTW, making your own
| exploration recoverable. You already mentioned one thing
| you can do, which is to not try the really long crossings.
| haliskerbas wrote:
| > Nobody else constructs models in their minds that are
| almost purely mechanical and specific to a small problem.
| Every model the sales guy or manager uses has very few knobs
| to twist and are mostly intuitive models for which everyone
| has a template and practices use of every day: emotions,
| status, hierarchy, urgency, etc.
|
| When we get to this sort of absolute perspective. I like to
| think "either everyone before me is/was an idiot, or maybe
| I'm missing an unknown unknown"
|
| I'm sure other technical fields of non programming require
| holding more than one thought in the head at once.
|
| Perhaps anyone constructing anything that depends on an
| intricate set of rules may experience the same thing.
| avmich wrote:
| In a lecture Lamport once talked about the difference
| between mathematical equation (where half a page is a lot)
| and a program (which is a sort of math, only many pages
| long).
|
| > I'm sure other technical fields of non programming
| require holding more than one thought in the head at once.
|
| That's not a good enough comparison. You don't see the
| qualitative difference.
| isbvhodnvemrwvn wrote:
| > Every model the sales guy or manager uses has very few
| knobs to twist and are mostly intuitive models for which
| everyone has a template and practices use of every day:
| emotions, status, hierarchy, urgency, etc
|
| Have you ever worked in sales or as a manager?
| lordnacho wrote:
| Managed teams for a long time. Not a sales guy per se,
| other than having been in a lot of sales calls.
| MattGaiser wrote:
| Looking at their schedules for the ones on my team, you
| could not break up software development like they do with
| that they do.
|
| My manager's day is filled with stuff in 15 minute to 1.5
| hour increments.
| isbvhodnvemrwvn wrote:
| And yet even with these 15 minutes you have to
| immediately mentally reconstruct the context of this
| meeting and then actively listen to what the other person
| says, figure out if they actually mean what they ask
| (quite commonly the issue is different), and then
| immediately jump into another meeting, and you can't just
| forget what happened during that 15 minutes. You have to
| carry this mental model of conversation and context
| (typically multiple ones) all the day with you. Then you
| have to actively prioritize across the various contexts
| and deliver value for all of them, while being in the
| meetings for the better part of the day.
|
| It's a different side of the same coin.
| thrower123 wrote:
| It doesn't matter that you explain that they're interrupting
| and wrecking your chain of thought; they're just going to keep
| doing it, and the train has already gone off the rails.
|
| I don't know what the solution is, aside from being blunt about
| setting expectations and fierce when those expectations are
| violated trivially. Or exiting to a remote location where one
| can do work without interruption.
| MattGaiser wrote:
| I learned to hide at a past company. I would book small
| meeting rooms for long periods and work in there. Or go work
| in the cafe. Even that is superior as while there are lots of
| small distractions, nobody specifically wants your attention.
| In the summer I would work outside under a tree.
|
| Or as I didn't want a promotion at another company, would
| come in very early and leave early.
| JoeAltmaier wrote:
| Sounds like a manager talking. The problem with programmers is,
| they haven't learn how to multitask! A few youtube videos and
| maybe a seminar and voila! They'll no longer be derailed by
| buzzword bingo and backseat driving.
|
| The act of saying "Sorry, ..." is enough to derail a deep debug
| session. Having a manager hover over your shoulder is enough.
| And if that's not believable, then clearly one of us hasn't
| been there, and has a naive view about programming.
| Toutouxc wrote:
| People are different. Back at the office my boss would be
| distracted every few minutes by someone else on the team and
| still be productive. I, on the other hand, cannot really
| concentrate if my GF is in the same room, silent, browsing
| the web on her computer.
| hinkley wrote:
| > We really need to get past this smug idea that tech work is
| uniquely difficult in a way that no one else can understand.
|
| When you think what you do is special, you will only look to
| other 'special' people for solutions to your problems. If you
| understand that many disciplines have the same problems, you
| can crib ideas from them. It's a major reason I push people to
| have extracurriculars.
|
| Most of my crisis management skills came from volunteering at
| public events for clubs. Your kitchen renovation guy could fill
| a book on how to manage customer expectations.
|
| > Instead, communicate like peers: "Sorry, I'm in the middle of
| something important. Can you come back at lunch time?" > Or:
| "Is this urgent? I can't really stop what I'm doing right now,
| but I can stop by your office around 3PM. Will that work?"
|
| You're trying to avoid dumping brain state, so the more open
| ended the question is, the more state you lose. They start
| bringing up related facts that your brain expects to hold onto
| in order to fulfill social obligations, and each fact wipes out
| more of your train of thought. Asking the person if it's urgent
| invites them to monologue. Your smarter peers will see these
| questions as equivalent, the rest of your coworkers won't.
| Don't ask them to decide. Make them decide.
|
| "Can you come back in X minutes/at time Y?" is short. Invites
| little commentary. If the answer is, "No you're late for a
| customer meeting" or "The building is on fire can't you hear
| the alarm?" then you were going to be interrupted anyway. We
| don't want to debate the relative importance of these two
| tasks. If we do then the interrupter wins, whether they deserve
| to or not.
| tharkun__ wrote:
| Absolutely true, nothing unique about programming there. In
| fact, a game I like to play with people to show how bad context
| switching is, is the letters, numbers, roman numerals game.
|
| Make two tables of 10 rows and 3 columns on a piece of paper.
| Column one is letters. Column 2 is roman numerals. Column 3 is
| numbers.
|
| Your task is simply to write down the letters from A to J,
| roman numerals from I to X and numbers from 1 to 10.
|
| You will do this twice and you will time yourself with a
| (cellphone) stopwatch. First time around in the first table you
| will fill each _row_ first. So you will write A in first row,
| first column, I into first row second column, 1 first row third
| column. B into second row first column and so forth until
| you're done.
|
| The second time around you fill out columns first. I.e. A in
| first row first column, B in second row first column, C ...
|
| It's a really nice game and you can even play it just against
| yourself or let your boss play it against himself if he wants
| you to multitask. If the other person says "well that's because
| I didn't know my roman numerals by heart any longer!" they can
| play it again. You can get better at it of course but it still
| shows the effects of context switching just from letters, to
| numerals to numbers. Can't get simpler than that!
| Dudeman112 wrote:
| >Recovering quickly from interruptions is a skill that can be
| developed and learned.
|
| Agreed. Interruptions aren't nearly as annoying when my
| immediate reply is "waaait, let me write down some stuff"
| snarf21 wrote:
| Interruptions are annoying but I think people are going a
| little overboard with this vitriol. I would wager that we are
| all just as guilty of doing the same to our team members who
| are deep in thought on something. "Did you merge that git
| branch?", "Is the staging server down for you?", "Can you take
| a look at this query and see if you notice anything?"; things
| like this are batted around between co-workers without thinking
| much about what someone else is doing. We expect co-workers to
| get back to us right away so that _WE_ are no longer blocked.
| If someone is showing offline, we 'll just ping the next person
| and so on until we get an answer. The difference is that the
| other engineers are on our team, we are in it together. The
| others aren't and they don't "deserve" to interrupt us.
|
| The other thing I don't see being discussed is that maximizing
| LoC per day may not be the thing that provides the most value
| to the company. It is tough though because those things aren't
| necessarily concrete and don't give us the same kind of
| satisfaction and feedback. We can't point to a new class or
| module or page that is now done, even if what it does isn't
| actually the result needed from the business. Sometimes the
| most important value you can provide to a business is thinking
| about what you are working on or what the newest requests from
| the business side are.
| MattGaiser wrote:
| At least on the teams I have been on, we didn't physically
| interrupt people. We sent Slack and Teams messages for all of
| that stuff about merges and staging.
| comeonseriously wrote:
| > Instead, communicate like peers
|
| I agree, however...
|
| > "Is this urgent? I can't really stop what I'm doing right
| now, but I can stop by your office around 3PM. Will that work?"
|
| I would just say:
|
| "I can't really stop what I'm doing right now, but I can stop
| by your office around 3PM."
|
| If you ask them if that will work, they'll tell you they need
| the answer immediately most of the time. People want instant
| gratification. But, by leaving it off, you have still given
| them something and you've gotten your time back.
| jbluepolarbear wrote:
| I got so tired of defending my time at a previous job that I
| just started saying "Is that what our producers needs me to
| do?" Shuts them up every time. Generally, the people that
| interrupted me were people that had no authority to ask me to
| do anything: marketers, ad agents, sales.
| pc86 wrote:
| I can't even imagine the hell of working with someone who
| responds to every request with "Is that what $THIRD_PARTY
| needs me to do?"
| jbluepolarbear wrote:
| Then you'd be the kind of person I'd say this to. I am
| very open and accommodating for individuals on my project
| that are trying to get their task done. I'll sit down and
| help, guide, whatever is needed. I won't allow a
| marketer, ad agent, or sales person to demand that I stop
| everything I'm doing and address the issue they have,
| only to tell them that it isn't going to be done this
| sprint and you'll have to talk to our producer to get
| that task.
|
| The only people that I've worked with that were
| intrusive, pushy, and demanding of engineers immediate
| time were the people that were trying to go around the
| producer because they already knew their issue was low
| priority for the team.
| MattGaiser wrote:
| That hell is seemingly the point.
| phkahler wrote:
| >> If you ask them if that will work, they'll tell you they
| need the answer immediately most of the time.
|
| The question "Will that work" is optional. You need to be
| polite when dismissing someone, but the goal here is to offer
| 2 messages "I'm busy now" and "I'll get to you as soon as
| this busyness passes" The discussion needs to end as quickly
| as possible so as to not lose your focus, but also without
| making them angry. Asking questions in that case is probably
| a bad idea.
| pc86 wrote:
| You don't have the context of the entire business, and
| sometimes they have an actual need to interrupt you, and you
| need to stop what you're doing.
|
| In my experience the vast majority of people are reasonable,
| especially in a professional environment.
| jbluepolarbear wrote:
| How about you respect my time on the job and I'll respect
| yours. A distraction cost me time needed to do my job. If
| someone doesn't respect my time, I let their managers know.
| bentcorner wrote:
| I probably interrupt myself more than anyone else.
|
| But my strategy for overcoming this with long and involved
| investigations is to write my thinking down in a stream-of-
| consciousness format.
|
| Write down all my thinking, dead ends I went down, why certain
| assumptions can or cannot be made, everything.
|
| Then if I have an interruption it's much easier picking
| everything up again, even if I have to start over from scratch
| with a new set of IDs or whatever.
|
| Think of it like frequently committing in git.
| SamBam wrote:
| > Now, tell him to add those numbers in his head. He can look at
| the screen and talk/whisper/mutter to himself, but he can't write
| anything down and he can't type anything.
|
| "Why can't I write anything down?"
|
| "Because when I'm seven to ten levels deep in a stack of issues,
| I never write anything down, I need to keep it all in my _head_.
| "
|
| "But why?"
|
| "Well... I have a whole mental model constructed. I couldn't
| possibly write it all down."
|
| "But it seriously wouldn't help you to keep _some_ notes while
| you work? And perhaps add to the skimpy comments in the codebase
| while you 're doing it?"
|
| "I seriously don't see how that would help."
|
| "You literally just said you've written down the code
| '8xZ204330Kd' and now you have no idea what it was for. Did you
| imagine you'd be guaranteed to remember it between writing it
| down and finally solving the bug? Why didn't you at least write
| some context about what that string was?"
|
| Seriously, just like most kids somewhere between the ages of four
| and ten goes from "I _know_ I will remember this! " to "I should
| write this down so I don't forget," programmers could stand to
| recognize that sometimes taking some notes can help clear their
| brain when they're too many levels deep in a stack.
| Popegaf wrote:
| Notes still require you to build context. Additionally, they
| have to be useful and up to date. I can't speak for others, but
| even with notes, it takes a while to get back into the flow.
|
| This study claims it takes >20 minutes to get back on track:
| https://www.ics.uci.edu/~gmark/chi08-mark.pdf The effects of
| notes weren't quantified, but if you have a study on that, I'd
| be happy to read it.
| sagivo wrote:
| This also applies to remote interruptions like slack and email
| messages. The difference is you can control these interactions
| better by hitting the "do not disturb" mode. Just make sure
| people understand why you're not responding right away.
| dekhn wrote:
| Hahahah. I tried this with my wife and she said I was being an
| asshole and go feed the kids.
|
| These days I have to actually look at my calendar and pay
| attention to where my family is and force myself to drop work at
| certain times. Further, I've begun not starting deep work until I
| know that I am not likely to be interrupted for hours at a time.
| I still get calls hours into that, "hey somebody else's plans
| changed at the last second, I need to drive 20 minutes to get
| somebody and then drive them home and feed them" which is
| basically gonna kill my productivity for 3X as long as it takes.
| Vaslo wrote:
| This reminds me of the scene in The Shining when Wendy disturbs
| Jack. I can't tell you how many times I've wanted to do Jack's
| reaction when someone interrupts me.
| satya71 wrote:
| I'm going to use this.
| ntrz wrote:
| The suggested `adding game' in the article seems pretty smug and
| patronizing to me.
|
| Surely explaining the situation to the `culprit' like an adult
| would do just as well without stooping to the ``I'm interrupting
| you! I'm interrupting you! See how annoying it is?'' solution. If
| someone has such little regard for you that a normal conversation
| won't work, I feel like that `demonstration' is likely to just
| garner you a reputation as an ass.
| brutal_chaos_ wrote:
| Probably in person it would be a bit different. I have a
| feeling this is a quickly whipped up example. Contrived and
| silly, sure, but the point is made.
| barry27 wrote:
| I'm bored of this whiny prima donna fallacy that interrupting a
| programmer is worse than interrupting anybody else.
| Spooky23 wrote:
| If some dev decided to teach me these lessons, I would be tempted
| to go out of my way to bug the dude as much as possible.
| nathias wrote:
| I really don't get this exaggeration about interruptions ...
| 1ris wrote:
| Me neither. I actually like to have some random human-to-human
| interaction from time to time. If I don't, I will start to feel
| lonely. Like actually sad.
| evilotto wrote:
| If you had to use a piece of software that ran lengthy operations
| and had to start over from the beginning if it was interrupted
| for any reason, would it be more effective to prevent
| interruptions as best you can and hope they never happen, or to
| fix the program so it saves its work along the way and can
| restart after an interruption? There are a lot of reason why you
| can get interrupted, not all of which are your boss stopping by
| for an update.
|
| This article is exactly why programmers are seen as whiny prima
| donnas. Too many refuse to work in a way that accommodates
| working with other people.
| mikesabbagh wrote:
| I agree with the destructiveness of meetings and interruptions.
| Many times the only productive work takes place after 5pm. I find
| creating protected time is a good solution that helps, but you
| cant have this every day when you work for an enterprise.
|
| So you just learn to work while the meetings are running.
| nkingsy wrote:
| I Don't get it.
|
| I certainly get grumpy when I get knocked out of flow state, but
| it's more about having to cut my direct feed to the universe than
| any measurable loss of productivity.
|
| Maybe I'm lucky to be able to get into flow quickly, or maybe
| people are misrepresenting the cost. Even 10 minutes of lost
| context/flow ramp seems like more than I'd estimate for the cost
| of one distraction.
| ryukafalz wrote:
| I think you're lucky to be able to get into flow that quickly.
| I certainly can't.
| igitur wrote:
| I'm a quantitative finance / actuarial programmer. I've
| flipflopped between the programming and business side a few times
| in my life. At one stage I was in the Actuarial Valuations team,
| responsible for the periodic valuation of a set of life insurance
| books. Timelines were very tight, input data was a mess, the
| products themselves were complex. This wasn't easy stuff. During
| valuation time all of us were on edge.
|
| But for some reason, being interrupted then didn't cause nearly
| as much damage to my mental house of cards as they do now, where
| my day job involves translating messy actuarial spreadsheets to
| code.
|
| I can't put my finger on it. Both tasks were complex. Maybe the
| fact that actuarial valuations (like most financial roles) are
| based on spreadsheets and you have a visual model right in front
| of you, or accessible within a few clicks. I think that relieves
| some pressure on the mental model.
|
| Programming, on the other side, even with all the IDE tools like
| a watch list and call stack, seems to require a larger mental
| stack, given the same complexity in another field.
|
| Side note: work from home has been a dream come true in terms of
| the disappeance of interruptions. But I do miss the coffee breaks
| with colleagues (or what others would call water cooler
| conversations).
| doublejay1999 wrote:
| People have jobs where they need to concentrate ? and...people
| prefer not to be interrupted when concentrating ?
|
| oh. my. god.
|
| The author looks old enough to know better than to propagate
| software development as some kind of novelty role in an
| organisation, and also old enough to know that cultivating the
| image of the tortured prima dona, who must not be disturbed while
| creating his masterwork, does a lot more harm to the profession
| than good.
|
| If you need to work without interruption, pull on your big boy
| pants, take your code and your laptop, and go work somewhere
| where there are none.
|
| If what you are working on is so intricate and volatile, get
| funding and build your own fucking lab like scientists have been
| doing for years.
|
| Otherwise, you're part of an organisation, on a salary, like
| everyone else. So play your part.
|
| Idiot.
| dang wrote:
| Could you please not post in the flamewar style to HN, cross
| into personal attack, or call names in arguments here? The site
| guidelines ask you not to do any of that. If you wouldn't mind
| reviewing https://news.ycombinator.com/newsguidelines.html and
| sticking to the rules when posting, we'd be grateful.
| doublejay1999 wrote:
| The submitted article is a flame war against non-developers
| and promotes the same attitude in the workplace. Other people
| have jobs too.
|
| It's condescends : "Your non-techie peers
| just don't get it, no matter how many times you try to make
| them understand."
|
| Demeans : "Tell him that you bet him lunch
| he can't get it done in five minutes, only getting one shot
| at getting the answer right. Maybe he'll stop laughing and
| get to work."
|
| ..and insults : "complete with ridiculous
| buzzword BS bingo and sports metaphors about "closing out the
| game in the endzone" or something. By the time the dust
| settles and you've been Six-Sigma-ed into submission by 3rd
| degree black belts",
|
| As long as HN keep accepting such submissions, I'll keep
| giving them the treatment they deserve, which I think is
| fair.
| itqwertz wrote:
| People are generally selfish and focused on their own goals.
| Everyone has their stress and tries to relieve it either by
| working machines or working people.
|
| Due to the unpredictable hours of salary positions, programmers
| should be defensive and stand up for themselves more often. Being
| walked all over is typically a sign to find a better work culture
| elsewhere.
|
| This article is a fantasy situation that would never play out in
| the real world. PMs don't have time to mess around with a stupid
| mental exercise, nor would the lesson change their reality.
|
| "Just get it done"
| 1-6 wrote:
| Actually, HN is more of a distraction to me than random people
| popping by.
| notatoad wrote:
| HN feels like a distraction, but i find that when i don't have
| some sort of distraction i'm _less_ productive. if i 'm deep
| into solving some problem i don't have any motivation to check
| HN or other time wasters.
|
| but without some way to distract myself in small increments
| when i need a break, i end up "focusing" on unimportant tasks
| that aren't material to the actual task i need to complete,
| which end up wasting more of my time than a couple minutes of
| scrolling through HN or twitter.
|
| the problem isn't the wasted time, it's the interruption _while
| you 're trying to focus_. there's nothing wrong with taking a
| break from focusing.
| paxys wrote:
| The fact that you are able to pick your own time to get
| distracted makes all the difference. I read HN when I'm blocked
| on something, waiting on a compile, on the loo, on a coffee
| break. The costs of context switching in these cases is very
| low compared to when I'm deep into debugging or writing code.
| pcbro141 wrote:
| I use SelfControl on Mac to block sites for deep work:
| https://selfcontrolapp.com
| lkbm wrote:
| I choose when to open HN. It might be more often than is ideal,
| but it's not mid-thought.
| bell-cot wrote:
| HN has a few features which might help:
|
| https://news.ycombinator.com/item?id=814695
| jaggederest wrote:
| You can use dual n-back as a systematized way to do this. Get
| them to do it for a bit uninterrupted, and then use a random beep
| generator to generate interruptions. Most people will score
| drastically lower with random interruptions.
| jrockway wrote:
| I think pg explains this better:
| http://www.paulgraham.com/makersschedule.html
|
| I think it's important to make sure you have the infrastructure
| in place to support your team's productivity. It isn't something
| that won't happen without work:
|
| 1) Have an escalation flow, and have someone dedicated to handle
| escalations. The example about the order API crashing should
| never hit anyone except the person who is on call that week, and
| that person shouldn't have any project work assigned. (They can
| be doing project work, but your planning should assume they're
| AFK the entire week. Sometimes on-call weeks are like that, and
| sometimes nothing comes up. Don't aim for the 50%-ile on that
| variance, aim for the 99.9%-ile, or your projects will be set-
| back 50% of the time instead of 0.01% of the time. And you'll
| burn out the on-call engineer.)
|
| 2) Forbid DMs. All questions should be posted to a public
| channel. (I guess people still use email, but I haven't seen it
| anywhere I've worked for several years, so it might be one of
| those things that's dead now.) Many questions that are directed
| at a specific engineer can easily be answered by the manager or
| lead who is probably on a "manager's schedule" and not a "maker's
| schedule". Forcing someone else to investigate also spreads the
| knowledge around on the team. (If there's only one person who
| knows how something works, they can't go on vacation, will get
| burned out, and quit; leaving you with 0 people that know how
| something works.)
|
| 3) Most meetings should be very targeted and be predicated on
| pre-work, and have an agenda. For example, if you're a product
| manager, you shouldn't invite 10 random engineers and say "hey
| can I have X by next Monday?" Write a PRD, solicit comments
| asynchronously, and then have a 1 hour working session to resolve
| the comments that require high-bandwidth discussion. Once the PRD
| is ready, eng leads can prioritize the feature, and assign
| resources to write a design document, and treat that as normal
| project work. Assigning people underspecified work just leads to
| disappointment on both sides -- the PM doesn't get the feature
| they want, the engineer has to delete the code they spent a month
| on. (It's also important for product to not change their mind too
| often: https://apenwarr.ca/log/20171213#slide13)
|
| 4) If you can get software to bin-pack meetings, you should.
| There are very few cases where the exact time of the meeting
| matters -- what matters is making sure that the global
| interruption cost is minimized. (This is NP-complete, but there
| are still services that will do it for you. Great is the enemy of
| good here, and "Everyone is free on 2pm Thursday" is the worst
| possible way to schedule meetings.)
|
| 5) Don't have status meetings. If you want a daily slot to
| discuss issues that come up, that's totally fine, but going
| around the room to ask what you did yesterday is a colossal waste
| of time. It's always "today I'm working on the same thing that I
| worked on yesterday", because nothing that is worth paying
| someone $200,000 a year to do is done in a day. (How do you know
| if someone is done with their high-impact project? Don't worry,
| they'll tell you.)
| clipradiowallet wrote:
| Are managers interrupting your work and making it hard to
| concentrate? Try working at home with young twin children. Great
| article though.
| werber wrote:
| To add to this, there's a lot of neurodiversity in the
| programming world. A lot of people have brilliant brains that
| just don't work well with interaction. I had a discussion with
| other people on my team recently and realized I was the only
| extroverted person on the team. I think it's also worth saying I
| personally think I'm one of the worst developers on the team but
| being able to context switch is unfairly rewarded and gives
| business people the impression I'm way more competent than I am.
| Furthermore, to me COVID was the worst thing in the world in
| terms of social isolation and a majority of my team mates loved
| it. I wish respecting communication preferences Was more
| respected. Asynchronous and non intrusive messaging seems so much
| better for the majority of my coworkers
| spideymans wrote:
| >I'm one of the worst developers on the team but being able to
| context switch is unfairly rewarded and gives business people
| the impression I'm way more competent than I am
|
| Why do you say you're being unfairly rewarded? Your
| communication skills are a genuinely useful skill to have.
| thaumasiotes wrote:
| > I had a discussion with other people on my team recently and
| realized I was the only extroverted person on the team.
|
| > I wish respecting communication preferences was more
| respected. Asynchronous and non intrusive messaging seems so
| much better for the majority of my coworkers
|
| I'm interested in this second point. You've provided an
| interpretation of what respecting your coworkers' communication
| preferences might mean.
|
| - What would it mean for them to respect your communication
| preferences?
|
| - If two people are going to communicate, and they have
| conflicting preferences, who gets accommodated?
| phaemon wrote:
| Wow maximal wines!
| harrisonjackson wrote:
| The example I like to use is sudoku. Often, after a day of
| programming, it takes me a while to "come out of it" and I
| explain that to my SO as if she'd been doing hours of sudoku and
| then had to jump into a social situation.
|
| Similarly, if you are interrupted in the middle of a "solve" it
| may be difficult to jump back in - especially if the puzzle
| hasn't been created correctly and you are trying to "debug" which
| numbers conflict. Some puzzles are harder than others. At times
| you don't have a pen and paper so you have to keep a mental model
| of the whole puzzle in your head which makes an interruption that
| much more jarring.
|
| Not a perfect analogy, but close enough to get me a 15 minute
| buffer at the end of the day and fewer knocks on the office door
| :D
| blockmeifyoucan wrote:
| This is brilliant!
| hahamrfunnyguy wrote:
| should be: Programmers, Teach Non-Geeks the True Cost of
| Interruptions (2014)
| peakaboo wrote:
| This article is why I'm not a programmer anymore. It's just
| impossible to be a programmer in the office while also trying to
| be social. I don't want to sit in an office surrounded by other
| people and get frustrated because it's not quiet or calm. I
| rather talk to people and have fun.
|
| For me, programming only works when working from home and I'm
| alone.
| ebiester wrote:
| PMs explicitly know the issue with interruptions. Most PMs I know
| work 1-2 hours either before or after business hours precisely
| because this is the only time they can get work done.
|
| Engineering Managers understand this too. And the goal is to
| minimize interruptions - and meetings are an interruption!
|
| The problem is that the time pressures on someone on a manager's
| schedule are such that they do not get the information needed to
| make the necessary decisions. As such, Managers are in a
| trilemma:
|
| * The PM makes the decision without the information necessary,
| and the team goes "why didn't you get me involved?" The PM or EM
| (Often working 50+ hours a week) then has to do rework and is not
| ready for the team. * The PM or EM interrupts someone on the
| team, reducing the team's ability to do useful work and being
| frustrated about how many meetings they have. * The PM/EM waits
| and is in a continual multitasking situation themselves, unable
| to do the creative work because they do not have the information
| necessary at the time they can do the work. (This also lends
| itself to long post-standups, and long hours for the PM.) Or, it
| turns into a "slack in a general channel and wait" situation.
| Slack is the same interruption in most organizations, even when
| not using direct mentions.
|
| I've tried to constrain the times I meet my team around other
| necessary meetings, and it throws out my day trying to
| accommodate, and even then I can't always do it.
|
| As an engineer, which do you prefer? (It's always great when the
| PM and EM are on a 7pm call because that's the only time we can
| do it, let me tell you.) Some engineers say that everything
| should be on paper from the PM, but that does not account for the
| extra time that it takes to put documentation together that may
| be based on faulty assumptions.
|
| It's a fundamentally hard problem. Let's not treat it as trivial
| to solve.
| charles_f wrote:
| Related to this, I love this comic, because it so much exactly
| what happens when you get interrupteurs
| https://pics.onsizzle.com/focus-poof-hey-do-you-have-isec-ne...
| lamontcg wrote:
| > "Any chance I can get an ETA on having that fixed?"
|
| This is the most annoying question in the world.
|
| I usually want to respond "probably sometime before the heat
| death of the Universe, but honestly that could slip".
|
| Until I write the fix I have no idea that the direction I'm
| taking will actually work. Very often I discover some $SADNESS
| while trying to actually do the fix. Some test may blow up in
| some way I never expected (often on some platform that I'm not
| actively testing until I run it through CI because I don't have
| an AIX virt on my laptop). That could derail me for a week or
| two.
|
| Then there's CI itself which breaks quite often due to how
| complicated it needs to be (we have to support AIX builds and
| things like that). I can't give you an estimate on that because I
| don't know how that is going to fail or how long it'll take to
| fix it, but if I tell you we can fix it next week that's exactly
| the time CI gets broken in some way that'll take 2 weeks (often
| for a different team that I don't have any control over) to sort
| out all the mess.
|
| The realistic estimate is often closer to 4 weeks for something
| that might seem like it'll only take a few days at the start. And
| it doesn't matter how vitally important it is to some customer.
| I'll try to get it out in a few days / next week, but it might
| slip for a month due to the unknown-unknowns and breakage outside
| of my direct control.
| titzer wrote:
| > This is the most annoying question in the world.
|
| But this is _exactly_ the information that _other_ people need
| to plan around to get on with their own work. You need to see
| things from their perspective. The inner workings of your
| processes and the long-winded explanation, from their side, is
| "the most annoying" response in the world.
|
| It's a simple question. The ETA is the only information that is
| actionable for them. If the answer is "anywhere from a couple
| days to a month", then flat out _say that_. If you think that
| sounds wishy-washy and absurd and that it must then require a
| long-winded explanation to soften, chances are that it _does
| sound absurd_ and the long-winded explanation will not soften
| it, but instead the person may start to think that you are
| unorganized and clueless. They might start to cringe at the
| thought of their next interaction with you. Just give them a
| straight answer.
|
| FWIW, I don't know anything about your system, but it sounds
| like you need to invest in making triage in your system more
| efficient.
| kokey wrote:
| I've been tempted to hack together a web based game. It will be
| some simple puzzles requiring working memory, like that addition
| of numbers example. It could even be word problems with multiple
| choice answers, but the questions has to be relatively wordy with
| several data points to consider. Periodically it will get
| interrupted, by several things, but mainly a face with a speech
| bubble, asking various questions like "are you busy?", "can I ask
| you a question?", "how much longer do you think you will take to
| complete this?". This will completely take over the screen and
| you won't see your last question. You can select some answers
| (yes, no, 5 minutes, etc.) and some answers will lead to more
| questions especially if you give wrong answers. Also questions
| that you need to visualise to come up with an answer, like
| comparison of sizes or distances of things you don't often
| compare (bus vs yacht) After each interruption you will return to
| your puzzle game. The first interruption will only kick in after
| a while so you get used to how easy it is without interruptions,
| but then they'll start to kick in frequently but also randomly so
| you have some breaks sometime but never know for how long.
| teddyh wrote:
| Whenever this comes up, I usually link to this:
|
| _Don 't Wake Up the Programmer!_
|
| https://alexthunder.livejournal.com/309815.html
| [deleted]
| Wistar wrote:
| At Microsoft, it was easy to see which teams were in crunch mode:
| the closed doors had "email only" signs on them.
| monkey_monkey wrote:
| This is my favorite cartoon about the cost of interrupting
| developers.
|
| https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...
___________________________________________________________________
(page generated 2021-07-09 23:01 UTC)