4 ms·

A related phenomenon: developers who generate a ton of LOC, create new services willy-nilly, and adopt new technologies to cure their boredom have the greatest

by dkarl 5y ago

A related phenomenon: developers who generate a ton of LOC, create new services willy-nilly, and adopt new technologies to cure their boredom have the greatest impact on coding norms in an organization. Developers who solve problems with less code and less complexity, and check to see if libraries already in use have the functionality they need before adopting new ones, those developers are less visible in the codebase, and it isn't obvious that others should see them as leaders and role models.

andyjsong 5y ago
Isn't generating a ton of LOC considered bad practice? If my pull request is over 1K LOC, most likely my review will take longer, increase cycle time, and be more bug prone?
- deleted 5y ago
  [deleted]
- vikingerik 5y ago
  Exactly - his point is that more LOC is more visible and more likely to exert influence, even if less LOC is structurally better.
windows2020 5y ago
One thing I dislike is superfluous code under the guise of best practices or defensive programming. Here's an opinion of mine I've found to be controversial: In JavaScript, I don't like to use ===/!== unless I'm actually operating on operands that can be multiple types.
- bigDinosaur 5y ago
  Hard disagree. Many more bugs are caused by the type coercion of '==' than are caused by people adding verbosity with the use of a single additional character. It also is way easier to read code when you don't have to worry about the type coercion possibilities of JS's double equals operator. Type coercion should be opt-in and not the default, if there are good reasons for it existing at all, since it inherently makes things more complicated. Imagine how absurd this position would be if there was an equivalent with the less/greater than operators...
  - deleted 5y ago
    [deleted]
- Gunax 5y ago
  Hmm, just curious why that would make it better. I think it's hard to justify because the cost is so low (it's an extra character, and possibly some confusion) but can have a big downside if the unexpected happens.
- beart 5y ago
  What happens if the code changes and something you thought was restricted to a single type, isn't anymore? Do you have to go through and update every equality check?
- BigJono 5y ago
  I think it's controversial because you have a really good point but your example kind of goes against your point rather than supporting it. '===' is a single operator in JS, just as '==' is. It's only superfluous in terms of character count (which barely matters at all), as opposed to token count or actual complexity. I'd argue that in the important metrics, '==' is actually more superfluous, in that it has a broader scope of functionality than '==='. When you use '==' to do an equality check you're essentially invoking something that does the check, but also does a bunch of implicit type conversion and checking between types, none of which you actually care about at all. I'm also not a fan of 'defensive programming', I think people fuck a lot of perfectly good code up trying to read the tea leaves about how other devs are going to poorly interact with it in the future. But using '===' is like saying "I just want to check equality". It's not adding something for the sake of defense (other than the single character), it's removing something useless for the sake of removing something useless. Which is a good thing for maintainability and bug prevention yada yada, but it also feels nice to do as a dev. That's why you see very few people arguing against '===' as a best practice, because incentives are mostly aligned in this case. It's not really like a lot of the other examples where something is seen as a 'best practice' in spite of being something that devs hate doing.
- fhars 5y ago
  You really prefer this https://javascriptwtf.com/wtf/javascript-holy-trinity https://javascriptwtf.com/wtf/javascript-holy-trinity to a well defined equality operator?
  - lloydatkinson 5y ago
    Agreed, it’s crazy they would want a coercive check in a dynamic language. I’m certainly glad ESLint will enforce sanity and ban ==
1vuio0pswjnm7 5y ago
"A related phenomenon: developers who generate a ton of LOC, create new services willy-nilly, and adopt new technologies to cure their boredom..." Perhaps the so-called "new technologies" were created out of boredom as well.
- sexy_panda 5y ago
  I think the problem is that everyone wants to make a name in the industry to get some of the fame.
oweiler 5y ago
And the heroes are those who fix problems in production, not the ones who prevent them in the first place.
bob1029 5y ago
The PRs that get the most attention from me are the ones with the fewest total lines modified. There is probably some important correlation between my engagememt at code review time and the quality of our software.

by dkarl 5y ago

andyjsong 5y ago

Isn't generating a ton of LOC considered bad practice? If my pull request is over 1K LOC, most likely my review will take longer, increase cycle time, and be more bug prone?

deleted 5y ago
[deleted]
vikingerik 5y ago
Exactly - his point is that more LOC is more visible and more likely to exert influence, even if less LOC is structurally better.

windows2020 5y ago

One thing I dislike is superfluous code under the guise of best practices or defensive programming. Here's an opinion of mine I've found to be controversial: In JavaScript, I don't like to use ===/!== unless I'm actually operating on operands that can be multiple types.

bigDinosaur 5y ago
Hard disagree. Many more bugs are caused by the type coercion of '==' than are caused by people adding verbosity with the use of a single additional character. It also is way easier to read code when you don't have to worry about the type coercion possibilities of JS's double equals operator. Type coercion should be opt-in and not the default, if there are good reasons for it existing at all, since it inherently makes things more complicated. Imagine how absurd this position would be if there was an equivalent with the less/greater than operators...
- deleted 5y ago
  [deleted]
Gunax 5y ago
Hmm, just curious why that would make it better. I think it's hard to justify because the cost is so low (it's an extra character, and possibly some confusion) but can have a big downside if the unexpected happens.
beart 5y ago
What happens if the code changes and something you thought was restricted to a single type, isn't anymore? Do you have to go through and update every equality check?
BigJono 5y ago
I think it's controversial because you have a really good point but your example kind of goes against your point rather than supporting it. '===' is a single operator in JS, just as '==' is. It's only superfluous in terms of character count (which barely matters at all), as opposed to token count or actual complexity. I'd argue that in the important metrics, '==' is actually more superfluous, in that it has a broader scope of functionality than '==='. When you use '==' to do an equality check you're essentially invoking something that does the check, but also does a bunch of implicit type conversion and checking between types, none of which you actually care about at all. I'm also not a fan of 'defensive programming', I think people fuck a lot of perfectly good code up trying to read the tea leaves about how other devs are going to poorly interact with it in the future. But using '===' is like saying "I just want to check equality". It's not adding something for the sake of defense (other than the single character), it's removing something useless for the sake of removing something useless. Which is a good thing for maintainability and bug prevention yada yada, but it also feels nice to do as a dev. That's why you see very few people arguing against '===' as a best practice, because incentives are mostly aligned in this case. It's not really like a lot of the other examples where something is seen as a 'best practice' in spite of being something that devs hate doing.
fhars 5y ago
You really prefer this https://javascriptwtf.com/wtf/javascript-holy-trinity https://javascriptwtf.com/wtf/javascript-holy-trinity to a well defined equality operator?
- lloydatkinson 5y ago
  Agreed, it’s crazy they would want a coercive check in a dynamic language. I’m certainly glad ESLint will enforce sanity and ban ==

1vuio0pswjnm7 5y ago

"A related phenomenon: developers who generate a ton of LOC, create new services willy-nilly, and adopt new technologies to cure their boredom..." Perhaps the so-called "new technologies" were created out of boredom as well.

sexy_panda 5y ago
I think the problem is that everyone wants to make a name in the industry to get some of the fame.

oweiler 5y ago

And the heroes are those who fix problems in production, not the ones who prevent them in the first place.

bob1029 5y ago

The PRs that get the most attention from me are the ones with the fewest total lines modified. There is probably some important correlation between my engagememt at code review time and the quality of our software.