Why Code Snobs Are Invaluable • Hacker News Board

Re: Why Code Snobs Are Invaluable

#11

Post by eldavido » Thu, Feb 26, 2015, 5:44 PM UTC

It depends a lot on your mentality toward writing code. I find matching the long/short-termness of engineering practice to the overall mentality of the organization results in the least friction.

Concrete example: if you're building a system to last 5-10 years, act like it. Spend time getting the architecture, the variable names, and the module structure correct. But realize not everything must be built to last. I read somewhere else on HN that some groups inside of Google plan a piece of code to handle 10x growth in traffic/storage/resource use before it's thrown out outright and rewritten -- so don't overdesign.

Maybe the real lesson is to invest in sufficiently good modularity that it's easy to throw things out without too much pain. Nothing lasts forever.

Re: Why Code Snobs Are Invaluable

#12

Post by taeric » Thu, Feb 26, 2015, 5:46 PM UTC

picks_at_nits wrote: post #7

taeric wrote: post #6

Earlier quoted context omitted.

What about the colleague's who have successfully enshrined non-idiomatic variable naming and space rules in a project? They seem to have just as much of this argument on their side, as far as consistency and such. Yet I actually loathe the decisions, as it causes a ton of friction with standard tools.

I stand by “if the objection has some merit.” If you don’t think it has merit, deploy the counter-snobbery. Naming seems cut-and-dried, but there are other cases that aren’t so clear cut. What if there are two factions in a team, one of whom are very OO, the other are very functional?

Fights between paradigms is never fun. Especially as that seems to imply there will be fights between evangalists.

Re: Why Code Snobs Are Invaluable

#13

Post by picks_at_nits » Thu, Feb 26, 2015, 5:46 PM UTC

taeric wrote: post #8

I'm fine for code snobs. I just despise swimming against the tide in tooling and formatting. If you care enough that the code look a certain way, make sure this way is a few keystrokes away for any developer using standard tools. Then there are those that insist on highly flexible and overly engineered solutions. Yes, they got it to work. No, they aren't doing any favors to anyone that was wanting to pick up the code…

> Then there are those that insist on highly flexible and overly engineered solutions. Yes, they got it to work. No, they aren't doing any favors to anyone that was wanting to pick up the code and make changes.

https://en.wikipedia.org/wiki/Inner-platform_effect

Re: Why Code Snobs Are Invaluable

#14

Post by ryandrake » Thu, Feb 26, 2015, 5:50 PM UTC

taeric wrote: post #6

picks_at_nits wrote: post #4

Consider a colleague who constantly objects to non-idiomatic variable name casing (snake_case_in_ruby, camelCaseInJavaScript, dashes-in-lisp, scheme-predicates?, &c.) When you first get a comment like this, it may feel like friction. After all, the code works. The cost of holding up a deploy and changing your code feels all out of proportion to the benefit. And it’s easy to extrapolate this: “If I get this objection…

What about the colleague's who have successfully enshrined non-idiomatic variable naming and space rules in a project? They seem to have just as much of this argument on their side, as far as consistency and such. Yet I actually loathe the decisions, as it causes a ton of friction with standard tools.

The norm seems to be: Conform to what's currently in the code.

Whether it's variable names, your brace style or indenting lengths, it doesn't matter if you think your way is the best, what matters is fitting in with the existing (shared) codebase so it's readable to everyone who has been working on it for the last 5 years.

Same is true for non-style things. If your project is 100K lines of 1998-era "C-with-classes" C++ code, your modern, templated, header-only, lambda-using work of art is going to cause more friction than it helps.

Re: Why Code Snobs Are Invaluable

#15

Post by gumby » Thu, Feb 26, 2015, 5:50 PM UTC

The last sentence is key: 'Perhaps a "code snob" is simply the term lazy programmers use to describe their more disciplined peers.'

If your colleagues really are your peers -- in that you trust each other, don't get pissed off when someone else makes a stupid comment, or when someone points out (hopefully politely) that you made a stupid comment -- then "code snob" is a joke term.

If you aren't lucky enough to have fallen into one of those high performance teams, then both types exist: the helpful code snob and the condescending one. The latter isn't help at all.

Re: Why Code Snobs Are Invaluable

#16

Post by pekk » Thu, Feb 26, 2015, 5:51 PM UTC

taeric wrote: post #6

picks_at_nits wrote: post #4

Consider a colleague who constantly objects to non-idiomatic variable name casing (snake_case_in_ruby, camelCaseInJavaScript, dashes-in-lisp, scheme-predicates?, &c.) When you first get a comment like this, it may feel like friction. After all, the code works. The cost of holding up a deploy and changing your code feels all out of proportion to the benefit. And it’s easy to extrapolate this: “If I get this objection…

What about the colleague's who have successfully enshrined non-idiomatic variable naming and space rules in a project? They seem to have just as much of this argument on their side, as far as consistency and such. Yet I actually loathe the decisions, as it causes a ton of friction with standard tools.

This kind of policy has to be set up front (or at least on a going-forward basis) or it'll never happen. You obviously can't fix this, all you can do is look out for yourself.

Circles of people who all agree to do something wrong and reinforce each other in it are one of humanity's big problems...

Re: Why Code Snobs Are Invaluable

#17

Post by zaphar » Thu, Feb 26, 2015, 6:01 PM UTC

jemfinch wrote: post #5

Singletons were perhaps the worst possible example of code snobbery: code snobs ( real code snobs, as in "no true code snob") typically detest the singleton pattern as less maintainable, less testable, and less flexible than dependency injection.

Over reliance on singletons can indeed be less maintainable, less testable, and less flexible than dependency injection.

However sometimes a singleton is in fact more maintainable and improves the code massively. Nor do they have to be less testable when implemented well.

None of which detracts from the article which is about consistency in the code base. A knew jerk reaction to the singleton completely misses the point.

Re: Why Code Snobs Are Invaluable

#18

Post by wmil » Thu, Feb 26, 2015, 6:03 PM UTC

It depends what you mean by code snob... I've had a dev replace large section of my code with "cleaner" code that didn't work in all cases, comment out the failing tests, then push that.

Some people are convinced that making components isolated and aesthetically clean is more important than making them functional.

Re: Why Code Snobs Are Invaluable

#19

Post by ultrasaurus » Thu, Feb 26, 2015, 6:10 PM UTC

wmil wrote: post #18

It depends what you mean by code snob... I've had a dev replace large section of my code with "cleaner" code that didn't work in all cases, comment out the failing tests, then push that. Some people are convinced that making components isolated and aesthetically clean is more important than making them functional.

There's a pretty large distinction between reviewers that are manually linting the code base and ones who change code to be easier to read but less working :)

Re: Why Code Snobs Are Invaluable

#20

Post by verbin217 » Thu, Feb 26, 2015, 6:11 PM UTC

gumby wrote: post #15

The last sentence is key: 'Perhaps a "code snob" is simply the term lazy programmers use to describe their more disciplined peers.' If your colleagues really are your peers -- in that you trust each other, don't get pissed off when someone else makes a stupid comment, or when someone points out (hopefully politely) that you made a stupid comment -- then "code snob" is a joke term. If you aren't lucky enough to have f…

> the helpful code snob and the condescending one. The latter isn't help at all.

HA! You're straight up wrong. You're never going to find someone more motivated to BE right. They don't care about appearing to be right for lesser people. If you have skin thick enough to tolerate them they'll be immensely valuable. Also, their attitude is a huge disadvantage in the workplace causing them to be far more exploitable (cheaper) than their peers.