[HN Gopher] Why interruptions are frustrating to developers
___________________________________________________________________
Why interruptions are frustrating to developers
Author : vitabenes
Score : 102 points
Date : 2021-05-28 13:59 UTC (9 hours ago)
(HTM) web link (tellspin.app)
(TXT) w3m dump (tellspin.app)
| BurningFrog wrote:
| My contrarian view on this:
|
| 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.
| mrfredward wrote:
| 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.
| commandlinefan wrote:
| > 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.
| BurningFrog wrote:
| I have programmed professionally since 1984. Never had to
| predict by the hour, but occasionally by day/week.
|
| 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.
| oauea wrote:
| Cool, how do you get there? And you realize some work is simply
| non-trivial?
| deepsun wrote:
| Sometimes you cannot write an easy code -- e.g. low-level
| heavily optimized code.
| theknocker wrote:
| >I have never solved a difficult problem on my own
| adkadskhj wrote:
| > 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?
| hashkb wrote:
| 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.
| jk20 wrote:
| Why do you assume that developers cannot collaborate?
| adkadskhj wrote:
| 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?
| BurningFrog wrote:
| My experience is that two heads are far superior to one
| for solving coding problems!
| Mike86534 wrote:
| 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.
| hashkb wrote:
| 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.
| username90 wrote:
| 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.
| dent9876543 wrote:
| Yep. Couldn't agree more.
|
| 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.
| hashkb wrote:
| 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.
| commandlinefan wrote:
| > weekly 30 minute standing meeting.
|
| 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.
| hashkb wrote:
| Sorry you had five bad bosses. I'm talking about standing
| strategy meetings, not stand-ups.
| dahfizz wrote:
| 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.
| OnlyOneCannolo wrote:
| 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.
| whiddershins wrote:
| I hear you but I almost feel like culturally people have an
| inkling that writers and musicians need flow state.
|
| 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.
| hinkley wrote:
| 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!"
| deepsun wrote:
| Many other professions react strongly to interruptions. E.g.
| from what I know: writers and mathematicians react even
| strongly.
| [deleted]
| pc86 wrote:
| 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.
| sirsinsalot wrote:
| They also arent creating output that has to be
| simultaneously harmonic with other peoples work in an often
| quickly changing landscape.
| hinkley wrote:
| You can interpret Hemingway's writing process such that he
| really could tell you what he did yesterday and what he's
| going to do today.
|
| Not that I'm particularly fond of this current incantation
| of Agile.
| Bancakes wrote:
| It's not pretentious. If programming were algorithmic, AI would
| be doing it.
| 100011_100001 wrote:
| 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.
| cnra wrote:
| Most good programmers need isolation and are not "whining".
|
| 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 ...
| mjburgess wrote:
| 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.
| cnra wrote:
| Ridiculous that this thoughtful post is down-voted.
| slingnow wrote:
| 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.
| mjburgess wrote:
| 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.
|
| Jupyter notebooks are, here, a notable exception.
| amozoss wrote:
| Author here: Thanks.
|
| 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.
| ethbr0 wrote:
| 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.
| mjburgess wrote:
| 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.
| ethbr0 wrote:
| It's a memoisation [0] problem: how completely does a
| professional store effort-expensive, intermediate
| results?
|
| 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
| mjburgess wrote:
| Consider:
| https://www.youtube.com/watch?v=HKt19-GsA1I#t=1m30s
|
| From c. 1m30s to 5m30s
| whatshisface wrote:
| 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.
| foxyv wrote:
| Don't forget to send him messages on Slack, marked as
| important, talking about stuff like Yoga exercises and the
| importance of taking breaks.
| mgkimsal wrote:
| 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.
| whatshisface wrote:
| 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.
| amozoss wrote:
| 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 ;)).
|
| Edit: fix a typo
| [deleted]
| Mike86534 wrote:
| > 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.
| kolbe wrote:
| 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.
| amelius wrote:
| 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.
| aequitas wrote:
| 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.
| Fordec wrote:
| 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.
| amelius wrote:
| These people need to learn that there is a time and place
| for everything.
| screye wrote:
| > 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.
| fouric wrote:
| 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".
| karmakaze wrote:
| 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.
| atum47 wrote:
| focus tower? what happened to train of thought?
| skadamat wrote:
| I'm surprised Cal Newport's recent book, A World Without Email
| wasn't mentioned!
|
| 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!)
| jedimastert wrote:
| 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.
| G4BB3R wrote:
| Once in a cowork space we had the golden rule to never call
| someone that is on headphone, unless it is urgent. I miss that.
| sumtechguy wrote:
| 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.
| tengbretson wrote:
| Interruptions are so frustrating to developers in particular
| because their skills are in sufficiently high demand that they
| can behave like immature divas.
| commandlinefan wrote:
| > 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?
| jk20 wrote:
| You sound like a scrum master.
| [deleted]
| [deleted]
| commandlinefan wrote:
| 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.
| [deleted]
| akomtu wrote:
| 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.
| [deleted]
| andi999 wrote:
| It depends, doesnt it. Two billable hours might be considered
| better than one billable hour.
| amozoss wrote:
| 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.
| [deleted]
| 908B64B197 wrote:
| > 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).
| Arainach wrote:
| 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.
| mjburgess wrote:
| 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.
|
| I have no idea what this community is.
| slingnow wrote:
| It's a community of people with thoughts that sometimes
| differ from yours. It doesn't seem that confusing.
| mjburgess wrote:
| 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.
| slingnow wrote:
| 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.
| beckingz wrote:
| Is this in reference to your comments the other day about
| Chess AI not actually "playing" chess?
| loopz wrote:
| 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.
| mjburgess wrote:
| 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.
| loopz wrote:
| Of course you'll feel good about venting your
| frustrations. But everyone around you will feel bad.
| mjburgess wrote:
| 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.
| loopz wrote:
| 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.
|
| _How_ others hear you, matters.
| mjburgess wrote:
| 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.
| NikolaeVarius wrote:
| Its because you assume programmers are special in some way.
| hackinthebochs wrote:
| 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.
| layer8 wrote:
| 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.
| dkdbejwi383 wrote:
| 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.
| sombremesa wrote:
| 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.
| commandlinefan wrote:
| > my job is actually to attend meetings.
|
| 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.
| sombremesa wrote:
| 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.
| ipaddr wrote:
| Have you ever tried just not showing up.
|
| 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?
| gregmac wrote:
| 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.
| pc86 wrote:
| > _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.
| sombremesa wrote:
| 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.
| jrockway wrote:
| 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.
| vagrantJin wrote:
| Please do. Sounds really interesting.
| seoaeu wrote:
| 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.
| sombremesa wrote:
| By definition? Surely finding time in your month for a
| 3-day conference is a lot easier than finding time for
| thirty one hour conferences?
| a1369209993 wrote:
| 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.
| sombremesa wrote:
| This is predicated on the idea that meetings are
| immutable once created, which is part of my original
| complaint.
|
| Edit: I see what you're saying, that makes perfect sense.
| a1369209993 wrote:
| I was only supporting the:
|
| > 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".
| jedimastert wrote:
| > 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
| sombremesa wrote:
| 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].
|
| [0] https://neilonsoftware.com/2020/09/08/non-technical-
| developm...
| zo1 wrote:
| 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.
| atatatat wrote:
| Anything over 100 seems to get tough.
|
| Federate your business today.
| lanstin wrote:
| And design the software to enable uncoordinated effort to
| make progress. It isn't trivial to do this, and does take
| some ability to think deeply, but it isn't rocket
| science. The speed of software development is
| proportional to how little I have to think about. If i
| care about fifty files to add one feature, then the
| productivity plummets. It I can just edit file small
| sensible file, and release it pretty quickly, then I can
| go so fast. And software development speed pays compound
| interest (tech debt eats interest compoundedly?)
| karaterobot wrote:
| 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.
|
| Not saying it's a good thing!
| ipaddr wrote:
| 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.
| tharkun__ wrote:
| Story points to the rescue.
|
| 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.
| thrower123 wrote:
| 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.
| mkl95 wrote:
| 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.
| thomastjeffery wrote:
| 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.
| screye wrote:
| > because they have less available working memory
|
| 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. :\
| dan_quixote wrote:
| > 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.
| euroderf wrote:
| 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
| ?
| gioele wrote:
| In far fewer words:
| https://heeris.id.au/trinkets/ProgrammerInterrupted.png
| lou1306 wrote:
| There is a very similar one wandering around the internet,
| e.g., here:
| https://twitter.com/boagworld/status/971328648048447490?s=20
| gdsdfe wrote:
| lool I got pissed just imagining this happening
| amozoss wrote:
| Love it! I was really tempted to include this in my article,
| but it didn't quite fit since it's so tall :)
| SkyPuncher wrote:
| 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.
| kolbe wrote:
| 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.
| amozoss wrote:
| 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.
| euroderf wrote:
| 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.
| kolbe wrote:
| Pen and paper for me! One big flaw is I occasionally can't
| read my own handwriting.
| hinkley wrote:
| 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.
| NovemberWhiskey wrote:
| 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.
| kolbe wrote:
| 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.
| tapan_jk wrote:
| > 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.
| twodave wrote:
| 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.
| lliamander wrote:
| I disagree.
|
| > 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.
| twodave wrote:
| 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.
| tharkun__ wrote:
| Play this game against yourself:
|
| https://www.bp-3.com/blog/a-fun-context-switching-game
| G4BB3R wrote:
| I agree with you, but that doesn't apply when someone
| interrupts in the middle of a thought.
| amozoss wrote:
| 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.
| twodave wrote:
| 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.
| acbabis wrote:
| > 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 have too, but sometimes I have to read other people's code,
| and I don't have any control over how difficult that is.
| twodave wrote:
| 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.
| sackerhews wrote:
| I'm interested in your point number 2. Do you have any links
| that back it up?
| hinkley wrote:
| 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.
| lanstin wrote:
| 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.
| hinkley wrote:
| > I've also learned to write code in a way that reduces
| cognitive load so that interruptions aren't so disruptive to my
| productivity.
|
| 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.
| BurningFrog wrote:
| 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.
| twodave wrote:
| 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).
| fouric wrote:
| 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.
| lanstin wrote:
| 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.
| amozoss wrote:
| 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)
|
| hence why I catered 2 of the 4 tips to myself.
| commandlinefan wrote:
| 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.
| amozoss wrote:
| 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.
| MarkLowenstein wrote:
| I liked your suggested mitigations. Well-designed to
| accommodate human motivation, and simple enough to be
| practical.
| bryanrasmussen wrote:
| 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!
| postalrat wrote:
| 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.
| warvariuc wrote:
| 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.
| loopz wrote:
| What did the developer do to avoid being interrupted, ie. why is
| it necessary for others to disturb said developer?
| amozoss wrote:
| Author here: Glad you asked
|
| 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
| TacticalCoder wrote:
| 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.
___________________________________________________________________
(page generated 2021-05-28 23:02 UTC)