Do you have an engineer that hops, skips, and jumps all over the codebase? You likely will notice how they’ll move from front-end issues to refactoring to switching over to another area of the database. You might even see that their submissions are never really challenging problems.
Do you use Git and Jira?
Take them to the Next Level with our Git-Jira integration
→ Try it For Free ←
Typically, it’s helpful if a developer isn’t relegated to one area of code since it helps them gain a more comprehensive understanding of the entire base. In fact, in short bursts and occasionally instances, it might even be healthy to have a dev go around, spreading themselves across the codebase.
However, a person that only jumps around from superficial fix to superficial fix could be an issue in the long run. Why? Because, eventually, they aren’t going to have a real sense of ownership of any substantial part of the code. And that can lead to boredom, disengagement, and attrition.
What to Do if Your Devs Are Showing Signs of Superficial Participation
The devs that are going around “fixing things” without too much depth will likely show::
- A high level of engagement in the review process
- Lots of pull requests (without any focus on any specific area in the code)
- Less time in bug fixing tasks
- A high concentration on code building
- Relatively low churn
I’ve Identified My Restless Developer Now What?
If you’ve identified a team member that’s jumping around the codebase without any sense of ownership, make sure you find a way to help them own something in its entirety. That could be anything from a large project to a new feature or module. The idea is to use this project to encourage them to become an “expert” in a specific project or focus area.
Once you’ve focused them in an area, don’t let them jump onto the next thing and return to the same demotivating habits. Assign them the 1.1 version and have them own the documentation, tests, and bug fixes. Keep them engaged through versions 1.2 and 1.3. This will give them the time to gain a deep understanding of their domain. Get them to continue to work on it and teach it to others so that they begin to develop a mastery while passing on their knowledge to others. Do whatever you can to nurture the sense of ownership in the project or code area (whether it’s a presentation to the team or documentation on lessons learned).
Code Ownership as a Responsibility – Not a Right
As a manager, you’ll want to develop a culture of ownership as responsibility and make sure you are not giving devs pieces of code that they feel ownership over. For example, suppose you allow your devs to claim ownership. In that case, you run the risk of engineers becoming territorial with their areas of expertise, which can wall off other devs from collaboration and contribution duties. While you want your superficial developer to dig deep into an area, you want to ensure that they aren’t so entrenched that they start getting possessive. So, even as you are working to make someone an “expert” in an area, don’t forget the fundamentals of reinforcing the sense of collaborative effort needed to build a healthy functional codebase.
Conclusion
Don’t just let your devs skip around your Git codebase and find and fix aimlessly. Instead, give each team member a key role and a key goal so that they can nurture a sense of ownership in their particular area. It will help them become stronger developers and help you ensure that there’s a strong foundation of good code (and a person who understands the process and history behind it) in each area of your code.
Love Jira but need to integrate it with apps like Bitbucket, GitHub, Gitlab (and more)? We’re here to make it happen. Bitband offers a variety of Jira integration apps, available now on the Atlassian Marketplace. Find out more about us here.
Want more Bitband insights? Check out:
