Collaboration across your team is excellent. It’s a natural process, especially when working with Git, as the entire platform is designed to have everyone work in tandem and collectively check commits, submit pull requests, and ensure the best code is being put forward for every project.
Do you use Git and Jira?
Take them to the Next Level with our Git-Jira integration
→ Try it For Free ←
That said, over helping can happen.
Overhelping is when one or more developers spend unbalanced amounts of time helping other developers finish their work before a sprint deadline. While one dev submits the code, another ends up cleaning it up, over and over again. While this might be typical on small teams, it’s time to flag it as something of a concern if this pattern fails to taper off.
Why is Overhelping a Problem?
While on its face, overhelping may seem like something that’s not the end of the world. After all, the work is getting done, and the code submitted is excellent. However, overhelping starts to become a real problem when:
- It’s drawing one developer’s attention away from their own work
- It impairs the original author from actually getting better at submitting good code
- It can do double duty of overburdening the overhelper while putting the reliant party in a constant state of “waiting on the fix”
Are You Actually Witnessing the Development of Overhelping?
If you have an overhelper, you might have noticed that they have the same underlying patterns as the “super-devs” that saves the day (as discussed in this blog here). However, another way to see if you’ve got an overhelper situation on your hands, keep an eye out for last-minute corrections of one dev’s work by another dev. Likely, while reviewing reports, you’ll begin to see who’s constantly reviewing and making changes to one’s work (and likely with a pattern of the effort not being reciprocated by the other dev).
How to Break the Cycle
This behavior can be healthy and helpful if one is mentoring the other. However, beyond a certain point, it might be good to switch out or bring in additional engineers that can be swapped into the code review process. Distributing the review process across other engineers makes the entire team more robust and shares knowledge. More importantly, the weaker dev isn’t using a specific person as a crutch to help them lift the quality of their code.
It may be a good idea to cross-train and toe assign each engineer in question (both the “overhelper” and the one relying on their help) to different areas of the codebase. Ideally, the senior engineer should be placed on something challenging and time-consuming to remove the likelihood they’ll have the time to slip back into old helping habits.
Embrace the Natural Leadership at Play
Don’t just refocus each dev on other work. Instead, take a moment to acknowledge and appreciate that the overhelper has revealed themselves to be a natural leader and may be well-positioned for coach opportunities in the future. Look for ways you can positively nurture these instincts – in a way that will positively impact the whole team in the long run.
Be Mindful of Friendship Dynamics
There might be bigger things at play between developers. Sometimes engineers who are “overhelpers” are overhelping friends or colleagues with whom they may have a relationship (for example, they may have worked together closely at another company). Be empathetic to their relationship and be transparent. You’re not a manager that’s trying to break up two buddies. Instead, you’re working to ensure the work is balanced equally between all parties, and you want to be supportive of helping each individual grow their skills and knowledge base in a positive way that can enrich their careers.
Download our Git-Jira integration app to manage your Git right from Jira. Bitband specializes in Git-Jira plugins (including Bitbucket, GitHub, Gitlab, and more), which you can find on the Atlassian Marketplace today.
Want more Bitband insights? Check out:
