"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 it helps any, I wrote "programmer's editor" because I was trying to disambiguate between things like emacs and ms word. I'd consider both editors, but I find it much easier to write text documents meant for human consumption.
I work from home. For a while, I was using Focusmate to keep me on track, which worked very well. I implemented something similar using a standard smart bulb connected to Apple Home, and then I just controlled it using shortcuts and Hammerspoon such that it would turn red when my webcam was active, and turned off when it wasn't. I mounted it in a normal lamp outside my office door. It worked really well to reduce family interruptions when I was trying to work. I haven't been doing this for a while now, but I'll probably come back to it at some point.
Yes that one, and yes it’s a real human. I don’t think it would work as well with an LLM, something about there being a real person there helps immensely with accountability. I’d encourage you to try it out if the idea is interesting, it’s nowhere near as weird as it sounds and it really does work for keeping you focused.
It looks like this service may be intended to have a significant off label use as a professional networking / online matchmaking app, judging by the choice of human pairs given in the stock images on the website. They're all male/ female pairings of similar age groups.
It's curious that the list of suggested activities includes conventional headshot-framed work activities as well as full body view stuff like exercise routines.
That seems like a stretch to me from the landing page, and is absolutely not my experience from using it. It’s also explicitly discouraged in all their documentation, e.g. this is from their FAQ:
Can I chat with my partner?
No. Talking with your partner is only allowed at the beginning and end of your session. At the beginning, you’re encouraged to say hello to your partner and share what you plan to work on. At the end, you should check in and ask your partner how the session went. If you’d like to talk to your partner more, you can suggest or offer it at the end of your session. Please bear in mind, no selling or propositions (business or otherwise) are allowed during Focusmate sessions.
Productivity interruption and destruction systems (teams, slack, zoom, email, etc.) along with quick responses to same are mandated by most workplaces. Disabling such interrupts typically triggers alarms and a stern lecture from management.
I don't know the specifics, but we already collect the time people spend coding for productivity telemetry, so we already have that signal. I assume the team that maintains our chat system either hooks into an editor notification, or into the Kafka-like event queue that feeds into the data warehouse. It likely only works if you're using the officially blessed IDE, but very nearly everyone does
if you are good at this and can’t find a job, you got some major, major issues as jobs at companies like ones described above are not something you should rely on in any way in your life. so it is better for you to run than to be discarded
I'm pretty average at it and have a shaky work history because of health problems. If I felt like I had better options I'd take em. What I need is a union.
The first thing I do in any fresh Teams installation is to disable all notifications, except maybe for voice calls. Then I check for new messages maybe once per hour. I would have gone crazy otherwise.
Yeah, that's why I think all this talk is really silly and a waste of time. Management simply does not believe in "flow" or the need for deep concentration. If you actually need to concentrate deeply to get your job done, you're going to fail in most workplaces today. The best you can do is to try to find a way of getting enough work done, despite the noisy open-plan office environment and constant distractions. The days of walled offices for programmers are long gone, and they're not coming back.
For me, at least, flow is about the ability to focus on a problem and really see (almost touch) all of the pieces that are or should be. Flow is not just using an editor. If it were, it would be easy to force people into flow.
KISS. You can just use a "cone of silence" spell...
... that is, take a A4/letter blank piece of paper, fold it like a cone and tape it down, then take a red large-tip marker and write "SILENCE!" or "BUSY" on it.
You can put it upright/on-the-desk when needed, and down/in-a-drawer otherwise.
Does anybody else find that statement controversial?