3 ms·
Remember that as a reviewer, you always have an advantage over the coder: as the coder, you need to crack the problem and find an algorithmic solution. It's eas
by gmueckl 7y ago
Remember that as a reviewer, you always have an advantage over the coder: as the coder, you need to crack the problem and find an algorithmic solution. It's easy to have a couple of false starts with this. These do stick around through iterations and changes. Eventually, you submit something that works, but you're overlooking that the code could probably be less convoluted in places, because you know the solution and it is perfectly reasonable.
The reviewer who gets to read the code gets to walk the shortcut to the solution after the trail was blazed for them: they get to think purely about the working solution without the intermediate steps. And they naturally will find places where the original developer was thinking in terms of his failed earlier attempts.
I bet that if I gave you a non-trivial problem to solve in a reasonable amount of time I could do the same kind of review on your code, forcing you to shorten it. And I will find something. Guaranteed. That is just how these iterations work.
- jodrellblank 7y agoI bet that [..] I could do the same [..] And I will find something. Guaranteed. Why are you framing this as though it's adversarial and the parent comment is stating some kind of superiority, and you're here to turn it around and put them in their place? Isn't teamwork all about doing better than one person working alone?
- gmueckl 7y agoMy take on the parent comment is that it has some adversity and feeling of superiority to it. And I don't like that. I agree that in the end it is not a competition, I didn't think that I would have to point it out. In fact I am in the middle of fixing up code that I wrote as novel research because the powers that be want it in a production system. The code review I got was detailed and - frankly - embarassing at times because all the uncertainties and meanderings of research had me change pieces of code over and over and over again to a point where remnants of old approaches didn't stand out to me anymore and where I had at times built on top of bad decisions because they were meant as a temporary hack and experiment, but worked well enough and stayed in. And by the time I submitted the code for review I had become blind to these mistakes. I know how to write good and clean code and I get through code reviews easily when I know what I am doing. Not this time, though.