
The Flow Fallacy - chokolad
http://blogs.msdn.com/b/eric_brechner/archive/2013/12/01/the-flow-fallacy.aspx
======
camperman
"Flow is very important. Working in a quiet room not only removes unproductive
context switching and frustrating distractions, it also promotes the joy of
being totally engrossed in your task—a state often needed to keep all the
complex interconnections in your head."

Couldn't agree more.

"However, flow necessarily requires isolation. Isolation from design
discussions. Isolation from customer engagements. Isolation from iteration and
feedback. Instead of continuously converging on what the customer finds
compelling, you go forward alone."

Nonsense. Flow necessarily requires isolation _when you are focused on a
task_. It does not exclude team interactions, design discussions or weekly (or
even daily) customer interactions. The most productive team I ever saw had
quiet individual offices for each programmer, a daily design and status
meeting of 15 minutes and a weekly customer meeting.

"I know it’s romantic to think that one person can create an incredible
product in isolation. If that’s what you believe, stick to reading romance
novels, and stay the heck out of software development."

Also nonsense. Recent history is replete with counter-examples.

~~~
toddmorey
Exactly. Both exercise and sleep promote health. It's like he's arguing
against exercise because gyms aren't conducive to sleeping.

I think the biggest problem is that the typical office environment and
workflow is designed to promote discussion without much thought towards the
impact it can have on flow. I'll often see the calendar littered with 30 - 60
minute meetings that could be much more efficiently clustered together.

~~~
andrewflnr
No, he's arguing for setting aside time and space both for flow and for team
interaction. Did you read the part about "team hallways"?

------
scotch_drinker
This author confounds the principles in Flow which deal with how to
individually optimize your experiences throughout your life including your
work with what I call "The Joel Spolsky Flow" (not a dance move) which says
that in order for developers to produce their best work, they need to have the
opportunity to work uninterrupted for large portions of their day. These two
concepts are orthogonal.

He also seems to think that a developer working in isolation won't have the
judgement and ethical sensibility to understand what code is good for his
employer/client. This is a massive fallacy in his own article that shows a
certain bias. Any responsible developer can work either in flow or without and
still produce code that is "good for business". Any irresponsible or immature
developer can produce the exact opposite code regardless of flow.

As an aside, that book provided a fundamental shift in how I look at work. To
boil its tenets down to "Flow makes you write sucky code" is to completely
miss the point of the book in such a way as to appear disingenuous.

~~~
joakin
I just finished reading the book, and his description of it is a shame.

For anybody interested it is a great book that talks about how to achieve
enjoyment and a meaningful life in the current context of western
civilizations. It is a great book, full of insights and really good
information. Very recommended

~~~
astrofinch
Could you summarize the most valuable points discussed beyond what a typical
layperson already knows about the idea of flow?

------
MDCore
So if you value flow, if you think that getting away from noise and
distraction is valuable and lets you write good code, that inevitably means a
totalizing removal of oneself from the customer?

Perhaps the author needs to discover nuance. There is a time for coding and a
time for working with your team and with customers. Unfortunately he posits
two positions: "always" or "never" and every approach must fit into one of
those two. He has a brief flirtation with nuance, comparing a couple of weeks
to a couple of days, but quickly abandons it by declaring an inevitable
outcome.

Yes we do "win when everyone comes together, with the customer at the center",
but I don't see why one bad extreme means we need to throw out every valuable
learning about flow.

TL;DR Flow isn't bad, hiding away is. Don't confuse the two. (And put away the
hammer.)

------
oz
Umm, what?

The author makes it seem as if isolation _while_ coding necessarily precludes
one from collaborating with teammates or meeting with the customer.

But what, exactly, is so difficult in say, having a team meeting in the
morning, going off to your batcave to code, and perhaps another meeting in the
afternoon (depending on how regularly you need to meet).

He makes some good (if obvious) points, but on the whole, this article is
poor.

------
jcutrell
I agree with the notion that the customer is extremely important.

I do not agree with the idea that me being amongst my team members will
inherently make the product more like what the customer wants. There are
logical fallacies riddling the whole article, but perhaps the most important
point is that it's not black or white.

The truth is, I could be very close to the client AND experience plenty of
flow state work sessions. It doesn't necessitate that I diminish the
effectiveness of either solution. Flow state does not necessarily create sucky
product.

For the most part, the analogy of the Ford Focus is entirely off base. How
many people go directly in the opposite direction, even with a mild
understanding of the end goals and a good sense of design? A better analogy
would be that it's far better to get in the F1 and head as fast as you can in
90% the right direction than piddle along in the focus. You can course
correct, or perhaps the client will end up changing their mind a bit when they
see your solution.

Perhaps I'm missing something, but in a project discovery phase, unless the
coder is completely out of the loop, it is much more effective to let software
designers design solutions to well defined problems. If the failure is in that
discovery phase, fix that instead of forcing your programmers to perform at
less than their potential.

------
jonahx
> However, flow necessarily requires isolation. Isolation from design
> discussions. Isolation from customer engagements. Isolation from iteration
> and feedback.

Total nonsense. It requires isolation for the 1-8 hours you'll be working in
that session, maybe. In between those coding sessions, you can have all the
design discussions, customer engagements, and feedback you want.

~~~
robert-wallis
Exactly. The author exaggerates the amount of time in flow. I wish I could be
in flow longer than a day. Design discussions, feedback, and engagements can
happen every day and you can block out some time to hopefully get in flow
every day.

The big misconception the author has is that flow means blocking out weeks of
time.

------
Killah911
Bit of a link bait since he never describes why flow is a fallacy, anywhere,
or backs up his claim in any arena beyond software development. He basically
says, what people perceive as "flow" in the software development world =
isolation. Which is BS.

Csikszentmihalyi says you can achieve "flow" in many traditional jobs where
you are not alone in an office, such as cooking at a restaurant, or even
janitorial service.

There's some discussion of work environments, backed up by a McLaren P1 vs
Ford Focus example (BTW, if you drive both cars at the same speed they will
take you equal distance despite one being a super car, and even in the wrong
direction the McLaren could get you closer to your destination, so the quote
is kind'o crappy too)

Alas, in my book, link bait! No discussion of actual "flow" here... just some
dude peddling his ideas using Csikszentmihalyi

------
qwerta
If all you do are simple CRUD web pages or apps, then flow is fallacy. However
not entire industry is like that.

(I hope) my product is pretty innovative, but it required long sessions of
uninterrupted concentration. Sometimes I would be 'in the zone' for days, and
my family complained I was like zombie.

I already gave up on 'dynamic companies' and now I work (almost) exclusively
from home. There is always new excuse not to give software developers private
office.

------
hseldon15
This article is pretty far off the mark. In a study on Flow in relationship to
virtual teamwork they found:

"...that flow is associated with positive team work outcomes in a virtual
learning team and that facilitating flow experience in virtual team may bring
positive changes in team effectiveness."

[http://www.academia.edu/215200/An_Investigation_of_the_relat...](http://www.academia.edu/215200/An_Investigation_of_the_relationship_between_Flow_in_Computer-
Mediated_Interaction_and_Virtual_Learning_Team_Effectiveness)

------
tehwalrus
> _" However, flow necessarily requires isolation. Isolation from design
> discussions. Isolation from customer engagements. Isolation from iteration
> and feedback."_

This is nonsense.

Flow doesn't require you to ignore the specs, or the customers. It means
allowing you to work in long enough bursts over the day that you get a couple
of really good, substantial things done in those bursts, before you break to
check up on emails and other "distractions".

------
Supermighty
> Because the goal of commercial software development isn’t to create code you
> love—it’s to create products your customers will love.

The two are not mutually exclusive.

~~~
girvo
Of course not, but in my professional experience, often times it is :(

~~~
jh3
Is your sadface implying you are saddened by the lack of love you have for the
code that creates products your customers love?

~~~
girvo
Yep. The products have been cool, the codebase monstrous. Painful legacy stuff
mainly.

"Architecture, what architecture?"

But then, contracts for it were in the $millions range, so it was an
experience!

------
strictfp
I think he's right. A culture where flow is encouraged is bad because the risk
of going down a rabbit hole increases enormously when in the zone. This makes
it an inefficient way of working.

I like to compare solving a programming task with navigating to a goal. Being
in the zone is the equivalent of going really fast. Speed might be good in
general, but it's really useless if you're going in the wrong direction.
Navigation skills are in fact a whole lot more important than speed.

In solving programming tasks you have to be smart - try to find shortcuts, ask
interrogative questions about the requirements to avoid unnecessary work,
check with your colleagues if someone has already done something similar, find
libraries which will help you solve the task etc.

So being in the zone is in my world just a sign of someone who's probably in a
hurry and/or isn't working strategically.

The only exception to this rule is when you're pair programming, because then
you have a co-driver who's handling the navigation, so you're allowed to focus
on going fast.

------
anon_java_hater
Real business thinking. You can't make a product yourself, you inexplicably
need a bunch of other people around doing stuff for it to work.

> I know it’s romantic to think that one person can create an incredible
> product in isolation. If that’s what you believe, stick to reading romance
> novels, and stay the heck out of software development.

This is the only fallacy I could find mentioned in the article.

------
hibbelig
Communication allows you to learn what software to write. Flow allows you to
write it.

Where I work they are all communication and no flow, and that's terrible. I
wish we had more flow.

------
wolframarnold
Some people report that they can get in a state of flow while pair
programming. I've experienced this on occasion but I'm unclear on what the
exact ingredients are to produce flow while pairing. A big bonus with pairing,
however, is automatic and real time code review, architecture review and
perhaps even product review. Two people together are a lot less likely to run
into the wrong direction _together_ than a single coder.

------
codementum
Flow, in the cognitive sense, could very well be directed towards a customer-
focused end. This article's central argument is a fallacy.

------
tmilard
I also believe this article is poor. Mixes two disfferent things : 1) Metting
: Clear decision for developper (with customer validating, agree with team,
ect) 2) Focus : Be alone, quit, focus on the difficult task/dev --> Flow

Two things are ok. Not opposite. We can see this guy is no developper at all.
Not at all !

------
dsirijus
Flow got to be a buzzword mostly to credit of Jenova Chen's (of
Thatgamecompany) master's thesis and subsequent game influenced by it -
_Flow_. It happened at around 2007. At least that's my perception of it.

It is mostly associated with games (this meaning of the word anyways),
especially where exposition of new challenges and use of skills already
acquired in-game as to become mechanical are so neatly balanced and tuned to
the individual gamer that they tend to evoke a state of _flow_ , commonly
described as "parahypnotic" state.

If I had to stretch the analogy to development, especially programming, I'd
had to stretch it very far, like the article seems to infer. Your programming
flow is, in this analogy, wholly dependant on the actual challenge you are
facing (over which you mostly don't have control of), and more or less has
nothing to do with you trying to "get into the flow" really.

I agree that it's a fallacy albeit from a different point of view.

~~~
aestra
Flow is not a buzzword. The concept of flow was introduced by Mihaly
Csikszentmihalyi in his book Flow: The Psychology of Optimal Experience. It is
a known concept in psychology.

It is achieved when skill level is high and challenge level is high.

[http://en.wikipedia.org/wiki/Flow_%28psychology%29](http://en.wikipedia.org/wiki/Flow_%28psychology%29)

Flow is the mental state of operation in which a person performing an activity
is fully immersed in a feeling of energized focus, full involvement, and
enjoyment in the process of the activity. In essence, flow is characterized by
complete absorption in what one does. Proposed by Mihály Csíkszentmihályi,
this positive psychology concept has been widely referenced across a variety
of fields.

Flow theory postulates three conditions that have to be met to achieve a flow
state:

    
    
        One must be involved in an activity with a clear set of goals and progress. This adds direction and structure to the task.[11]
        The task at hand must have clear and immediate feedback. This helps the person negotiate any changing demands and allows him or her to adjust his or her performance to maintain the flow state.[11]
        One must have a good balance between the perceived challenges of the task at hand and his or her own perceived skills. One must have confidence that he or she is capable to do the task at hand.[11]
    

However, it was argued that the antecedent factors of flow are interrelated,
as a perceived balance between challenges and skills requires that one knows
what he or she has to do (clear goals) and how successful he or she is in
doing it (immediate feedback). Thus, a perceived fit of skills and task
demands can be identified as the central precondition of flow experiences.[12]

~~~
collyw
I remember around 12 or so years ago, the concept of being "in the zone"
appeared (in the mainstream) and was talked about in relation to athletic
performances. Since then the term seems to have been more and more loosely
applied to more and more subjects. As such I think the meaning of the term has
been lost to an extent (the way I understood it as applied to sports). I mean
does programming actually have "clear and immediate feedback"? Most of the
time it doesn´t even seem to have "a clear set of goals and progress" in my
place of work.

The way I look at it "riding a bicycle" could fit the description given above.
But I would see a world cup downhill mountain biker as being in flow. As such
not everyone will achieve a state of flow, so many people will use the term
without having actually experienced it.

For programming, maybe uninterrupted concentration would be a better term, or
maybe I just haven achieved a state of flow while programming, whereas I feel
I have in some sports.

~~~
aestra
It really depends on the person. People are different, some may get flow from
coding and others from knitting. An important point is to achieve flow you
have to find what you are doing intrinsically rewarding. It is really ok that
some people don't get flow from coding, and some do, but we shouldn't expect
everyone to.

There's even a checklist for "have I achieved flow?" so you know.

Nakamura and Csíkszentmihályi identify the following six factors as
encompassing an experience of flow. [3]

    
    
        intense and focused concentration on the present moment
        merging of action and awareness
        a loss of reflective self-consciousness
        a sense of personal control or agency over the situation or activity
        a distortion of temporal experience, one's subjective experience of time is altered
        experience of the activity as intrinsically rewarding, also referred to as autotelic experience
    

Those aspects can appear independently of each other, but only in combination
do they constitute a so-called flow experience.

------
blueblank
A very poor understanding of psychological concepts of flow.

------
ChristianMarks
The author should disclose whether he was interrupted while writing this
article.

------
olgeni
It started with the "agile" cargo cult, and it continues...

------
just2n
Eating is good. I love eating. I eat all the time, because I'm a human. There
are even studies that show that eating is good for your health. It can even
keep you alive.

But did you know that even though eating is good for you, it's also bad for
you? If you eat constantly, you can become obese. You are at risk for heart
disease and diabetes.

Therefore you should not eat.

Did I do it right? I like this style of blog writing.

