[HN Gopher] Fragmented thinking is a bigger threat to flow state...
___________________________________________________________________
Fragmented thinking is a bigger threat to flow state than
interruptions
Author : nickwritesit
Score : 212 points
Date : 2024-04-25 10:33 UTC (3 days ago)
(HTM) web link (blog.stackblitz.com)
(TXT) w3m dump (blog.stackblitz.com)
| Kinrany wrote:
| "Boring tasks shatter flow state even in the absence of external
| distractions"?
| layer8 wrote:
| They give few examples unfortunately, but the "writing a commit
| message" is one.
| elevaet wrote:
| Writing a commit message doesn't seem like a good example
| because it's usually a moment where you _can_ pause the flow
| state because you 've just completed the thing that needed
| flow
|
| They're more like the period at the end of a sentence, so
| that you can flow into the next one.
| leetrout wrote:
| I have found it to be a sign of inexperience when devs
| protest "good" (whatever that means to you) commit
| messages.
|
| They seem to have never worked with legacy code that has a
| good commit history you can rely on.
|
| Arguing commits break flow would likely come from the same
| mouth that comments are useless and the code is self
| documenting. The "doesn't write code thinking of others"
| type.
| em-bee wrote:
| when i am writing commit messages i am actually very
| focused. i study the changes and try to condense them
| into a helpful description. incidently i am working with
| legacy code now which has me studying the commit history
| forwards and backwards, and good commit messages that
| allow me to discover changes that i am interested in are
| really making a difference.
| tengbretson wrote:
| I've actually found the opposite to be true. That usually
| the people harping for rich commit messages are the ones
| not thinking of others. That they are trying to get their
| coworkers to bend or produce extra work just to make
| their personal workflow more ergonomic. The information
| they seek is already redundantly documented, often 3
| times over in the form of PR messages, jira tickets,
| requirements documents, slack history, etc.
| wnoise wrote:
| But are they at all discoverable from the code base?
| Those PR messages, jira tickets, and slack history ought
| to be linked to in the commit message, and that
| requirements document checked in.
|
| (None of those links help when you switch to different
| providers; but that might not be too bad, depending on
| timescales of those changes)
| hedora wrote:
| Most teams I've been on just link to the PR from Jira and
| Slack. The PR links to the commit message, and the commit
| message explains the change.
|
| Other stuff like "this is ready, can you review it?", or
| "we can ship feature X now" lives in the other tools.
|
| Note that (in the rare case where you want to), you can
| then search for links to old PRs in the other tools.
| Also, putting the jira ticket number in the commit
| message usually makes sense.
| em-bee wrote:
| anything that is not in the commit message or in the
| commit itself is practically useless. documentation
| covers how to use a thing. it usually doesn't cover why a
| change was made. that why also normally does not end up
| in code comments, and even less so would be aparent from
| the change it self. the commit message remains the only
| place where the why can be documented meaningfully and
| along with the change where it is needed.
|
| at least in my current project working with legacy code
| that i am not familiar with, the why is the most
| important detail about a commit.
| adamors wrote:
| In a perfect world yes that is true, but I've worked at
| multiple places where Jira got reshuffled by someone and
| either entire projects got deleted or ticket ids were
| reset.
|
| Slack history and requirement documents are rarely linked
| in commit messages and looking through thousands of
| documents and channels to search the context of a commit
| is nauseating.
|
| There's never a need to write an essay in a commit
| message, but 2-3 paragraphs won't kill anybody either.
| tengbretson wrote:
| There are better uses of resources than to amortize the
| cost of a jira migration that may never even happen
| across all devs in perpetuity.
| throwuxiytayq wrote:
| Jira always gets shut down before the repo. Often _years_
| before. For a thousand reasons. Take these two, for
| example: git is free, and jira is shit.
| hedora wrote:
| I find writing commit messages helps my development flow:
|
| Why did I spend an hour refactoring 1000 lines of rust
| code again?
|
| It worked the first time I got it to compile again, so
| it's probably fine, but it was a subtle non-functional
| change. I'd better commit + write a good message so:
|
| - I don't forget why I just did that
|
| - In case I need to back out the next step
|
| - So that my coworkers know what I'm up to, and don't ask
| me on slack.
| andoando wrote:
| PRs are merged squash everywhere I worked, so whats the
| point? Commit messages are hardly ever useful for me
| working on a task for a few days or even weeks.
| leetrout wrote:
| Git keeps the commit messages when using `git merge
| --squash`.
|
| By default it will produce a commit message starting with
| `Squashed commit of the following:`
|
| The contents of this message are staged in
| `.git/SQUASH_MSG`.
|
| When using GitHub the squash merge commit behavior is
| configurable and the teams I've been on have kept it
| configured to keep the commit messages of the commits
| being squashed. I assume GitLab has similar
| functionality.
| layer8 wrote:
| Yes, I didn't find it entirely convincing either, other
| than if you struggle with the right wording for the commit
| message, then it indeed can have the effect of being more
| of a disrupting break than if you were seamlessly
| proceeding with the next connected coding step that your
| mind was already occupied with.
| sanderjd wrote:
| I think a better example that might be more broadly relatable
| would be "a lot of latency between writing something and
| seeing if it works", ie. long compile times, slow tests, long
| startup time for an executable, needing to restart a server,
| etc.
|
| There is no "turn off slack notifications" solutions to this
| kind of thing, and it's a big persistent flow-shattering time
| sink for me.
| hodgesrm wrote:
| One of the truly great programmers I met at VMware was almost
| obsessive in the way that he thought about not just commit
| messages but the entire structure of the commit log. The goal
| was to make changes appear as a flow of understandable
| commits that build to some greater goal.
| hodgesrm wrote:
| I would add that's in some sense "externalizing" an ideal
| flow state in the sense of the article. Real flows are
| hesitating and often emerge incoherently. So you end up
| reworking the commits to represent the path you would have
| followed had you understood things fully at the start.
| layer8 wrote:
| I'm hereby coining the term "literate committing" for that.
| :)
| bluerooibos wrote:
| What a horrific article. At least define fragmented thinking for
| us and provide some sort of conclusion/TLDR for this waffle.
| causal wrote:
| This felt like someone trying to fill out a word count
| ranprieur wrote:
| Yes, it repeats itself so much I kept thinking I had
| accidentally scrolled up.
| JonChesterfield wrote:
| Thinking incoherently can definitely cause more problems than
| being repeatedly interrupted.
|
| Concluding that the interruptions aren't so bad is consistent
| with this observation.
|
| It does not generalise to all developers.
| sanderjd wrote:
| I think the primary point here is that interruptions don't only
| happen _externally_ , but also _internally_. I think this point
| is a bit obscured by the article 's use of this "fragmented
| thinking" terminology, which it does not do a good job of
| defining before building an argument on top of it. (I found
| myself searching for those words to see if I had missed the
| definition.)
|
| However, I do think this is an insightful point! I think these
| "internal interruptions" are indeed a big problem for me, and one
| I don't think about nearly as much, but will try to more now that
| I've read this article.
|
| The frustrating thing about external interruptions is the
| inability to control them. Things like turning off notifications
| and putting on headphones are mechanisms to reduce that
| frustration by imposing control over those interruptions.
|
| The good news for these _internal_ interruptions is that it
| should be much easier to control them. But it requires being
| aware of the problem! So I 'm thankful to this article for making
| this more top of mind for me.
| Swizec wrote:
| > The good news for these internal interruptions is that it
| should be much easier to control them
|
| Just get good sleep, great nutrition, enough exercise, and
| remove all stressors from your life. How hard can it be!?
|
| Yes really that's the source/cause of most internal
| distractions.
| sanderjd wrote:
| I think this is true, but I was also thinking about more
| specific things. Like identifying, "ok, what do I commonly do
| in my own workflow that interrupts me from what I'm working
| on". In another comment I used the example of wanting to see
| the results of something I just did, but having to wait for
| something that executes slowly. Another example of something
| I'm guilty of is going down premature refactoring rabbit
| holes.
|
| But all of the general good mental health stuff you mentioned
| helps maintain the right focused mental state to introspect
| about where you're getting interrupted, figuring out how to
| avoid those things, and then actually avoiding them.
| manicdee wrote:
| Ha ha yeah. Let me just remove all that childhood trauma and
| PTSD, then we'll get this train of thought right back on
| track. Why didn't I think of that sooner?
| erikerikson wrote:
| Yes, the headline term was never truly defined for use. Past
| the headline it didn't get used until almost half way through
| and then assumed you knew what was meant by it. Only near the
| end were there hints as to what the writer was referencing.
|
| Good job pulling out a very plausible interpretation though. We
| talk about this in our dev meetings and attempt to proactively
| identify and resolve sources. Having well defined and coherent
| contexts improved our work and the emotional experiences of
| doing it. This has been helping me recapture the joy of coding.
|
| Shouldn't have taken starting a company fellow business
| leaders.
| Tainnor wrote:
| > The frustrating thing about external interruptions is the
| inability to control them. [...] The good news for these
| internal interruptions is that it should be much easier to
| control them.
|
| Interestingly, I feel the exact opposite. I'm aware that it's
| not always possible or socially acceptable to do so, but at
| least in theory you can always make a choice to ignore or tune
| out other people. Ignoring the stuff that is going on in your
| own head is IMHO much harder.
| sanderjd wrote:
| Yeah I clearly worded this poorly. What I meant to say is
| that it should be much easier to control _only_ the internal
| interruptions, compared to the necessity to control both the
| external ones _and_ the internal ones. That is, the existence
| of external interruptions doesn 't make the internal ones go
| away, they're just additive on top, which can only make
| things more difficult.
| justinpombrio wrote:
| > The good news for these internal interruptions is that it
| should be much easier to control them.
|
| For a long-time meditator, this is comedic gold. Just control
| your internal interruptions, stay focused. That's all, eh?
| Hehehehehe
| Terr_ wrote:
| "My boss is always interrupting me with questions, and the
| office is very noisy. There's no easy fix for either of those
| external things, so you're lucky that all you have to deal
| with is internal ADHD and tinnitus!" /s
| sanderjd wrote:
| But you still have to deal with those internal issues in a
| noisy distracting office! Being interrupted more by other
| people doesn't make it easier to manage internal struggles,
| it is a strictly additive difficulty.
| sanderjd wrote:
| Not _easy_ , eas _ier_! For "external interruptions", you
| have to do both things, keep people from bugging you _and_
| control your own mind. I think it 's definitely easier to
| only do one of the two, despite still being really hard.
| saulpw wrote:
| It's actually easier to control your external environment
| than your internal environment. If interruptions or
| distractions are like a monkey hopping around, then at
| least with an external monkey you can put it outside and
| lock the door. With an internal monkey you're stuck with
| it. Drugs help but come with side effects; meditation helps
| but takes concerted long-term effort separate from work.
| (And it's hard to motivate yourself in addition to your
| already long workday to improve your performance during
| said workday.)
| zmgsabst wrote:
| As a long time meditator, I'm not sure what you find amusing.
|
| Are you saying you have more control of what other people do
| than your own mind? If not, what are you objecting to in
| saying that it's _easier_ to control yourself than others?
|
| I'm really struggling not to see your comment as living down
| to stereotypes: vapidly smug.
| avtar wrote:
| After enough hours of meditation practice it becomes quite
| clear that one's mind is ungovernable at best. We can just
| hope to hold a clear intention (meditation practice in a
| nutshell) and return to the task whenever internal or
| external interruptions arise. Perhaps more and more parts
| of the mind will align with the intention. Hopefully the
| mind gets unified over time and as a result flow states can
| be experienced.
|
| The person whose comment you're replying to was probably
| highlighting the fact that this process is not as
| predictable as the parent comment alluded to.
| justinpombrio wrote:
| Oh that's not what I'm saying at all.
|
| I was recently at a meditation retreat, and a group of
| meditators much more advanced than me universally agreed
| that an apt description of their minds was "like a box of
| ferrets".
|
| The illusion that you _control_ your chain of thought
| vanishes pretty quickly with meditation. The reality is
| that your attention shifts rapidly (especially between
| different senses) and that most of those shifts aren 't
| under direct conscious control.
| makmanalp wrote:
| Agreed fully.
|
| I'll admit I also had a chuckle at the expense of the parent
| post here (I'm sorry - the rest of this post isn't meant to
| pick on you or describe you specifically). I think this there
| is a lesson in here somewhere on the intellectual confidence
| that comes with being good at one thing, and the silliness
| that can ensue when it might not translate elsewhere. Not in
| even necessarily in a malicious or foolish way, but in a "it
| can catch you even when you think you're accounting for it"
| kind of way.
|
| If not empathy for the sake of moral reasons or even good
| vibes, I wish that we could at least convince the "I read the
| abstract of 3 papers / I read a gwern post about this / I
| accomplished something hard in my life so I know everything"
| crowd of the utility of empathy as a tool for exploring your
| "unknown unknowns". You'd think that more people would be
| interested in a dialectic (in the classical philosophy sense)
| discussion as a cooperative if conflicting search for truth.
| This is harder to do if you systematically overestimate
| yourself and underestimate others. Of course as I write this
| I'm thinking of all the times I didn't practice what I'm
| preaching now.
| zmgsabst wrote:
| > "I accomplished something hard in my life so I know
| everything" crowd of the utility of empathy as a tool for
| exploring your "unknown unknowns".
|
| Do you believe you've demonstrated "the utility of empathy"
| in your post? -- or even your interpretation of what was
| said?
|
| - - -
|
| > Of course as I write this I'm thinking of all the times I
| didn't practice what I'm preaching now.
|
| > Not in even necessarily in a malicious or foolish way,
| but in a "it can catch you even when you think you're
| accounting for it" kind of way.
|
| > This is harder to do if you systematically overestimate
| yourself and underestimate others.
|
| Mm.
| kbenson wrote:
| I'm not sure if you're expressing what you think you are.
| They outlined a group by nature of the problem (so the
| people in question have something to improve,
| tautalogically), so it's not like they are painting with
| an overly broad brush, unless you think people that
| accomplished something hard and then automatically assume
| they have faculty in all topics is not a group in need of
| examining their assumptions more closely?
| jstanley wrote:
| The post is pretty close to being guilty of the very
| problem it is pointing out.
| kbenson wrote:
| I don't think it is, which is my point. It's essentially
| saying "I wish people with BEHAVIOR PROBLEM would do
| THING THAT MAY HELP MITIGATE PROBLEM." There is no
| statement of the size of that group, or how many people
| exhibit that problem. Unless you don't think the behavior
| being talked about is a problem (which is different than
| thinking not many people have this problem), then I'm not
| sure how having empathy towards them factors in. Is
| wishing they had more perspective and could avoid a
| cognitive pitfall not empathy?
| JohnMakin wrote:
| struck a little too close to home, eh?
| makmanalp wrote:
| My contention is that I make a good faith effort to be
| open to the idea that others know or have experienced
| things or might have some thoughts that I haven't
| considered adequately. And that I think this concept
| would be helpful to others here. That's all, no more, no
| less.
|
| It isn't that I'm perfect, or infallible, or even immune
| to frustration and the occasional bout of snark. It
| doesn't mean that I'm a "better" person. It also doesn't
| mean that I have to accept every viewpoint as true or
| equally likely. Nor does it mean that I can't criticize.
| Nor that I can't take a side on a considered opinion. It
| doesn't mean that this always leads to perfect results or
| that I'm always successful. It doesn't mean that it's a
| perfect heuristic. It's only one more tool in a toolbox.
|
| I think it is undervalued - and sometimes angrily pushed
| back against - in this community, maybe because it gets
| dismissed as "feelings" (and not "reason"). The reason I
| think this is that I've encountered here the "experienced
| expert with healthy self doubt versus passionate amateur
| with little self awareness" dynamic in action over and
| over again.
|
| There's an ongoing, half century current in the field
| trying to examine whether reasoning may often involve a
| heuristic-based, adaptive process based on incomplete and
| imperfect information, and less so something resembling a
| pure application of formal logic.
|
| In this universe, cognitive biases extend more clearly to
| things like which facts you consider as possible at all
| in the first place and by which methods you weight them
| as more or less likely or influential, as opposed to
| merely fallacies of formal logic that we're most often
| exposed to. So, the thinking goes, it can help to try to
| fill some gaps in this area by trying to increase the
| breadth of what you're exposing yourself to and allowing
| yourself to take into account.
|
| In my experience this can be a frustrating and exhausting
| concept to contend with as a person. You certainly can tu
| quoque yourself - or me, like you and others in this
| thread have - into oblivion. After all, what business do
| I have talking about cognitive biases if I've been shown
| to be subject the very same, and am not an expert in it?
| I don't know where the line is but I'm not certain it
| makes the concept less helpful outright. At the very
| least I don't think I'm claiming something that'd be
| considered very controversial as far as I'm aware.
| jajko wrote:
| Just stop being sad. Just focus. Just be a good balanced
| human being.
|
| When I was a child, world and humans in it were so simple.
| Good old times, at least relatively speaking.
| hgomersall wrote:
| From the article, a fair few internal interruptions are
| procedural, things like writing a commit message. I took a
| big point as being that you should design your work processes
| to help maintain flow.
| VS1999 wrote:
| Obviously it's easier than dealing with external
| interruptions. I don't suppose you do your hippie calming
| exercises while bob from accounting tries to get information
| from you for the 5th time this hour.
| hinkley wrote:
| I spent a long time thinking about why I always end up being
| the guy that people feel comfortable interrupting. I'm never
| the nicest guy in the office, I'm not always the cleverest,
| especially when I'm trying to do something else. But I do seem
| to recover better from external distractions than most people.
|
| Mostly because my life is a constant struggle against internal
| distractions, so my coping mechanisms are more evolved.
| tonyarkles wrote:
| > I think this point is a bit obscured by the article's use of
| this "fragmented thinking" terminology, which does not do a
| good job of defining before building an argument on top of it.
|
| I totally agree with you that the article didn't explicitly
| define it, but I had the opposite experience reading it. For
| me, sans definition, could very quickly imagine what they were
| talking about because it started resonating for me almost
| immediately.
|
| > The frustrating thing about external interruptions is the
| inability to control them. Things like turning off
| notifications and putting on headphones are mechanisms to
| reduce that frustration by imposing control over those
| interruptions.
|
| This is partly _why_ it started resonating for me right away. I
| currently share a semi-private office with another senior
| engineer. Lately he 's been spending a good chunk of his time
| working on higher-level systems planning work and I've been
| spending most of my time working on very specific complex low-
| level work. The questions are sometimes frustrating because
| they'll interrupt my flow state, but... only sometimes. I've
| been chewing on that for a couple of weeks now, actually,
| because I hadn't yet figured out _why_ he could sometimes ask
| me questions and it would have almost zero effect on me while
| other times it would have a massive negative effect.
|
| The article nailed it, on reflection: the effect size of being
| interrupted with a question, for me, is proportional to how far
| away from the problem I'm working on is. If I'm digging into
| some of the autopilot code and get asked a question about GPS
| or IMUs, it is absolutely no problem to think about the
| question and answer it. If, though, it's a question about, say,
| a battery or the charging system, I'll get the "black cloud
| evaporating" phenomenon from the comic in the article. And it
| happens so quickly that by time I can even just answer "sorry,
| I don't have brain capacity to think about that right now" it's
| too late.
| aantix wrote:
| I use Cold Turkey to block my habbit of scrolling time-wasting
| sites when I should be reflecting harder on what it is needed
| to solve the issue at hand.
|
| https://getcoldturkey.com/
|
| It's almost like I need some mental space, to meditate on the
| solution, but that feels exhausting, so I choose sometimes to
| mindlessly scroll.
|
| Any other tools that I may be missing?
| hackerlight wrote:
| An alternative is to add URLs to /etc/hosts like this to
| block them:
|
| 127.0.0.1 tiktok.com
|
| 127.0.0.1 www.tiktok.com
|
| Then use ublock origin extension to pare down features on
| sites you still visit, and an RSS reader app to slow down
| media consumption.
| heisenbit wrote:
| Let's face it: Interruptions happen and what is worse I'm not
| immune interrupting others. While we can and should strive to
| influence the environment to provide and protect flow state we
| also need imho. care about something else: Recovering flow state.
| Having notes laying out key milestones beforehand and capturing
| intermediate results at least for me make a big difference.
| parpfish wrote:
| it's unfortunate that the times when you _need_ the flow state
| to focus on an urgent problem are also the times when you'll
| get hit with a deluge of distractions (from automated
| notifications and panicking managers that don't know what to do
| other than asking "is this fixed yet?")
| RealityVoid wrote:
| Nah, it's simpler for me when I have an _urgent_ problem. I
| then _know_ what I focus on and prioritize to fix that
| problem. I basically... rudely ignore anything and anyone
| else. When the priorities are not as clear is when I feel
| like wading through mud.
| samatman wrote:
| The example of writing a commit message breaking flow state is an
| interesting one, which ties flow to a related word: fluency.
|
| For the first year or two of using git, I treated it as an undo
| buffer, with a nice bonus that I could try things out on distinct
| branches. Commit messages were frequently pro forma, because I
| wasn't thinking in terms of units of change.
|
| There are still projects I approach this way, "latest firmware"
| is all I really need if I'm changing things around on my keyboard
| firmware, for instance.
|
| But with a bit of mentoring several years ago, at a job with
| expectations for how git should be used, I've come to think of
| changes to a codebase in terms of a commit. I'm not just writing
| software, I'm writing a commit on a specific branch.
|
| So writing a commit message doesn't take me out of my flow,
| because it's part of it: that's what the work was flowing
| towards. I don't let git drive the work, so there are definitely
| commits of the form "add $specific-thing\nAlso (minor
| bugfix/change)", but every time I'm working on a complex project,
| it's toward a specific commit-sized goal.
|
| I'd love a revision system (probably based on pijul) which
| created a patch every time I save, which I do every minute or so.
| With a tool which removed patch lines which never show up in the
| final diff, and displayed the total change in a way which makes
| it easy to pick those unrelated changes off into their own patch,
| so I could break the commit into logical pieces. I wouldn't need
| it often, but when I'm working on something specific, and I see
| something else which is wrong, or just easy to change, it _would_
| take me out of flow to, idk, write it on a Post-it and do it
| after the commit is fixed. But commits with unrelated work in
| them create a sense of creative disorder, one which I would
| happily take a minute to resolve if the tool made it easy.
| vladxyz wrote:
| That's pretty much how I use git. My text editor auto saves, I
| work on a task, doing refactors, or throw away wishful code
| along the way. When I feel like I'm at a good point for a
| commit, I repeatedly use `git status`, `git diff`, and `git add
| -p` to split the sum of changes into a reasonable set of
| commits. A commit does not need to be all-or-nothing.
| j33zusjuice wrote:
| This nonsense of quoting the "profound thought" you're about to
| read in the next paragraph is the most annoying stylistic choice
| to emerge from the internet. I didn't finish the article because
| of its overuse.
| tome wrote:
| I saw two uses. Is that right?
|
| > Now, "flow state" has all sorts of associations ...
|
| and
|
| > Before I started writing this article ...
| marcosdumay wrote:
| It emerged from printed news. It's more than a century old.
| kstenerud wrote:
| Sorry, but this just sounds like a bunch of hogwash.
|
| Extraordinary claims call for extraordinary evidence. You see a
| lot of references to studies, but take a moment to actually
| follow the links and see what the studies say. Then come back and
| look at his many conjectures.
|
| The reason why "internal interruptions" occur is because you get
| tired and your mind wanders. That is your cue to TAKE A DAMN
| BREAK! We're not machines. Trying to optimize your "flow state"
| is a fool's errand. Just keep a healthy, distraction-free work
| environment and work with what your body allows.
|
| And it's not the scheduled interruptions such as meetings and
| such that destroy flow; it's the unscheduled interruptions. So if
| you don't want to be prematurely pulled out of your flow, make
| sure you keep your schedule in your mind, and do whatever you can
| to ensure that nobody interrupts you on a whim.
|
| And if someone does, it's not the end of the world. Rebuilding
| the state in your mind is a LOT easier the second time than the
| first! If it happens too often, bring it up with the boss.
|
| Also: Flow is not necessary or even desirable at all times. Many
| times you just want to be out for a walk while your fabulous
| brain rekejiggers things in the background. Or just walk away
| from it so that you can come back and look at it from a different
| perspective! Or have a chat with concerned persons to make sure
| the design makes sense. Flow isn't the answer to everything (or
| even most things).
|
| Flow is not something to optimize or life hack. My advice after
| 30 years in the industry is: Just do your job adequately. No one
| at your funeral is going to eulogize your work performance.
| hobs wrote:
| It's rare, but I have done it twice. The thing is it doesn't
| matter if I say nice things at your funeral, you're dead, work
| less.
| ec109685 wrote:
| This seems overly harsh. Poor development environments,
| documentation that takes too long to find anything, annoying
| code practices, etc. are all ways to snap yourself out of of
| flow.
|
| The point of the article is that you should examine what keeps
| you in flow and what knocks you out, and optimize for the
| former.
| permo-w wrote:
| is this really an extraordinary claim, though?
| robocat wrote:
| > My advice after 30 years in the industry is: Just do your job
| adequately. No one at your funeral is going to eulogize your
| work performance.
|
| Maybe nobody cares about your work, but there is one person
| that should care: you.
|
| You are already devoting your time to work, so why not make
| sure that you get some satisfaction from it. A massive pay
| increase for something that your bosses can't take from you.
|
| Watch any good tradie or professional, and discover what pride
| they get beyond the dollars paid to fix your tap or wipe your
| arse.
|
| I look back on work I have done with pride. There is no-one
| with enough knowledge (only me) to judge the qaulity of my past
| work (especially because much of it was not part of a
| development team). Like most work done by most people, the work
| I have done in the past is now worthless e.g. superceded by
| other systems. I haven't built monuments. Only I can judge the
| work I have done.
| Teleoflexuous wrote:
| Author mentions, but doesn't focus on, 'work being too
| challenging/not challenging enough'. I wrote a fair bit about it
| here (with a slightly different focus as name suggests, but I go
| over original research first)
| https://incentiveassemblage.substack.com/p/why-is-nobody-ser....
| I'm not sure _why_ 'challenge level' is less focused on compared
| to lack of interruptions - both seem about equally demanding to
| environment including manages and take similar amount of work to
| adjust.
|
| Either way, to save you a click, Csikszenthmihalyi research
| wasn't mainly about cognitive load, because we already had a fair
| bit of research on cognitive load. It seems insufficient
| (although I do have my reservations), but addition of complexity
| of the task and w/e additional issues are happening is pretty
| solid predictor* of performance. Challenge/skill 'graph'
| presented can be reinterpreted with challenge/skill on X axis and
| a parallel flat line above it. Even better, and empirically
| supported, graph can be seen in first image in the post I linked,
| but it is a bit much to paint with words.
|
| Flow research is cool, but there are more simple and actionable
| tools.
|
| *Observant reader may notice that this is because of lack of
| units, but we do have physiological indicators if one desires to
| monitor them.
| em-bee wrote:
| you bring up a good point. when work is very challenging then i
| get exhausted and need to take a break. however, i don't see
| that as a threat to the flow state because i see no point in
| trying to keep the flow at that point. i need a break anyways.
| so i don't see it as an interruption but more like having
| reached my limits. i have been wracking my brain over this
| piece of code and i don't understand whats wrong. then it's
| time to take a step back, take a break, do something else and
| look at the problem again with a fresh mind tomorrow.
| godelski wrote:
| I think it's a bit much to generalize this. I imagine it's
| different for each person and there's nuances.
|
| But with respect to working, I like to have an office with a
| door. The reason is I can mute slack and notifications and close
| the door when I'm in deep thought. The thing is that a physical
| door tends to do a good job at making people think more before
| interrupting. But doors are increasingly uncommon. WFH also is an
| alternative. I do like being in the office more but I'd rather
| WFH than be an an open noisy environment where there's constantly
| people walking through my pereferial and will talk behind me when
| I have my headphones on so I don't know if they're trying to talk
| to me or someone else. At least at home I can turn up the music
| and the main interruption is my cat doing something silly which
| makes me laugh and isn't that distracting.
| hgomersall wrote:
| Pink noise with noise cancelling headphones. I often find
| myself emerging from a zombie like state wondering what has
| gone on around me for the last 2 hours. I actually don't use it
| enough because I find it too all enveloping.
| jdblair wrote:
| this headline should be posted at the top of hacker news.
| Too wrote:
| " _54% of developers find that "Waiting on answers to questions
| often causes interruptions and disrupts my workflow."_ "
|
| Isn't this ironic? We are not allowed interrupt for questions,
| yet we find that the delay of waiting causes other interruptions.
|
| Designing systems and documentation to avoid question thus
| becomes a double win-win.
| hakanderyal wrote:
| This article perfectly describes what I usually go through when
| working. Well written. My most productive days are when I'm in
| the flow for 5-10 straight hours. Which only happens if I prepare
| both internal and external conditions to my satisfaction.
|
| Then, after reading the comments in here reminded me there is a
| lot of nuance to how one does software development. There are
| wildly different ways to achieve the same end result.
| iamleppert wrote:
| This article itself was written by someone with fragmented
| thinking. It feels like it was written by AI or just a stream of
| consciousness. Way too long, could have been a few paragraphs to
| basically make the points, that aren't backed up by any sort of
| evidence.
| ChrisMarshallNY wrote:
| This was an excellent article.
|
| However, I would add one practice to the things we can do, to
| reduce fragmented thinking. It's probably the oldest trick in the
| book; thousands of years old.
|
| _Create structured habits._
|
| This is what musicians do, when they practice scales, endlessly,
| or artists do, when they are constantly doodling (I have done
| both).
|
| When something becomes habit, we no longer think about it. It
| becomes "muscle memory."
|
| There's a bunch of habits that I employ in my own work, and I
| feel that they pay off. To go into more detail would take more
| work than I feel like doing, now (I really need to get back to
| writing, but have gotten out of practice).
|
| _" We are what we repeatedly do. Excellence, then, is not an
| act, but a habit."_
|
| - Mis-attributed to Aristotle
| qprofyeh wrote:
| I find that flow state is sometimes mind numbing. Taking a shower
| gives me more creative ideas.
|
| But visualizing any system or only a partial system on paper,
| makes a huge difference. Added bonus, pen and paper cannot be
| interrupted.
|
| Need to learn Mermaid one day.
| Footnote7341 wrote:
| Does anyone ever feel like they can enter too much of a flow
| state where you can solve a programming problem or an equation
| and not even consciously know what you just did and how it works
| calmworm wrote:
| "63% of developers report that searching for answers and
| solutions takes at least 30 minutes per day."
|
| I find this funny because I imagine the question was just "do you
| spend at least 30 minutes per day searching for answers..." which
| makes it seem like a lot less time is used than what is actually
| being used searching for solutions.
|
| Searching for answers is, in itself, a state of flow at times.
___________________________________________________________________
(page generated 2024-04-28 23:00 UTC)