4 ms·

i have the guilts reviewing work of non native english speakers and asking them to rename functions after review. hard to ask for it without it seeming complet

i have the guilts reviewing work of non native english speakers and asking them to rename functions after review. hard to ask for it without it seeming completely petty, particularly when everything else is perfect. it does represent a minor improvement.

acdha 12y ago
It definitely requires some tact and thought first. The angle I like to focus on is whether something will actively confuse future maintainers. If it's an internal method and the name is odd but not misleading, it's probably not worth raising at a code review or maybe even privately
- throwawayaway 12y ago
  yeah it's definitely not one for the rooftops with a megaphone anyway.
  - acdha 12y ago
    This is also a good time for many of us to work on social skills: most people like getting help with a second language as long as it's not putting them on the spot & if you have a good relationship with someone you can bring it up at the right time more along the lines of “Isn't English so absurdly arbitrary?” than something to be defensive about.
    - pluma 12y ago
      I think this is being unnecessarily non-confrontational. As long as you explain why the term is wrong or sub-optimal and what it should be called instead, I can't see how any serious programmers should take offence. Consider it this way: natively speaking English means you have domain knowledge, sharing that domain knowledge should feel no different from pointing out mistakes in other domains. If someone gets English wrong, that's no different from getting, say, VAT calculation wrong. Maybe I'm just assuming everyone already handles mistakes in other domains with tact and respect. Also, it's a matter of proportion. If a function name is extremely misleading that's different from a function name just using an awkward synonym, just as a broken piece of code is different from dodgy indentation. You'll want to fix either problem eventually, but the immediate repercussions are quite different (serious bug vs minor annoyance, basically).
      - acdha 12y ago
        > As long as you explain why the term is wrong or sub-optimal and what it should be called instead I think we're generally in agreement – I was trying to keep the focus on things which can be reasonably be considered objectively wrong and keeping the degree of wrongness in mind when deciding how to handle it. If you're on the low end of that scale, it's probably not a good use for everyone's time in a code-review session unless it happens a lot.
duwease 12y ago
That's valuable work in my eyes.. a little effort helps a lot when returning to the code (or having someone else use it) later. Bad naming even causes unnecessary confusion once I'm immersed in the code base.. the fifth time or so I have to ask myself "Which one generated the view, 'processAnnotation' or 'handleAnnotation'?", I just spend the time to refactor.
jonahx 12y ago
Naming is incredibly important. I don't think that's petty at all.
pluma 12y ago
As a non-native English speaker, I can tell you that this is not only perfectly acceptable but actually a good thing. Naming is important. Bad function names are a bug in the API, just like any other API bug. Non-native speakers frequently struggle naming things even more than native speakers, especially when they have to deal with a problem domain for the first time. Just like any other mistake, bad function names usually aren't intentional -- often quite the opposite. I remember struggling with naming business domain related functions and variables in the first booking system I worked on, especially because the UI wasn't localized into English, so I had no direct reference. Should this class be called Invoice or Bill? Are the terms "netto" and "brutto" commonly used in English as they are in German? What's the proper plural of "index"? And so on. Having tactful help from a native speaker can be a huge advantage.
whyaduck 12y ago
This problem isn't isolated to non-native English speakers. The potential cost of poorly named methods/variables/classes, etc. is high enough on a complex product that it's almost always worth raising the issue in reviews. If your reviews are run positively it really shouldn't be an issue. As an aside, I recently saw a job listing that included the requirement to be able to "defend your code in reviews" - I would say that's an environment where reviews probably aren't positive experiences.
- clay_to_n 12y ago
  On the other hand, I could see that as meaning "know what you're talking about so that you can defend the decisions you make." As an intern, I've had many times where I'd say "I did it this way using A B and C, is that the best way? Are there any improvements you'd suggest?" after completing work. But in a more senior position, you probably don't want people second guessing / not really understanding these decisions.
  - whyaduck 12y ago
    I have no problem with anyone, from interns on up, constructively criticizing my code/architecture/design decisions. I work for a company with an exceptionally strong engineering culture and no one shies away from expressing an opinion when invited (and sometimes when not invited). That said, "defend" is a poor choice of words for code review. If someone asks me why I did something, I tell them. It's not a defense, it's an explanation. If they have a better way to do what needs to be done that's GOOD. If we disagree, we discuss why we disagree. Defending is what you do when someone's attacking you, not when you're collaborating.
rogerbinns 12y ago
There are two hard problems in computer science: naming things, cache invalidation and off by one errors.
coolguy43 12y ago
I believe that the best way is to practice english with native speakers. There are now sites like http://preply.com/en/skype/english-native-speakers http://preply.com/en/skype/english-native-speakers that offers tutorials or you can just find a native speaker in person and try to casually converse from time to time.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]

acdha 12y ago

It definitely requires some tact and thought first. The angle I like to focus on is whether something will actively confuse future maintainers. If it's an internal method and the name is odd but not misleading, it's probably not worth raising at a code review or maybe even privately

throwawayaway 12y ago
yeah it's definitely not one for the rooftops with a megaphone anyway.
- acdha 12y ago
  This is also a good time for many of us to work on social skills: most people like getting help with a second language as long as it's not putting them on the spot & if you have a good relationship with someone you can bring it up at the right time more along the lines of “Isn't English so absurdly arbitrary?” than something to be defensive about.
  - pluma 12y ago
    I think this is being unnecessarily non-confrontational. As long as you explain why the term is wrong or sub-optimal and what it should be called instead, I can't see how any serious programmers should take offence. Consider it this way: natively speaking English means you have domain knowledge, sharing that domain knowledge should feel no different from pointing out mistakes in other domains. If someone gets English wrong, that's no different from getting, say, VAT calculation wrong. Maybe I'm just assuming everyone already handles mistakes in other domains with tact and respect. Also, it's a matter of proportion. If a function name is extremely misleading that's different from a function name just using an awkward synonym, just as a broken piece of code is different from dodgy indentation. You'll want to fix either problem eventually, but the immediate repercussions are quite different (serious bug vs minor annoyance, basically).
    - acdha 12y ago
      > As long as you explain why the term is wrong or sub-optimal and what it should be called instead I think we're generally in agreement – I was trying to keep the focus on things which can be reasonably be considered objectively wrong and keeping the degree of wrongness in mind when deciding how to handle it. If you're on the low end of that scale, it's probably not a good use for everyone's time in a code-review session unless it happens a lot.

duwease 12y ago

That's valuable work in my eyes.. a little effort helps a lot when returning to the code (or having someone else use it) later. Bad naming even causes unnecessary confusion once I'm immersed in the code base.. the fifth time or so I have to ask myself "Which one generated the view, 'processAnnotation' or 'handleAnnotation'?", I just spend the time to refactor.

jonahx 12y ago

Naming is incredibly important. I don't think that's petty at all.

pluma 12y ago

As a non-native English speaker, I can tell you that this is not only perfectly acceptable but actually a good thing. Naming is important. Bad function names are a bug in the API, just like any other API bug. Non-native speakers frequently struggle naming things even more than native speakers, especially when they have to deal with a problem domain for the first time. Just like any other mistake, bad function names usually aren't intentional -- often quite the opposite. I remember struggling with naming business domain related functions and variables in the first booking system I worked on, especially because the UI wasn't localized into English, so I had no direct reference. Should this class be called Invoice or Bill? Are the terms "netto" and "brutto" commonly used in English as they are in German? What's the proper plural of "index"? And so on. Having tactful help from a native speaker can be a huge advantage.

whyaduck 12y ago

This problem isn't isolated to non-native English speakers. The potential cost of poorly named methods/variables/classes, etc. is high enough on a complex product that it's almost always worth raising the issue in reviews. If your reviews are run positively it really shouldn't be an issue. As an aside, I recently saw a job listing that included the requirement to be able to "defend your code in reviews" - I would say that's an environment where reviews probably aren't positive experiences.

clay_to_n 12y ago
On the other hand, I could see that as meaning "know what you're talking about so that you can defend the decisions you make." As an intern, I've had many times where I'd say "I did it this way using A B and C, is that the best way? Are there any improvements you'd suggest?" after completing work. But in a more senior position, you probably don't want people second guessing / not really understanding these decisions.
- whyaduck 12y ago
  I have no problem with anyone, from interns on up, constructively criticizing my code/architecture/design decisions. I work for a company with an exceptionally strong engineering culture and no one shies away from expressing an opinion when invited (and sometimes when not invited). That said, "defend" is a poor choice of words for code review. If someone asks me why I did something, I tell them. It's not a defense, it's an explanation. If they have a better way to do what needs to be done that's GOOD. If we disagree, we discuss why we disagree. Defending is what you do when someone's attacking you, not when you're collaborating.

rogerbinns 12y ago

There are two hard problems in computer science: naming things, cache invalidation and off by one errors.

coolguy43 12y ago

I believe that the best way is to practice english with native speakers. There are now sites like http://preply.com/en/skype/english-native-speakers http://preply.com/en/skype/english-native-speakers that offers tutorials or you can just find a native speaker in person and try to casually converse from time to time.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]