Some remarks on programmer well-being
When browsing the internets for coding knowledge, most of the resources are centered around the theory and practice of coding but not so much on the practical exercise of coding. While exercising our main activity, coding (in a broad term, from understanding specs, communicating with project managers and colleagues to designing test), we, of course, are working. Yet in this work, we want, as the next man / woman, to enjoy ourselves as much as possible. Since working for a company that preoccupies specifically of the notion of well-being, I thought that I could gather some ideas relative to well-being in our activity of programming. So what can be a very short and (hopefully) pertinent definition of well-being? We can picture well-being as a three-headed beast, with a subjective, intersubjective and normative aspect. It is a subjective and durable feeling which has both mental and physical / medical origin (both physical and mental being interrelated). it colours our actions in the course of our interactions with others in the world. it’s increased or decreased when we evaluate our life as a whole. It’s comparing our life as it is to how it ought to be by referring to objective values (such as autonomy, and meaning or purpose) and subjective intents or desires. If these three aspects are positive for a person, we will say she / he has a high well-being. The most salient part of this view of well-being is that it is dynamic. Our subjective feelings influence our actions and how we act of course influence our feelings. Another point: our actions and feelings are one of the main constituents of our life and greatly impact how we will evaluate it. Thus it is clear that the three aspects of well-being are causally connected. On this point, it is worth mentioning the works of the philosopher Michael Bishop. Now that we have a partial yet working definition, how can we apply it to working conditions, and in particular to programming?
Concretely, each development task is not an atom, it will be part of a sprint (in an agile work method) and will be communicated either directly by the project manager or via an issue (e.g. on Github or Jira). At the issue level, several factors can, I think, influence the programmer well-being : the clarity of the issue the intended outcome / output should be unambiguous to prevent cognitive stress a minimal degree of adhesion with the goal of this task: it has a meaning, it is useful for the project. By doing it, I will contribute to the project’s advancement ; so I do something that matters. Thus it can improve my sense of commitment and belief in the importance of my work. completeness of the task (are all pertinent use cases taken into account?, all necessary information or assets? business rules?). It is essential to prevent indecisions, working partly in vain or necessity to do again and again the same task. conceptually atomic: it will help the programmer for planning the future development. Of course it might not be possible for some issues.
The task in itself
In order to highlight the well-being of the realization of a task, I think it is enlightening to see it through the lens of the flow theory of Mihaly Csikszentmihalyi. It is described as an intense focus on the activity and nothing else, which brings a psychological state that is empowering and helps the user to continue on his task without any other stimulus or influence. Let’s examine the constraints that are necessary for a flow experience in a programming context: there should be a balance between the skills and knowledge of the developer and the challenge of the task. If at each step I have to read for several minutes a library documentation, to read stack overflow answers, or if I don’t have a precise knowledge of the project I am working on, it will be very hard to start a flow experience, it will probably generate anxiety while a reasonably challenging task in a more familiar context can create a flow state. there should be a clear goal and a sense of progress. For the first part, the content of the issue is decisive. For the second part, it’s up to the programmer to divide the task into subtasks in a kind of todo-list in order to concretely represent work advancement. the task should have a clear and immediate feedback. This point can be easily realized in some cases, e.g. creating a login form, you create a template, work on a script to handle interactions, reload the browser and see the result on your result almost instantly, which allows you to adjust your code if necessary. The longer the feedback loop (coding, compiling, result on screen), the harder it can be to preserve a flow experience, even with a very high knowledge and adequate skill in the technology used.
A flow inducing task / problem will require beforehand a careful planning, deep knowledge of the project and the tools in use, then working on the algorithm and finally implementing it in the clearest and most efficient way. The planning, algorithm and implementation will all require creativity, adaptation, research but will not be too outside of our coding knowledge
Preserving focus on the task
Before engaging in the the flow state, it is necessary to be able to focus on the task at hand and nothing else. This can be more or less hard depending on the workplace (open space or not, noise and agitation or calm, etc.). Of course some developers might have a difficulty to work in a too calm setting but in my experience, most of the time we tend to prefer a calm workspace versus an overactive an noisy workspace. Listening to music to help us to focus is very common in this respect in my experience. Another important factor we have to take into account here are of course distractions emanating from our computer. A programmer like most team members in an IT firm, is part of a communication network consisting of (mostly) emails and channel discussions or direct messages (in Slack or Facebook pro typically) - since we focus on work here we will not talk about external personal messages but of course they can have an impact. Inside this network, the programmer has to a minima follow the hot subjects to gather information and potentially intervene in a discussion if necessary. This is like a concurrent process regularly called which can disrupt a pending task and reduce focus on the task at hand.
The flow benefits
Achieving the flow state can be very hard and elusive for many reasons. Yet the benefits are numerous but can be summed-up in one expression, intrinsic motivation. Once in a flow state, the activity becomes a goal in itself (a praxis, i.e. an activity which have its goal in itself as opposed to a poises which has as a goal an external produce, see for example 1140 b 1-5 paragraph of Nicomachean Ethics, Aristotle). This is a considerable plus since it contradicts the utilitarian insistence on results only over the actual activity. If we want to increase intrinsic motivation, we have to take into account the context and the coding activity in itself and not only the shipped feature. As I wrote this paragraph I was considering focus and flow as only a positive, well-being boosting factor. Yet, interestingly, considering it in such a way, is an example of one a psychological fact I would like to emphasize now: it is a case of cognitive tunnel effect. Sometimes, too much focus and concentration on one task only can yield to forgetting very important aspects. Going back to our working definition of well-being, we could say that the subjective part of well-being takes too much importance over the intersubjective and evaluative aspect. For example, let’s imagine a coder which starts to work on an issue, quickly enters a flow-like activity, and starts committing as if it’s life depended in it. After two hours of intense and satisfying work, she / he starts considering the unit tests and then, oh my, a big problem arises: the code in itself is very good but is dependent on a particular technology / library that while previously reliable is now close to being deprecated. Fun fact, as I am typing this I realize that it’s past 10pm and I don’t really know how and what I am going to eat… While it can be tempting to keep searching for the elusive flow state by making commit after commit, it can be, in my experience, more subjectively beneficial to alternate production tasks (commit and pull request) with analytical ones (code review). Here the subjective and intersubjective aspects of well-being are clearly in evidence since code review is an exercise in analysis involving ideally rigour, thoroughness as well as empathy and good communication with the reviewed.
External and internal motivation, very short thoughts on a past debate in Github
As a programmer we are more or less familiar with gamification, by using a tool such as Github for example. An interesting fact in the history of Github that pertains to our argument is that there used to be a commit streak feature that counted the number of continuous days with a pushed commit and no interruptions. This gamification feature had supporters as well as opponents, as seen in this rather long issue posted on Github. I will only evoke two salient facts here: some people found it motivating and thought it helped them forming a habit which they found healthy and good for their well-being. Others claimed that, on the contrary, it was, first, a false representation of your commitment, second, it could be an incentive for fragile and stressed people to be even more stressed by continuously working (to not break the commit streak). What we can get from this debate (which was concluded by Github removing the feature with no clear consensus), is that external motivation can indeed have an impact on programmers well-being. The problem is that it must be used with great care and probably be optional in order to be tunable to the needs of every type of programmer.
Short bibliography and resources
The origin of this article was the discovery of the very interesting initiative of selfcare.tech which proposes resources for the well-being of programmers.
- Mental Health in Tech: Guidelines for Mental Wellness in the Workplace, OSMI. An interesting study with concrete advice.
- bluehackers.org: a site with resources and a forum relative to mental health of the tech workers.
Resources on the more physical aspect of programming
- https://blog.codinghorror.com/programming-your-hands/ An article on tunnel effect in programming which I found inspiring