How to Make Your Code Reviewer Fall in Love with You

Re:How to Make Your Code Reviewer Fall in Love with You by mumblemumble on Monday December 07, 2020 @05:32PM (#25338616)

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.

[ Parent | on HN ]

Re:How to Make Your Code Reviewer Fall in Love with You by jbverschoor on Monday December 07, 2020 @06:23PM (#25339160)

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

[ Parent | on HN ]

Re:How to Make Your Code Reviewer Fall in Love with You by KPLauritzen on Tuesday December 08, 2020 @02:19AM (#25342762)

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

[ Parent | on HN ]

Re:How to Make Your Code Reviewer Fall in Love with You by randomswede on Tuesday December 08, 2020 @03:23AM (#25343119)

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

And latency.

[ Parent | on HN ]

Re:How to Make Your Code Reviewer Fall in Love with You by lmilcin on Tuesday December 08, 2020 @08:30AM (#25344746)

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.

[ Parent | on HN ]

Re:How to Make Your Code Reviewer Fall in Love with You by randomswede on Tuesday December 08, 2020 @05:17PM (#25352172)

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".

[ Parent | on HN ]

Re:How to Make Your Code Reviewer Fall in Love with You by lmilcin on Wednesday December 09, 2020 @06:11AM (#25357422)

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.

[ Parent | on HN ]