"The easiest way to detect if a person is asleep is to see if they're lying down with your eyes closed."
This is clearly not always true.
However when that's false, it either
a) the person is trying to fall asleep
b) the person is pretending to sleep with no intent of actually sleeping
It's often said that in order to fall asleep one has to pretend to fall asleep first.
I think the programming flow is similar. You may not actually be in that state yet, but it doesn't just come to you unless you actually do some programming while not in the flow yet.
Part of being on autopilot and in flow for many people might be thinking about/solving/planning what you will do next while you are writing code for the last item…
I find this especially true while working on data science tasks - slicing and dicing data, visualizing, fitting initial models, etc - things where the larger more complex data generation pipelines are already taken care of and the data (or temp data/subsets of data) are readily available and you are free to rely on the improvisational skills you have developed working on similar data science tasks countless times over.
Also feel something similar when working on frontend wireframing/laying out and styling dashboards with no reference design.
Anyways, point is, it’s definitely feasible to enter into a flow state where you mind is a few steps ahead of your fingers and is actively solving problems that your fingers catch up to.
Exactly. And this has very little to do with the concept of flow except for the relative end of it with no quantification of the flow that may have come before it.
Not controversial, but simplified. My flow comes from working out problems on my notebook (pen and paper). Typing into the editor is the outcome of my flow process. This aso applies to my writing. I figure stuff out on paper and then put them on an electronic document. Works for me as I need to think while scribbling notes while doodling on the margin.
For me personally, I think it is the case. I like bottom up approaches, starting from technical details and working up to the global structure, it means I spend most of my "flow" time writing and rewriting code. It means lots of typing, even if most of it doesn't become production code.
Others seem to prefer to start with the big picture, maybe with a pen and paper. So less typing but proportionally more of that typing becomes production code. So, for them, typing is probably not the right indicator.
Is it controversial or just something we can all agree is wrong?
I think a better metric is how fast I'm switching between things. Logs, Slack, editor, something else: if the monitor's flashing like crazy as I go back and forth trying to tie things together...
> Is it controversial or just something we can all agree is wrong?
It's certainly not something we all can agree is wrong. For me, the author's metric is reasonably accurate. If I'm typing, I am almost certainly in the zone and I will lose it if someone disturbs me.
Well I imagine we can all agree on that (too). I meant that it's incomplete; I suppose the original is ambiguous as to whether it means a rough 'sufficient and necessary' way, or merely a rough 'sufficient' way.
It's definitely rough regardless (I spend non-'flow' time in the editor) but people are largely objecting to the perceived idea that it's necessary to be in the editor.
I don't find it controversial. I think it's a decent heuristic that's simple to implement. It would be pretty trivial to extend this with other heuristics, like how often commands other than self-insert-command are ran, their frequency and duration. Then the author, if they wanted, make some classification model with their lossage. Add in a few manual toggle keybindings (maybe with some numeric options to set duration as well as some defcustoms), org-mode clock-in integration, pomodoro integration, calendar integration (like with org-caldav) for setting status during meetings, slack notification setting updating, and I'd say you'd have a pretty thorough implementation.
And editor typing detection is the perfect place to start.
It also does not say that is the only way. Just that it is the easiest one. Some one is actively writing lot of code. Seems to me factually true. If someone is writing code consistently at good effort they probably are in some kind of good state, might be flow or might not.
> Does anybody else find that statement controversial?
No. But even if programmer's want flow, it is not what they need for their work to be done. Prototyping something and butting heads against a bad documentation or trying to find a way to manage something is not flowing, to the contrary. But it is your job.
If all you want is typing almost mindlessly there are tons of typing game to get in the flow while the "AI" replaces you.
maybe replace typing with, 'has editor in focus', /maybe/ 'editor | docs' because of course I may be idling while in the flow, but as soon as I've tabbed over to stack overflow its because something isn't working and it might actually be a good time to walk off for 5 minutes and come back to it.
The phrase "their programmer's editor" is wrong and so malformed that it's essentially nonsense. It's clear what the author is trying to say, but that's not what the text actually says. "Their programmer's editor" translates to "the programmer's programmer's editor." That is, there are two possessives, which means that "programmer's editor" is being used as an expression, a noun phrase, by itself. There is no such thing as "a programmer's editor." That's not idiomatic English. So it's either not written by a native speaker or is sloppy, awful, incorrect writing that deserves a barrel of red ink, a failing grade, and a paddling, because a native speaker should know better.
I'm not just confident; I'm saying it is objectively true and demonstrable that (a) "their programmer's editor" is a solecism and (b) "programmer's editor" is equally wrong by being clunky, unidiomatic usage that any competent editor would mark as incorrect.
I assume you see that "their programmer's editor" is obviously wrong, so I'll skip it.
Finding a product named Programmer's Editor doesn't support the claim that "programmer's editor" is natural, normal, idiomatic English (and the author of the program by that name, in addition to being weirdly incapable of even correctly defining "programmer," isn't clearly a native speaker). Quite the contrary. You wouldn't name a program Code Editor, IDE, Editor, or Text Editor, just as you wouldn't name a company or a line of products Computers, because these are too generic to be used as proper nouns.
To the best of my knowledge, at no time in the history of English has "programmer's editor" been idiomatic English, either inside or outside of the world of software and engineering. And today, in late 2024, it is unarguably incorrect usage, regardless of its history.
They are all terms that work in a similar way: they qualify the name of a tool or object by the profession of who's using it.
The qualifier mattes. A Teacher's Guide is not just a guide that happens to be owned by a teacher.
A chef's knife is not whatever knife a chef happens to be using.
The reason this feels outdated or "wrong" when applied to the job of "peogrammers" very likely has less to do with English grammar or whether "programmer's editor" per se is idiomatic or not rather than the fact that the name "programmer" to denote the profession of who writes computer programs has fallen out of favour.
Take a quick look at LinkedIn and you'll rarely see people using the title "programmer" and rather use "developer" or "software engineer". Some people even use "builder".
The words "developer" and "builder" are still actively used on some parts of the anglosphere to denote people who build buildings.
The demise of the word programmer is interesting. Is it because it got associated with a boring cubicle job, devoid of any creativity?
In any case, within a given profession you don't quite need the qualifier.
Chefs will ask they colleagues to fetch a knife, not a Chef's knife
A painter will grab a palette, not a painter's palette.
The professional qualifier is obviously redundant when you're talking inside the circle of a given profession. So it's entirely expected to "sound weird" if we refer to an editor as programmer's editor when we're in a forum of software developers.
My point is that it's not wrong in the sense you're making it out to be wrong.
If we rephrase the scenario as:
"The easiest way to detect if a person is asleep is to see if they're lying down with your eyes closed."
This is clearly not always true.
However when that's false, it either
a) the person is trying to fall asleep b) the person is pretending to sleep with no intent of actually sleeping
It's often said that in order to fall asleep one has to pretend to fall asleep first.
I think the programming flow is similar. You may not actually be in that state yet, but it doesn't just come to you unless you actually do some programming while not in the flow yet.