Improving Developers Impact

IMPACT on a code base can be described as how your code affects existing code base. This can be measured by the number of lines you’ve added or updated, the number of files touched and most importantly the cognitive complexity on the changes you’ve added. Generally, engineers’ impact can be affected due to many external factors ranging from software practices to having code blocks. Below are some of the causes of having a negative impact

• Context switching:
  When tasks are not created to be as indivisible as possible, it can lead to making avoidable mistakes since such tasks might have a different context attached to it. Also, having to unblock people working on a different task, in turn, can make you propose half-baked solutions.
• Time:
  an engineer spends on ramping up on a new code base. More so, one without a good documentation
• Churning:
  In software engineering, this is the number of code lines that gets rewritten within a period of time. When churning increases for an engineer, it in total affects the impact that an engineer has on the team in general. Below are some of the leading cause for churn
• Bad business requirements:
  Agile is good, but a bad business requirement (BR) is another issue entirely. A bad BR will cause engineers to keep removing and adding new code within a very short period of time as new information comes in
• Inconclusive commits:
  gradual commits are good. Engineers should avoid committing code that doesn’t do what it’s stated to do. This means a commit should hold a working functionality as the case may be. I.e “feat(Date Parser): create a utility to parse date” should only be committed when this utility works.
• Conventions:
  different conventions across multiple scrum team can also lead to high churn as reviews would ensure that engineers meet this convention thus Churn

Possible Solutions:

Documentation:

This plays an important role on any code base. It can sometimes be the difference between a good code base and a bad one.

1. Documentation should be part of an epic: Documentation should be a continuous task on any code base and should be made an important part of an epic
2. The technical decisions should be documented

Understanding, functional area:

1. Engineers should be more active during architecture and problem solving
2. Engineers should spend more time architecting solutions and gaining more insight
3. Engineers should schedule weekly code walkthrough to ensure everyone is close to being up to date with his or her functional area.
4. Engineers should be more involved with engineering decision on the team

Project Requirements:

1. Time should be taken by the engineering team to validate the assumptions on requirements before inception starts
2. Engineers should be more involved with product decision on the team

General:

1. Uniform convention across a code base
2. Tasks should not be shared based on perceived strength and younger engineers should stay away from picking too complex tasks
3. Engineers’ cumulative impact shouldn’t be measured by lines of code only