undefined | Better HN

0 pointsswiftcoder10d ago0 comments

> in a few sentences, what do you expect out of a quality code review? (sounds like nothing in your case, but I am curious)

From my perspective, there are three sorts of PRs:

- One is very close to the final form of a particular change, and any feedback you get at that late stage is indicative of holes in your process.

- Another is one where someone throws something up and says "hey, this is an experiment, can I get feedback on the approach". This is great, the parameters are clear, not much to say about these.

- The 3rd sort is someone making a trivial 5-line patch to a makefile/cargo.toml/github workflow/etc. These add basically no value to anyone.

Of those only the 2nd type really brings much value, and those are the ones that folks would keep posting even if you didn't require PRs (since they have an actual question, or a cool thing to show off).

I'll also note that this only really negatively impacts small remote teams, because on a sufficiently large, co-located team, you just ask your buddy one desk over to rubber stamp all the trivial commits...

0 comments

3 comments · 1 top-level

necovek9d ago· 2 in thread

On the first category, what is a process you use which has no "holes" in it?

Does everybody produce completely readable, tested code every time? Perhaps that's just "style" to you when it is "maintainability" to me?

swiftcoderOP9d ago

> Does everybody produce completely readable, tested code every time?

Do your coworkers not reliably produce readable, tested code?

That's kind of the minimum bar for a software engineer in my book

necovek9d ago

I like to invert that to: do I produce code I am perfectly happy with in regards to readability and maintainability or would I benefit from another pair of eyes?

Every question I get (when my code is reviewed) is a signal that code could be more self-explanatory, unless it is a complex algorithm itself, and that my — by now deep — exposure to the problem is keeping me misguided about what is and isn't "obvious" or "clear". A reviewer can take a step back and help ensure both them and I will be able to easily grasp the same code 3 or 24 months later.

Note that one of the best advice I got early in my career about doing a good code review is that you "just" need to ask good questions: the point is not for a reviewer to show how much smarter they are, but for both to develop a shared understanding and ensure code can be interpreted as quickly as possible.

j / k navigate · click thread line to collapse