Ask HN: How do you handle code ownership?
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?
18 comments
- 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.
- 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.
> - 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).
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).
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.
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.
I'm not saying yours is like that, but I've definitely seen that happen.
Well, many things on your list are spot on but the ones that are shouldn’t be scary.
- end to end integration tests - if they are APIs, they for the most part have a Postman collections in the repo. If they are event based lambdas, they have the standard
- build pipeline and manual resource creation. It’s so easy to export a SAM template from the console it’s criminal to not at least do that. But, yeah we have a CodePipeline to do that.
I have been on the other side though of inheriting a lambda and wondering how the hell did they go through the write->debug->fix cycle? Did they actually load it to AWS first? I spent a day creating a “test harmess”. Not real AAA unit tests, just something I could run locally to debug.
- end to end integration tests - if they are APIs, they for the most part have a Postman collections in the repo. If they are event based lambdas, they have the standard
if __name__ == "__main__":
- build pipeline and manual resource creation. It’s so easy to export a SAM template from the console it’s criminal to not at least do that. But, yeah we have a CodePipeline to do that.
I have been on the other side though of inheriting a lambda and wondering how the hell did they go through the write->debug->fix cycle? Did they actually load it to AWS first? I spent a day creating a “test harmess”. Not real AAA unit tests, just something I could run locally to debug.
I do believe in giving people responsibility for an area/concern/system of code. It gives them a sense of responsibility and and encourages them to do good work. It allows some creativity and style. I limits turn-over. I agree with totally however.
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 best reviewers (by looking at history, chatting with others, etc) to ensure high quality and understanding.
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 best reviewers (by looking at history, chatting with others, etc) to ensure high quality and understanding.
Some people have claimed that in my organization. I think that can work for library code, and particularly libraries that are used in many different places.
But once you're talking about a service, or code that is only used by one service, then you need to have an owner (or a team of owners). If you still think there's no owner, then ask yourself who is going to get woken up at 2AM when it breaks, and that's your owner.
But once you're talking about a service, or code that is only used by one service, then you need to have an owner (or a team of owners). If you still think there's no owner, then ask yourself who is going to get woken up at 2AM when it breaks, and that's your owner.
For those looking for a deeper look into the subject (and are not self-deceiving about human nature in groups) I heartily recommend https://en.wikipedia.org/wiki/Diffusion_of_responsibility
the team owns the code. the whole team. whoever is oncall gets to wake up at 3am if there is an issue.
That works OK-ish for small organizations. When you have 1000 engineers, or even 100, it is no longer feasible to have a single on-caller who can keep up with changes enough to debug every system, much less the multiple on-callers you need in order to have an on-call rotation.
IME even in small organizations (<20 engineers) it's very easy to end up not knowing enough to debug everything, and your on-caller basically becomes a smart router. ie, they can debug enough to figure out that it's a DB problem, and then wake up the DB guy. This becomes really annoying for the on-caller, so there's an impetus to have more focused paging groups, and now you're back to having owners for services.
IME even in small organizations (<20 engineers) it's very easy to end up not knowing enough to debug everything, and your on-caller basically becomes a smart router. ie, they can debug enough to figure out that it's a DB problem, and then wake up the DB guy. This becomes really annoying for the on-caller, so there's an impetus to have more focused paging groups, and now you're back to having owners for services.
nope.
you need to know how the thing that you're responsible for works. no exceptions.
what you can have is an interface to another service/team that represents the boundary of your service. When shit breaks and you isolate the breakage to this dependency you wake them up (preferably you detect and you raise this automatically). bonus point if you thought about this as you were building your stuff and your service can work in degraded mode while the thing is solved.
owners for services if okay as long as owner == team. if owner == individual you're doomed + people owning critical things will hate you and their job.
what you can have is an interface to another service/team that represents the boundary of your service. When shit breaks and you isolate the breakage to this dependency you wake them up (preferably you detect and you raise this automatically). bonus point if you thought about this as you were building your stuff and your service can work in degraded mode while the thing is solved.
owners for services if okay as long as owner == team. if owner == individual you're doomed + people owning critical things will hate you and their job.
>owners for services if okay
This is pretty much the exact opposite of your assertion at the beginning of this thread, to wit:
>once you submit the code for review and it passes and gets merged everybody owns the code. Everybody.
Anyway, this last comment I agree with entirely, and is pretty much what I've been saying all along. So I'm glad we can agree.
>you need to know how the thing that you're responsible for works Agree with this as well, but a critical point is that "the thing you're responsible for" may be subset of "everything" in your organization. Maybe even a relatively tiny subset, in a large organization.
This is pretty much the exact opposite of your assertion at the beginning of this thread, to wit:
>once you submit the code for review and it passes and gets merged everybody owns the code. Everybody.
Anyway, this last comment I agree with entirely, and is pretty much what I've been saying all along. So I'm glad we can agree.
>you need to know how the thing that you're responsible for works Agree with this as well, but a critical point is that "the thing you're responsible for" may be subset of "everything" in your organization. Maybe even a relatively tiny subset, in a large organization.
yes. everybody in the team. i sure hope there aren't places out there where you have thousands of people each responsible for millions of lines of code.
my point was that you should not have individual code ownership and individual gatekeepers. I can see how that might be misinterpreted.
my point was that you should not have individual code ownership and individual gatekeepers. I can see how that might be misinterpreted.
What happens when you have 2M or 20M lines of code floating around? Is every engineer expected to know enough to fix (or at least patch) any issue at 3 am?
If you have 20M lines of code you hopefully have more than 1 team and you also hopefully have more than one service w/ the right interfaces/apis between them.
As unrealistic as it sound, yes, if you're oncall you need to be able to understand the problem and fix it/mitigate it at 3am. This opens another can of worms around what is worth of a 3am page and how development, deployment and monitoring should be done but if you wake me up I should be empowered to do something about it
As unrealistic as it sound, yes, if you're oncall you need to be able to understand the problem and fix it/mitigate it at 3am. This opens another can of worms around what is worth of a 3am page and how development, deployment and monitoring should be done but if you wake me up I should be empowered to do something about it
That's the beauty of code review, it gets also checked for maintainability and whether it's a code style everybody accepts. It's also possible without code review but that requires much more things to be in place.
Nothing is more frustrating than a single person pushing code that the other devs don't agree on and do have to fix/maintain actually.
Nothing is more frustrating than a single person pushing code that the other devs don't agree on and do have to fix/maintain actually.
yeah. the 10x-er usually play the role of wrecking havoc and after that the 0.1x-ers usually clean it up and stabilize it. If you're in that situation you need to get to greener pasture after you've put a reasonable amount of effort into explaining why this is bad + trying to raise awareness
Not sure if this matches my definition of 10x-er ;) No, but there is certainly some truth to it, those who routinely push a lot of code tend to be less stringent on following best practices. I think it's smart to keep changesets small but efficient without being neither too pedantic nor too sloppy. After all coding should still be a fun activity, even with all these crazy processes in place...
I prefer the term SME (Subject Matter Expert) over owner.
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
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
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 also other non-ownership roles assigned (developer role can check in code to those repos, prod support role can log into the servers owned by the bucket, etc).
It's generally heavily integrated with an LDAP directory, HR system to handle joiners and leavers, and also change management (Developers can only ssh to a production host during the change window of a change for that bucket).
These home-grown apps are generally old and clunky (written for IE6, with piecemeal improvements since then, that kind of thing), but hard to replace because they're integrated with so many other applications.
I tend to think that this would be a good opportunity for some (startup) to do a great job of this as an off-the-shelf product, with good integrations with Linux + Windows authentication, an API, nice web app, etc - it would be very easy to do better than the in-house systems filling this niche.
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 also other non-ownership roles assigned (developer role can check in code to those repos, prod support role can log into the servers owned by the bucket, etc).
It's generally heavily integrated with an LDAP directory, HR system to handle joiners and leavers, and also change management (Developers can only ssh to a production host during the change window of a change for that bucket).
These home-grown apps are generally old and clunky (written for IE6, with piecemeal improvements since then, that kind of thing), but hard to replace because they're integrated with so many other applications.
I tend to think that this would be a good opportunity for some (startup) to do a great job of this as an off-the-shelf product, with good integrations with Linux + Windows authentication, an API, nice web app, etc - it would be very easy to do better than the in-house systems filling this niche.
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".
Where do you work?
The office I work in has five development teams that cover different aspects of our service (provisioning from our customers, core product on Android, the UI for the Android code, servers, and call processing [1]). Each team has ownership of their respective products and how things are divided up are left to the teams themselves.
The team I'm on has three developers (I'm one of them) and for our team, we just kind of fell into ownership of different aspects. I deal with the programs that are customer facing (CDMA and SIP interfaces); the second developer deals with the business logic (a separate program) and the third deals with SMPP (also customer facing, but not as critical as the CDMA and SIP interfaces). And it's not like we (my team) are fiercely protecting our turf (each of our programs)---I have worked on both the business logic and SMPP service, but generally, each of us just gravitated to what we find enjoyable.
I do not know how the other teams divide their work.
Bug reporting is pretty each to route as each portion of our service is clearly delineated (with the possible exception of the Android core and UI teams).
As far as features go, it depends upon the feature. Yes, there are some features that affect all the teams (such as number to name translation---have to provision that, deal with obtaining the info during call processing and having the phone receive and display such information) and some that only affect one department (like supporting SIP---largely my team).
[1] I work in the call processing side of things.
The team I'm on has three developers (I'm one of them) and for our team, we just kind of fell into ownership of different aspects. I deal with the programs that are customer facing (CDMA and SIP interfaces); the second developer deals with the business logic (a separate program) and the third deals with SMPP (also customer facing, but not as critical as the CDMA and SIP interfaces). And it's not like we (my team) are fiercely protecting our turf (each of our programs)---I have worked on both the business logic and SMPP service, but generally, each of us just gravitated to what we find enjoyable.
I do not know how the other teams divide their work.
Bug reporting is pretty each to route as each portion of our service is clearly delineated (with the possible exception of the Android core and UI teams).
As far as features go, it depends upon the feature. Yes, there are some features that affect all the teams (such as number to name translation---have to provision that, deal with obtaining the info during call processing and having the phone receive and display such information) and some that only affect one department (like supporting SIP---largely my team).
[1] I work in the call processing side of things.
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 Releases related to the Rust code because two of the three members are OS programmers by experience. That said, we don't exclusively work on the Rust code and sometimes wander into the Ruby code base.
Similarly, other teams occasionally need to update the Rust code to generate some new data - a lot of that is pretty basic stuff and doesn't require deep OS knowledge. So they'll make changes there.
Since our stack is so heterogenous, it's hard to have everyone work on everything. However, from what I know of most companies outside Apple/MSFT/Google/etc, they're gonna fall in the "we own web services" where the only real bifurcation will be "frontend code" and then "middle-to-backend code". Maybe throw in some apps as well.
=========
Now all of that said - the reason we went to teams owning "features" and "releases" was to push folks to not be possessive of code. Stuff changes and it changes quickly, so there's not much use trying to isolate folks. Document gratuitously, test heavily, and refactor often.
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 Releases related to the Rust code because two of the three members are OS programmers by experience. That said, we don't exclusively work on the Rust code and sometimes wander into the Ruby code base.
Similarly, other teams occasionally need to update the Rust code to generate some new data - a lot of that is pretty basic stuff and doesn't require deep OS knowledge. So they'll make changes there.
Since our stack is so heterogenous, it's hard to have everyone work on everything. However, from what I know of most companies outside Apple/MSFT/Google/etc, they're gonna fall in the "we own web services" where the only real bifurcation will be "frontend code" and then "middle-to-backend code". Maybe throw in some apps as well.
=========
Now all of that said - the reason we went to teams owning "features" and "releases" was to push folks to not be possessive of code. Stuff changes and it changes quickly, so there's not much use trying to isolate folks. Document gratuitously, test heavily, and refactor often.
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?
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?
SRE + On Call Dev Engineer.
Basically SRE takes the page - if they can't troubleshoot it or restore it to normal service, then the on call engineer gets called.
In our case, we're still small enough that one on call engineer has to take the load regardless of feature/product.
The exception is the aforementioned Rust code base which calls myself or the other engineer. But this is because it's not running on our infra - it's running on customer boxes so that's a different support story.
Re:
> 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?
Culturally, our engineering team doesn't really tolerate "not deploying". That's not to say that you're being measured by number of deploys like some sort of perverse "IBM Lines of Code" metric - but you're expected to be deploying code as it's ready via PR + Tests.
It's not a perfect system but we've tried pretty hard during hiring to select folks that are well aligned with how we think about this. No one gets to own their space and no one is immune from rolling their sleeves up and figuring it out. If that isn't someone's thing, we try to find that out during the interview because it doesn't fly internally with the team.
Basically SRE takes the page - if they can't troubleshoot it or restore it to normal service, then the on call engineer gets called.
In our case, we're still small enough that one on call engineer has to take the load regardless of feature/product.
The exception is the aforementioned Rust code base which calls myself or the other engineer. But this is because it's not running on our infra - it's running on customer boxes so that's a different support story.
Re:
> 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?
Culturally, our engineering team doesn't really tolerate "not deploying". That's not to say that you're being measured by number of deploys like some sort of perverse "IBM Lines of Code" metric - but you're expected to be deploying code as it's ready via PR + Tests.
It's not a perfect system but we've tried pretty hard during hiring to select folks that are well aligned with how we think about this. No one gets to own their space and no one is immune from rolling their sleeves up and figuring it out. If that isn't someone's thing, we try to find that out during the interview because it doesn't fly internally with the team.
At 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.
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.
> 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.
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.
I hate that attitude. Especially if a bug is impacting something I am doing, I’ll just fix it myself and let them know.
[deleted]
Thanks for sharing.
What if that person leaves the company? Can that information get old.
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...
Everyone "owns" the code. Then there's the guy you go to when it fails.
Helps to document things, so you at least have something to throw at people when they come asking.
Helps to document things, so you at least have something to throw at people when they come asking.
Ideally you want to restrict changes to the owners (I don’t mean hard limits)
So instead of having a team responsible for a part of code, they are responsible for the product. So if a new integration is needed, the owner is a service provider and should provide the interface or service for their client. That is fairly easy to setup with Microservices. However, that is a bit harder in a monolithic application code base.
In my workplace, we use the above model for almost everything. And there is one old code base where we use Github code ownership feature to force everyone to ask for a code review from owners. But even there, it doesn’t happen very often that people from different domain need to touch a code of another domain.
And that is the second point as well. Dividing responsibilities base on domains instead of components/modules between teams make it easier as most of the time they are not going to touch a code outside their own domain.
In my workplace, we use the above model for almost everything. And there is one old code base where we use Github code ownership feature to force everyone to ask for a code review from owners. But even there, it doesn’t happen very often that people from different domain need to touch a code of another domain.
And that is the second point as well. Dividing responsibilities base on domains instead of components/modules between teams make it easier as most of the time they are not going to touch a code outside their own domain.
I work for a large global company, and my department is building a fairly large Angular application. My team "owns" the primary project and several shared component libraries, and other teams build features for this project.
These teams are from all over the world, and many of us have never worked closely before this project began.
When we first started the project, we decided to split the UI into feature projects which are packaged and referenced in the common project. Each team owns their own feature projects; however, everyone is welcome to contribute PRs to any of the projects.
Some of our projects are shared and maintained by many teams, but we always have one team that owns each project.
These teams are from all over the world, and many of us have never worked closely before this project began.
When we first started the project, we decided to split the UI into feature projects which are packaged and referenced in the common project. Each team owns their own feature projects; however, everyone is welcome to contribute PRs to any of the projects.
Some of our projects are shared and maintained by many teams, but we always have one team that owns each project.
By trusting the people working here. Anyone can commit anywhere, so long as they get a reviewer. We ask the reviewer to punt to someone better qualified if they're not sure how to best proceed.
I had written about this topic a few years ago. Hopefully it is of use to you and provides you the necessary tips.
https://www.softwareyoga.com/individual-code-ownership https://www.softwareyoga.com/collective-code-ownership
https://www.softwareyoga.com/individual-code-ownership https://www.softwareyoga.com/collective-code-ownership
I, 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.
We struggle with this question where I work and there is some toxicity.
I've been wondering if you could add a comment to the top of files to indicate ownership (//owners:someTeam, someGuy). Then your CI could parse the modified files and require a review from a team and/or send a notification to said user.
I've been wondering if you could add a comment to the top of files to indicate ownership (//owners:someTeam, someGuy). Then your CI could parse the modified files and require a review from a team and/or send a notification to said user.
Github has the code owners feature. A pull request can't be merged until all the owners approve.
and what if you don't use GitHub?
One option is that the feature is built on a plain text .gitignore-like (.gitattribute-like more accurately) CODEOWNERS file(s) in a repository that you could implement support for in whatever tools that you do use.
https://github.blog/2017-07-06-introducing-code-owners/
https://github.blog/2017-07-06-introducing-code-owners/
[deleted]
sure everyone “owns” the code, but I think having at least two people be the true owners and have full understanding of a module so they can debate details/direction, then everyone else floats around them contributing. I always imagine this as an ideal setup
git blame
hum.. person left.
recode my way around that code so the new feature works and I'm not tagged as the owner by future git blames.
/sarcasm. I think.
hum.. person left.
recode my way around that code so the new feature works and I'm not tagged as the owner by future git blames.
/sarcasm. I think.
1. I don't say "guys", I say "folks"
2. Code is owned by teams of people and not individuals.
2. Code is owned by teams of people and not individuals.
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.
The definition of "folks" is "people in general"
I'm not sure what point you are trying to make here.
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 any risk of misunderstanding by choosing a different word.
And unfortunately, as seems all to common these days, some may choose to see offence where none was intended.
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 any risk of misunderstanding by choosing a different word.
And unfortunately, as seems all to common these days, some may choose to see offence where none was intended.
[deleted]
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.
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.
>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.
Yeah, that's fair. I think we can agree that the meaning is ambiguous.
TBH I just figure that "folks" is a change that might, in some cases, make some people feel more welcome, at basically no expense in time, effort or clarity. Seems like a decent cost/benefit to me. But I don't get up in arms about it - this thread notwithstanding. ;)
And now I'm tired of talking about this. :)
Yeah, that's fair. I think we can agree that the meaning is ambiguous.
TBH I just figure that "folks" is a change that might, in some cases, make some people feel more welcome, at basically no expense in time, effort or clarity. Seems like a decent cost/benefit to me. But I don't get up in arms about it - this thread notwithstanding. ;)
And now I'm tired of talking about this. :)
The same could have been said about the word "man" a long time ago.
https://www.etymonline.com/word/Man
>Old English used wer and wif to distinguish the sexes, but wer began to disappear late 13c. and was replaced by man.
It would be pretty awesome if we'd kept to the wer/wif tradition. It'd make modern conversations a ton easier. Also, I'm fully onboard with calling males wermen or werman.
Final note, a female werewolf would be a wifwolf.
Sorry to totally geek out but I just wanted to point out the fluidity of definitions.
https://www.etymonline.com/word/Man
>Old English used wer and wif to distinguish the sexes, but wer began to disappear late 13c. and was replaced by man.
It would be pretty awesome if we'd kept to the wer/wif tradition. It'd make modern conversations a ton easier. Also, I'm fully onboard with calling males wermen or werman.
Final note, a female werewolf would be a wifwolf.
Sorry to totally geek out but I just wanted to point out the fluidity of definitions.
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.
> 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.
Experiment #2: Someone says, "OK, I want you guys to stand up." with no particular emphasis on any word or looking at particular people. Did something different happen? I think that's closer to the original post's usage. If you say it the way it's naturally said instead of the strawman way in this article, it's not explicitly gendered or exclusive, maybe just a little implicitly. Reason enough to dispose with it I guess, but let's argue from reality not a made-up caricature.
This is a really good point. The usage of the term really ads clarity to it's usage.
You guys - gender neutral. The guys - gender specific.
I think a lot of people who are annoyed by the term guys don't like the fact that there is a word that has both gender neutral and gender specific definitions being used as gender neutral.
Dudes is another one.
Spanish has an explanation for this (which i think is what people are frustrated by).
Ellos => them male Ellas => them female Ellos => a group of 10 women with one man in the bunch
You guys - gender neutral. The guys - gender specific.
I think a lot of people who are annoyed by the term guys don't like the fact that there is a word that has both gender neutral and gender specific definitions being used as gender neutral.
Dudes is another one.
Spanish has an explanation for this (which i think is what people are frustrated by).
Ellos => them male Ellas => them female Ellos => a group of 10 women with one man in the bunch
I think there's a distinction between 'you guys' and 'the guys', just like there's a difference between 'my baby' and 'the baby' in songs. If I said 'I want you guys to all stand up' I would expect everyone to stand up, if I said 'I want all the guys to stand up' I would expect only males to stand.
[deleted]
I like the counter-example: "How many guys have you dated?"
Still gender-neutral?
Still gender-neutral?
That's what dictionary.com says, and that's true in some places, but in other places "guys" is definitely gendered.
Imagine a group of cishet men saying : "I'm off to the strip club to see a bunch of guys taking their clothes off and dancing in a provocative manner."
Does that seem reasonable? If not, then the term "guys" is gendered.
On top of that, most of the women I know feel that "guys" is a term that excludes them. That's enough for me to avoid using it.
Imagine a group of cishet men saying : "I'm off to the strip club to see a bunch of guys taking their clothes off and dancing in a provocative manner."
Does that seem reasonable? If not, then the term "guys" is gendered.
On top of that, most of the women I know feel that "guys" is a term that excludes them. That's enough for me to avoid using it.
I think "guys" is gendered and using a non-gendered word is better when referring to a group of people.
1. Congratulations!
2. Agreed.
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 ;-)
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 ;-)