4 ms·

> PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" i.e I should not know until the very end WHO wrote the code. Helps to

by bojan 5y ago

> PS2. Oh and on 'code reviews': It would be cool if code-reviews were done "anonymously" i.e I should not know until the very end WHO wrote the code. Helps to keep any personal biases at bay - my 2cents. This is a generally good idea, but in small teams it can't really work. Code is in that sense a bit like handwriting, everyone has their own style, and after a long enough time in a small team you learn to recognize whose the author of the code just by reading it.

skohan 5y ago
My biggest problem with code reviews is that they are so often without value. Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. In my experience, a lot of the time code reviews are either just a task - where people try to find superficial "mistakes" just to tick a box, or worse a chance for certain colleagues to power trip and try to get other team members to submit for it's own sake.
- zoomablemind 5y ago
  > ... Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. IMO a practical benefit of a routine code review is just a shared understanding. As simple as that. Does the code look to be doing what it says it should do? Do the tests express the intended behavior? Of course, the style, the quality of code could be of attention too, but that's extras, in my opinion, as long as the functionality is understood and confirmed. I like relating this to an effort of understanding someone who speaks with an accent, be it a local dialect or foreign-originated. It does require some tolerance, but the shared understanding is the goal.
- muttled 5y ago
  > where people try to find superficial "mistakes" just to tick a box I've found this to be true in change control as well as any meeting involving people who feel they are compelled to "contribute" even if they don't have anything of value. You don't want to seem like the person who's just attending the meeting and slacking off, so if you're expected to contribute and you can't find any useful critiques, you just pick nits.
rawoke083600 5y ago
Yea true, and not just the code-signature, also the problem or jira-tickets the code is addressing. I.e If i'm reviewing a backend-api ticket I KNOW it's prob NOT the new Frontend-UX hippie we hired :P > everyone has their own style, Which then you can asked is that not ALSO a red-orange-flag ? Should one of the metrics not be to be as 'uniform' as possible ? But I do get your point even with uniform guidelines etc, any seasoned def can quickly pick-up who wrote it.
- Planktonne 5y ago
  > Should one of the metrics not be to be as 'uniform' as possible ? I don't think so; someone's code 'handwriting' always seems to me to be more about how they think about problems than specific syntax conventions. Everyone working on the same codebase should follow stylistic conventions - where do you put the opening bracket, how do you name functions etc. - but that still leaves a lot of room for personal style/approach. Faced with the same problem, two programmers might solve it in two different-but-valid ways, and that's recognisable.

by bojan 5y ago

skohan 5y ago

My biggest problem with code reviews is that they are so often without value. Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. In my experience, a lot of the time code reviews are either just a task - where people try to find superficial "mistakes" just to tick a box, or worse a chance for certain colleagues to power trip and try to get other team members to submit for it's own sake.

zoomablemind 5y ago
> ... Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. IMO a practical benefit of a routine code review is just a shared understanding. As simple as that. Does the code look to be doing what it says it should do? Do the tests express the intended behavior? Of course, the style, the quality of code could be of attention too, but that's extras, in my opinion, as long as the functionality is understood and confirmed. I like relating this to an effort of understanding someone who speaks with an accent, be it a local dialect or foreign-originated. It does require some tolerance, but the shared understanding is the goal.
muttled 5y ago
> where people try to find superficial "mistakes" just to tick a box I've found this to be true in change control as well as any meeting involving people who feel they are compelled to "contribute" even if they don't have anything of value. You don't want to seem like the person who's just attending the meeting and slacking off, so if you're expected to contribute and you can't find any useful critiques, you just pick nits.

rawoke083600 5y ago

Yea true, and not just the code-signature, also the problem or jira-tickets the code is addressing. I.e If i'm reviewing a backend-api ticket I KNOW it's prob NOT the new Frontend-UX hippie we hired :P > everyone has their own style, Which then you can asked is that not ALSO a red-orange-flag ? Should one of the metrics not be to be as 'uniform' as possible ? But I do get your point even with uniform guidelines etc, any seasoned def can quickly pick-up who wrote it.

Planktonne 5y ago
> Should one of the metrics not be to be as 'uniform' as possible ? I don't think so; someone's code 'handwriting' always seems to me to be more about how they think about problems than specific syntax conventions. Everyone working on the same codebase should follow stylistic conventions - where do you put the opening bracket, how do you name functions etc. - but that still leaves a lot of room for personal style/approach. Faced with the same problem, two programmers might solve it in two different-but-valid ways, and that's recognisable.