Hacker News Reader

Comment by mumblemumble | Hacker News Reader

This is one spot where I strongly prefer the standard from the Google guidelines[1]. "Reviewers should not require the author to polish every tiny piece of a CL before granting approval. Rather, the reviewer should balance out the need to make forward progress compared to the importance of the changes they are suggesting." Getting caught up in all the little details rarely serves this purpose; more likely it's being done in the service of something anti-productive like a personality conflict.

[1]: https://google.github.io/eng-practices/review/reviewer/stand...

View on HN

Moreover, Google’s style guides contain a very specific clause at the beginning. Here’s the example for Java.

> This document serves as the complete definition of Google's coding standards for source code in the Java™ Programming Language. A Java source file is described as being in Google Style if and only if it adheres to the rules herein.

https://google.github.io/styleguide/javaguide.html

Google requires all code to go through code review, so to avoid time being wasted by style disputes or reviews being sent back for style-only changes, style disputes are essentially banned. Anything that can be enforced by an auto-formatter or linter is so enforced. For anything else reviewers are expected to be able to cite the style guide to back up their requested change.

This practice seems to have spread into the community due to the popularity of Gofmt, and now other languages like Rust have a community-standardized formatter (rustfmt) and linter (Clippy). Many thousands of hours have probably been saved by this point by treating format akin to language syntax.

That's the ideal, but there's a kind of magical "nits of the gaps" effect where some folks will find gaps in what can be automatically handled, and zero in on them.

I once had a colleague who loved to nitpick variable names. Should that flag be named "continue" or "shouldContinue"? Or maybe the i variable should be renamed to index. Or maybe "row" and "column" should be renamed to "i" and "j". Sometimes "buffer" should be renamed to "data" and sometimes "data" should be renamed to "buffer".

It does not make sense to say that variable names don't matter just because there's no way to automate a style guide on the semantic content of variable names. Sometimes variable names matter quite a lot.

So interpret that particular part of their code review guide as being less about the value of automation, and more about how to guard against some of these social headaches. A culture of breaking ties toward the requester discourages nitpicking. A culture of breaking ties toward the reviewer encourages it. Even in the presence of linters.

The two most difficult things in programming.. caching and naming

The two most difficult things in programming: caching, naming and off-by-one errors.

The three most difficult things are naming, cache invalidation, off-by-one errors.

And latency.

Latency is not difficult.

It is just lack of knowledge or focus to understand the total execution path and remove unnecessary elements from it.

I have worked in algorithmic trading where I did research and I designed framework to respond to stock exchange messages within 5 microseconds, consistently.

5 microseconds is difficult and requires some special techniques but 100 microseconds is quite easy and requires just understanding what is execution path and removing all unnecessary operations from it.

If you look at contemporary developers and web frameworks it doesn't seem anybody puts particular care into understanding those things and only try to twiddle couple of things and see how that transfers to performance.

Latency is (where I am used to it) a hard physical limit imposed on the upper end by the speed of light. When you have a system that literally spans a planet, there's only so much clever algorithms (and hardware) can do to speed up the time difference between "things happen in one end" to "things happen on the other".

Yeah, it is hard problem when you are hitting physics.

But then it really isn't a problem -- it is a limitation. Nothing you can do much about.

There are of course types of applications where latency is really tough topic. For one, low-latency trading is where companies are in arms race against other low-latency market players and there is always improvements form improving your product's latency.

But in a typical situation like websites and corporate services, the latencies required are so large that it is quite easy to reach them -- just don't do anything stupid.

Reply on news.ycombinator.com