The autotelic programmer

September 18, 2019

This article is the first of a series of articles inspired by my reading of Flow: The Psychology of Optimal Experience, by Mihaly Csikszentmihalyi. In the current instance, I will focus on the notion of autotelic personality, and see how it applies in the particular case of the programmer. My goal in this article is to show how, by pushing the programmer to set goals and renew her challenges, she can become more fulfilled, and hence happier. We will call Flow such fulfillment and enjoyment.

Comfort and boredom

You may feel bored doing your everyday tasks. Or perhaps not even bored, but just feel very comfortable doing them. Csikszentmihalyi is arguing that neither of these sensations are conducive to Flow, even though comfort is undoubtfully more desirable than boredom.

For instance, if you are a web developer using a MVC Framework (say Django or Ruby on Rails), you might at some point become too comfortable, or bored of repeating the pattern corresponding to creating a view: create the view per se, add an url, add a template, and so on. This of course is an extreme simplification of what it means to work in those web frameworks, and repeatitivity is not specific to them. My point is that regardless of your tasks as developer, there is a risk of repeatitivity which can either lead to boredom or too much comfort.

Generally speaking, Csikszentmihalyi has developed a model illustrating this need to have an adequation between skills and complexity. I will discuss this in a future an article. Now, how do we escape boredom or excess of comfort ?

The autotelic welder

In the book, Csikszentmihalyi gives the example of this welder who refused to get promoted and hence stayed in the lowest rung of the hierarchy in his plant. The reason for this was because he enjoyed performing every phase in the plant’s operation, and as a result mastered every single one of them.

This welder can be said to have an autotelic personality. Autotelic comes from the two greek words autos, which means self, and telos, which means goal. Namely an autotelic person can turn one activity into an autotelic activity, that is a an activity with no other end than itself. Simply put, an autotelic activity is done for its own sake, not in the expectation of external rewards (such as fame or money). The welder performs his tasks not for extrinsical reasons (though that might have been the case in the beginning), but because he founds them intrinsically rewarding. Such persons can experience flow more easily than others.

How can the programmer take example from this welder to experience Flow ?

The autotelic programmer

In the book, Csikszentmihalyi gives 3 rules in order to help you develop an autotelic personality. The first one is to set goals. As a programmer, you can for instance set learning goals. Much like the autotelic welder undertook to master every phase in the plant’s operation, the programmer could decide to further increase her knowledge of her tools, and find better ways to perform the same task. In the case of a MVC web framework such as Django, it could be like:

  • Level 1: learn how to write a view.
  • Level 2: write a custom routing logic.
  • Level X: write your own web server (not for using it, but for reaching a higher level of comprehension of the tool).

This is of course an arbitrary example, whose idea can be adapted to whatever piece of technology you are using.

The second given rule is to get immersed in the task. This means not allowing distractions to prevent you from focusing on the task at hand. In the case of the welder, this could mean not being interrupted when trying to fix a broken machine. In the case of the typical 2019 developer, this can mean not consulting his email box every 5 minutes, or turning Slack off for a given chunk of time. My humble opinion is that the cognitive and emotional costs associated with the nearly permanent availability which often accompanies those communication means are underrated. On the over hand, the gains related to the associated serendipity, promoted by the startup culture, are overrated (Cal Newport has a lot to say on this topic, in his book Deep Work).

The third rule is to pay attention to what is happening. In the case of the welder, this can mean noticing that there is a defect in an electric monitor, and set out to fix it. As for the autotelic programmer, she could pay attention to her environment to find out how such and such improvement could make things better. There is a bottleneck in your build pipeline ? Then invest time on it, and, for instance, parallelize it. Non technical people of your company keep wasting time in repetitive chores ? Try to see if you could help them by automating these chores.

Final word

Applying the aforementioned rules can be a strategy for the programmer who wishes to escape boredom or comfort, and reach a Flow state. As a reminder, those rules are:

  • Setting goals.
  • Get immersed in the task.
  • Pay attention to what is happening.

If you are not afraid of a long read, I can only recommend reading the book. Alternatively, you can get the gist of it with this TED talk. I’ll probably release more articles on this topic.


Profile picture

Written by Vincent Perez, a polymorphic software developer.