3 ms·

There is a difference between working on a team where everyone works on the same bits and you have to work around their projects and their timelines, and being

by adeaver 14y ago

There is a difference between working on a team where everyone works on the same bits and you have to work around their projects and their timelines, and being part of a team where each 'member' works in a semi-siloed, semi-independant capacity. I much prefer the latter to the former since I don't have to work about anyone else makes changes to stuff without my knowledge but I'm still on the team, still met with the others to discuss what we are working on and how it impacts X or Y.

alanctgardner2 14y ago
I can see the siloed approach working to a point, but there are two big drawbacks: - no exposure to new skills and techniques. This particular employee is pretty fond of cut-and-paste, and we've been refactoring to fix a lot of that. As we refactor, the ground is sort of shrinking beneath his feet, because he isn't willing to work on other people's code. If you aren't willing to learn new techniques and read other people's code, your portion of the codebase is going to accumulate technical debt while the rest moves forward. - no big-picture perspective. I love to stick my nose into every architectural discussion, and I think it's beneficial for us to plan big decisions as a team, to try and find the best solution. From experience, a siloed employee won't be interested in getting involved in these large-scale discussions, because they haven't kept up with the rest of the codebase, and they don't have an interest in it. Essentially, having all your team hived off from each other, doing their own thing: - gives you a very low bus factor. If one guy moves on, dies, whatever, suddenly you've got a dark area of your codebase with built up debt and no knowledge. - reduces the cohesiveness of your design. At the best, the high level plan will be dictated by management or a single architecture, and each employee builds their part according to spec. This seems to reduce autonomy and job satisfaction, and it presumes none of the coders have any good ideas about architecture (wrong). If you have techniques or suggestions for getting around these issues, I'd be glad to hear them. It is a big problem that some very good technical people aren't necessarily very social.
adeaver 14y ago
@alanctgardner2 Agreed, there are limitations. If that guy is a fan of cut-n-paste then there are bigger issues at hand than just social interaction. Working in a siloed environment doesn't mean not learning new skills or techniques. And I don't mean that you are only working on the same project/chunk of code the entire time. We would often switch projects so that what I'm working on today is completely different that last week and has been touched/edited/tweaked by just about everyone on the team at some point. Having a Big Picture perspective is vital be being able to work individually. You have to know how your work will ultimately impact everyone else and how their will impact you. I don't mean that everyone is working on completely separate projects but that Employee 1 might be working on a feature enhancement on version 4.5.3 while Employee 2 is working on a refactor of the back end code and I might be working on implementing a change control request on version 4.5.4. Perhaps this is a better way to explain: everyone is working on the same Project but on individual and separate Tasks
- alanctgardner2 14y ago
  That just seems like every team ever, except for pairs programming I can't imagine having two people in the same part of the codebase at the same time. Is there an alternative you can think of that isn't just poor management, or ambiguous descriptions leading to conflicts? Also, you can reply even during the cooling-off period by hitting the 'link' link.
  - adeaver 14y ago
    Majors bugs that involve both the front and back end developers. Major feature enhancements in which multiple devs touch the same set of files. There are probably ways around these issues, just some instances where I've had to sit next to someone and work out a bug/problem.

by adeaver 14y ago

alanctgardner2 14y ago

I can see the siloed approach working to a point, but there are two big drawbacks: - no exposure to new skills and techniques. This particular employee is pretty fond of cut-and-paste, and we've been refactoring to fix a lot of that. As we refactor, the ground is sort of shrinking beneath his feet, because he isn't willing to work on other people's code. If you aren't willing to learn new techniques and read other people's code, your portion of the codebase is going to accumulate technical debt while the rest moves forward. - no big-picture perspective. I love to stick my nose into every architectural discussion, and I think it's beneficial for us to plan big decisions as a team, to try and find the best solution. From experience, a siloed employee won't be interested in getting involved in these large-scale discussions, because they haven't kept up with the rest of the codebase, and they don't have an interest in it. Essentially, having all your team hived off from each other, doing their own thing: - gives you a very low bus factor. If one guy moves on, dies, whatever, suddenly you've got a dark area of your codebase with built up debt and no knowledge. - reduces the cohesiveness of your design. At the best, the high level plan will be dictated by management or a single architecture, and each employee builds their part according to spec. This seems to reduce autonomy and job satisfaction, and it presumes none of the coders have any good ideas about architecture (wrong). If you have techniques or suggestions for getting around these issues, I'd be glad to hear them. It is a big problem that some very good technical people aren't necessarily very social.

adeaver 14y ago

@alanctgardner2 Agreed, there are limitations. If that guy is a fan of cut-n-paste then there are bigger issues at hand than just social interaction. Working in a siloed environment doesn't mean not learning new skills or techniques. And I don't mean that you are only working on the same project/chunk of code the entire time. We would often switch projects so that what I'm working on today is completely different that last week and has been touched/edited/tweaked by just about everyone on the team at some point. Having a Big Picture perspective is vital be being able to work individually. You have to know how your work will ultimately impact everyone else and how their will impact you. I don't mean that everyone is working on completely separate projects but that Employee 1 might be working on a feature enhancement on version 4.5.3 while Employee 2 is working on a refactor of the back end code and I might be working on implementing a change control request on version 4.5.4. Perhaps this is a better way to explain: everyone is working on the same Project but on individual and separate Tasks

alanctgardner2 14y ago
That just seems like every team ever, except for pairs programming I can't imagine having two people in the same part of the codebase at the same time. Is there an alternative you can think of that isn't just poor management, or ambiguous descriptions leading to conflicts? Also, you can reply even during the cooling-off period by hitting the 'link' link.
- adeaver 14y ago
  Majors bugs that involve both the front and back end developers. Major feature enhancements in which multiple devs touch the same set of files. There are probably ways around these issues, just some instances where I've had to sit next to someone and work out a bug/problem.