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.
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.
I'm not sure if you're expressing what you think you are. They outlined a group by nature of the problem (so the people in question have something to improve, tautalogically), so it's not like they are painting with an overly broad brush, unless you think people that accomplished something hard and then automatically assume they have faculty in all topics is not a group in need of examining their assumptions more closely?
I don't think it is, which is my point. It's essentially saying "I wish people with BEHAVIOR PROBLEM would do THING THAT MAY HELP MITIGATE PROBLEM." There is no statement of the size of that group, or how many people exhibit that problem. Unless you don't think the behavior being talked about is a problem (which is different than thinking not many people have this problem), then I'm not sure how having empathy towards them factors in. Is wishing they had more perspective and could avoid a cognitive pitfall not empathy?
My contention is that I make a good faith effort to be open to the idea that others know or have experienced things or might have some thoughts that I haven’t considered adequately. And that I think this concept would be helpful to others here. That’s all, no more, no less.
It isn’t that I’m perfect, or infallible, or even immune to frustration and the occasional bout of snark. It doesn’t mean that I’m a “better” person. It also doesn’t mean that I have to accept every viewpoint as true or equally likely. Nor does it mean that I can’t criticize. Nor that I can’t take a side on a considered opinion. It doesn’t mean that this always leads to perfect results or that I’m always successful. It doesn’t mean that it’s a perfect heuristic. It’s only one more tool in a toolbox.
I think it is undervalued - and sometimes angrily pushed back against - in this community, maybe because it gets dismissed as “feelings” (and not “reason”). The reason I think this is that I've encountered here the “experienced expert with healthy self doubt versus passionate amateur with little self awareness” dynamic in action over and over again.
There’s an ongoing, half century current in the field trying to examine whether reasoning may often involve a heuristic-based, adaptive process based on incomplete and imperfect information, and less so something resembling a pure application of formal logic.
In this universe, cognitive biases extend more clearly to things like which facts you consider as possible at all in the first place and by which methods you weight them as more or less likely or influential, as opposed to merely fallacies of formal logic that we’re most often exposed to. So, the thinking goes, it can help to try to fill some gaps in this area by trying to increase the breadth of what you’re exposing yourself to and allowing yourself to take into account.
In my experience this can be a frustrating and exhausting concept to contend with as a person. You certainly can tu quoque yourself - or me, like you and others in this thread have - into oblivion. After all, what business do I have talking about cognitive biases if I've been shown to be subject the very same, and am not an expert in it? I don't know where the line is but I'm not certain it makes the concept less helpful outright. At the very least I don't think I'm claiming something that'd be considered very controversial as far as I'm aware.
Please continue preaching empathy and self awareness. But please practice them also.
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.
OP’s remark just reminded me of something more general not necessarily in that remark that really has been bothering me. It wasn't very clear that I was going off on a tangent, and I tried to keep it lighthearted in a hamfisted way that ended up being more condescending than I intended, and then I got more defensive about it than I should when it wasn’t received well. Sorry about that - thanks for keeping me honest.
For what it's worth, when I (the author of that first comment) first read your comment, my thought was "wait, how is this responsive to what I wrote?". But now I've read this whole thread, and while I do think it was a bit of a tangent not super directly related to what I wrote, I have found it interesting and reflective in a positive way. And I agree with your broad point about empathy and such.
I've mentioned in a few comments now that the point I wanted to make (which I clearly did a poor job of), is that it's obviously easier to deal with only "internal interruptions", rather than both those and "external interruptions" additionally. You don't get to choose between the two, because the "internal interruptions" will exist regardless of how well you've managed to control "external interruptions".
Well I think you catalyzed a fantastic meta conversation!
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?
It's certainly not an uninteresting question! But personally I think the answer is "no". I think getting interrupted externally makes it strictly harder for me to manage my own internal distractions. Which doesn't mean it is universally bad though, to be clear! There are other important things, even far more important things, than individual productivity. But from the perspective of "is it easier or harder for me to get my individual contributions done if I'm left entirely alone or if I'm pinged about things frequently", I really think the answer is that it's always worse to be fielding communications.
I think there are some education maybe... take for example a gong ringing periodically in the background , this is an example of an external interruption that can be beneficial for addressing internal out of control thinking.
This is getting well outside the initial discussion (in some ways, but not all), but it's interesting.
Not easy, easier! For "external interruptions", you have to do both things, keep people from bugging you and control your own mind. I think it's definitely easier to only do one of the two, despite still being really hard.
It's actually easier to control your external environment than your internal environment. If interruptions or distractions are like a monkey hopping around, then at least with an external monkey you can put it outside and lock the door. With an internal monkey you're stuck with it. Drugs help but come with side effects; meditation helps but takes concerted long-term effort separate from work. (And it's hard to motivate yourself in addition to your already long workday to improve your performance during said workday.)
Yes, but again, the point I intended to make was that if you don't have to spend time controlling your external environment, then you only have to focus on what's going on with yourself. But if you do have to put time into controlling things externally, you still have to focus on those internal things. Being interrupted more externally doesn't make your internal struggles easier, it only gives you less time for them.
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.
You can put an external monkey outside and lock the door if you have a door and your boss doesn't tell you you to allow the monkey. Some internal monkeys can be tamed with simple habits.
Not everyone can form "simple habits", especially when they have monkeys running around their brain. For external monkeys, there are always some solutions that have little ongoing costs - negotiation, ANC headphones, office hours, telling the monkey to GTFO. Can't tell your own brain to shut up.
GP did not say that "everyone can form "simple habits." That's a strawman version of their position.
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.
I like to say "just" for things like this :) In the sense that, this really is the answer, but the devil is in the details. (Usually in this same way of implying that it approaches pointlessness to even mention the thing you "just" need to do.)
Obviously it's easier than dealing with external interruptions. I don't suppose you do your hippie calming exercises while bob from accounting tries to get information from you for the 5th time this hour.
This is wonderfully naive. You can fairly easily learn to control Bob though articulated speech or just leave. Controlling the internal is the central focus of most world religions, and not being able to do it is responsible for most suffering on earth. We are mostly helpless cognonauts.
But again, controlling Bob is in addition to controlling the internal. It's additive, not a replacement of a harder thing with an easier one. And if you feel time pressure, as I often do, any time spent controlling those external distractions just leaves you with less time to work through the real issues, and thus more anxiety, such that the final level of difficulty is even greater than the sum of the parts.
Respectfully disagree, controlling the internal and controlling bob are parallel at best, they are not binary states.
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.
They might be "parallel" if there were no zero-sum time trade off, or no time pressure. I wouldn't mind so much spending time fielding interrupts all day every day, if I didn't have anything else I was trying to get done. But that's not the reality. And for me (and I think many others), it isn't just additive, because time pressure makes me anxious and less focused, which slows me down more, which increases the time pressure, which makes me more anxious, etc.
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.
From the article, a fair few internal interruptions are procedural, things like writing a commit message. I took a big point as being that you should design your work processes to help maintain flow.
You said this so much better than me! These were the ones I was thinking more of when writing my comment, rather than all the distractions of a noisy brain. I agree entirely with folks here that those are not in any way easy to overcome. (Though still easier to overcome in the absence of lots of external interruptions.)
As a long time meditator, I’m not sure what you find amusing.
Are you saying you have more control of what other people do than your own mind? If not, what are you objecting to in saying that it’s easier to control yourself than others?
I’m really struggling not to see your comment as living down to stereotypes: vapidly smug.
After enough hours of meditation practice it becomes quite clear that one's mind is ungovernable at best. We can just hope to hold a clear intention (meditation practice in a nutshell) and return to the task whenever internal or external interruptions arise. Perhaps more and more parts of the mind will align with the intention. Hopefully the mind gets unified over time and as a result flow states can be experienced.
The person whose comment you're replying to was probably highlighting the fact that this process is not as predictable as the parent comment alluded to.
But there’s empirical results, from sports to military to meditation — you can train focus.
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.
It's almost like the facade of mental control is a sieve that tries to exclude the chaos and let something coherent flow through... And you can't even be certain how it accomplishes that. It's a mystery where the nonsense and sense even comes from, too.
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.
Some people like to project their problems into the rest of the population. Someone that has never achieved a major capacity to direct their attention will believe that it is not a skill they can attain. If they find someone with such a skill then they are “oh so gifted”, completely dismissing all the training and effort that said person has put into themselves. Timeless dialectic.
"My boss is always interrupting me with questions, and the office is very noisy. There's no easy fix for either of those external things, so you're lucky that all you have to deal with is internal ADHD and tinnitus!" /s
But you still have to deal with those internal issues in a noisy distracting office! Being interrupted more by other people doesn't make it easier to manage internal struggles, it is a strictly additive difficulty.
Point is, external interruptions are trivial to deal with compared to internal struggles. You can wear ANC headphones in the office and negotiate focus time with your boss. You can change your boss, or your job, or restructure your work around interruptions. Point is, you have options that are sure to work, and tend to not require much upkeep; many are just "fire and forget" fixes.
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.
I really think "trivial" is massive hyperbole here. Like most people commenting here, I have deep struggles with my own mind, I relate extremely strongly to all the things people are saying here about this.
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.
Yes, the headline term was never truly defined for use. Past the headline it didn't get used until almost half way through and then assumed you knew what was meant by it. Only near the end were there hints as to what the writer was referencing.
Good job pulling out a very plausible interpretation though. We talk about this in our dev meetings and attempt to proactively identify and resolve sources. Having well defined and coherent contexts improved our work and the emotional experiences of doing it. This has been helping me recapture the joy of coding.
Shouldn't have taken starting a company fellow business leaders.
> The frustrating thing about external interruptions is the inability to control them. [...] The good news for these internal interruptions is that it should be much easier to control them.
Interestingly, I feel the exact opposite. I'm aware that it's not always possible or socially acceptable to do so, but at least in theory you can always make a choice to ignore or tune out other people. Ignoring the stuff that is going on in your own head is IMHO much harder.
Yeah I clearly worded this poorly. What I meant to say is that it should be much easier to control only the internal interruptions, compared to the necessity to control both the external ones and the internal ones. That is, the existence of external interruptions doesn't make the internal ones go away, they're just additive on top, which can only make things more difficult.
I am under the impression that its harder to control internal interruptions. Like the quote from st.augustine, 'the mind commands the body and it obeys. The mind commands itself and meets resistance.'
I spent a long time thinking about why I always end up being the guy that people feel comfortable interrupting. I’m never the nicest guy in the office, I’m not always the cleverest, especially when I’m trying to do something else. But I do seem to recover better from external distractions than most people.
Mostly because my life is a constant struggle against internal distractions, so my coping mechanisms are more evolved.
> I think this point is a bit obscured by the article's use of this "fragmented thinking" terminology, which does not do a good job of defining before building an argument on top of it.
I totally agree with you that the article didn't explicitly define it, but I had the opposite experience reading it. For me, sans definition, could very quickly imagine what they were talking about because it started resonating for me almost immediately.
> The frustrating thing about external interruptions is the inability to control them. Things like turning off notifications and putting on headphones are mechanisms to reduce that frustration by imposing control over those interruptions.
This is partly why it started resonating for me right away. I currently share a semi-private office with another senior engineer. Lately he's been spending a good chunk of his time working on higher-level systems planning work and I've been spending most of my time working on very specific complex low-level work. The questions are sometimes frustrating because they'll interrupt my flow state, but... only sometimes. I've been chewing on that for a couple of weeks now, actually, because I hadn't yet figured out why he could sometimes ask me questions and it would have almost zero effect on me while other times it would have a massive negative effect.
The article nailed it, on reflection: the effect size of being interrupted with a question, for me, is proportional to how far away from the problem I'm working on is. If I'm digging into some of the autopilot code and get asked a question about GPS or IMUs, it is absolutely no problem to think about the question and answer it. If, though, it's a question about, say, a battery or the charging system, I'll get the "black cloud evaporating" phenomenon from the comic in the article. And it happens so quickly that by time I can even just answer "sorry, I don't have brain capacity to think about that right now" it's too late.
Regarding internal interruptions, classic Pomodoro technique (the one with a kitchen timer and a sheet of paper) deals with them this way: there is an 'interruptions' section on the sheet, and whenever an interrupting thought occurs, it's written down to that section and a dot is put above current Pomodoro. This way one is confident that no important ideas are missed and also can track the number of interruptions per Pomodoro.
Tying this to one of the author's arguments: Many internal interruptions occur because of the type of work we are doing is not right. I find myself distracted when my task is too complex, vague, or limiting. The task needs to have the right balance of difficulty and creativity to make it "flow-statable".
I use Cold Turkey to block my habbit of scrolling time-wasting sites when I should be reflecting harder on what it is needed to solve the issue at hand.
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.
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?
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!
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.
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!
Same, I started writing JS around 2011. Back then, even Grunt and Gulp hadn't been created yet. I was literally optimizing my files by hand, and deploying by dragging my files via an FTP client. It was tedious, but also transparent.
Software development keeps expanding in functionality and the level of detail. Twenty years ago you made a simple desktop application and that was it. Today, the same application would need to be online, which of course requires REST, authentication, load balancing, etc. You don't save information in a text or binary file, you need a database, which means object modeling, transactions, indexes, partitioning, etc. Instead of writing information to the standard output, we have log file, dynamic configuration of loggers, log rotation, infrastructure to move the logs in cloud, etc. Just editing the source code already requires several tools, including version control, which includes conflict resolution, pull requests, pre-commit hooks, etc. Nothing is ever simple; any functionality can be expanded into a separate library, parts of which will soon require libraries of their own, etc.
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.
> just feels like there's this overwhelming amount of constant change and detail
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.
For my own tech yes, I can ignore it. But for job opportunities, the unfortunate reality is that recruiters, hiring managers, and interviewers will be looking for knowledge about relevant tech. I don't want to learn NextJS, and you will not catch me trying to use it in my free time. But if one day I apply for a job that's looking for people with knowledge of NextJS, I probably won't get that job. And if it comes to pass that the majority of the industry moves to NextJS, I'm now at significant risk.
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.
> And if it comes to pass that the majority of the industry moves to NextJS, I'm now at significant risk.
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.
Does reading a dozen papers on different algorithms to accomplish a specific goal count as scavenging. Asking for me because I've gone down a rabbit hole with recent work. Not trying to be antagonistic or humble brag either. Actually not sure what I'm trying to accomplish with this question.
I think most papers should effectively just be scavenged through. In (mathematics) grad school I’ve only had time to seriously study a single digit number of research papers, but I at least feel like I gained a lot from looking through many many more than that.
John Cassian's "The Conferences"[0][1] is a collection of interviews with the Desert Fathers, and one of the subjects discussed is that of focus and concentration (a selection of excerpts was recently compiled into a small book entitled "How to Focus", a review of which was posted here on HN two months ago [2]).
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.
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.
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!".
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.
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.
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."
> 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
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.
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.
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.
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.
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.
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.
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.
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.
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?”)
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.
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.
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.
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.
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.
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.
Yeah so you're right about Brown not coming from the color, but I believe this was still done on purpose.
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.
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.
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.
One can rarely “schedule” flow so when a scheduled meeting interrupts flow it’s still an interruption.
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.
> My advice after 30 years in the industry is: Just do your job adequately. No one at your funeral is going to eulogize your work performance.
Maybe nobody cares about your work, but there is one person that should care: you.
You are already devoting your time to work, so why not make sure that you get some satisfaction from it. A massive pay increase for something that your bosses can't take from you.
Watch any good tradie or professional, and discover what pride they get beyond the dollars paid to fix your tap or wipe your arse.
I look back on work I have done with pride. There is no-one with enough knowledge (only me) to judge the qaulity of my past work (especially because much of it was not part of a development team). Like most work done by most people, the work I have done in the past is now worthless e.g. superceded by other systems. I haven't built monuments. Only I can judge the work I have done.
I do work for others because I'm not rich enough to survive without a salary.
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.
> No more so than "vaccinations cause autism" or "homeopathic medicine works" or "the stars direct your fate".
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.
“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.
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.
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.
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.
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.
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.
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. :)
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").
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.
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.
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?
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.
Author mentions, but doesn't focus on, 'work being too challenging/not challenging enough'. I wrote a fair bit about it here (with a slightly different focus as name suggests, but I go over original research first) https://incentiveassemblage.substack.com/p/why-is-nobody-ser.... I'm not sure why 'challenge level' is less focused on compared to lack of interruptions - both seem about equally demanding to environment including manages and take similar amount of work to adjust.
Either way, to save you a click, Csikszenthmihalyi research wasn't mainly about cognitive load, because we already had a fair bit of research on cognitive load. It seems insufficient (although I do have my reservations), but addition of complexity of the task and w/e additional issues are happening is pretty solid predictor* of performance. Challenge/skill 'graph' presented can be reinterpreted with challenge/skill on X axis and a parallel flat line above it. Even better, and empirically supported, graph can be seen in first image in the post I linked, but it is a bit much to paint with words.
Flow research is cool, but there are more simple and actionable tools.
*Observant reader may notice that this is because of lack of units, but we do have physiological indicators if one desires to monitor them.
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.
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
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> The good news for these internal interruptions is that it should be much easier to control them.
For a long-time meditator, this is comedic gold. Just control your internal interruptions, stay focused. That's all, eh? Hehehehehe
Agreed fully.
I'll admit I also had a chuckle at the expense of the parent post here (I'm sorry - the rest of this post isn't meant to pick on you or describe you specifically). I think this there is a lesson in here somewhere on the intellectual confidence that comes with being good at one thing, and the silliness that can ensue when it might not translate elsewhere. Not in even necessarily in a malicious or foolish way, but in a "it can catch you even when you think you're accounting for it" kind of way.
If not empathy for the sake of moral reasons or even good vibes, I wish that we could at least convince the "I read the abstract of 3 papers / I read a gwern post about this / I accomplished something hard in my life so I know everything" crowd of the utility of empathy as a tool for exploring your "unknown unknowns". You'd think that more people would be interested in a dialectic (in the classical philosophy sense) discussion as a cooperative if conflicting search for truth. This is harder to do if you systematically overestimate yourself and underestimate others. Of course as I write this I'm thinking of all the times I didn't practice what I'm preaching now.
> “I accomplished something hard in my life so I know everything" crowd of the utility of empathy as a tool for exploring your "unknown unknowns".
Do you believe you’ve demonstrated “the utility of empathy” in your post? — or even your interpretation of what was said?
- - -
> Of course as I write this I'm thinking of all the times I didn't practice what I'm preaching now.
> Not in even necessarily in a malicious or foolish way, but in a "it can catch you even when you think you're accounting for it" kind of way.
> This is harder to do if you systematically overestimate yourself and underestimate others.
Mm.
I'm not sure if you're expressing what you think you are. They outlined a group by nature of the problem (so the people in question have something to improve, tautalogically), so it's not like they are painting with an overly broad brush, unless you think people that accomplished something hard and then automatically assume they have faculty in all topics is not a group in need of examining their assumptions more closely?
The post is pretty close to being guilty of the very problem it is pointing out.
I don't think it is, which is my point. It's essentially saying "I wish people with BEHAVIOR PROBLEM would do THING THAT MAY HELP MITIGATE PROBLEM." There is no statement of the size of that group, or how many people exhibit that problem. Unless you don't think the behavior being talked about is a problem (which is different than thinking not many people have this problem), then I'm not sure how having empathy towards them factors in. Is wishing they had more perspective and could avoid a cognitive pitfall not empathy?
My contention is that I make a good faith effort to be open to the idea that others know or have experienced things or might have some thoughts that I haven’t considered adequately. And that I think this concept would be helpful to others here. That’s all, no more, no less.
It isn’t that I’m perfect, or infallible, or even immune to frustration and the occasional bout of snark. It doesn’t mean that I’m a “better” person. It also doesn’t mean that I have to accept every viewpoint as true or equally likely. Nor does it mean that I can’t criticize. Nor that I can’t take a side on a considered opinion. It doesn’t mean that this always leads to perfect results or that I’m always successful. It doesn’t mean that it’s a perfect heuristic. It’s only one more tool in a toolbox.
I think it is undervalued - and sometimes angrily pushed back against - in this community, maybe because it gets dismissed as “feelings” (and not “reason”). The reason I think this is that I've encountered here the “experienced expert with healthy self doubt versus passionate amateur with little self awareness” dynamic in action over and over again.
There’s an ongoing, half century current in the field trying to examine whether reasoning may often involve a heuristic-based, adaptive process based on incomplete and imperfect information, and less so something resembling a pure application of formal logic.
In this universe, cognitive biases extend more clearly to things like which facts you consider as possible at all in the first place and by which methods you weight them as more or less likely or influential, as opposed to merely fallacies of formal logic that we’re most often exposed to. So, the thinking goes, it can help to try to fill some gaps in this area by trying to increase the breadth of what you’re exposing yourself to and allowing yourself to take into account.
In my experience this can be a frustrating and exhausting concept to contend with as a person. You certainly can tu quoque yourself - or me, like you and others in this thread have - into oblivion. After all, what business do I have talking about cognitive biases if I've been shown to be subject the very same, and am not an expert in it? I don't know where the line is but I'm not certain it makes the concept less helpful outright. At the very least I don't think I'm claiming something that'd be considered very controversial as far as I'm aware.
Please continue preaching empathy and self awareness. But please practice them also.
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.
[1] https://news.ycombinator.com/item?id=40190376
OP’s remark just reminded me of something more general not necessarily in that remark that really has been bothering me. It wasn't very clear that I was going off on a tangent, and I tried to keep it lighthearted in a hamfisted way that ended up being more condescending than I intended, and then I got more defensive about it than I should when it wasn’t received well. Sorry about that - thanks for keeping me honest.
For what it's worth, when I (the author of that first comment) first read your comment, my thought was "wait, how is this responsive to what I wrote?". But now I've read this whole thread, and while I do think it was a bit of a tangent not super directly related to what I wrote, I have found it interesting and reflective in a positive way. And I agree with your broad point about empathy and such.
> Your interpretation of sanderjd's comment was uncharitable and incorrect.
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've mentioned in a few comments now that the point I wanted to make (which I clearly did a poor job of), is that it's obviously easier to deal with only "internal interruptions", rather than both those and "external interruptions" additionally. You don't get to choose between the two, because the "internal interruptions" will exist regardless of how well you've managed to control "external interruptions".
Well I think you catalyzed a fantastic meta conversation!
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?
It's certainly not an uninteresting question! But personally I think the answer is "no". I think getting interrupted externally makes it strictly harder for me to manage my own internal distractions. Which doesn't mean it is universally bad though, to be clear! There are other important things, even far more important things, than individual productivity. But from the perspective of "is it easier or harder for me to get my individual contributions done if I'm left entirely alone or if I'm pinged about things frequently", I really think the answer is that it's always worse to be fielding communications.
I think there are some education maybe... take for example a gong ringing periodically in the background , this is an example of an external interruption that can be beneficial for addressing internal out of control thinking.
This is getting well outside the initial discussion (in some ways, but not all), but it's interesting.
struck a little too close to home, eh?
Not easy, easier! For "external interruptions", you have to do both things, keep people from bugging you and control your own mind. I think it's definitely easier to only do one of the two, despite still being really hard.
It's actually easier to control your external environment than your internal environment. If interruptions or distractions are like a monkey hopping around, then at least with an external monkey you can put it outside and lock the door. With an internal monkey you're stuck with it. Drugs help but come with side effects; meditation helps but takes concerted long-term effort separate from work. (And it's hard to motivate yourself in addition to your already long workday to improve your performance during said workday.)
Yes, but again, the point I intended to make was that if you don't have to spend time controlling your external environment, then you only have to focus on what's going on with yourself. But if you do have to put time into controlling things externally, you still have to focus on those internal things. Being interrupted more externally doesn't make your internal struggles easier, it only gives you less time for them.
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.
You can put an external monkey outside and lock the door if you have a door and your boss doesn't tell you you to allow the monkey. Some internal monkeys can be tamed with simple habits.
Not everyone can form "simple habits", especially when they have monkeys running around their brain. For external monkeys, there are always some solutions that have little ongoing costs - negotiation, ANC headphones, office hours, telling the monkey to GTFO. Can't tell your own brain to shut up.
GP did not say that "everyone can form "simple habits." That's a strawman version of their position.
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.
Just stop being sad. Just focus. Just be a good balanced human being.
When I was a child, world and humans in it were so simple. Good old times, at least relatively speaking.
I like to say "just" for things like this :) In the sense that, this really is the answer, but the devil is in the details. (Usually in this same way of implying that it approaches pointlessness to even mention the thing you "just" need to do.)
Obviously it's easier than dealing with external interruptions. I don't suppose you do your hippie calming exercises while bob from accounting tries to get information from you for the 5th time this hour.
This is wonderfully naive. You can fairly easily learn to control Bob though articulated speech or just leave. Controlling the internal is the central focus of most world religions, and not being able to do it is responsible for most suffering on earth. We are mostly helpless cognonauts.
But again, controlling Bob is in addition to controlling the internal. It's additive, not a replacement of a harder thing with an easier one. And if you feel time pressure, as I often do, any time spent controlling those external distractions just leaves you with less time to work through the real issues, and thus more anxiety, such that the final level of difficulty is even greater than the sum of the parts.
Respectfully disagree, controlling the internal and controlling bob are parallel at best, they are not binary states.
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.
They might be "parallel" if there were no zero-sum time trade off, or no time pressure. I wouldn't mind so much spending time fielding interrupts all day every day, if I didn't have anything else I was trying to get done. But that's not the reality. And for me (and I think many others), it isn't just additive, because time pressure makes me anxious and less focused, which slows me down more, which increases the time pressure, which makes me more anxious, etc.
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.
You have having a wonderful time not understanding what is being said. It seems deliberate at this point.
From the article, a fair few internal interruptions are procedural, things like writing a commit message. I took a big point as being that you should design your work processes to help maintain flow.
You said this so much better than me! These were the ones I was thinking more of when writing my comment, rather than all the distractions of a noisy brain. I agree entirely with folks here that those are not in any way easy to overcome. (Though still easier to overcome in the absence of lots of external interruptions.)
Step 1. find inner peace
~It's literally that easy~
Not to just throw drugs at a problem, but I've found Lamictal really helps with internal interruptions.
I can't find any search results. Did you mean Lamictal?
yes thanks, edited.
As someone with ADHD, I concur.
But, like, why don't you just stop getting distracted? Have you ever tried that?
As a long time meditator, I’m not sure what you find amusing.
Are you saying you have more control of what other people do than your own mind? If not, what are you objecting to in saying that it’s easier to control yourself than others?
I’m really struggling not to see your comment as living down to stereotypes: vapidly smug.
After enough hours of meditation practice it becomes quite clear that one's mind is ungovernable at best. We can just hope to hold a clear intention (meditation practice in a nutshell) and return to the task whenever internal or external interruptions arise. Perhaps more and more parts of the mind will align with the intention. Hopefully the mind gets unified over time and as a result flow states can be experienced.
The person whose comment you're replying to was probably highlighting the fact that this process is not as predictable as the parent comment alluded to.
But there’s empirical results, from sports to military to meditation — you can train focus.
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.
Oh that's not what I'm saying at all.
I was recently at a meditation retreat, and a group of meditators much more advanced than me universally agreed that an apt description of their minds was "like a box of ferrets".
The illusion that you control your chain of thought vanishes pretty quickly with meditation. The reality is that your attention shifts rapidly (especially between different senses) and that most of those shifts aren't under direct conscious control.
It's almost like the facade of mental control is a sieve that tries to exclude the chaos and let something coherent flow through... And you can't even be certain how it accomplishes that. It's a mystery where the nonsense and sense even comes from, too.
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.
Your lack of discipline does not reflect a major truth about the human condition. Sorry you feel that way.
Some people like to project their problems into the rest of the population. Someone that has never achieved a major capacity to direct their attention will believe that it is not a skill they can attain. If they find someone with such a skill then they are “oh so gifted”, completely dismissing all the training and effort that said person has put into themselves. Timeless dialectic.
"My boss is always interrupting me with questions, and the office is very noisy. There's no easy fix for either of those external things, so you're lucky that all you have to deal with is internal ADHD and tinnitus!" /s
But you still have to deal with those internal issues in a noisy distracting office! Being interrupted more by other people doesn't make it easier to manage internal struggles, it is a strictly additive difficulty.
Point is, external interruptions are trivial to deal with compared to internal struggles. You can wear ANC headphones in the office and negotiate focus time with your boss. You can change your boss, or your job, or restructure your work around interruptions. Point is, you have options that are sure to work, and tend to not require much upkeep; many are just "fire and forget" fixes.
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.
I really think "trivial" is massive hyperbole here. Like most people commenting here, I have deep struggles with my own mind, I relate extremely strongly to all the things people are saying here about this.
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.
Yes, the headline term was never truly defined for use. Past the headline it didn't get used until almost half way through and then assumed you knew what was meant by it. Only near the end were there hints as to what the writer was referencing.
Good job pulling out a very plausible interpretation though. We talk about this in our dev meetings and attempt to proactively identify and resolve sources. Having well defined and coherent contexts improved our work and the emotional experiences of doing it. This has been helping me recapture the joy of coding.
Shouldn't have taken starting a company fellow business leaders.
> The frustrating thing about external interruptions is the inability to control them. [...] The good news for these internal interruptions is that it should be much easier to control them.
Interestingly, I feel the exact opposite. I'm aware that it's not always possible or socially acceptable to do so, but at least in theory you can always make a choice to ignore or tune out other people. Ignoring the stuff that is going on in your own head is IMHO much harder.
Yeah I clearly worded this poorly. What I meant to say is that it should be much easier to control only the internal interruptions, compared to the necessity to control both the external ones and the internal ones. That is, the existence of external interruptions doesn't make the internal ones go away, they're just additive on top, which can only make things more difficult.
I am under the impression that its harder to control internal interruptions. Like the quote from st.augustine, 'the mind commands the body and it obeys. The mind commands itself and meets resistance.'
I spent a long time thinking about why I always end up being the guy that people feel comfortable interrupting. I’m never the nicest guy in the office, I’m not always the cleverest, especially when I’m trying to do something else. But I do seem to recover better from external distractions than most people.
Mostly because my life is a constant struggle against internal distractions, so my coping mechanisms are more evolved.
> I think this point is a bit obscured by the article's use of this "fragmented thinking" terminology, which does not do a good job of defining before building an argument on top of it.
I totally agree with you that the article didn't explicitly define it, but I had the opposite experience reading it. For me, sans definition, could very quickly imagine what they were talking about because it started resonating for me almost immediately.
> The frustrating thing about external interruptions is the inability to control them. Things like turning off notifications and putting on headphones are mechanisms to reduce that frustration by imposing control over those interruptions.
This is partly why it started resonating for me right away. I currently share a semi-private office with another senior engineer. Lately he's been spending a good chunk of his time working on higher-level systems planning work and I've been spending most of my time working on very specific complex low-level work. The questions are sometimes frustrating because they'll interrupt my flow state, but... only sometimes. I've been chewing on that for a couple of weeks now, actually, because I hadn't yet figured out why he could sometimes ask me questions and it would have almost zero effect on me while other times it would have a massive negative effect.
The article nailed it, on reflection: the effect size of being interrupted with a question, for me, is proportional to how far away from the problem I'm working on is. If I'm digging into some of the autopilot code and get asked a question about GPS or IMUs, it is absolutely no problem to think about the question and answer it. If, though, it's a question about, say, a battery or the charging system, I'll get the "black cloud evaporating" phenomenon from the comic in the article. And it happens so quickly that by time I can even just answer "sorry, I don't have brain capacity to think about that right now" it's too late.
Regarding internal interruptions, classic Pomodoro technique (the one with a kitchen timer and a sheet of paper) deals with them this way: there is an 'interruptions' section on the sheet, and whenever an interrupting thought occurs, it's written down to that section and a dot is put above current Pomodoro. This way one is confident that no important ideas are missed and also can track the number of interruptions per Pomodoro.
Tying this to one of the author's arguments: Many internal interruptions occur because of the type of work we are doing is not right. I find myself distracted when my task is too complex, vague, or limiting. The task needs to have the right balance of difficulty and creativity to make it "flow-statable".
I agree it's an insightful point, I just wish there were more examples. As far as I can tell there's one single example, the commit message.
I use Cold Turkey to block my habbit of scrolling time-wasting sites when I should be reflecting harder on what it is needed to solve the issue at hand.
https://getcoldturkey.com/
It's almost like I need some mental space, to meditate on the solution, but that feels exhausting, so I choose sometimes to mindlessly scroll.
Any other tools that I may be missing?
An alternative is to add URLs to /etc/hosts like this to block them:
127.0.0.1 tiktok.com
127.0.0.1 www.tiktok.com
Then use ublock origin extension to pare down features on sites you still visit, and an RSS reader app to slow down media consumption.
> 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.
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.
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?
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!
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.
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!
Same, I started writing JS around 2011. Back then, even Grunt and Gulp hadn't been created yet. I was literally optimizing my files by hand, and deploying by dragging my files via an FTP client. It was tedious, but also transparent.
Software development keeps expanding in functionality and the level of detail. Twenty years ago you made a simple desktop application and that was it. Today, the same application would need to be online, which of course requires REST, authentication, load balancing, etc. You don't save information in a text or binary file, you need a database, which means object modeling, transactions, indexes, partitioning, etc. Instead of writing information to the standard output, we have log file, dynamic configuration of loggers, log rotation, infrastructure to move the logs in cloud, etc. Just editing the source code already requires several tools, including version control, which includes conflict resolution, pull requests, pre-commit hooks, etc. Nothing is ever simple; any functionality can be expanded into a separate library, parts of which will soon require libraries of their own, etc.
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.
> just feels like there's this overwhelming amount of constant change and detail
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.
For my own tech yes, I can ignore it. But for job opportunities, the unfortunate reality is that recruiters, hiring managers, and interviewers will be looking for knowledge about relevant tech. I don't want to learn NextJS, and you will not catch me trying to use it in my free time. But if one day I apply for a job that's looking for people with knowledge of NextJS, I probably won't get that job. And if it comes to pass that the majority of the industry moves to NextJS, I'm now at significant risk.
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.
> And if it comes to pass that the majority of the industry moves to NextJS, I'm now at significant risk.
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.
> The good news is, you can mostly ignore it.
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.
Does reading a dozen papers on different algorithms to accomplish a specific goal count as scavenging. Asking for me because I've gone down a rabbit hole with recent work. Not trying to be antagonistic or humble brag either. Actually not sure what I'm trying to accomplish with this question.
I think most papers should effectively just be scavenged through. In (mathematics) grad school I’ve only had time to seriously study a single digit number of research papers, but I at least feel like I gained a lot from looking through many many more than that.
John Cassian's "The Conferences"[0][1] is a collection of interviews with the Desert Fathers, and one of the subjects discussed is that of focus and concentration (a selection of excerpts was recently compiled into a small book entitled "How to Focus", a review of which was posted here on HN two months ago [2]).
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
[1] https://a.co/d/fygMduA
[2] https://news.ycombinator.com/item?id=39653517
[3] https://www.newadvent.org/summa/3138.htm
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.
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!".
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.
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.
From my experience with "specialists", internal peace of mind is not what you will get from most mental health "professionals".
Sorry, I should have been more specific - I wanted to mean by that knowing if it's ADHD or not.
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
> 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
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/
”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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?”)
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.
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.
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.
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.
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.
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
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.
Yeah so you're right about Brown not coming from the color, but I believe this was still done on purpose.
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
[2] https://www.szynalski.com/tone-generator/
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.
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.
One can rarely “schedule” flow so when a scheduled meeting interrupts flow it’s still an interruption.
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.
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.
> My advice after 30 years in the industry is: Just do your job adequately. No one at your funeral is going to eulogize your work performance.
Maybe nobody cares about your work, but there is one person that should care: you.
You are already devoting your time to work, so why not make sure that you get some satisfaction from it. A massive pay increase for something that your bosses can't take from you.
Watch any good tradie or professional, and discover what pride they get beyond the dollars paid to fix your tap or wipe your arse.
I look back on work I have done with pride. There is no-one with enough knowledge (only me) to judge the qaulity of my past work (especially because much of it was not part of a development team). Like most work done by most people, the work I have done in the past is now worthless e.g. superceded by other systems. I haven't built monuments. Only I can judge the work I have done.
I do work for others because I'm not rich enough to survive without a salary.
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.
is this really an extraordinary claim, though?
> Almost everyone, as it turns out, is wrong about flow.
For sure this one is.
No more so than "vaccinations cause autism" or "homeopathic medicine works" or "the stars direct your fate".
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.
> No more so than "vaccinations cause autism" or "homeopathic medicine works" or "the stars direct your fate".
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.
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.
“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.
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.
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.
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.
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.
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.
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.
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.
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. :)
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").
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.
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.
Don't forget to consider the sample size.
What a horrific article. At least define fragmented thinking for us and provide some sort of conclusion/TLDR for this waffle.
Yes, it repeats itself so much I kept thinking I had accidentally scrolled up.
This felt like someone trying to fill out a word count
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.
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.
Author mentions, but doesn't focus on, 'work being too challenging/not challenging enough'. I wrote a fair bit about it here (with a slightly different focus as name suggests, but I go over original research first) https://incentiveassemblage.substack.com/p/why-is-nobody-ser.... I'm not sure why 'challenge level' is less focused on compared to lack of interruptions - both seem about equally demanding to environment including manages and take similar amount of work to adjust.
Either way, to save you a click, Csikszenthmihalyi research wasn't mainly about cognitive load, because we already had a fair bit of research on cognitive load. It seems insufficient (although I do have my reservations), but addition of complexity of the task and w/e additional issues are happening is pretty solid predictor* of performance. Challenge/skill 'graph' presented can be reinterpreted with challenge/skill on X axis and a parallel flat line above it. Even better, and empirically supported, graph can be seen in first image in the post I linked, but it is a bit much to paint with words.
Flow research is cool, but there are more simple and actionable tools.
*Observant reader may notice that this is because of lack of units, but we do have physiological indicators if one desires to monitor them.
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.
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
yeah, or sometimes it just happens while I am resting, totally thinking about distractions. This is why this article is nonesense to me.
"What tooling choices...reduce lower-level thinking and optimize for higher-level thinking?"
This is the value I get from AI tools while coding.
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.
I saw two uses. Is that right?
> Now, “flow state” has all sorts of associations ...
and
> Before I started writing this article ...
It emerged from printed news. It's more than a century old.
"Boring tasks shatter flow state even in the absence of external distractions"?
They give few examples unfortunately, but the “writing a commit message” is one.
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.
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.
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.
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.
There are better uses of resources than to amortize the cost of a jira migration that may never even happen across all devs in perpetuity.
Jira always gets shut down before the repo. Often years before. For a thousand reasons. Take these two, for example: git is free, and jira is shit.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
I’m hereby coining the term “literate committing” for that. :)
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.
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.
this headline should be posted at the top of hacker news.