13 ms·

Fragmented thinking is a bigger threat to flow state than interruptions

386 points by nickwritesit 2y ago

Kinrany 2y ago
"Boring tasks shatter flow state even in the absence of external distractions"?
- layer8 2y ago
  They give few examples unfortunately, but the “writing a commit message” is one.
  - elevaet 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
        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 2y ago
        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 2y ago
        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 2y ago
        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 2y ago
        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.
      - hedora 2y ago
        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 2y ago
        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 2y ago
        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 2y ago
      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 2y ago
    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 2y ago
    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 2y ago
      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 2y ago
      I’m hereby coining the term “literate committing” for that. :)
bluerooibos 2y ago
What a horrific article. At least define fragmented thinking for us and provide some sort of conclusion/TLDR for this waffle.
- causal 2y ago
  This felt like someone trying to fill out a word count
- ranprieur 2y ago
  Yes, it repeats itself so much I kept thinking I had accidentally scrolled up.
- Sleepful 2y ago
  yep, dude literally says "create nudging to increase focus" like he didn't just copy paste some nonsense text from chatGPT. Create.... nudging? Sorry what? That's the opposite of focus, literally, lol.
JonChesterfield 2y ago
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 2y ago
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 2y ago
  > 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 2y ago
    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 2y ago
    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?
heisenbit 2y ago
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 2y ago
  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 2y ago
    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 2y ago
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 2y ago
  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.
- kubanczyk 2y ago
  martinvonz/jj - it's primary use case is as you've described, while using git as backend (i.e. other devs can still use git). But it's line-oriented, non ast-oriented.
j33zusjuice 2y ago
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 2y ago
  I saw two uses. Is that right? > Now, “flow state” has all sorts of associations ... and > Before I started writing this article ...
- marcosdumay 2y ago
  It emerged from printed news. It's more than a century old.
kstenerud 2y ago
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 2y ago
  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 2y ago
  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 2y ago
  is this really an extraordinary claim, though?
Teleoflexuous 2y ago
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-serious-about-managing 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 2y ago
  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 2y ago
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 2y ago
  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.
  - godelski 2y ago
    I tend to be a bigger fan of brown noise. Even just sound ~60Hz tends to do the trick[0]. Really, I like when it is dominated by sounds <125kHz and you get that under water feeling. Though I think it is likely unsurprising that this is a rather pleasant sound. [0] https://mynoise.net/NoiseMachines/whiteNoiseGenerator.php https://mynoise.net/NoiseMachines/whiteNoiseGenerator.php
    - hgomersall 2y ago
      Isn't that pink noise? I.e broadband, low frequency dominated? I'm not being snarky, I'm just trying to understand people's usage of terminology. I get the colour analogies for the most part, but brown doesn't make any sense to me. I just looked it up, and apparently brown noise is "Brownian" noise and has a more rapid fall off at higher frequencies. Personally I use Chroma Doze on android and draw a downward sloping frequency profile.
jdblair 2y ago
this headline should be posted at the top of hacker news.
Too 2y ago
”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.
- Aeolun 2y ago
  I’m sure I’ve read this as one of the success metrics in the Phoenix Project. Every time a ticket needs to go back to the original owner is a failure.
- TeMPOraL 2y ago
  This explains the success of StackOverflow: don't have to wait on your colleagues or even your own investigative work, the answer is usually a Google query away. This also explains the success of ChatGPT in dev work: StackOverflow is still too much bullshit to deal with. LLMs strip that all away. It's such a big difference it's worth risking being led astray by hallucinations.
  - fragmede 2y ago
    For coding, if the LLM hallucinates, you feed the error message into the LLM and it apologises and corrects itself. For bonus points, you can tell it to run the code until it works.
hakanderyal 2y ago
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 2y ago
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 2y ago
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
- hn_user82179 2y ago
  > 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). I'd really love to hear at least at a high level what sort of habits have helped you, if you have some time in the future
  - ChrisMarshallNY 2y ago
    I have done a lot of writing[0], but have fallen out of the habit. I’ll try to get back to it. [0] https://littlegreenviper.com/miscellany/ https://littlegreenviper.com/miscellany/
deleted 2y ago
[deleted]
qprofyeh 2y ago
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.
- andyferris 2y ago
  Yes. I find Mermaid and markdown is a decent replacement for writing, and Excalidraw is a decent replacement for whiteboarding / doodling. Mermaid is too slow for exploring ideas though, IMO.
Footnote7341 2y ago
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
- Sleepful 2y ago
  yeah, or sometimes it just happens while I am resting, totally thinking about distractions. This is why this article is nonesense to me.
calmworm 2y ago
“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.
hoc 2y ago
Even movies say: Opening invoices and final notices just keeps you from evolving into the hero that you're destined to become. Bad interpretation: Keeping the flow at any cost might make you drown. The whole productvity thing seems much more complex situation-wise, and still it boils down to keeping it up. Everything that nudgingly reminds you of that seems helpful. If it's a person, you even can hate them for it. A little bit at least.
sirsinsalot 2y ago
It's good to see a rising awareness of and language around executive function. As an ADHD sufferer the more talking about executive function we have, however rigorous, is a path to being able to talk about neurological issues causing executive dysfunction like ADHD. Extreme fragmentation of thought and constant internal disruption is my default and often only state.
JR1427 2y ago
I'm still waiting to experience what this "flow" is... I would say the reason I get stuff done is because I don't wait to develop flow. Instead I try and use what I call "micro-progress", where you try and identify the smallest thing you can do to move the task forward, and do it. Maybe one day I will experience flow, but in the meantime I'm fine without it. p.s. unrelated, but another thing I have no experience of is ASMR.
- rocgf 2y ago
  I don't think it's common for people to wait for flow to come in order to get things done. You can set up the conditions for it and likely reliable trigger it, but getting things done (or concentrating on a problem) is how you get to flow in the first place. You might be in the flow state without knowing. :)
- hifromwork 2y ago
  I'm positive you experience "flow" all the time, maybe without realising it. It's not the magical experience you may think it is, just a state of being focused on work. You don't have to actively work on getting into "flow", it just happens naturally when you're working undisturbed for several minutes on something you understand. >Instead I try and use what I call "micro-progress", where you try and identify the smallest thing you can do to move the task forward, and do it. That sounds like a great way to focus (and get into "flow").
  - JR1427 2y ago
    Oh, the way people sometimes talk about it, I really thought it must be some amazing feeling, and I'd definitely know if I'd experienced it! I'm slightly disappointed now.
    - Dessesaf 2y ago
      I'm not sure either. I definitely remember occasionally feeling a distinct "flow" feeling the first few years I was studying and working. But now I still have periods of similar and superior concentration, but it's not accompanied by any extraordinary feeling. I'm not even sure nowadays if I really experienced this, or if the feeling is just nostalgia.
janandonly 2y ago
I don't think that I have ADHD, but at times I just have to re-read a sentence a couple of times to grasp its meaning. Or rewind 30 seconds in a podcast or audiobook to listen again. If this happens too many times in a row, I assume I'm tired, so I switch to a more manual task (like doing the dishes). I remember times when I just had to study at that moment. I would force myself to re-read sentences until they made sense. I would rephrase the sentence or read the same sentence in another language that I know, until it made sense. I could spend the whole afternoon focussing on just a few pages. But I think it was a good exercise. I think focus is like a "muscle" that can be trained a bit.
- StefanBatory 2y ago
  Could be anxiety, could be bad habits. If it's possible, better to go to ask to specialist just in case - not much to be lost, and you gain internal peace.
  - SebKba 2y ago
    From my experience with "specialists", internal peace of mind is not what you will get from most mental health "professionals".
    - StefanBatory 2y ago
      Sorry, I should have been more specific - I wanted to mean by that knowing if it's ADHD or not.
- simple10 2y ago
  Happens to me sometimes too. And I don't have ADHD after testing. Choline and other focus related supplements helped a bit. Aggressively trying to reduce anxiety helped more than anything. Anxiety disconnects the "now" from the "goal" states and can massively disrupt concentration.
- Sleepful 2y ago
  You can be diagnose with ADHD for any number of circumstances, the ADHD diagnosis is not based on a specific cause, only on specific symptoms, it doesn't matter where the symptoms come from exactly (circumstance? nutrition? neurodivergent in the wrong environment? etc). I feel the same way you do. Something else to take into account: A lot of people are just mediocre at explaining themselves. This is fine because sometimes the information they have is good, the medium of communication is shabby, but we can still do an extended effort and look past the medium in order to get to the information. The point being, if someone is really adept at communication then you might find yourself focusing on really complex topics with ease, because it is engaging and nicely laid out. OTOH if I hand you an IKEA manual to build a simple vase but the scribbles are tiny and confusing, you will be like "Woah this is so difficult to pay attention to!".
bdjsiqoocwk 2y ago
Regarding the specific example of the commit, what I do to avoid precisely this is git commit -m wip. After the feature is done I git rebase -i and go thru the commits which should be merged (forgot the term) and which need a commit message.
anonzzzies 2y ago
My happiest time is when I start seeing code all day and in my dreams. I still have that after 40 years of coding if people don’t bother me and it makes me very happy. So for the coming 4 months everything is shut down for my new project. Only way I found to shut off both external and internal interruptions.
bux93 2y ago
Reading the headline, I though, sounds like an opinion piece rather than, you know, a systematic review.. But, the article cites studies! Cool! A survey. A survey combined with analysis of actual tasks (but, 'recorded' using a 'data extraction form', which sounds like self reported data?). Another study used "self-reflection". Another collects data through a daily survey(monley) and finally another based on self-reporting. This is (a lot) better than nothing, but all of these rely on self reporting.
voidhorse 2y ago
I think this is one reason why doing your design work on pen and paper in a quiet place, before you sit down to write any code, can be a game changer. Thinking on the fly and trying to keep a bunch of state in your head is difficult. Mathematical notation is super powerful and there's a reason it exists—use it! I also find that some programmers' bad habits naturally lead to "fragmented" thinking or lack of sustained focus. A lot of beginning programmers I encounter are sort of like information mice. They have some specific problem that they need a quick answer to, so they hunt around and scavenge for it, skimming various resources like crazy until they find it. While this works for basic, entry-level work and tasks, the same behavior is a complete achilles heel as you progress in you career and have to solve more complex problems. It teaches you to abandon detailed, sustained, focused thinking and building of deep understanding—the kind that allows you to solve problems in a novel way—for a mode of consumption and thinking that is shallow, fragile, and built upon expectations of instantaneousness and immediate gratification. I realize that having the time not to settle for scavenging is sometimes a luxury, but resist the impulse if you can!
- danielvaughn 2y ago
  This is wonderfully put, and it perfectly expresses why I'm frustrated with the current state of my career. In terms of fast/shallow vs slow/deep thinking, I've gone through a bell curve of sorts. When I was a junior, I did exactly as you said - skimming around Stack Overflow every few minutes. But as I progressed, I did that less and less, and entered into a blissful state of my career where I felt myself really sinking into deeper and deeper concepts. But in the past 3-5 years, something has changed. I don't know if it's me, or my industry (frontend web dev), or both. But it just feels like there's this overwhelming amount of constant change and detail, and I feel like I simply don't have the time or energy to keep up with it all. It's forced me back into a kind of frantic work process, and it makes me just want to give up. I've honestly thought about just trying to get into OS-level programming just so I can work with something that doesn't change every 2 weeks.
  - freedomben 2y ago
    The cost of change is real, and I think you've touched on it. When I started developing, Stack Overflow was in its infancy and occassionally had helpful answers, but "search the internet" was usually the fourth or fifth option when you couldn't find answers using the following: 1. Look through the documentation and/or man pages 2. Look through (one of) the book(s) you have on the subject 3. Ask a knowledgable co-worker (depending on what you're doing) 4. Try a few things to see if you can figure it out. If the source is available, dig through the source code of the framework you're building on. This was especially useful when it was a Qt-related question for example. So I came up with a balance of having theory/foundation in place before starting . There were pros and cons to this approach of course. It meant a bigger investment and higher barriers of entry to learning a new language/framework, but it also meant I would really learn those things and understand them deeply. The javascript world around 2011 or so when I got heavily into it (more than just jQuery, I started learning Backbone.js) was a change. It felt slower then than it does now. My approach of book-based learning worked great for learning Ruby and Rails, but not JS stuff. There just weren't many great focused books, and when I found one it would be outdated quickly or lose relevance (for example, because we moved to Ember.js, and then to React, etc). Eventually I did get the foundation in JS, but it was painful to get at especially with how many levels of abstraction there is (or used to be, now that browsers support a lot of ES6 and above features it's much better). Anyway, all that to essentially say that yes, the javascript world makes this very hard by being so fast-moving and mercilessly fragmented. I feel mostly insulated from that world now that I'm mainly doing Elixir (Phoenix and LiveView), but if you're doing anything web it's impossible to avoid it entirely. If Alpine.js disappears I'll be much regressed!
acureau 2y ago
Am I the only one who isn't super off-put by interruptions? I don't forget what I was thinking about so quickly, and if I'm thinking through something complex I work it out on paper.
- demondemidi 2y ago
  No you’re not. I too am able to handle interruptions. I find this discussion to be largely exaggerated. Flow / zone are documented but to the extent young developers belabor their prima Donna needs it becomes more of an identity.
datavirtue 2y ago
"What tooling choices...reduce lower-level thinking and optimize for higher-level thinking?" This is the value I get from AI tools while coding.
simple10 2y ago
Main takeaway: write more documentation and end your day by updating the documentation (reflecting). At least that's how I read the article. I've personally experienced a significant benefit from changing my software development habits to always writing documentation first. A sort of hybrid TDD approach where I try to stub everything out in either comments or tests before writing code. It's just a shift in viewing the documentation as a critical part of the end product. The goal being to create great documentation that happens to also have functioning code vs the other way around. This approach is especially useful for entrepreneurs who also code. As long as I have good documentation, I can replace myself as a developer pretty easily. But if I just write code and no docs, I'm effectively just building technical debt.

386 points by nickwritesit 2y ago

Kinrany 2y ago

"Boring tasks shatter flow state even in the absence of external distractions"?

layer8 2y ago
They give few examples unfortunately, but the “writing a commit message” is one.
- elevaet 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
      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 2y ago
        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 2y ago
        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 2y ago
        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 2y ago
        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.
    - hedora 2y ago
      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 2y ago
      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 2y ago
        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 2y ago
    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 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
    I’m hereby coining the term “literate committing” for that. :)

bluerooibos 2y ago

What a horrific article. At least define fragmented thinking for us and provide some sort of conclusion/TLDR for this waffle.

causal 2y ago
This felt like someone trying to fill out a word count
ranprieur 2y ago
Yes, it repeats itself so much I kept thinking I had accidentally scrolled up.
Sleepful 2y ago
yep, dude literally says "create nudging to increase focus" like he didn't just copy paste some nonsense text from chatGPT. Create.... nudging? Sorry what? That's the opposite of focus, literally, lol.

JonChesterfield 2y ago

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 2y ago

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 2y ago
> 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 2y ago
  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 2y ago
  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?

heisenbit 2y ago

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 2y ago
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 2y ago
  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 2y ago

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 2y ago
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.
kubanczyk 2y ago
martinvonz/jj - it's primary use case is as you've described, while using git as backend (i.e. other devs can still use git). But it's line-oriented, non ast-oriented.

j33zusjuice 2y ago

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 2y ago
I saw two uses. Is that right? > Now, “flow state” has all sorts of associations ... and > Before I started writing this article ...
marcosdumay 2y ago
It emerged from printed news. It's more than a century old.

kstenerud 2y ago

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 2y ago
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 2y ago
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 2y ago
is this really an extraordinary claim, though?

Teleoflexuous 2y ago

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-serious-about-managing 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 2y ago
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 2y ago

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 2y ago
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.
- godelski 2y ago
  I tend to be a bigger fan of brown noise. Even just sound ~60Hz tends to do the trick[0]. Really, I like when it is dominated by sounds <125kHz and you get that under water feeling. Though I think it is likely unsurprising that this is a rather pleasant sound. [0] https://mynoise.net/NoiseMachines/whiteNoiseGenerator.php https://mynoise.net/NoiseMachines/whiteNoiseGenerator.php
  - hgomersall 2y ago
    Isn't that pink noise? I.e broadband, low frequency dominated? I'm not being snarky, I'm just trying to understand people's usage of terminology. I get the colour analogies for the most part, but brown doesn't make any sense to me. I just looked it up, and apparently brown noise is "Brownian" noise and has a more rapid fall off at higher frequencies. Personally I use Chroma Doze on android and draw a downward sloping frequency profile.

jdblair 2y ago

this headline should be posted at the top of hacker news.

Too 2y ago

”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.

Aeolun 2y ago
I’m sure I’ve read this as one of the success metrics in the Phoenix Project. Every time a ticket needs to go back to the original owner is a failure.
TeMPOraL 2y ago
This explains the success of StackOverflow: don't have to wait on your colleagues or even your own investigative work, the answer is usually a Google query away. This also explains the success of ChatGPT in dev work: StackOverflow is still too much bullshit to deal with. LLMs strip that all away. It's such a big difference it's worth risking being led astray by hallucinations.
- fragmede 2y ago
  For coding, if the LLM hallucinates, you feed the error message into the LLM and it apologises and corrects itself. For bonus points, you can tell it to run the code until it works.

hakanderyal 2y ago

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 2y ago

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 2y ago

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

hn_user82179 2y ago
> 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). I'd really love to hear at least at a high level what sort of habits have helped you, if you have some time in the future
- ChrisMarshallNY 2y ago
  I have done a lot of writing[0], but have fallen out of the habit. I’ll try to get back to it. [0] https://littlegreenviper.com/miscellany/ https://littlegreenviper.com/miscellany/

deleted 2y ago

[deleted]

qprofyeh 2y ago

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.

andyferris 2y ago
Yes. I find Mermaid and markdown is a decent replacement for writing, and Excalidraw is a decent replacement for whiteboarding / doodling. Mermaid is too slow for exploring ideas though, IMO.

Footnote7341 2y ago

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

Sleepful 2y ago
yeah, or sometimes it just happens while I am resting, totally thinking about distractions. This is why this article is nonesense to me.

calmworm 2y ago

“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.

hoc 2y ago

Even movies say: Opening invoices and final notices just keeps you from evolving into the hero that you're destined to become. Bad interpretation: Keeping the flow at any cost might make you drown. The whole productvity thing seems much more complex situation-wise, and still it boils down to keeping it up. Everything that nudgingly reminds you of that seems helpful. If it's a person, you even can hate them for it. A little bit at least.

sirsinsalot 2y ago

It's good to see a rising awareness of and language around executive function. As an ADHD sufferer the more talking about executive function we have, however rigorous, is a path to being able to talk about neurological issues causing executive dysfunction like ADHD. Extreme fragmentation of thought and constant internal disruption is my default and often only state.

JR1427 2y ago

I'm still waiting to experience what this "flow" is... I would say the reason I get stuff done is because I don't wait to develop flow. Instead I try and use what I call "micro-progress", where you try and identify the smallest thing you can do to move the task forward, and do it. Maybe one day I will experience flow, but in the meantime I'm fine without it. p.s. unrelated, but another thing I have no experience of is ASMR.

rocgf 2y ago
I don't think it's common for people to wait for flow to come in order to get things done. You can set up the conditions for it and likely reliable trigger it, but getting things done (or concentrating on a problem) is how you get to flow in the first place. You might be in the flow state without knowing. :)
hifromwork 2y ago
I'm positive you experience "flow" all the time, maybe without realising it. It's not the magical experience you may think it is, just a state of being focused on work. You don't have to actively work on getting into "flow", it just happens naturally when you're working undisturbed for several minutes on something you understand. >Instead I try and use what I call "micro-progress", where you try and identify the smallest thing you can do to move the task forward, and do it. That sounds like a great way to focus (and get into "flow").
- JR1427 2y ago
  Oh, the way people sometimes talk about it, I really thought it must be some amazing feeling, and I'd definitely know if I'd experienced it! I'm slightly disappointed now.
  - Dessesaf 2y ago
    I'm not sure either. I definitely remember occasionally feeling a distinct "flow" feeling the first few years I was studying and working. But now I still have periods of similar and superior concentration, but it's not accompanied by any extraordinary feeling. I'm not even sure nowadays if I really experienced this, or if the feeling is just nostalgia.

janandonly 2y ago

I don't think that I have ADHD, but at times I just have to re-read a sentence a couple of times to grasp its meaning. Or rewind 30 seconds in a podcast or audiobook to listen again. If this happens too many times in a row, I assume I'm tired, so I switch to a more manual task (like doing the dishes). I remember times when I just had to study at that moment. I would force myself to re-read sentences until they made sense. I would rephrase the sentence or read the same sentence in another language that I know, until it made sense. I could spend the whole afternoon focussing on just a few pages. But I think it was a good exercise. I think focus is like a "muscle" that can be trained a bit.

StefanBatory 2y ago
Could be anxiety, could be bad habits. If it's possible, better to go to ask to specialist just in case - not much to be lost, and you gain internal peace.
- SebKba 2y ago
  From my experience with "specialists", internal peace of mind is not what you will get from most mental health "professionals".
  - StefanBatory 2y ago
    Sorry, I should have been more specific - I wanted to mean by that knowing if it's ADHD or not.
simple10 2y ago
Happens to me sometimes too. And I don't have ADHD after testing. Choline and other focus related supplements helped a bit. Aggressively trying to reduce anxiety helped more than anything. Anxiety disconnects the "now" from the "goal" states and can massively disrupt concentration.
Sleepful 2y ago
You can be diagnose with ADHD for any number of circumstances, the ADHD diagnosis is not based on a specific cause, only on specific symptoms, it doesn't matter where the symptoms come from exactly (circumstance? nutrition? neurodivergent in the wrong environment? etc). I feel the same way you do. Something else to take into account: A lot of people are just mediocre at explaining themselves. This is fine because sometimes the information they have is good, the medium of communication is shabby, but we can still do an extended effort and look past the medium in order to get to the information. The point being, if someone is really adept at communication then you might find yourself focusing on really complex topics with ease, because it is engaging and nicely laid out. OTOH if I hand you an IKEA manual to build a simple vase but the scribbles are tiny and confusing, you will be like "Woah this is so difficult to pay attention to!".

bdjsiqoocwk 2y ago

Regarding the specific example of the commit, what I do to avoid precisely this is git commit -m wip. After the feature is done I git rebase -i and go thru the commits which should be merged (forgot the term) and which need a commit message.

anonzzzies 2y ago

My happiest time is when I start seeing code all day and in my dreams. I still have that after 40 years of coding if people don’t bother me and it makes me very happy. So for the coming 4 months everything is shut down for my new project. Only way I found to shut off both external and internal interruptions.

bux93 2y ago

Reading the headline, I though, sounds like an opinion piece rather than, you know, a systematic review.. But, the article cites studies! Cool! A survey. A survey combined with analysis of actual tasks (but, 'recorded' using a 'data extraction form', which sounds like self reported data?). Another study used "self-reflection". Another collects data through a daily survey(monley) and finally another based on self-reporting. This is (a lot) better than nothing, but all of these rely on self reporting.

voidhorse 2y ago

I think this is one reason why doing your design work on pen and paper in a quiet place, before you sit down to write any code, can be a game changer. Thinking on the fly and trying to keep a bunch of state in your head is difficult. Mathematical notation is super powerful and there's a reason it exists—use it! I also find that some programmers' bad habits naturally lead to "fragmented" thinking or lack of sustained focus. A lot of beginning programmers I encounter are sort of like information mice. They have some specific problem that they need a quick answer to, so they hunt around and scavenge for it, skimming various resources like crazy until they find it. While this works for basic, entry-level work and tasks, the same behavior is a complete achilles heel as you progress in you career and have to solve more complex problems. It teaches you to abandon detailed, sustained, focused thinking and building of deep understanding—the kind that allows you to solve problems in a novel way—for a mode of consumption and thinking that is shallow, fragile, and built upon expectations of instantaneousness and immediate gratification. I realize that having the time not to settle for scavenging is sometimes a luxury, but resist the impulse if you can!

danielvaughn 2y ago
This is wonderfully put, and it perfectly expresses why I'm frustrated with the current state of my career. In terms of fast/shallow vs slow/deep thinking, I've gone through a bell curve of sorts. When I was a junior, I did exactly as you said - skimming around Stack Overflow every few minutes. But as I progressed, I did that less and less, and entered into a blissful state of my career where I felt myself really sinking into deeper and deeper concepts. But in the past 3-5 years, something has changed. I don't know if it's me, or my industry (frontend web dev), or both. But it just feels like there's this overwhelming amount of constant change and detail, and I feel like I simply don't have the time or energy to keep up with it all. It's forced me back into a kind of frantic work process, and it makes me just want to give up. I've honestly thought about just trying to get into OS-level programming just so I can work with something that doesn't change every 2 weeks.
- freedomben 2y ago
  The cost of change is real, and I think you've touched on it. When I started developing, Stack Overflow was in its infancy and occassionally had helpful answers, but "search the internet" was usually the fourth or fifth option when you couldn't find answers using the following: 1. Look through the documentation and/or man pages 2. Look through (one of) the book(s) you have on the subject 3. Ask a knowledgable co-worker (depending on what you're doing) 4. Try a few things to see if you can figure it out. If the source is available, dig through the source code of the framework you're building on. This was especially useful when it was a Qt-related question for example. So I came up with a balance of having theory/foundation in place before starting . There were pros and cons to this approach of course. It meant a bigger investment and higher barriers of entry to learning a new language/framework, but it also meant I would really learn those things and understand them deeply. The javascript world around 2011 or so when I got heavily into it (more than just jQuery, I started learning Backbone.js) was a change. It felt slower then than it does now. My approach of book-based learning worked great for learning Ruby and Rails, but not JS stuff. There just weren't many great focused books, and when I found one it would be outdated quickly or lose relevance (for example, because we moved to Ember.js, and then to React, etc). Eventually I did get the foundation in JS, but it was painful to get at especially with how many levels of abstraction there is (or used to be, now that browsers support a lot of ES6 and above features it's much better). Anyway, all that to essentially say that yes, the javascript world makes this very hard by being so fast-moving and mercilessly fragmented. I feel mostly insulated from that world now that I'm mainly doing Elixir (Phoenix and LiveView), but if you're doing anything web it's impossible to avoid it entirely. If Alpine.js disappears I'll be much regressed!

acureau 2y ago

Am I the only one who isn't super off-put by interruptions? I don't forget what I was thinking about so quickly, and if I'm thinking through something complex I work it out on paper.

demondemidi 2y ago
No you’re not. I too am able to handle interruptions. I find this discussion to be largely exaggerated. Flow / zone are documented but to the extent young developers belabor their prima Donna needs it becomes more of an identity.

datavirtue 2y ago

"What tooling choices...reduce lower-level thinking and optimize for higher-level thinking?" This is the value I get from AI tools while coding.

simple10 2y ago

Main takeaway: write more documentation and end your day by updating the documentation (reflecting). At least that's how I read the article. I've personally experienced a significant benefit from changing my software development habits to always writing documentation first. A sort of hybrid TDD approach where I try to stub everything out in either comments or tests before writing code. It's just a shift in viewing the documentation as a critical part of the end product. The goal being to create great documentation that happens to also have functioning code vs the other way around. This approach is especially useful for entrepreneurs who also code. As long as I have good documentation, I can replace myself as a developer pretty easily. But if I just write code and no docs, I'm effectively just building technical debt.