Enjoyment and flow are essential to productivity. According to research, which asked the developers about productivity, the second most mentioned reason for having a productive workday is getting into a “flow” without many “context-switches” and with no or few interruptions and distractions (50.4%). Developer gains flow if the DX of tools and services is great. The most common reason is when developer completes tasks, achieve their planned goals or make progress on their goals (53.2%).
Some managers do say that people will work better if you put them under a lot of pressure. They won’t—they’ll just enjoy it less. You need to provide opportunities to adjust environment to fit their needs, proper tools and freedom to choose tooling, challenges in right size chunks and let them to their work. Primary task of a manager is to reduce friction in the work and remove obstables. Obstacles and friction might appear in plethora of ways, but tools and services (APIs) with poor developer experience consumed by the developers are for sure among those.
According to 2017 Software Developer Productivity Survey developers are under performing because they are waiting for others to finalize their tasks (41,1%)Spending time in meetings (39,9%) is the second most common productivity killer. Third in the list is struggling with bad tools (35,1%). It’s a bit unclear what is included in bad tools, but it sounds like struggling with bad developer experience is one of the factors.
Interestingly achieving flow state does not work like a switch, it takes time. According to Demarco and Lister it takes about 15 minutes or more to get into the flow. Before achieving the flow, person is extremely sensitive to noises and disruptions and those can make it impossible to achieve. Once you’re in the flow, the state can be broken by something that is focused on you. According to research that state is also broken easily by internal interruptions.
According to research external distractions are felt to be more influencal than internal, but results indicate the opposite. The internal interruptions aka self-interruptions break the flow. Most common (30%) self-interruption is being blocked on a task (e.g. tool obstacles, technical issues). That is more common than getting sidetracked to other tasks (23%) or lack of technical information for example documentation (16%).
Minimize the famous “5 minute manager damage”
Great developer experience can minimize the “manager damage”. If your product (API/platform) has great Developer eXperience, it can reduce the developer’s return time to flow state after interruption. I’ve been in multiple organisations as part of the development team. It’s unfortunately still too common to discuss with some of the managers who think developers can almost instantly resume productive after small “5 minutes thing to discuss” moment. They can’t.
It takes time to get back on the saddle and in the flow. Depending of the developer and task at hand it might take an hour to be productive again. Best way to reduce the drops in productivity is not to interrupt the developer, but that is not always possible. By selecting tools and APIs which have great developer experience you can shorten the timespan of returning to be productive.
So significant amount of developers struggle with pointless meetings, waiting for others to finalize tasks and bad tools. So what? What’s the monetary loss we are dealing with?
Some more to read from 100 Days DX
- #85 - Great Developer eXperience requires fluent internal workflow
- #84 - Theory of Economics of Developer eXperience
- #83 - The Space of API Design Decisions is missing
- #82 - Purpose of API Evaluation Framework
- #81 - Should We Move to Stack Overflow?
- #80 - Four data driven ideas for improving API documentation
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!