This is the second part of the article describing the outcomes of my coding experience after quite a time in management. Here I note a few psychological observations I made while coding myself and working closely with SW development teams.

Flow state while programming

I have almost forgotten how cool it was to write my own code, which works, does what you expect it to do. Another question, whether it will also meet user expectations. Who cares, it works cool! The match between a user’s intuitive expectations, a customer who pays for development, a product manager who defines requirements, and developers is a subject of a separate discussion.

One way or another, there is no doubt that development is a “flow state” in the sense of Mihai Chikesentmihaii( see Psychology of Optimal Experience ). This fact implies several important requirements for the development process, which are often neglected by managers because they are unfamiliar with or have forgotten this “flow state”.

Developers are supposed to experience “flow” at work as much as possible. Because if they don’t motivation falls. They just don’t get the thing due to which many decided to become a developer. Developers work quite poorly “just for the sake of money”. Here are some common preconditions of the flow state:

• Entry time to the “flow state” is at least 15–20 minutes. Therefore, if you receive messages every 15 minutes (including slack, emails, meetings, conf calls, and so on) these are distractions that destroy the flow state. For my experiment of starting to code again, I had to allocate an untouchable time for such flow coding. I developed the habit of getting up at 4–50 in the morning and getting my two hours of silence. Therefore, you need to find a way when and how developers will be able to allocate their time for the “flow”. And at this time there should be a “tabu” for any external annoying signals.

• The work should include a challenge but still, be manageable. The complexity of tasks should be slightly higher than the current level of skills or maturity. At least some significant portion of work should contain challenges, to avoid boredom.

• A switch of context is an extremely expensive luxury, and a frequent change of context is the “team killer”. Switching a development group from one task to another does not just destroy the flow, but can slow down the whole dev team for several days or weeks, especially if they were “in the flow” of the previous development and were looking forward to their dose of “light euphoria” from the result. Panic or frustration from a big boat turning around is inevitable. Switching to another task, if the previous one is not “packaged” and not completed, leads to losses and the one might need later to spend time studying what was done by him or herself. An average developer’s “memory cache” cleans very quickly.

• Focus or die. Parallel work of a team or even one person on two or more contexts (projects) is a decrease in efficiency by at least 20–30%. You cannot conduct two fights in a half force. This is equal to fighting without the intention to win.

Few more things to keep in mind

I would like to outline several observations that also have to do with psychology:

• Perfectionism vs carelessness. There are both developer profiles. It is a kind of art to recognize who is of what profile and use these qualities in a suitable way. It’s hard to even say which is better (or rather, which is worse). Perfectionism can immerse the project in a deep over-engineering nosedive and consequent uncontrolled overengineering spin (when the work can’t be continued or contributed by other people than those who had started that over-engineering process). In the beginning, it may look very promising how the developer (or team) drills down to subject matter and constantly improving its outcomes. But, in the end, such an attitude can cost much more than an “easygoing attitude”. It is a simple task to make things complex, but a complex task to make them simple. Many developers experience almost physical pain when shipping an “imperfect” product. Not every building requires a three-meter foundation and it is necessary to be extremely clear and pragmatic in setting the purpose of the building and target engineering budget.

• Verification of assumptions. While coding, the programmer is forced to make many small, but often fateful decisions, since an exhaustive description of the requirements is a utopia. There are two extremes. Some developers feel like admitting themselves incompetent or annoying others when they ask a question to a manager or colleague. Other developers cannot move a single step forward until they receive a definite answer, all possible combinations of parameters are defined and all edge conditions are clarified. The way out can be a “dev culture” plus a mechanism of registering assumptions that a developer can take autonomously and continue working. These assumptions should be verified and approved by the appropriate knowledge owner (customer, tester, analyst, product owner).

• It is better to do nothing than to do by anticipation or assumptions based on unverified requirements with an unclear demand. There is nothing more demotivating than well-written software that no one needs. It is better to invest in research or migrating to new tools and technologies than do what turns out to be “not quite what’s needed.” That’s why you better fake it until you make it before you verify the product-market fit. We cannot allow the development to do something for the future purpose just in case (just not to stay idle).

• There are two types of technical push trap that engineering-minded people are used to falling in. The one is when an engineer experiences a strong gravity towards a certain technical solution. Usually, it refers to the perfectionism mentioned above, curiosity, willingness to study new technology, and sometimes irrational or intuition-based belief in some technology trends that might be just overhyped. And another kind of the same issue is when engineers for some reason become confident in a certain feature that is mandatory to be implemented, that it is kind “shame not having it,” or it is “de-facto standard”. Devs are quite used to make their mind on what needs to be done out of global trends. It is usually quite hard to resist such initiatives and be data-driven or stay at least pragmatic.

• It is psychologically natural to stall to self-belief or self-persuasion. Then the one unconsciously finds a reason to keep going the taken direction even if it is the wrong one. It is relevant to both engineering and business-minded people. It is very hard to identify whether our reasons to believe are rational or whether we just pretend and/or convince ourselves. We should constantly ask ourselves again and again why we really believe in the success of what we do and put the rational reason in front of everything else making it the main input for priority arbitration considering the roadmap options. This reason is like a bottleneck, which is jumping from one place to another, but the focus should always be on it. The reason to believe is not just a buzzword; it is a really difficult exercise of distinguishing beliefs from rational convictions. If the reasons are not generally convincing even inside the office, it will be just background noise and “bla-bla-bla” on the open market.

• There is a limited size of contextual information that developers can bear in mind. This is a substantial difference in the way of thinking between the engineering-minded and manager-minded personalities. The managers’ mind spreads in a thin layer over a large area of ​​the subject matter domain. The manager remembers many aspects of the solution at the same time and tries to meet and match them in their head so that they form a non-contradicting holistic picture of reality (abstracting details). The developer is forced to make a deep-dives, which is exponentially difficult with a large ballast of operational information. The ballast is dropped. Therefore, a developer cannot keep in mind many aspects and contexts of a problem, especially for a long time.

I would very much appreciate any sort of reflection on the mentioned observations. I really would like to confirm if any of you had a different experience or disagree with my statements.

The next dilemma that I am going to elaborate in the next article is the problem of roadmap items definition. What to productize out of many market opportunities, promising technologies, and customer requests. How to filter the trends from hypes, the signal from noise, allow mistakes or keep the conservative protective approach. Stay tuned…