Fragmented thinking is a bigger threat to flow state than interruptions
blog.stackblitz.com
blog.stackblitz.com
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.
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.
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.
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.
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.
For a long-time meditator, this is comedic gold. Just control your internal interruptions, stay focused. That's all, eh? Hehehehehe
That's almost never the case with internal struggles. You can't negotiate your ADHD away. There's no mental "ANC headphones" equivalent to shut the bees buzzing in your head up. You're lucky if the problem is something that responds to pharmacotherapy. That means there's actually something you can do to fix it that has even a snowball's chance in hell of working.
But things like negotiating across a power imbalance, finding and switching managers, teams, groups, switching jobs entirely... these are not trivial things! These are also extremely stressful things for which I don't think the word "trivial" gets anywhere near being an appropriate word choice.
Emphasis mine:
> Some internal monkeys can be tamed with simple habits.
If you dismiss the advice because it's not universally applicable, I think you do yourself and others a disservice.
I have some very bad ADHD that I have worked for years to control (using tools ranging from medication to meditation/mindfulness, etc). I fully agree that the monkeys in your brain can't be fully tamed, but surely you would agree that there is at least something that most people can do to improve things even a little bit? It's definitely hard, but not impossible.
Say that I'm working on some fairly big fairly sprawling and cross-cutting effort, and I'm having trouble getting it done efficiently because I keep going down unnecessary refactoring rabbit holes, or getting distracted while waiting for end-to-end tests to run. I can (and do) experience these issues with a wide open schedule, notifications silent, and a home office with zero external interruptions. But now say I am getting frequent high-urgency pings about various other things that I need to research and dig into. When I pop each of those off the stack, I'm just back to my rabbit-hole strewn slow-to-test mess, but now it's just later in the day with less time before I have to pick up the kids or before the next scheduled meeting, or whatever else. I'm still dealing with all the same internal issues, just with less time and more anxiety.
But it's very clear that I did not make this point well at all in my original post.
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.
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.
That makes it easier to maintain your focus, as the person originally said. A few cute euphemisms don’t mitigate that demonstrated reality; and so I’m left confused still —
You’re mocking someone pointing out fact with a quip.
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.
Somehow we mistake the sieve for free will, or that it's even a fully conscious mechanism. But it "just happens". It's very strange stuff.
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.
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.
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.
Your interpretation of sanderjd's comment was uncharitable and incorrect.[1] Saying you had a chuckle at their expense was condescending and added nothing.
zmgsabst's reply to you was rude. But it was a challenge to reflect. No one suggested you thought you were perfect. No one suggested your stumble disproved the utility of empathy. You wrote paragraphs against straw men.
Please receive criticism from others as you want others to receive criticism from you.
Which parts were incorrect, and how?
> Saying you had a chuckle at their expense was condescending and added nothing.
Are you referring to your model of reality or all models of reality?
I wonder if it's really as simple as your theory though...I don't disagree as a generalization, but perhaps certain classes of internal issues can be bypassed/moderated by external stimulus?
This is getting well outside the initial discussion (in some ways, but not all), but it's interesting.
When I was a child, world and humans in it were so simple. Good old times, at least relatively speaking.
No one (other than possibly the sprinkling of humans who have achieved enlightenment or someone temporarily under a heavy dose of psycho-motor stimulants) can fully control themselves internally. Minor, fleeting internal control occurs frequently. Being able to sum up the strength to initiate the process of planning and acting to perform directed speech to control Bob would be an example of this (and appropriate for your additive example) but the full state of internal control required to disconnect your senses and observation from Bob's incoming external interferences without impacting your own faculties or performance is a rare kind, or 'level' of internal control that many do not possess. Interestingly, this is all derivative of personality.
By the way, I'm not trying to say that this is always happening in my work, or even frequently, but this is an actual bad outcome that I experience from time to time. I currently have, and have been fortunate in my career to usually have very good management and teammates who are very respectful of each other's focus time.
~It's literally that easy~
Mostly because my life is a constant struggle against internal distractions, so my coping mechanisms are more evolved.
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.
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?
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.
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!
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.
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!
But ironically, instead of specialization, the trend is the opposite. Everyone is full-stack dev-sec-ops working in several different programming ecosystems, sometimes on multiple projects in parallel. You also do the testing and write the documentation, of course.
At the same time, you are supposed to be agile, and sprint, sprint, sprint, until you collapse. You can't really spend a week just sitting in silence and studying one of the hundred technologies you are supposed to master. So instead you learn everything on the fly. But as you keep jumping between thousand topics, it becomes impossible to remember them. If you accidentally memorize a library, it gets soon replaced by something new. So you keep googling endlessly, and maybe soon you will just keep pressing Ctrl+space and letting an artificial intelligence write your code... and then pray that it compiles and contains no bugs.
Makes me wonder whether it really increases the productivity, or just creates an illusion of greater productivity because people are kept visibly busy. I guess we keep writing more, but a lot of that is rewriting, or writing the supporting infrastructure.
If this keep accelerating at the same speed, in another twenty years only the artificial intelligence will be able to write code. It will use a different programming language every week, reinventing all the tools and libraries all the time. Bugs probably won't get fixed; humans will no longer be capable of that, and if the AI couldn't write the code correctly in the first place, it would be probably simpler to just throw the entire application away and rewrite it from scratch, using this week's programming language instead of the previous week's one. The resulting applications will be slow and require the latest hardware to run.
The good news is, you can mostly ignore it. I have 20 year old server-side rendered apps that are still running just fine today. Why run on that treadmill? Find something that looks solid and makes sense, and stick with it for awhile.
Not if you work in shared codebases with other teams who don't ignore it.
But otherwise:
> Find something that looks solid and makes sense, and stick with it for awhile.
100% yes.
Of course, when I hire I look for fundamental skills, not familiarity with XYZ technology. But I've seen people hire that way, and I know it's fairly common in our field.
I think "significant" is overstating it. Learning new tech is not that hard, particularly if you're already familiar with adjacent tech. I recognize that some people look for checkmarks on a CV, but if that's how they operate then you probably don't want to work there.
At one point, one of the monks interviewed by John Cassian and Germanus (either Abba Moses, Abba Serenus, or Abba Isaac, all of Scetis) compares the mind to a millstone driven by a water wheel. As long as the water flows, you cannot stop the millstone from moving and grinding whatever has been put into it. We cannot stop the millstone, but we can control what we feed into it and what is ground up by it.
Of course, there is also a long tradition of mortification of the flesh ("The Conferences" also discusses such things), crudely parodied and ridiculed by bad literature and trash Hollywood films. The basic understanding is that our bodily appetites can be unruly, grasping, wanting, desiring, imprudently and with no regard for the objective good that the intellect knows. Mortification is a way of training these insubordinate appetites and passions into obedience to the intellect through exercises of denial. Fasting is one example. An element of discomfort, and even suffering, can be involved as the lower is sacrificed for the sake of the higher, and the appetites throw their tantrums as we persevere and dominate them, reigning them in like a man on horseback reigns in his horse.
Our culture has sold us the idea that indulging our whims and desires with no regard for our objective good is freedom, but nothing could be further from the truth. This kind of lifestyle is a recipe for misery and enslavement, both to the chaos and disorder of unruly and even disordered appetites and passions, but also those who gladly exploit the appetites of such weak and blind men, herding and using them like mindless beasts. As Augustine of Hippo wrote, "a good man, though a slave, is free; but a wicked man, though a king, is a slave. For he serves, not one man alone, but what is worse, as many masters as he has vices." The relevance to focus here is that if you do not learn to exercise restraint and self-mastery, you will have trouble with focus as your appetites and passions will pull you away from the matter at hand. Perseverance is thwarted by such softness [3]. Pour only good things into your millstone. Do not pollute your millstone with darnel. Endure truth, whether pleasant or painful. Let is grind away your marble you bring forth your sculpture. It is not mastered, repressed appetites that come back to bite you. On the contrary. It is repressed truth that does.
[0] https://www.newadvent.org/fathers/3508.htm
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.
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!".
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
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
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.
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.
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.
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.
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.
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.
Concluding that the interruptions aren't so bad is consistent with this observation.
It does not generalise to all developers.
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.
[0] https://mynoise.net/NoiseMachines/whiteNoiseGenerator.php
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.
Pink noise has an inverse proportion to frequency, so defined by f^{-x} where 0 <=x<=2 (so at best, an inverse square). Now the problem with this is that sensitivity of human hearing is not flat across frequencies. There's a sharp uptick from 1kHz to 3kHz (peak) and you gotta get to 9kHz before you're back down to the level of 1kHz (which 100Hz - 1kHz is fairly flat). Here's a random graph[0], take it with a bit of a grain of salt but as far as I know it is reasonable. But remember that dB is logarithmic so this is significantly louder.
Because of this, Pink Noise is created to be "flat" with respect to the human ear[1]. I mean there's approximations going on for this but think of it as a lazy version of that if we didn't know the more complex response curve from [0]. While white noise is flat across frequencies, the perception is that higher frequencies are louder.
In short, pink noise will sound like it is raining on a metal surface or by rapids in a river. You can hear the low frequencies but you got lots of high ones too. Brown noise will be like sitting in the forest when it is raining, it hitting the soft dirt. Or a lot like being near the ocean.
So if you want that comfort slow pace feeling, turn up the low frequencies, so 10Hz to 500Hz, and I like to cut-off anything above 600Hz.
It can be good to play with single tones too[2]. I like about 65Hz (I can hear about 21Hz to 17kHz on this site with some good headphones but who knows. All that isn't flat and I'm a tad over 30). But the site I sent you previously has a lot to play around with. I'm not sure there's a high quality refined tone specification site but if you find one let me know.
I hope this helps.
[0] https://www.compadre.org/nexusph/course/images/OscillationsA...
[1] https://en.wikipedia.org/wiki/Colors_of_noise#Pink_noise
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.
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.
For sure this one is.
It's an unsubstantiated, novel claim about causation that has no peer reviewed research to support it.
It's fine to postulate such things, or even to explore its potential implications. But to present it as fact requires extraordinary evidence.
For extra fun/rage/narrative-catalyzing: negate your claims and re-ask the questions.
> It's an unsubstantiated, novel claim about causation that has no peer reviewed research to support it.
Do claims of nonexistence have a burden of proof, and if not:
a) why not?
b) can you cite any authority that explicitly asserts that they do not (as opposed to only pointing out the epistemic difficulty (teapots, etc))?
And even setting aside those rarely considered details:
> "It's an unsubstantiated, novel claim about causation that has no peer reviewed research to support it."
...even if we assume this to be true, do any specific necessarily correct conclusions derive from that observation? (And if not...actually, I think we have enough to chew on for now).
> But to present it as fact requires[!] extraordinary evidence.
I bet this isn't actually true, but let's see.
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.
When I work, I of course do so with skill and professionalism (which I do take pride in), but that's where it ends.
I only take pride in the work I do for myself and as a service to the community. If I'll have no rights to the work, I take no pride in it; it's merely a mercantile exchange.
Additionally, anecdotally, I don’t work for anyone if/when I’m developing but I still very much appreciate the moments of flow when creating. Why bash it altogether? Seems a strange take.
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.
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.
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.
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.
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.
You might be in the flow state without knowing. :)
>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").
I'm not even sure nowadays if I really experienced this, or if the feeling is just nostalgia.
That's the opposite of focus, literally, lol.
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.
This is the value I get from AI tools while coding.
> Now, “flow state” has all sorts of associations ...
and
> Before I started writing this article ...
They're more like the period at the end of a sentence, so that you can flow into the next one.
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.
(None of those links help when you switch to different providers; but that might not be too bad, depending on timescales of those changes)
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.
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.
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.
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.
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.
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.
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.