More on this book
Kindle Notes & Highlights
Read between
September 12 - September 19, 2020
most software developers are moderately happy.
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.
However, developers feel bad when they are stuck and under pressure, and several detrimental consequences do happen
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.
factors related to information needs in terms of software quality and software construction are strong contributors to unhappiness among developers.
Other consequences include delays, process deviations, low code quality, throwing away code, and breaking the process flow in projects.
Being happy while developing software brings higher learning abilities: “It made me want to pursue a master’s in computer science and learn interesting and clever ideas to solve problems.” However, being unhappy causes mental fatigue, and participants reported “getting frustrated and sloppy.”
Unhappiness causes interruptions in developers’ flow, resulting in adverse effects on the process.
Unhappiness and happiness are causes of work withdrawal and work engagement, respectively. Work withdrawal is a destructive consequence of unhappiness, and it emerged often among the responses.
Work engagement is committing to the act of moving toward a goal.
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.
happy developers can also mean more collaborative team members, leading to increased collaboration.
Being happy or unhappy influences not only the productivity of the code writing process but also the quality of the resulting code.
Participants reported that unhappiness while developing software is a cause of anxiety (“These kinds of situations make me feel panicky.”), stress (“[The] only reason [for] my failure [is] due [to] burnout.”), self-doubt (“If I feel particularly lost on a certain task, I may sometimes begin to question my overall ability to be a good programmer.”), and sadness and feeling depressed (“[…] feels like a black fog of depression surrounds you and the project.”). In addition, we found mentions of feelings of being judged, frustration, and lack of confidence in one’s ability.
However, observing developers’ workdays revealed that they constantly switch contexts, often multiple times an hour.
This high number of task and activity switches and the high variety of activities and tasks developers pursue each day illustrate the high fragmentation of a developer’s work. Surprisingly, many developers still felt productive despite the high number of context switches. The follow-up interviews with the developers revealed that the cost of context switches varies. The cost or “harm” of a context switch depends on several factors: the duration of the switch, the reason for the switch, and the focus on the current task that is interrupted.
Interruptions from co-workers are one of the most often mentioned reasons for costly context switches, especially when they happen at an inopportune moment, such as when a developer is focused on a challenging problem.
The majority of developers reported coding as the most productive activity, as coding allows them to make progress on the tasks that are most important to them.
This suggests that measures or models that attempt to quantify productivity should take individual differences, such as the context of a developer’s workday, into account, and attempt to capture a developer’s work more holistically rather than reducing them to a single activity and one outcome measure.
Our studies also revealed that interruptions, one specific type of a context switch, are one of the biggest impediments to productive work.
In summary, productivity requires sometimes singular focus and sometimes distraction.
Since most jobs require more than mechanical concentration on a single thing, measurement of productivity is nontrivial.
While some forms of productivity require targeted attentional focus, other forms of productivity require mental flexibility.
being aware of all relevant information in a software project is crucial to enable productivity in software development.
Awareness includes both short-term, momentary awareness (awareness of events at this particular point in time, such as the current build status) and long-term, historical awareness (awareness of past events, such as code evolution and team velocity). As the complexity of software systems grows, maintaining awareness of all relevant context is becoming increasingly challenging. To address this situation, many tools have been developed over the last decades to help developers maintain awareness of everything that goes on in a project.
From the perspective of who receives awareness information, numeric measures should not be provided in isolation: they should be augmented with useful information about recent changes in the project that happened according to plan, i.e., expected events, and most importantly, they should provide information about the unexpected.
To accurately represent what goes on in a software project, awareness tools need to focus on summarizing instead of measuring information and be careful when presenting numbers that could be used as an unintended proxy for productivity measures.
Tools that help developers make sense of everything that goes on in a software project are necessary to enable developer awareness. These tools currently favor quantitative information over qualitative information but need to focus on summarizing instead of measuring information. Team awareness can influence developers’ perceptions of their colleagues’ productivity, and developers do not feel that productivity can be collapsed into a single metric.
COSMIC size of a functional process is measured by counting its data movements. In other words, this approach assumes that each data movement accounts for any associated data manipulation. By definition, a data movement is a subprocess that moves a group of data attributes that all describe a single object of interest (think of an object-class, a relation in 3NF, or an entity-type). The unit of measurement is one data movement, designated as 1x COSMIC function point, or 1 CFP. A functional process has a minimum size of 2 CFPs. It must have an Entry plus either an Exit or a Write, as the
...more
One of the key challenges in the software industry is to measure productivity of completed sprints, releases, projects, or portfolios in an apples to apples way so that this information can be used for processes such as estimation, project control, and benchmarking. At this moment, only the standards for functional size measurement comply with demands for standardized measurement procedures and intermeasurer repeatability to produce measurement results that can be compared across domains to benchmark productivity.
To have a meaningful benchmark, all aspects not under scrutiny must be made the same. This is called normalizing
The problem is that waste is often hidden. Rework is hidden in “new features” and “bug fixes.” Building the wrong features is hidden by lack of good feedback. Knowledge loss is hidden by not realizing the organization used to know this information. We hide distress to avoid looking weak. Bureaucracy hides waste behind an official policy.
The Process Maturity Framework can be applied to individual processes—the so-called continuous approach. However, this framework is most effective when applied as a unique guidebook for organizational change and development. If the organization does not change, individual best practices typically will not survive the stress of crisis-driven challenges.
From an industrial perspective, an answer to the question might be this: given the dominant role of system knowledge for productive development, companies may not like to let their top-general-knowledge developer go, but they are terrified of losing their single top-system-knowledge developer. And frequent pair programming is an excellent technique to make sure system knowledge spreads continuously across a team.
Pair programming will tend to pay off if the pair manages to have high process fluency. Pair programming will pay off if the pair members’ knowledge is nicely complementary.
personal behavior at work can improve developers’ performance for a substantial proportion of developers. Self-reporting productivity allows developers to briefly reflect about their efficiency and progress at work and take timely actions that improve productivity. Developers have a diverse interest in measures about their work, ranging from development related data to data about their collaboration in the team, all the way to biometric data.
These negative effects and costs of interruptions are particularly high when the interruptions happen at inopportune moments and cannot be postponed. This is why in-person interruptions are one of the most disruptive types of interruptions. Compared to other types of interruptions such as an e-mail notification or an instant message, it is difficult to ignore a person waiting next to the desk and first finish the current task at hand.
The physical LED lamp is usually mounted on a person’s desk, cubicle separator, or office entrance to be easily visible by co-workers. Depending on personal preference, the light can be places so that it is visible for the workers themselves, for use as a personal flow monitor, or on a less visible place, to prevent distraction. After installing the FlowLight application on a user’s computer, it calculates the users’ “flow status”—the availability for interruptions—based on the user’s current and historical computer interaction data.
Our hypothesis has been that software development productivity can be increased by improving the access and flow of information between the humans and tools involved in creating software systems.
As software is an information-intensive activity, the ability to deliver value is critically dependent on the flow of, and access to, information. When information does not flow appropriately, delivery is delayed, or worse, errors may occur, causing a decrease in quality or a further delay in delivery. If the flow of information is supported and optimized, delivery times can be shortened, and productivity within an organization can rise.
The idea is that you learn to relax by bringing your attention to your breath and not taking your thoughts so seriously. Some preliminary evidence for mindfulness’ effect on stress reduction was given by a seminal study [3], which showed that employees of a biotech firm, when given a mindfulness intervention, felt less stressed and showed an improved immune response. In addition, it is generally thought that mindfulness helps to counteract distraction and mindlessness and thereby allow one to concentrate for longer periods of time without interruption.
