Learning and Flow
Go.  With the Flow...

Learning and Flow 

The allure of really learning something has been well recorded [1].  Software developers, in creating something that has sparse physical presence, are working almost exclusively in the knowledge domain.  This means that, as they design, code, and test, they are creating knowledge.  Since another word for "creating knowledge" is learning, their primary function is to learn. [2]

In earlier times, the results of this learning would have been stored initially in someone's brain, perhaps followed by instantiating the knowledge in some physical object or machine.  Important knowledge that needed to be retained over time would have been committed to paper.  Knowledge needed by others may have been passed through the brain-to-brain mechanism of speech.  

In the modern era, almost all such learning will inevitably be stored in some software form...

...But it still requires learning. 

As we have already seen, true learning occurs outside the Comfort Zone.  Provided the learner is not so far into the Incompetent/Anxious Zone or, if so, has the ability and willingness to recognize the feeling of incompetence [3] with its associated anxiety and the fortitude to tolerate these feelings, then learning will occur.  The sometimes intense response that occurs when something radically new is learned and a previous lack of ability is replaced by true expertise, can be invigorating.   When this expertise is accompanied by a clear demonstration that proves it [4], a person can find themselves achieving the state of Flow described by Professor Csikszentmihalyi.

Not only are peoples' levels of performance increased enormously when in this state, their sense of satisfaction and achievement is also reported to be very high. 

Given that achieving this state of Flow results in much higher levels of:

• Productivity

• Quality of results

• Motivation and investment and

• Sense of satisfaction 

One would think that helping their employees get into and stay in the state of Flow would be one of the top priorities of any modern business.

It is not.

FOOTNOTES 

[1]    In general in Csikszentmihalyi, M. Flow: The Psychology of Optimal Experience. Harper and Row, 1990.  For software developers (in particular), the two top motivators are creating something and learning new stuff (as described in eg.  https://michaelscodingspot.com/motivation-of-software-developers/ and Couger, D. J. and Zawacki, R. A. Motivating and Managing Computer Personnel, John Wiley & Sons, (1980).).

[2]    Many years ago I ran a 2.1/2 day workshop for senior executives: CEOs, COOs, CFOs, Directors, etc., of technology companies that have suddenly come to the realization that they had become, in fact, software development enterprises.  While their putative product line might be radios, telecom switches, servers, relays, etc., what actually performed the work was embedded software developed by their engineers.  This occurred for many companies in the 1990s and 2000s.

At that time the typical executive managing these enterprises had very little experience or knowledge of what it takes to build software.  Having risen through the ranks from electrical engineering, mechanical engineering, manufacturing, sales, and accounting, these executives knew about these domains, what they needed and how they worked.  But not software development.  Hence this program.

The workshop included a section where teams of executives spent a day actually designing and coding a system (!).  The net result was awful.  Despite the fact that a fully functional system to specs could have been built in a matter of  hours, the execs spent most of the time "playing" with the code to see what it could do.  I pointed out to them that, prior to this workshop, none of them had any experience in coding.  "Playing" with the code was in fact a highly effective way to learn--to acquire knowledge in the area where they had the most ignorance.  

I wrote about this experience in the article When Executives Code Communications of the ACM, Vol.47 No.1 January 2004

[3]  Not recognizing one's lack of ability or unwillingness to own such is described by the Dunning-Kruger model.

[4]  Of course, the ability (or knowledge) has to be proven to conform to the definition of Zeroth Order Ignorance (0OI)