4 ms·

Is that a productive idea to push? Not to say you're wrong, but some hard human problems to solve are: - getting people to not be defensive during code review

Is that a productive idea to push? Not to say you're wrong, but some hard human problems to solve are: - getting people to not be defensive during code reviews - getting people willing to be critical (constructively) of their peers work Emphasizing that code reviews with productive design comments indicates a failing seems more likely to stop the comments, not to improve the design. Most people wont want to do the work multiple times and will quickly learn to do as you desire in the face of repeated code reviews that have comments pointing out design problems.

Mvhsz 7y ago
There are times that I get into the flow while coding and end up solving a few future problems in addition to right now problems. I know that the code is over-engineered, but if it passes all of the tests and there's nothing obviously wrong with it I would probably check it in anyway. Over engineering never comes up in our code reviews but I think it would be a productive conversation if it did - even if the decision was still to accept the code as-is. The programmers I work with can be defensive of their architecture, but they also love to talk about architecture generally. I think there's a "yes and" [0] way to bring this up that engages the whole team. [0] https://en.m.wikipedia.org/wiki/Yes,_and.. https://en.m.wikipedia.org/wiki/Yes,_and...
- onemoresoop 7y ago
  And then you decide to get another job and next guy to maintain the code is utterly confused and misdirected because let’s be honest, there’s no documentation or there is but is either not up to date or sparse, theres no thorough unit testing (lucky if there is any). Not saying that’s your case but it happened to me personally to be on the other end a few times and let me tell you, it’s quite an effort to ramp up on such projects.

4 ms·

Is that a productive idea to push? Not to say you're wrong, but some hard human problems to solve are: - getting people to not be defensive during code review

by ergothus 7y ago

Mvhsz 7y ago
There are times that I get into the flow while coding and end up solving a few future problems in addition to right now problems. I know that the code is over-engineered, but if it passes all of the tests and there's nothing obviously wrong with it I would probably check it in anyway. Over engineering never comes up in our code reviews but I think it would be a productive conversation if it did - even if the decision was still to accept the code as-is. The programmers I work with can be defensive of their architecture, but they also love to talk about architecture generally. I think there's a "yes and" [0] way to bring this up that engages the whole team. [0] https://en.m.wikipedia.org/wiki/Yes,_and.. https://en.m.wikipedia.org/wiki/Yes,_and...
- onemoresoop 7y ago
  And then you decide to get another job and next guy to maintain the code is utterly confused and misdirected because let’s be honest, there’s no documentation or there is but is either not up to date or sparse, theres no thorough unit testing (lucky if there is any). Not saying that’s your case but it happened to me personally to be on the other end a few times and let me tell you, it’s quite an effort to ramp up on such projects.