Comment by necovek
2 days ago
On the first category, what is a process you use which has no "holes" in it?
Does everybody produce completely readable, tested code every time? Perhaps that's just "style" to you when it is "maintainability" to me?
2 days ago
On the first category, what is a process you use which has no "holes" in it?
Does everybody produce completely readable, tested code every time? Perhaps that's just "style" to you when it is "maintainability" to me?
> Does everybody produce completely readable, tested code every time?
Do your coworkers not reliably produce readable, tested code?
That's kind of the minimum bar for a software engineer in my book
I like to invert that to: do I produce code I am perfectly happy with in regards to readability and maintainability or would I benefit from another pair of eyes?
Every question I get (when my code is reviewed) is a signal that code could be more self-explanatory, unless it is a complex algorithm itself, and that my — by now deep — exposure to the problem is keeping me misguided about what is and isn't "obvious" or "clear". A reviewer can take a step back and help ensure both them and I will be able to easily grasp the same code 3 or 24 months later.
Note that one of the best advice I got early in my career about doing a good code review is that you "just" need to ask good questions: the point is not for a reviewer to show how much smarter they are, but for both to develop a shared understanding and ensure code can be interpreted as quickly as possible.