3 ms·

Well, as much I have seen code reviews in my life (ignoring a few people that have OCD), I have noticed that the trend is to: - add whatever comment that comes

by stiray 6y ago

Well, as much I have seen code reviews in my life (ignoring a few people that have OCD), I have noticed that the trend is to: - add whatever comment that comes to your mind and you know wont be argued about (like using spaces instead of tabs) to have your persona look better on management statistics - not deal with actually understanding the code but rather argue about syntax (dont malloc, use vector.reserve(),...) - dont press accept until few lines are exchanged... again, boosting the statistics instead of giving something meaningful - ... whatever boosts the reviewer visibility, even going ballistic on irrelevant parts of code (while no one reviews 3rd party dependencies where most of the evil is) My proposal for code quality is different. Put together a team that communicates (a rare skill nowdays) and LET THEM communicate, offer them free beer afterwork, whatever interests them. Dont use enforced meetings like scrum etc., they just show that you have failed putting together a functional team. Make developers friends instead of rivals. Then avoid JIRA overhead, avoid management visibility,... just listen what people are saying (and preferably become their friend too), surpres any outside world influeces from your team and fire anyone trying to ladder over anyone else. Then you wont need code reviews. And you will always have a long list of improvements at any moment. Just send an email and ask. Be capable of coding. Be really good at coding. Everyone will follow you after "shit hit the fan" and team had to work over weekend and you have stayed with them and help them fix the bugs, analyze the code. DONT be a manager, be helpful part of the team (if this would be industry standard we can just fire 99.999% of managers).

mumblemumble 6y ago
This is a big part of why I've started pushing for aggressive autoformatting and linting. The automated tools and checks are sometimes annoying, but automating away checks for the low-value stuff like this helps encourage the human reviewers to review for actual bugs and design problems rather than just taking potshots at the easy stuff.
matthewmacleod 6y ago
This is possibly the worst advice I've ever encountered about how to run a functional software team. It sounds like you have worked with a succession of terrible people if this is your impression of code review or team communication, so I can certainly understand that would have an effect on your ideas. I've encountered this sort of team before – the high-functioning jealously-protected team that's isolated from outside interaction and visibility. They usually produce absolutely wonderful high-quality software that is useless and meets none of the requirements that other teams have of them. In fact, I'd say that well-functioning teams will usually themselves develop a system of code reviews or similar, along with using task-tracking software, regularly seeking influences from the outside stakeholders, and making sure work is visible to other teams. A good manager supports those interactions and helps to make sure everyone has the resources they need to work effectively.
- stiray 6y ago
  Worst advice? I am just commenting what I am seeing. Worked as a contractor in a bunch of teams in large companies, quite a few blue-chips. Yep, I was quite amazed when I came out of pocket size companies, it is quite amazing how f*-up everything becomes when you have a few layers of management, methodologies, enforced way of working, measuring "effectiveness" that affects your promotions, when scrum meetings suddenly become just a simple way of filling in burn out charts for manager, when number of solved JIRA tickets becomes more important than what was solved ("yes you have solved a bug that could prevent nuclear core meltdown, BUT your X coworker solved 20 bugs in that time"), when documents are more worth than code, when people are forced working together even if they fit together like an oil and water "as they have right skills" etc. Can someone still remember the times when developers were paid by the lines of code? It all comes from the same type of thinking. And this all came out when there was a huge push to make development streamlined around 15 years ago. And it is certanlly not getting any better, if you are having person who wants quality of code, you can be 100% sure there is someone trying to make his promotions work easier. Sure, maybe I had a bad luck to have never find "the right company" as they (beyond some scale, lets say a few hundred developers) all seem very similar to me. Same bs, wherever I look. And I agree with you, when the company is small it works the way you have described.

by stiray 6y ago

mumblemumble 6y ago

This is a big part of why I've started pushing for aggressive autoformatting and linting. The automated tools and checks are sometimes annoying, but automating away checks for the low-value stuff like this helps encourage the human reviewers to review for actual bugs and design problems rather than just taking potshots at the easy stuff.

matthewmacleod 6y ago

This is possibly the worst advice I've ever encountered about how to run a functional software team. It sounds like you have worked with a succession of terrible people if this is your impression of code review or team communication, so I can certainly understand that would have an effect on your ideas. I've encountered this sort of team before – the high-functioning jealously-protected team that's isolated from outside interaction and visibility. They usually produce absolutely wonderful high-quality software that is useless and meets none of the requirements that other teams have of them. In fact, I'd say that well-functioning teams will usually themselves develop a system of code reviews or similar, along with using task-tracking software, regularly seeking influences from the outside stakeholders, and making sure work is visible to other teams. A good manager supports those interactions and helps to make sure everyone has the resources they need to work effectively.

stiray 6y ago
Worst advice? I am just commenting what I am seeing. Worked as a contractor in a bunch of teams in large companies, quite a few blue-chips. Yep, I was quite amazed when I came out of pocket size companies, it is quite amazing how f*-up everything becomes when you have a few layers of management, methodologies, enforced way of working, measuring "effectiveness" that affects your promotions, when scrum meetings suddenly become just a simple way of filling in burn out charts for manager, when number of solved JIRA tickets becomes more important than what was solved ("yes you have solved a bug that could prevent nuclear core meltdown, BUT your X coworker solved 20 bugs in that time"), when documents are more worth than code, when people are forced working together even if they fit together like an oil and water "as they have right skills" etc. Can someone still remember the times when developers were paid by the lines of code? It all comes from the same type of thinking. And this all came out when there was a huge push to make development streamlined around 15 years ago. And it is certanlly not getting any better, if you are having person who wants quality of code, you can be 100% sure there is someone trying to make his promotions work easier. Sure, maybe I had a bad luck to have never find "the right company" as they (beyond some scale, lets say a few hundred developers) all seem very similar to me. Same bs, wherever I look. And I agree with you, when the company is small it works the way you have described.