tl;dr:OKR maturity was found to be positively correlated with the following: (1) Having a unified mission as a team. This is intuitive: a unified mission brings alignment, and this alignment may drive people to set better OKRs as it is clear what they’re working toward. (2) Overall happiness at the company. This aligns with the finding from previous research that progressing towards a meaningful goal is a top motivator for employees. (3) Working remotely. “We hypothesize this is because teams who do not have regular face time and in person meetings with leadership need to be more clear on what they are doing, how it relates to the org, and have better ability to share back their progress.”
tl;dr:Developers were asked to rate a set of challenges to determine which factors had the highest impact. The two most impactful challenges identified were insufficient analysis at the beginning of a task and lack of leadership. Other impactful challenges included missing documentation, demotivation, and information not being made known to the team. Abi discusses how to address these.
tl;dr:“Developers are different in what they consider as a productive or unproductive workday; this study aimed to help leaders make sense of these differences.” The study found 6 types of developers and what they deemed as productive: (1) Social developers: feel productive when helping coworkers, collaborating and doing code reviews. (2) Lone developers: avoid disruptions such as noise, email, meetings, and code reviews. (3) Focused developers: feel most productive when they are working efficiently and concentrated on a single task at a time. (4) Balanced developers: less affected by disruptions. (5) Leading developers: more comfortable with meetings and emails. (6) Goal-oriented developers: productive when they complete or make progress on tasks.
tl;dr:“Researchers found that readability and structure were the most commonly used defining properties for code quality. 82% of interviewees referred to either readability or structure, or both, when describing how they define code quality.” After that, the researchers discovered that comprehensibility, documentation and correctness followed. Abi reminds us that “code quality is a fundamentally human property” and not measured by quantitive metrics.
tl;dr:Abi summarizes a study by Google researchers on the factors that correlate with software developers' productivity. The study found that "Job enthusiasm," "Peer support for new ideas," and "Useful feedback about job performance" were the most strongly correlated factors with self-rated productivity. The top 10 productivity factors were non-technical.
tl;dr:Abi highlights a study on developers' productivity, revealing that reflective goal-setting leads to improvements. 84% of participants identified concrete goals through reflection, 80% saw positive behavior change, and 92% planned to maintain new habits. The key takeaway is that reflective goal-setting not only enhances awareness and productivity but also encourages lasting behavioral changes, empowering developers to gain control over their work.
tl;dr:The takeaway is that even modest improvements to build times are helpful. Three things: (1) There is no specific threshold for how fast builds need to be for developers to stay on task and be productive. (2) Providing developers with estimated build times can improve productivity. (3) Even modest improvements in build latency can be helpful.
tl;dr:The highest priority adoption factor for 4 types of internal tools: (1) For build tools, it is whether the tool is highly configurable. (2) For continuous integration tools, it’s whether the tool is compatible with the technologies developers use. (3) For infrastructure as code tools, it’s how visible the usage of the tool is within the organization. (4) For version control tools, it’s whether the tool fits well with the way developers work.
tl;dr:The first part describes the categories of tech debt and the second part explores how categories may be measured, providing insights on how to determine whether teams are struggling with technical debt and the types of tech debt they’re struggling with. The final part of this paper provides several tactics that may help reduce tech debt.
tl;dr:The 3 pillars are: (1) Reducing friction: minimizing obstacles, inefficiencies, and complexities in the development process. (2) Optimizing workflows: streamlining processes, automating repetitive tasks, and integrating tools and technologies. (3) Enabling a state of flow: creating an environment that fosters concentration, creativity, and intrinsic motivation.