Want to ruin a developer's day? Coders reveal what really destroys their productivity

Any more than two meetings per day is enough to make your developers a bunch of unhappy campers, so says new research.

develop-burnout-annoyed-coder-stress-meantal-health.jpg

Too many meetings spoil the code...or something.

Image: CleoFilter/iStock

How many meetings per day is too many? According to new research by GitHub, any more than two is enough to have a massive impact on how much quality work your developers can get done – not to mention make their stress levels skyrocket.

GitHub's Good Day Project surveyed 40 software engineers to discover how work-related events throughout the day affected their productivity, stress and feelings of satisfaction.

Over the course of two weeks, participants were prompted to rate their day as 'Awesome', 'Good', 'OK', 'Bad' or 'Terrible' and then asked to describe their day in more detail using questions based on GitHub's SPACE productivity framework.

SEE: The best programming languages to learn--and the worst (TechRepublic Premium)

Each developer's survey data was then mapped to their GitHub activity data for that day: code pushes, pull requests, comments, and issues. Perhaps unsurprisingly, it found that developers reported their best days as those containing the fewest meetings and interruptions, while those with more meetings and more disruption were more likely to result in developers having a bad day.

In fact, meetings and interruptions were found to have a more significant impact on how developers rated their days than researchers anticipated. On days with few or no interruptions, developers' chances of having a good day were 82%. When developers reported being interrupted for the majority of the day, this dropped to 7%. 

The research also determined that any more than two meetings per day was enough to knock developers off their goals substantially. When developers had an average of two meetings a day, there was a 74% chance of them reporting having made progress toward their goals. Yet any more than three meetings a day pushed this down to 14%.

GitHub researcher Eirini Kalliamvakou pointed out that not all meetings can be avoided, but keeping them to a minimal offered the best chances of developers being able to focus and achieve 'flow' – periods of productive and unbroken work. Developers had a 99% chance of doing quality work when meetings were limited to just one a day, for example.

Kalliamvakou noted that interruptions sometimes offered a respite from work, but too many caused developers' days to become fragmented and made make them less effective. "Context switches are cognitively expensive and take time to recover from," the research said.

For example, developers who pushed more code and created more pull requests had a greater chance of feeling like they had a good day, but developers who created the most pull requests did not report the best days. Researchers put this down to the fact that creating pull requests distracted developers from focused work and interrupted their days.

SEE: C++ programming language: How it became the foundation for everything, and what's next (free PDF) (TechRepublic)

"By minimizing distractions and creating focus time, we not only get work done, we create better and less stressful days for ourselves," said Kalliamvakou.

GitHub's research found that periods of reflection were also effective at boosting developers' feelings of satisfaction, creating lower stress and increasing productivity, with many developers opting to continue the practice even after the two-week study was over.

"Feedback from developers showed that the simple act of taking a few minutes at the end of each work day to reflect made a big difference in how they felt," said Kalliamvakou.

"Noting key activities and how they felt about the day helped developers "close out" their day and gain insight. In other words, this small moment has a big impact for those of us wanting to pause and reflect on our days and work. And it can be done by anyone, and doesn't require any fancy tech or tooling – a simple notebook or markdown file can work."

Also see