311–315 of 315 posts
Earlier quoted context omitted.
> I don't see any other reason to require code reviews before a change can be merged. In the US, a SOC 2 audit of your org’s change management process is going to be a really bad time without this.
Do I really have to add "...unless required by law/contract"?
Code reviews help. However, it is unclear to me if PRs are the best way to do them. I often find a walkthrough on a screen share a lot more helpful to receive/give feedback. It also ends up saving time. The downside of this approach is that it has to be synchronous.
Earlier quoted context omitted.
I don't believe that to be true. I believe the expected outcome is that people will still want code reviews on anything vaguely complex as insurance against fuckups . "Shit, WE missed something" is a nicer place to be than "I was sure I was perfect and I'm actually an idiot". It does however mean you don't sit around waiting for someone to approve a three line delete PR that you know is safe. The "Rubber Stamp" revie…
Since I am currently working in an environment that resembles GP's premise, I have to say that I find this take to be way too optimistic. I'd be exactly in the boat you describe (and actually: I've yet to see a situation where someone reviewing my code did not lead to improvements). But: If I want my code reviewed, I have to actually fight for it. Since everybody's workload is too high, even the willing often simply…
Was interesting to hear your experiences and maybe update my expectations of workplaces somewhat
Earlier quoted context omitted.
Since I am currently working in an environment that resembles GP's premise, I have to say that I find this take to be way too optimistic. I'd be exactly in the boat you describe (and actually: I've yet to see a situation where someone reviewing my code did not lead to improvements). But: If I want my code reviewed, I have to actually fight for it. Since everybody's workload is too high, even the willing often simply…
I appreciate the context and the different point of view! I live in a bubble of how I perceive my coworkers (and indeed myself), alongside the culture of my employer where "getting it right is more important than getting it out" Was interesting to hear your experiences and maybe update my expectations of workplaces somewhat
> [...] alongside the culture of my employer [...]
I think you've hit the nail on the head here. As many others have said in different HN posts, culture is hard to change. And I would also understand the argument that one can also enforce culture changes with policies; my hope up to now simply has always been that engineers could "overrule" some artificial time limits in favor of more collaboration by referencing such a policy.
I guess if you're starting from a context where code reviewing practices "just work", introducing explicit policies also can't improve much, anyway. On that note: If you happen to know a good heuristic to detect such cultures during interviews or the like, I would be extremely interested :)
Earlier quoted context omitted.
Yeah, IMO this is like a publisher saying "we don't have editors: we trust our authors". The intended ethos of editors and code review is that mistakes and imperfections are the norm, and you need a second pair of eyes to iron them out. That said, I do sometimes encounter individuals or cultures that seem to view code review more as a mechanism for catching abnormal/unexpected mistakes than as a normal part of the pr…
> this is like a publisher saying "we don't have editors: we trust our authors" No it's not. If an author produces gibberish and nobody checks, the published result is gibberish. And with print books uneditable in a run starting in the thousands. If a programmer produces gibberish, it won't compile. It also won't pass the unit test or acceptance tests, never mind QA or the alpha/beta testers.
But I think it's still the right analogy. You code review to make sure the code is comprehensible to other humans. You code review to make sure the tests (which are great automated protections) are protecting against the right things. And (most relevant to the analogy) getting those things wrong are not abnormalities that mean you're a bad programmer and we don't trust you, they're things that competent devs can get wrong all the time.