More on this book
Kindle Notes & Highlights
Read between
March 8 - March 30, 2021
A more recent study [19] found only one personality trait—conscientiousness—impacted productivity (positively).
Several studies [16–18] looked at the relationship of happiness of developers and their productivity.
The e-factor introduced by DeMarco and Lister in Peopleware [3] emphasizes that uninterrupted time for work is important for productivity.
In software companies, we frequently see open-plan offices with the reasoning that interaction between team members is important. A recent large study [22] found no evidence that this is actually the case. Instead, interruptions are much higher; hence, the e-factor becomes worse in open-plan offices.
It is well established that larger teams lead to exponentially increasing communication efforts that, in turn, lead to lower productivity. Newer, agile software development processes therefore often recommend team sizes of about seven.
Highly unstable requirements lead to time, effort, and budget overruns; overall demotivation; decreased efficiency; and the need for post-implementation
Several studies show that schedules that are too tight in effect reduce the productivity.
A recent observational study of IT professionals found that some people interrupt themselves after just 20 seconds of settling into focused work
interruptions take time to recover from and lead to errors
Experiments have investigated whether longer interruptions are more disruptive than shorter interruptions—finding that longer interruptions result in longer resumption lags
shorter interruption lags are found when interruptions occur at natural breakpoints in a task, such as the completion of a subtask
interruptions that are relevant to the primary task are less disruptive than interruptions that have nothing to do with the primary task
longer resumption lags following an interruption were in fact beneficial in terms of reducing the occurrence of errors.
One of the main insights to come from modeling work using the Memory for Goals theory is that the longer an interruption, the more likely it is that errors are to occur, including forgetting to resume the task altogether (and for specific cases, the models can give even more specific and exact predictions). Therefore, the implication of this work is that there is value in avoiding being interrupted.
By closely monitoring workers in-situ, it was found that people switched activities (conversations, work on computer applications, phone calls) about every three minutes on average. At a less-granular level, when activities were clustered into tasks, or “working spheres,” these were found to be interrupted or switched about every 11 minutes [16]. There is a relationship of length of time on task and interruptions: the longer time spent in a working sphere, the longer is the interrupting event. It has been proposed that when interruptions are used as breaks, then such longer interruptions might
...more
Interruptions may be beneficial or detrimental.
Generally, interruptions that disrupt concentration in a task, especially when they occur at a point that is not a natural breaking point for a task, can be detrimental
When notifications from smart phones were turned off for a week, people reported higher levels of attention
Interruptions in the workplace can also provide benefits . Longer interruptions (or work breaks), such as taking a walk in nature during work hours, have been shown to increase focus and creativity at work [1]. Observational studies have identified that people use a variety of social media and news sites to take breaks to refresh and to stimulate themselves [29
In a study that focused specifically on the role of e-mail interruptions, Kushlev and Dunn [30] found that limiting the amount of checking e-mail significantly reduced stress.
Cutting off smartphone notifications also significantly reduced inattention and symptoms of hyperactivity
It is theorized that people who multitask more and who are susceptible to interruptions may have lower ability to filter out irrelevant stimuli
Interruptions can take time from which to recover from and can lead to errors. Shorter interruptions are less disruptive than longer interruptions. Interruptions delivered during a natural break in a task are less disruptive. Interruptions that are relevant to the current task are less disruptive. Resuming a task too quickly can lead to errors being made. All of these characteristics of the resumption lag can be explained by an underlying memory retrieval process. People self-interrupt almost as often as being interrupted by external sources. People often work on multiple tasks at the same
...more
these ideas are also supported by scientific research. We have previously shown that happy developers solve problems better [1], that there is a relationship between affect and how developers assess their own productivity [2], and that software developers themselves are calling for research in this area [5
Software developers are indeed a slightly happy group—and they are happier than what we would expect based on knowledge about various other groups of the human population.
The causes of unhappiness that are controllable by managers and team leaders are mentioned four times as often as those being personal and therefore beyond direct managerial control. We also expected the majority of the causes to be related to human aspects and relationships. However, most of them came from technical factors related to the artifact (software product, tests, requirements and design document, architecture, etc.) and the process. This highlights the importance of strategic architecture and workforce coordination.
Being stuck in problem-solving and time pressure are the two most frequent causes of unhappiness, which corroborates the importance of recent research that attempts to understand these issues.
Psychological grit could be an important characteristic to train among software developers.
The third most frequent cause of unhappiness is to work with bad code and, more specifically, with bad code practices. Developers are unhappy when they produce bad code, but they suffer tremendously when they meet bad code that could have been avoided in the first place.
Many of the negative consequences can be avoided by rotating tasks, by making better decisions, and by actually listening to developers.
As you can see, developers reported several productivity-related consequences—and some even explicitly reported experiencing lower productivity. Other consequences include delays, process deviations, low code quality, throwing away code, and breaking the process flow in projects. These external effects are direct impacts on productivity and performance. Internal consequences, such as low motivation and reduced cognitive performance, indirectly affect productivity as well. Work withdrawal and mental unease, or, in the worst case, signs of disorders, are among the gravest consequences mentioned
...more
The unhappiness] has left me feeling very stupid, and as a result I have no leadership skills, no desire to participate, and feel like I’m being forced to code to live as a kind of punishment.”
Work withdrawal is a destructive consequence of unhappiness, and it emerged often among the responses. Work withdrawal is a family of behaviors that is defined as employees’ attempts to remove themselves, either temporarily or permanently, from daily work tasks. We found varying degrees of work withdrawal, ranging from switching to another task (“[…] You spend like two hours investigating on Google for a similar issue and how it was resolved, you find nothing, and desperation kicks in.”) to considering quitting developing software (“I really start to doubt myself and question whether I’m fit
...more
Work engagement is committing to the act of moving toward a goal.
An interesting aspect is that, when happy, developers tend to take on undesired tasks: “I think that when I’m in this happy state, I am more productive. The happier I am, the more likely I’ll be able to accomplish tasks that I’ve been avoiding.” On the other hand, unhappy developers could be so unproductive that they become destructive.
We compared the scores obtained in both tasks with the happiness of developers. The results showed that the happiest software developers outperformed the other developers in terms of analytic performance. We estimated the performance increase to be about 6 percent.
The results have shown that high pleasure with the programming task and the sensation of having adequate skills are positively correlated with the productivity.
Unhappiness causes glitches in communication and a disorganized process:
Often, we saw a repeating pattern of willingness to share knowledge (“I’m very curious, and I like to teach people what I learned”)
The main principles provided by the agile manifesto ( http://agilemanifesto.org ) are as follows: Individuals and interaction over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
observing developers’ workdays revealed that they constantly switch contexts, often multiple times an hour. For example, developers switched tasks on average 13 times an hour and spent just about 6 minutes on a task before switching to another one. An example of a task switch is a developer who is switching from implementing a feature to answering e-mails that are unrelated to the previous task. Similarly, when we looked at how much time developers spend on activities–actions they usually pursue at work (e.g., writing code, running tests, or writing an e-mail)–we found out that they usually
...more
productivity is highly individual and differs greatly across developers.
On the individual level, we could build self-monitoring tools that allow developers to increase their awareness about productive and unproductive behaviors and use the insights they gain to set well-founded goals for self-improvements at work
By knowing the trends of developers’ perceived productivity and the activities they consider as particularly productive/unproductive, it might be possible to schedule the tasks and activities developers must perform in a way that best fits their work patterns. For example, if a developer is a morning person and considers coding particularly productive and meetings as impeding productivity, blocking calendar time in the morning for coding tasks and automatically assigning afternoon hours for meeting requests may allow the developer to best employ their capabilities over the whole day. Or, it
...more
interruptions, one specific type of a context switch, are one of the biggest impediments to productive work. Productivity could potentially be improved on the team level by enhancing the coordination and communication between co-workers, depending on their preferences, availabilities, and current focus. For example, on the team level, quiet, less interruption-prone offices could be provided to the “lone developers” and “focused developers,” and “social developers” who feel more comfortable with discussions every now and then could be seated in open space offices.
Different software developers experience productivity differently, which is why they do not agree on how to measure productivity.
Measuring developer productivity should not only include output measures but also include measures inherent to developers’ abilities, workdays, work environments, and more.
Rapid prototyping [15] allows quick and simple prototypes of the intervention to be tried, often just drawn on paper, which helps to refine good ideas and eliminate bad ones. Sometimes it might be too expensive to create the real intervention before being able to test it. In these cases, we have used another recommended human-centered method called iterative design using prototypes [14].
heuristic evaluation [13] employs ten guidelines to evaluate an interface.
Another expert-analysis method is called cognitive walkthrough [8]. It involves carefully going through tasks using the interface and noting where users will need new knowledge to be able to take the next step. Using both of these methods, we helped a company iteratively improve a developer tool [3].
