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
featured_image
About the Author

Olusegun Adesanya

Thanks for subscribing!

 

More Insights

January 29, 2019

Improving Impact Amongst Engineers

Olusegun Adesanya

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
featured_image
About the Author

Olusegun Adesanya

Thanks for subscribing!

 

More Insights

Evolving HR Through Design Thinking

Growing up as a child, a lot of things intrigued me. Top on the list was food, my special stones (ak...

23_August_2019

Finding Answers: Benedicte Musabimana’s Dev Journey

"When I was a kid, I always wanted to know how a computer or a mobile phone worked." Benedicte is...

21_August_2019

Introducing The Andela Talent Marketplace

Andela set out as a company to advance human potential by investing heavily in building technology l...

20_August_2019

On Designing Good Microservices Architectures

It may be difficult to know exactly what constitutes a well-designed microservice on your first assi...

19_August_2019

RubyConf Kenya 2019: My Nairuby Recap

Two weeks ago was the first time I attended a Ruby conference outside my home country, and boy was i...

14_August_2019

How To Manage Communication as a Distributed Product Manager

With more companies embracing distributed and remote work teams, the communication challenge tak...

9_August_2019

Partners

Tap into a global talent pool and hire the “right” developers in days, not months.

Developers

Accelerate your career by working with high-performing engineering teams around the world.

BECOME A DEVELOPER

Hire Developers

We take great pride in matching our developers with the best partners. Tell us about your team below!

preloader_image

Thank you for your interest

A member of our team will reach out to you soon.