Hacker News Reader

Comment by edudobay | Hacker News Reader

I can't tell if the previous comment was ironic, but it seems to me that developers seeing things that way is a sign of immaturity or unprofessionalism.

Why must developers write and ship code? To deliver a certain goal / feature / business value. If all they're willing to do is writing and shipping code without considering how will that software work in the future, what problems it might have, how hard it will be to make changes to it, they're not being responsible enough about their work.

Software in general (except for throwaway code) is not supposed to work only NOW — it is expected to work for a long time, with an acceptable degree of quality, and with changing requirements.

If, to build a wall, it takes longer than just laying some bricks, it is because a solid wall serves many more purposes than some layers of bricks.

View on HN

What does the business really want? If it is more or less worming code, or perfect code? Or somewhere in the vast continum between?

Code review is one tool in a large set to get closer to perfect. However if the business doesn't care to get there why are you doing it at all?

Of course if you care at all about quality code review is one of the better bang for buck tools and so maybe you need to change your culture around peer correction so it can be used. The choice is your companies.

Code review is not about perfection – it is about peer review, much like in science, recognizing that a single person might have overlooked a lot of important stuff, and recognizing that collaboration usually leads to higher quality work.

Of course the desired level of quality will be different at each company/team, and each team should adjust for its own reality.

In the same team there can be times for throwaway code with low standards, and times for high quality code with strict standards. It is part of the developers' responsibility to tell them apart and make contextualised choices.

In practice code review allows 1 or 2 people on the team to insist on their preferences throughout the project.

I once saw a 3-4 line fix turn into a rewrite of an entire page that took several full-time days to finish because the developer didn't like the original fix. I've seen a former DBA turned software dev insist on using nulls throughout the codebase rather than empty strings and ignore the argument that's not considered good practice as a software developer because they themselves are "now software developers".

And the rebuttal is always the same, "well you're just doing it wrong". Maybe, but it gets done wrong more often than right.

I'm not against code review per se, but the number of times I've seen silly and arbitrary changes because of one developer's sensibilities is way too high.

If you don't care about people overlooking things and otherwise turning in low quality work, then don't do code reviews.

In short your very words prove that you are wrong and code review is about getting to perfection. (along with types, formal proofs, tests, static analysis, and a few dozen other tools that are often used).

Reply on news.ycombinator.com