Hacker News Reader

Comment by mtlynch | Hacker News Reader

Author here. Happy to answer any questions or take any feedback about this post.

Hey, meta comment since I found this post first through your meta post / tweets about trying to get this to the front page of HN.

It's great content, and exactly the kind of things I want to read here, but wondered if you had thoughts about how to solve the Goodhart's law[0] effect. e.g. in an ideal world for me (and I guess for you too), the best posts would more naturally rise to the top of places like HN that ostensibly act as quality filters.

I really like your posting advice in general as most of it is about 'how to improve quality', but some of it (choosing what time to post at etc) falls into 'how to improve my chances at this gambling like system'.

I have mixed feelings about this. Having a higher barrier to entry does lead to higher quality posts (and in one possible future, only people who have read the 'how to get to front page of HN' guide can get to the front page of HN). On the other hand, I've seen the problem of 'should we invest this dollar into producing a better quality Widget or into telling people more effectively that our Widgets are the best?' kill entire organizations when the see-saw tilts too much to the latter.

Maybe I'm relating some things too broadly and it's actually nothing more than 'hey I post high quality content and do things to help it succeed', but wondering if you've thought about this tradeoff at all / if you're worried about getting deeper into the metrics rabbit hole that you've discussed in some of your other posts.

[0] https://en.wikipedia.org/wiki/Goodhart%27s_law

Hey Gareth, good question!

It's unusual for me to try to "time" my submissions to Hacker News. When I published this post, I thought it would be interesting to live tweet my publication day process,[0] so I published sooner than I originally planned because it was a slow news day on HN. But it ended up not gaining traction on HN that day anyway, so even that optimization seemed to have no effect.

But overall, I think the HN filter works pretty well. I can't think of anything I do to get an edge aside from investing a lot more time into editing and illustrations than I think most bloggers do, but that would be the filter working as intended.

I do worry about taking scores and readership metrics too personally. When I published my first code review article back in 2017,[1] it flopped on Hacker News and on reddit, the two places I was hoping it would find readers. I felt awful because I spent more time on it than I'd ever spent on a blog post before.

I took a break from watching the metrics and went for a run, and that cleared my head. I decided that I felt good about the post regardless of what response it got, and I need to have that attitude on future posts. When I got back from my run, it had taken off on reddit, which made me excited but also kind of interfered with the lesson I was hoping to learn. But I do try to view my articles mainly in terms of how good I feel about them and maybe 20% what kind of response they get.

[0] https://twitter.com/deliberatecoder/status/13341560121321185...

[1] https://mtlynch.io/human-code-reviews-1/

Thanks for the response! I made that 2017 post compulsory reading for a bunch of code reviewers I helped train if that counts for anything :)

Wanted to add one thing I noticed after I've been on the reviewing side for a while. Add a section in the description of the MR describing how the changes were tested. If this is detailed enough and covers all the edge cases I worry about, sometimes I don't even need to look at the code to be comfortable with approving the change. Conversely, it's frustrating when I get a MR with a blank or generic description without any notes on purpose, approach, how it was tested, etc.

Oh, that's interesting. I'd really only want to do that for things that are hard to test automatically. I have 100x more confidence in a test where I can see the source for it and watch it run in CI. But I agree that for exceptional cases where it's hard to write test automation, it's a good idea to explain how the author verified the changes.

This is an excellent article, making several points that I would not have thought of if I were to write on the same topic (point 11, for instance.)

I would, however, like to make a point about commenting, as there are at least three related cases where renaming identifiers and restructuring logic is not sufficient. The first thing is where one is doing something non-obvious on account of an unintuitive (and possibly undocumented) fact about either the problem domain or some remote part of the the system that it is infeasible to change; the second is some non-obvious corner-case (a subtle issue of thread- or exception-safety, for example); and the third is where the algorithm itself is non-obvious (Jon Bentley wrote of a colleage who found that one of his algorithms had beem 'fixed' and 'improved' to the point where it was no longer efficient; a suitable comment might have avoided that (and there's also the famous /* You are not expected to understand this */, for which no mere restructuring or renaming seems to offer an effective alternative.))

I am sure you are aware of these exceptions, but not everyone on the comment-deprecating bandwagon seem to do so.

https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6t...

Thanks for reading!

I absolutely agree with all of the exceptions you listed. I'm totally in support of comments when they're used judiciously.

To add a bit of context, a tendency I've noticed when I encourage people to answer questions with the code is that they think that means "add a comment in case anyone else has this question," when really what I want them to think is, "rewrite the logic so nobody else has this question. If that's not possible, add a comment." In other words, a comment should be the last resort for explaining code rather than the first line of defense.

First I just wanted to say I loved the doggo and the general tone of the post.

Also wanted to say that there's a lot of parallel between code reviews and "work review" in Investment Banking. Tooling aside, the underlying concept behind your tips is likely true for a variety of sectors, so I do wonder if one could dig a level deeper and find that essential truth in how to properly manage write-review workflows. Just some food for thought in case you want to jump into that rabbit hole.

Thanks for reading!

That's interesting about "work review" in Investment Banking. I've never heard that term and Google isn't helping me out much. Do you have a recommendation on where I could learn more?

I have noticed that things like this aren't too far removed from other fields. When I wrote my article about reviewing code from the reviewer's side[0], I got feedback that most of the techniques apply to giving feedback in other domains. And while I was writing my guide to hiring writers,[1] I realized that the process is 80% identical to my process for hiring developers and graphic designers.

The thing that's tough about going more abstract is that it becomes hard to convince any particular group that the content is worth reading. Focusing on code review appeals to HN because a large percentage of the audience is developers, but if it was a more general guide to improving review workflows, I'd have a harder time convincing HN readers that it was relevant to them.

[0] https://mtlynch.io/human-code-reviews-1/

[1] https://mtlynch.io/hiring-content-writers/

Love the concept of reviewing your own code first. I’ve been doing that for the longest now and usually find something I missed when reviewing my own code. I think I have taken this for granted and assumed everyone does this.

Thanks for reading!

Yeah, I had the same assumption for years. And then I started to realize that people would submit PRs to me where there's a ton of debug logging code left in or git merge markers they accidentally didn't fix. I thought, "Wait, are some authors not even reading this before they send it out?"

"fall in love with you" is catchy but not the right interpersonal dynamic. Something like "love reviewing your code" is better.

Sure but that wouldn't get on the 1st page, right?

The one weird trick that will make your coworkers fall in love with your Pull Requests.

This is good guidance to junior devs. I see these issues frequently from the reviewer side.

The title is super creepy though, so is the claim that "your reviewer will literally fall in love with you". I review code from my team every day, including code written by young engineers, male and female. I can't point them to this.

Ugh. Stopped reading after this bit:

  They’re going to fall in love with you. Deal with it.
  Nobody ever complained on their deathbed that too many
  people fell in love with them.

That's just so outright dumb + wrong. Assumed the rest of the article would be of similar low quality, so left.

That was in jest. I assumed readers would understand that nobody's going to fall in love over proper code review technique.

Can you write a counter article?

Unfortunately, I'm incredibly handsome, charismatic, and just generally awesome, and as a result this keeps happening to me.

There's always lots of drama when I just want to remain co-workers, and I've had to move on often.

Help appreciated.

Reply on news.ycombinator.com