Why Code Snobs Are Invaluable
mjswensen.com
Why Code Snobs Are Invaluable
1–10 of 56 posts
Re: Why Code Snobs Are Invaluable
#2What 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.
Re: Why Code Snobs Are Invaluable
#3My experience tends to agree. A lot of things done in the name of not being a snob are really just laziness, the bad kind. And I know my own act shaped up almost instantly when I switched jobs and found myself surrounded by such folks.
Re: Why Code Snobs Are Invaluable
#4Consider 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 to every pull request, I’ll never get anything done!”
But you don’t need to get this objection to every pull request. If the objection has some merit, no matter how trivial, you can change your naming, and never hear this objection again.
And the entire code base will be a little bit better. Your change is for now, a little bit better is forever, and everyone changing the way they name variables to be a little bit better adds up to a lot better.
And so it is with other forms of code snobs. Although it may feel like it’s not worthwhile to change the code today, if it’s a meritorious objection, then the right thing to do is change it and learn to write it that way the first time around, to develop a habit of writing it that way.
And then everyone will end up being a little bit better. And with every new commit, the code will get better. And that adds up like compound interest into making the code a lot better.
Re: Why Code Snobs Are Invaluable
#5Singletons 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.
Re: Why Code Snobs Are Invaluable
#6Consider 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.
Re: Why Code Snobs Are Invaluable
#7Consider 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.
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?
Re: Why Code Snobs Are Invaluable
#8I'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 and make changes. (Been there, done that. On both ends.)
Basically, if you encounter a large amount of friction for every new contributor to your codebase. Consider that the source of that friction is not necessarily the "low quality" of the contributors.
Re: Why Code Snobs Are Invaluable
#9Code review is really useful. People should listen to reviews of their code, even if they're arguable, for the sake of team harmony and having a system of checks and balances.
But a "code snob" is not necessarily correct just because he is a snob and sounds confident. There is sometimes a calibration problem where someone is trying hard to enforce practices which are actually wrong, or argues vehemently against things which are normal and okay. This is actively counterproductive and it would be better just to have less enforcement.
One way to check for this calibration would be to ask whether the snob is advocating something that will obviously benefit people beyond the snob objectively, e.g. fewer broken builds or adhering to a widely used standard style. A useful reviewer isn't just pushing his own agenda.
Re: Why Code Snobs Are Invaluable
#10Singletons 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.
In the author's example it's about internal consistency, a bunch of other similar items are already singletons.
Better a consistent-but-suboptimal architecture than a random grab bag of varying quality.