Does anybody else find that statement controversial?
Does anybody else find that statement controversial?
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.
c) the person is dead
d) the person is doing breathing exercises
e) the person is relaxed, not asleep, and not pretending to be either
f) the person is in a psychoanalyst's couch
Similarly, one can be typing about for a thousand reasons, none of them about flow. Or one is in a stare of flow drawing boxes or just thinking.
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.
the preceding minutes trawling logs, filling my head with events, and connecting all the dots is the unstable part i need to keep in my head
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.
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...
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.
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 know if this is a good measure or not, but it's fun to build and use.
I'll try it for a few months and maybe post my thoughts.
And editor typing detection is the perfect place to start.
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.
For me, a large part of flow is understanding the problem enough that I can jump in and go.
It may no longer be a fashionable term but it has been used by native speakers.
Examples:
https://en.m.wikipedia.org/wiki/Programmer%27s_File_Editor
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.
And the ngram of "programmer's editor" speaks for itself: https://books.google.com/ngrams/graph?content=programmer%27s...
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.
* Chef's Knife
* Painter's Palette
* Carpenter's Toolbelt
* Teacher's Guide
...
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.
Yes it's an unnecessary qualifier. But so what.