4 ms·

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 terribl

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.

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.