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

Why Code Snobs Are Invaluable

mjswensen.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: Why Code Snobs Are Invaluable

#31

Post by jeremiep »

andhof-mt wrote: post #21

But your thinking like a programmer. Some times it is also valuable to think like a business. What is the goal of this software? Ship now? MVP? Are we trying to polish the software? Or just get it to work? Is it a prototype? Some thoughts to take into consideration.

It could also be a double-edged sword. I've seen it happen more times than I can remember.

Management sets a clear deadline, we rush the code to get it done by its due date. Then the product sits there for months doing nothing while we're in between projects wasting time away. Half a year down the road we get asked for support because some things broke which would've been working fine had we taken the proper time to built them.

From personal experience, most businesses don't think in terms of maintenance and debugging. These are costs which can very quickly add up to way more than the saved development costs.

Re: Why Code Snobs Are Invaluable

#32

Post by joesmo »

Suppose that in the example given, changing the existing classes to not be singletons was just as valid as changing the new ones to be singletons. Or there was a good reason for the new classes not being singletons that the code reviewer did not understand. In these cases I'd call the reviewer a code snob. I don't think the reviewer in the example given is a code snob. A code snob to me is one who asks for or makes changes that have no benefit except to himself and might even be detrimental to the project. Since all changes do take time, the benefit of the changes absolutely need to outweigh the time spent making them for them to be valid.

Re: Why Code Snobs Are Invaluable

#33

Post by jeremiep »

dkarapetyan wrote: post #2

What about type theory weenies? The title is also a little link-baity. The person commenting on his pull request was not being a snob. He was making sure there was architectural coherence across the board. When codebases grow large having an idea of the overall architecture becomes an invaluable resource and the more consistent the codebase the easier it is to make sense of the architecture.

Type theory can help you build the proper abstractions to help the codebase grow and scale in a clean and manageable manner. It doesn't matter if you're working in Haskell or JavaScript either; types are still present and affect how well the different parts of the system can be composed together.

Re: Why Code Snobs Are Invaluable

#35

Post by gknoy »

dkarapetyan wrote: post #2

What about type theory weenies? The title is also a little link-baity. The person commenting on his pull request was not being a snob. He was making sure there was architectural coherence across the board. When codebases grow large having an idea of the overall architecture becomes an invaluable resource and the more consistent the codebase the easier it is to make sense of the architecture.

  The person commenting on his pull request was not being a snob. 
  He was making sure there was architectural coherence across the board.
This is actually the essence of the article. When people criticize things in our code that we see as "trivial", it's EASY to mistakenly ascribe that to snobbery or being a jerk. The entire point of this article is that we should look for the value that our peer is trying to add by pointing out inconsistencies or better ways of doing things.

Some of the best pull request comments for me have been the ones that made me say, "Dammit! .... you're right." Many of those PR comments have been replaced by impersonal linting tests that do the same, but the net result is still that I feel proud of what I write.

Re: Why Code Snobs Are Invaluable

#36

Post by richardlblair »

Where I work we keep on each other about nitpicky things, but when we do it, we declare it. You will frequently see "Nitpick: don't like the variable name. Maybe try "

And you know what? No one complains. If you don't want nitpicks, conform to the coding standard of the place of which you work. It is _their_ code after all.

Re: Why Code Snobs Are Invaluable

#37

Post by klagermkii »

I certainly support any drive for code that is cleaner or more consistent, I just feel like for every good "code snob" there are a lot of "code snobs" that are basically just bikeshedding.

By that I mean that they don't know how to fix poorly structured code, suggest a better algorithm, or improve the interface... but they still want to feel and look useful, so they instead burn a lot of time finding relatively trivial things to change.

Re: Why Code Snobs Are Invaluable

#38

Post by jaimefjorge »

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…

"And that adds up like compound interest into making the code a lot better."

Like inverse (or reverse) technical debt. Excellent way of putting why code reviews are important.

I would just add that while improving adds up, it shouldn't cover the fact that blocking the team because of camel case issues is not the best use of time. There are static analysis tools that are free and open source that can do this work.

We are spending between 1/5th to 1/10th of our time reviewing code[1]. Most of the times the disciplined have to carry the burden of being 'that guy' that always has something to say.

1: http://www.quora.com/How-much-per-day-or-week-do-engineers-s...

Re: Why Code Snobs Are Invaluable

#39

Post by Retra »

ryandrake wrote: post #14
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.

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…

This is why it is so awesome to encode your conventions into an auto-formatter.

Re: Why Code Snobs Are Invaluable

#40

Post by Retra »

thedudemabry wrote: post #27
zaphar wrote: post #17

Earlier quoted context omitted.

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 po…

I totally agree that the singleton detail is beside the article's point, but what is the modern case for singletons? It seems like singletons are now considered a synonym for global variables. What other purpose do they serve?

I wrote a singleton the other day. Using Java, I had a static utility class that had a function that I wanted to memoize. So I put a static HashMap in the class to do the lookups. There's no reason to have multiple copies, and it's easy to instantiate it only if it is needed.
Post reply on HN