Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do you handle code ownership?

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Ask HN: How do you handle code ownership?

#41

Post by nilkn »

breischl wrote: post #18
NickBusey wrote: post #12

Earlier quoted context omitted.

According to dictionary.com, the definition of "guys" is "persons of either sex; people" The definition of "folks" is "people in general" I'm not sure what point you are trying to make here.

Dictionary definition aside, the colloquial meaning of "guys" is quite frequently "men". I think the GP was trying to be gender-neutral. I actually have tried to move to "folks" myself for that reason.

It depends on how the word is used. "You guys" is very different, for instance, than just "guys". As it happens, that's the usage in the title of this thread.

I'm not saying there's no reason to reconsider language choices. Frankly, I agree overall that this phrase and its derivatives should probably be slowly retired, if only to avoid the occasional confusion. My point is only that even in colloquial usage there are patterns involving "guys" that are clearly gender-neutral at this point and have been for decades.

Re: Ask HN: How do you handle code ownership?

#42

Post by protonimitate »

mharroun wrote: post #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…

> - Ownership is only the point person of knowlage/direction/insights

this is such a key factor to preventing the toxic attitudes that can develop, imo.

At the end of the day, everyone who touches the code base is "responsible" for keeping the machine running.

Any team that favors blaming/shaming for bad code should be avoided at all costs. The mindset should be "what is wrong? How do we fix it? How do we prevent it in the future?" At no point should "who did this?" enter the equation, unless they are harboring some secret fix that no one else knows about (and this just points to other deficiencies in the process).

Re: Ask HN: How do you handle code ownership?

#43

Post by [deleted] »

Domenic_S wrote: post #23
NickBusey wrote: post #12

Earlier quoted context omitted.

According to dictionary.com, the definition of "guys" is "persons of either sex; people" The definition of "folks" is "people in general" I'm not sure what point you are trying to make here.

https://msmagazine.com/2013/09/06/a-guy-is-a-man-is-a-guy/ > Thought Experiment #1: Imagine a room full of men and women. Someone stands at the front and says, “I want all the guys to stand up.” What happens next? I don't know where I personally land on this debate, but the points are cogent.

[deleted]

Re: Ask HN: How do you handle code ownership?

#44

Post by xsmasher »

mirceal wrote: post #11

It's usually a bad idea to have code "owners". Yes, sometimes someone will know the most about a specific piece of code if either they wrote it or worked on it a lot. Sometimes people will not want to touch a piece of code. My rule is that once you submit the code for review and it passes and gets merged everybody owns the code. Everybody. The person who is modifying the code has the responsibility to identify the be…

I prefer the term SME (Subject Matter Expert) over owner.

Re: Ask HN: How do you handle code ownership?

#45

Post by macca321 »

scarface74 wrote: post #9
mharroun wrote: post #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…

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.

What's tricky is when that lambda doesn't have a documented contract with the systems it talks to, doesn't have end to end integration tests, has a unique build pipeline, requires manual infrastructure creation and there are 100 others like that.

I'm not saying yours is like that, but I've definitely seen that happen.

Re: Ask HN: How do you handle code ownership?

#46

Post by tickthokk »

HeWhoLurksLate wrote: post #19
tacostakohashi wrote: post #13

In my experience with several big organizations (20,000+ employees), they tend to have a home-grown application to track ownership of resources (assets) - including source code (repositories), and servers, databases, scheduled jobs (in autosys or suchlike). Generally each of these entities is grouped into some bucket for an application / "system" / business area, and then that bucket has a few owners assigned, and al…

Does Git not provide this functionality? I'm curious.

You can use `git blame` for who touched a line last, but you should tread lightly with it. If you fix a typo in a comment, move some whitespace, etc, you're now to "blame".

Re: Ask HN: How do you handle code ownership?

#47

Post by snidane »

rufius wrote: post #24

In our case, teams don't own projects/code-bases, they own "features" and "releases". About 67% of our code is some form of Ruby - some of it Rails, some of it custom Ruby code running in Kubernetes+Docker processing data. The other 33% of our code is Rust - and not just service side code but Rust that has to run on multiple platforms with varying deep operating systems knowledge. My team generally owns Features and…

I like the idea of owning features and releases. This lets the team to assign a responsible person for documenting and demoing the new feature or release.

How do you respond to emergencies when your people don't own projects or code bases? Who gets woken up at midnight? The person responsible for the latest release? Wouldn't that discourage people from deploying new releases?

Re: Ask HN: How do you handle code ownership?

#48

Post by [deleted] »

jfk13 wrote: post #34
d4mi3n wrote: post #20

Earlier quoted context omitted.

There’s an ongoing debate on “guys” being non-inclusive. I don’t personally buy into it, but that doesn’t make it an invalid position. I generally recommend calling people what they want to be called and exercising common courtesy.

There's certainly a history of "guys" being used specifically for men, as in "Guys and Dolls"; however, there is also an (increasing, I think) acceptance of its use in reference to mixed or even all-female groups. But not everyone is equally comfortable with that usage. In many contexts I think it should be clear enough whether an inclusive or gender-specific meaning is intended, but some people may prefer to avoid a…

[deleted]

Re: Ask HN: How do you handle code ownership?

#49

Post by drewmol »

jgrahamc wrote: post #8

1. I don't say "guys", I say "folks" 2. Code is owned by teams of people and not individuals.

Folks seems like a better fit.

I also enjoy the slight irony of advocating grammatical accuracy in a thread that uses the word "owns" to indicate "is responsible for maintainance, failure and modification", or what the top poster defined it as, or some other meaning that's definably not ownership ;-)

Re: Ask HN: How do you handle code ownership?

#50

Post by callmeed »

We care a lot about "ownership" in our teams. In fact, its one of our core values. But I don't think we define it the way you mean here. To us, it means putting care, professionalism, and follow-through into the feature or release you're working on (as others have mentioned). Did you put thought into your design and seek feedback before you started coding? Did you confirm your assumptions about how things work now? Did you write/update tests? Did you write/update documentation? After release/deployment to production, did you verify acceptance criteria and monitor performance?

That's what we mean when we say "ownership".

Your question implies a single person owning a specific feature or system component ad infinitum. That's generally a bad idea. Yes, some people will naturally have more experience/expertise in some areas. Yes, those people should be called to review PRs/releases in those areas. But your long-term goal should be to increase your bus factor[1] and spread knowledge. It is a win-win: it improves velocity and reduces risk for your org, while also giving your engineers a chance to learn and grow professionally.

Long-term silos of ownership shouldn't be your goal.

[1] https://en.wikipedia.org/wiki/Bus_factor

Post reply on HN