Interested in finding out how you guys approach code ownership in your respective workplaces. This could mean for sources, feature areas and bug routing. What do you like and dislike about your current process?
Ask HN: How do you handle code ownership?
1–10 of 68 posts
Re: Ask HN: How do you handle code ownership?
#2At my current workplace, most top-level subdirectories in the source tree have a primary author. That person is (nominally) "owner" of that code. If they aren't the one making changes, they're almost always at least the one doing the code review.
Bugs by default get routed to the person who wrote the code (presuming that we can tell which code the bug is in). If that person finds out the bug is somewhere else, the bug gets transferred to a new owner.
Re: Ask HN: How do you handle code ownership?
#3At my current workplace, most top-level subdirectories in the source tree have a primary author. That person is (nominally) "owner" of that code. If they aren't the one making changes, they're almost always at least the one doing the code review. Bugs by default get routed to the person who wrote the code (presuming that we can tell which code the bug is in). If that person finds out the bug is somewhere else, the bu…
Thanks for sharing.
What if that person leaves the company? Can that information get old.
Re: Ask HN: How do you handle code ownership?
#4At my current workplace, most top-level subdirectories in the source tree have a primary author. That person is (nominally) "owner" of that code. If they aren't the one making changes, they're almost always at least the one doing the code review. Bugs by default get routed to the person who wrote the code (presuming that we can tell which code the bug is in). If that person finds out the bug is somewhere else, the bu…
Thanks for sharing. What if that person leaves the company? Can that information get old.
People don't leave here very often. But, yeah, that would be a problem. Having someone else code review everything helps spread the knowledge, at least somewhat. But we definitely need to work on our bus factor...
Re: Ask HN: How do you handle code ownership?
#5At my current workplace, most top-level subdirectories in the source tree have a primary author. That person is (nominally) "owner" of that code. If they aren't the one making changes, they're almost always at least the one doing the code review. Bugs by default get routed to the person who wrote the code (presuming that we can tell which code the bug is in). If that person finds out the bug is somewhere else, the bu…
> Bugs by default get routed to the person who wrote the code...
That was the root of some very toxic teams I've seen. Because it built a lack of shared ownership as a team, it inspired competition instead of cooperation, and people would just ignore problems because "it wasn't my code".
Admittedly, that is a problem with the leadership that took the team to that place, but I'd be interested in hearing counter-examples of how to avoid such pitfalls.
Re: Ask HN: How do you handle code ownership?
#6- Ceartian people own certain systems/projects.
- Ownership is only the point person of knowlage/direction/insights
- Anyone can work on the code "owned" by someone else
- Idealy the writer fixes their own bugs and does their own refactoring (for speed and learning reasons) but that should NEVER obstruct delivery of a feature or value add to the company.
The moment a team starts pointing fingers for issues or starts building moats around "their" code then you have a toxic environment.
Re: Ask HN: How do you handle code ownership?
#7I, too, am curious about this especially if your repository has started to become a mono-repo. My team has started owning most of the code reviews as more teams get added and contribute to their sections of the code base but it gets pretty hectic. It's not as simple as assigning certain folders as a group because lots of things are intertwined.
Re: Ask HN: How do you handle code ownership?
#81. I don't say "guys", I say "folks"
2. Code is owned by teams of people and not individuals.
Re: Ask HN: How do you handle code ownership?
#9- Ceartian people own certain systems/projects. - Ownership is only the point person of knowlage/direction/insights - Anyone can work on the code "owned" by someone else - Idealy the writer fixes their own bugs and does their own refactoring (for speed and learning reasons) but that should NEVER obstruct delivery of a feature or value add to the company. The moment a team starts pointing fingers for issues or starts…
The moment a team starts pointing fingers for issues or starts building moats around "their" code then you have a toxic environment.
I have just the opposite problem. No one else wants to add features to code that I wrote because they don’t want to ramp up.
This isn’t difficult to understand code - some of it is less than a 30 line Python AWS Lambda function.
The process is documented in the repo in the readme.
Re: Ask HN: How do you handle code ownership?
#10At my current workplace, most top-level subdirectories in the source tree have a primary author. That person is (nominally) "owner" of that code. If they aren't the one making changes, they're almost always at least the one doing the code review. Bugs by default get routed to the person who wrote the code (presuming that we can tell which code the bug is in). If that person finds out the bug is somewhere else, the bu…
> Bugs by default get routed to the person who wrote the code... That was the root of some very toxic teams I've seen. Because it built a lack of shared ownership as a team, it inspired competition instead of cooperation, and people would just ignore problems because "it wasn't my code". Admittedly, that is a problem with the leadership that took the team to that place, but I'd be interested in hearing counter-exampl…
[deleted]