4 ms·

why would it be hard to implement this in a bigger team? if it's hard, then it's leadership failure.

maxxxxx 8y ago
It's easy to implement if you are the dictator who can just tell people that that's the way how things are done. Or you have worked with people for years and learned your lessons. If you have to convince people it's much harder. I find that a lot of people these days avoid writing code and just want to plug components from GitHub or npm together. They don't see the point of writing an API layer if it's not coming from GitHub.
- mk89 8y ago
  I somehow understand your comment. Logically you are right. Having the first and last word is always the easiest way. I mean, the easiest way to get what you want for a limited amount of time, until all hell breaks loose. I hear a lot of frustration in your words, as if you had difficulties trying to explain to your colleagues why a certain thing could be done better in a certain way. I think that sometimes they might be right, sometimes reinventing the wheel is pointless, sometimes it needs to be invented, and sometimes you need to add that layer of complexity. It seems that information is not shared correctly at your workplace, as not everyone is probably aware of the same problem to solve, or maybe not everyone has the same skills, in which case you need to mentor and explain. Or it seems that you don't have constructive design discussions. And no, this does not depend on the company/team size. Probably in larger teams it's actually easier to convince, as generally there is a process in place for such things like design, refactoring, etc.
  - zdragnar 8y ago
    It's not unique. I've worked in large teams with benevolent dictators (who were open to feedback and suggestion), and large teams where everyone wanted to be at the same level. In the latter scenario, generating momentum is damned difficult, as everyone is trying to herd cats to their own priorities. Smaller teams in that regard can be more flexible / nimble, as there are fewer total competing priorities, but that isn't to say that it is always true in either direction.

It's easy to implement if you are the dictator who can just tell people that that's the way how things are done. Or you have worked with people for years and learned your lessons. If you have to convince people it's much harder. I find that a lot of people these days avoid writing code and just want to plug components from GitHub or npm together. They don't see the point of writing an API layer if it's not coming from GitHub.

mk89 8y ago
I somehow understand your comment. Logically you are right. Having the first and last word is always the easiest way. I mean, the easiest way to get what you want for a limited amount of time, until all hell breaks loose. I hear a lot of frustration in your words, as if you had difficulties trying to explain to your colleagues why a certain thing could be done better in a certain way. I think that sometimes they might be right, sometimes reinventing the wheel is pointless, sometimes it needs to be invented, and sometimes you need to add that layer of complexity. It seems that information is not shared correctly at your workplace, as not everyone is probably aware of the same problem to solve, or maybe not everyone has the same skills, in which case you need to mentor and explain. Or it seems that you don't have constructive design discussions. And no, this does not depend on the company/team size. Probably in larger teams it's actually easier to convince, as generally there is a process in place for such things like design, refactoring, etc.
- zdragnar 8y ago
  It's not unique. I've worked in large teams with benevolent dictators (who were open to feedback and suggestion), and large teams where everyone wanted to be at the same level. In the latter scenario, generating momentum is damned difficult, as everyone is trying to herd cats to their own priorities. Smaller teams in that regard can be more flexible / nimble, as there are fewer total competing priorities, but that isn't to say that it is always true in either direction.