The Flow Fallacy | Hacker News Reader

The Flow Fallacy

blogs.msdn.com

67 pointschokolad39 comments

"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.

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.

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"?

To be fair to the original article, the author does point out isolation is helpful 'when you are focused on a task':

"As for flow, it works best when there is a specific, narrowly scoped piece of code that must be written. For that work, being in a quiet place free from distraction is ideal. Just don’t stay isolated too long"

I don't see much to disagree with there. I think the point of contention is on what should be the default work environment: an open plan office with "concentration rooms" here and there or individual offices and occasional meetings. I don't believe there will be a definitive answer, it depends on team dynamics and company culture.

Fair enough.

"As for flow, it works best when there is a specific, narrowly scoped piece of code that must be written."

But this is also not necessarily true. A state of flow is very desirable when doing experimental or exploratory creative work of any kind, not just programming. If you're doing something you've never done before but it's not too far out of reach, then you can most definitely enter a state of flow. Too far out of reach and anxiety kills the state. Not challenging enough and you don't get absorbed enough to enter it in the first place.

‎Csiksczentmihalyi's book identifies eight major components of flow:

1. We confront tasks we have a chance of completing; 2. We must be able to concentrate on what we are doing; 3. The task has clear goals; 4. The task provides immediate feedback; 5. One acts with deep, but effortless involvement, that removes from awareness the worries and frustrations of everyday life; 6. One exercises a sense of control over their actions; 7. Concern for the self disappears, yet, paradoxically the sense of self emerges stronger after the flow experience is over; and 8. The sense of duration of time is altered.

I don't think I've ever got into the flow state when just banging out a specific, narrowly scoped piece of code. It's just grunt work. It has to be done sure, but for me personally, it doesn't provoke the loss of time or complete absorption that experimental or exploratory work does.

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.

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

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

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.)

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.

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.

> 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.

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.

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

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.

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...

> "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".

> 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.

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

Maybe I'm being overly optimistic. Where I work we rarely output code that is beautiful and lovely at the expense of creating deliverables on time. I blame our process. I think that we could do both if we adjusted a few of our assumptions. But then maybe I'm just a daydreamer.

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

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!

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.

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.

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.

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.

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

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 !

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.

The concept of Flow was coined decades ago, and applied to software development more than a decade ago.

Getting in the flow doesn't necessarily mean that you can force it, just that you enable it by removing impediments, such as distractions, since absolute concentration is a precondition for getting in the zone.

Flow, under the name of flow, was applied to software development in the 1980s in the book Peopleware.

It may go farther back than that. But that's as far as I know about off of the top of my head.

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

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]

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.

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.

Loved that game and it does a good job at "explaining" flow. But the concept is way older than Chen.

http://en.wikipedia.org/wiki/Flow_(psychology)

A very poor understanding of psychological concepts of flow.

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

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

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.

Reply on news.ycombinator.com