Code review can be better • Hacker News Board

Re: Code review can be better

#141

Post by sdeframond » Thu, Aug 21, 2025, 8:47 AM UTC

3036e4 wrote: post #81

What bothered me for a long time with code reviews is that almost all useful things they catch (i.e. not nit-picking about subjective minor things that doesn't really matter) are much too late in the process. Not rarely the only (if any) useful outcome of a review is that everything has to be done from scratch in a different ways (completely new design) or that it is abandoned since it turns out it should never have…

I share your feelings.

Regarding design reviews, we used to have them at my current job. However we stopped doing both formal design documents and design reviews in favor of prototyping and iterative design.

The issue with the design phase is that we often failed to account for some important details. We spent considerable time discussing things and, when implementing, realized that we omitted some important detail or insight. But since we already invested that much time in the design phase, it was tempting to take shortcuts.

What's more, design reviews were not conducted by the whole team, since it would be counter-productive to have 10-more people in the same room. So we'd still discover things during code reviews.

And then not everyone is good at/motivated to producing good design documents.

In the end, I believe that any development team above 5 people is bound to encounter these kinds of inefficiencies. The ideal setup is to put 5 people in the same room with the PO and close to a few key users.

Re: Code review can be better

#142

Post by ChrisMarshallNY » Thu, Aug 21, 2025, 8:48 AM UTC

ozim wrote: post #102

epolanski wrote: post #87

Earlier quoted context omitted.

> and that isn't something I ever encountered in the wild (in any formal sense) Because in the software engineering world there is very little engineering involved. That being said, I also think that the industry is unwilling to accept the slowliness of the proper engineering process for various reasons, including non criticality of most software and the possibility to amend bugs and errors on the fly. Other engineer…

It still is engineering you only mistake design phase. Writing code is the design phase. You don’t need design phase for doing design. Will drop link to relevant video later.

I see there has been a “spirited discussion” on this. We can get fairly emotionally invested into our approaches.

In my experience (and I have quite a bit of it, in some fairly significant contexts), “It Depends” is really where it’s at. I’ve learned to take an “heuristic” approach to software development.

I think of what I do as “engineering,” but not because of particular practices or educational credentials. Rather, it has to do with the Discipline and Structure of my approach, and a laser focus on the end result.

I have learned that things don’t have to be “set in stone,” but can be flexed and reshaped, to fit a particular context and development goal, and that goals can shift, as the project progresses.

When I have worked in large, multidisciplinary teams (like supporting hardware platforms), the project often looked a lot more “waterfall,” than when I have worked in very small teams (or alone), on pure software products. I’ve also seen small projects killed by overstructure, and large projects, killed, by too much flexibility. I’ve learned to be very skeptical of “hard and fast” rules that are applied everywhere.

Nowadays, I tend to work alone, or on small teams, achieving modest goals. My work is very flexible, and I often start coding early, with an extremely vague upfront design. Having something on the breadboard can make all the difference.

I’ve learned that everything that I write down, “ossifies” the process (which isn’t always a bad thing), so I avoid writing stuff down, if possible. It still needs to be tracked, though, so the structure of my code becomes the record.

Communication overhead is a big deal. Everything I have to tell someone else, or that they need to tell me, adds rigidity and overhead. In many cases, it can’t be avoided, but we can figure out ways to reduce the burden of this crucial component.

It’s complicated, but then, if it were easy, everyone would be doing it.

Re: Code review can be better

#143

Post by AndrewDavis » Thu, Aug 21, 2025, 8:50 AM UTC

3036e4 wrote: post #126

jmholla wrote: post #116

Earlier quoted context omitted.

I also read this series of blog posts recently where the author, Hillel Wayne, talked to several "traditional" engineers that had made the switch to software. He came to a similar conclusion and while I was previously on the fence of how much of what software developers do could be considered engineering, it convinced me that software engineer is a valid title and that what we do is engineering. First post here: http…

I was an undergraduate (computer) engineer student, but like many of my friends at that time (dot-com boom) I did not graduate since it was too tempting to get a job and get well paid instead. However many, probably half, that I work with, and most that I worked with overall for the last 25+ years (since after I dropped out) have an engineering degree. Especially the younger ones, since this century it has been more…

I've decided that titles are mostly meaningless in software. What X title means in one org means another in a different one with near zero overlap, and another title might have considerable overlap with a differently named one but viewed lowly, borderline pejoratively at another org. Eg system admin vs devops vs sre. In one org sysadmins are deploying desktop machines with no expectations they can cut code, in my old role as one I was working with Linux systems, building glue and orchestration, and when things go wrong debugging backend code written by a development team. Something far closer to the work of "devops" or "sre".

As a aside, I find your example of doctor as amusing because it's overloaded with many considering the term a synonym of physician, and the confusion that can cause with other types of doctors.

Re: Code review can be better

#144

Post by grilledcheez » Thu, Aug 21, 2025, 8:52 AM UTC

skybrian wrote: post #104

3036e4 wrote: post #81

What bothered me for a long time with code reviews is that almost all useful things they catch (i.e. not nit-picking about subjective minor things that doesn't really matter) are much too late in the process. Not rarely the only (if any) useful outcome of a review is that everything has to be done from scratch in a different ways (completely new design) or that it is abandoned since it turns out it should never have…

One way to fix it: pair programming. You're getting feedback in real time as you write the code. Unfortunately, the conditions where it works well can be difficult to set up. You need people who are into it and have similar schedules. And you don't want two people waiting for tests to run.

It's crazy that we go out of our way to design processes (code review, design review) to avoid actually just... working together? And then we design organizations that optimize for those processes instead of optimizing for collaboration.

Re: Code review can be better

#145

Post by ghosty141 » Thu, Aug 21, 2025, 8:54 AM UTC

3036e4 wrote: post #81

What bothered me for a long time with code reviews is that almost all useful things they catch (i.e. not nit-picking about subjective minor things that doesn't really matter) are much too late in the process. Not rarely the only (if any) useful outcome of a review is that everything has to be done from scratch in a different ways (completely new design) or that it is abandoned since it turns out it should never have…

I work in a small team where we are essentially 4-6 core developers. When I develop a feature I usually talk about it with my coworkers once I made a rough draft in my head how I'd approach it. They do the same so our code reviews are mostly only the minor code smells etc. but we usually decide on the architecture together (2-3 people usually).

I find this to be one of the most important things in our team. Once people don't agree on code it all kinda goes downhill with nobody wanting to interact with code they didn't write for various reasons.

In bigger orgs I believe it's still doable this way as long as responsibilities are shared properly and it's not just 4 guys who know it all and 40 others depend on them.

Re: Code review can be better

#146

Post by lukan » Thu, Aug 21, 2025, 9:04 AM UTC

3036e4 wrote: post #126

jmholla wrote: post #116

Earlier quoted context omitted.

I also read this series of blog posts recently where the author, Hillel Wayne, talked to several "traditional" engineers that had made the switch to software. He came to a similar conclusion and while I was previously on the fence of how much of what software developers do could be considered engineering, it convinced me that software engineer is a valid title and that what we do is engineering. First post here: http…

I was an undergraduate (computer) engineer student, but like many of my friends at that time (dot-com boom) I did not graduate since it was too tempting to get a job and get well paid instead. However many, probably half, that I work with, and most that I worked with overall for the last 25+ years (since after I dropped out) have an engineering degree. Especially the younger ones, since this century it has been more…

If you are doing the work of an engineer and you do it right, I believe you are an engineer, whether you graduated, or not.

And proper software developement definitely has engineering parts. Otherwise titles are just labels.

Re: Code review can be better

#147

Post by flir » Thu, Aug 21, 2025, 9:11 AM UTC

3036e4 wrote: post #81

What bothered me for a long time with code reviews is that almost all useful things they catch (i.e. not nit-picking about subjective minor things that doesn't really matter) are much too late in the process. Not rarely the only (if any) useful outcome of a review is that everything has to be done from scratch in a different ways (completely new design) or that it is abandoned since it turns out it should never have…

You can get the same thing if you do user interface testing after you've built the thing. A design system can help there - at the very least, the change can feed back into the next revision of the playbook.

Even if you can't fix it this time, hopefully you've taught someone a better pattern. The direction of travel should still be positive.

On personal projects I've used architectural decision records, but I've never tried them with a team.

Re: Code review can be better

#148

Post by dotancohen » Thu, Aug 21, 2025, 9:15 AM UTC

lmm wrote: post #100

dotancohen wrote: post #83

Earlier quoted context omitted.

Bit Bucket had a git-related tool called Stash? I love Bit Bucket, but I'm glad I did not know about that.

There was a locally-hosted Git server platform called Stash. Atlassian bought it, rebranded it as "BitBucket Server" (positioned similarly to GitHub Enterprise or self-hosted GitLab) and gradually made it look and feel like BitBucket (the cloud product), even though they're actually completely separate codebases (or at least used to be).

But why was it ever called Stash? The word stash has particular meaning in git, and it's been that way since a very early git version.

Re: Code review can be better

#149

Post by dsego » Thu, Aug 21, 2025, 9:17 AM UTC

jbmsf wrote: post #61

Recently, I've been wondering about the point of code review as a whole. When I started my career, no one did code review. I'm old. At some point, my first company grew; we hired new people and started to offshore. Suddenly, you couldn't rely on developers having good judgement... or at least being responsible for fixing their own mess. Code review was a tool I discovered and made mandatory. A few years later, everyo…

You can also automate it now with AI code review tools. You get most of the benefits, it will catch most obvious mistakes and suggest code changes.

Re: Code review can be better

#150

Post by motorest » Thu, Aug 21, 2025, 9:22 AM UTC

mytailorisrich wrote: post #137

motorest wrote: post #136

Earlier quoted context omitted.

> You need a high level design up-front but it should not be cast in stone. Yes, you need a design that precedes code. > Writing code and iterating is how you learn and get to a good, working design. You are confusing waterfall-y "big design upfront" with having a design. It isn't. This isn't even the case in hard engineering fields such as aerospace where prototypes are used to iterate over design. In software engin…

> You are confusing waterfall-y "big design upfront" with having a design. I do not and I have explained it. > In software engineering fields you start with a design and you implement it And part of my previous comment is that this "waterfall-y" approach in which you design first and implement second does not work and has never worked. > you do not need to pay the cost of a big design upfront Exactly, and not only th…

> I do not and I have explained it.

You should review the sources of your confusions and personal misconceptions, as you deny design and then proceed to admit there is design.

> And part of my previous comment is that this "waterfall-y" approach in which you design first and implement second does not work and has never worked.

Nonsense. "Big design upfront" works, but is suboptimal in software development. That's why it's not used.

"Big design upfront" approaches are costly as it requires know-how and expertise to pull off, which most teams lack, and it assumes requirements don't change, which is never the case.

Once you acknowledge that requirements will change and new requirements will emerge, you start to think of strategies to accommodate them. In software development, unlike in any hard engineering field, the primary resource consumed is man-hours. This means that, unlike in hard engineering fields, a software development process can go through total rebuilds without jeopardizing their success. Therefore in software development there is less pressure to get every detail right at the start, and thus designs can be reviewed and implementations can be redone with minimal impact.

> Exactly, and not only that but usually requirements will also change along the way. The design can change and will change as you hit reality and learn while writing actual, working code.

Yes.

But you do need a design upfront, before code is written. Design means "know what you need to do". You need to have that in place to create tickets and allocate effort. It makes no sense at all to claim that writing code is the design stage. Only in amateur pet projects this is the case.