4 ms·

Are you suggesting that different languages and tooling would make different players on the team 'A' players? Sorry, but I find this to be an extremely dubious

Are you suggesting that different languages and tooling would make different players on the team 'A' players? Sorry, but I find this to be an extremely dubious claim. At the risk of coming off as a completely arrogant ass, I've been an 'A' player in two completely different language, stack and tooling environments so far. Now I find myself shifting the lion's share of my coding time from back-end to front-end work, but aside from an initial adjustment period, I don't find this to be a huge hit to my productivity or effectiveness. I'm pretty confident most other 'A' players can do the same easily, probably more easily than I can. Am I unhappy in an environment that forces to use tooling that I find to be unproductive, sure. I've been here before, but nonetheless I was still one of the 'A' players. A players are not different because of having the right fit with tools or projects, or because of more (or less) education. They are different because they have a good fit with their purpose combined with passion for what they do.

michaelochurch 14y ago
Are you suggesting that different languages and tooling would make different players on the team 'A' players? Sorry, but I find this to be an extremely dubious claim. It depends how far apart they are. Having written the code is a huge advantage. Getting to write code is a major advantage (if most of your time is spent reading code, your odds of transferring to a new-dev role on the same team are low). Picking tools that one knows well is also an advantage, but probably less of one, because there are far crappier corporate codebases than in-use open source tools (in general). If the people are very far apart in ability, then those kinds of changes won't permute the ranking... on the other hand, if there's that much spread among programmers of equal rank, then you have an unusual team and a recipe for chaos.
- arohner 14y ago
  > It depends how far apart they are. Totally disagree. A level programmers are almost by definition, A level programmers in every language they've ever encountered. For B level programmers, you're right, it's worthwhile to play tug-of-war on languages and tooling.
  - michaelochurch 14y ago
    It's not just about languages. It's about environments and coding practices as well. Sure, an A programmer can write quality code in any language. It doesn't take very long to learn a new programming language itself. Learning a corporate codebase and an environment (often broken) takes a lot longer. Three to six months, easily. Reputations are formed, and people are slotted rather inflexibly into the pecking order, in less time than that. Being an A programmer won't stop you from writing quality Java code if you get to develop from scratch. The crappiness of the language may hold you back, but not at a career-killing rate, and it won't bring you below expectations because no one expects high productivity when Java is the language of choice. However, if you're dropped into an existing codebase and the code has a bunch of VisitorFactory garbage, being an A programmer hurts you. Good programmers just don't have much patience (or experience, if they can help it) with shit code.
    - lucisferre 14y ago
      But I think that really invalidates this whole premise that there is no such thing as 'A' players and that they are primarily a product of the tooling and environment. Teams with shit code and poor unproductive environments, pretty much by definition, don't have 'A' players and the ones they do have don't stay long. Someone once told me "it's easy to retain mediocrity in a company, it's the talented people that are hard to keep." This is a chicken-and-egg problem, but in my mind it is the lack of quality team members and managers that leads to a poor environment all around. That being said I've worked in environments like this, where tooling was poor, the build chain almost non-existant and there was a legacy of extremely poor architecture. I was still able to make improvements, bring in better code, architectures and dev practices (albeit slowly). For that matter, so was every other 'A' player I know that worked there. The main thing is none of us stayed there more than a year.

michaelochurch 14y ago

Are you suggesting that different languages and tooling would make different players on the team 'A' players? Sorry, but I find this to be an extremely dubious claim. It depends how far apart they are. Having written the code is a huge advantage. Getting to write code is a major advantage (if most of your time is spent reading code, your odds of transferring to a new-dev role on the same team are low). Picking tools that one knows well is also an advantage, but probably less of one, because there are far crappier corporate codebases than in-use open source tools (in general). If the people are very far apart in ability, then those kinds of changes won't permute the ranking... on the other hand, if there's that much spread among programmers of equal rank, then you have an unusual team and a recipe for chaos.

arohner 14y ago
> It depends how far apart they are. Totally disagree. A level programmers are almost by definition, A level programmers in every language they've ever encountered. For B level programmers, you're right, it's worthwhile to play tug-of-war on languages and tooling.
- michaelochurch 14y ago
  It's not just about languages. It's about environments and coding practices as well. Sure, an A programmer can write quality code in any language. It doesn't take very long to learn a new programming language itself. Learning a corporate codebase and an environment (often broken) takes a lot longer. Three to six months, easily. Reputations are formed, and people are slotted rather inflexibly into the pecking order, in less time than that. Being an A programmer won't stop you from writing quality Java code if you get to develop from scratch. The crappiness of the language may hold you back, but not at a career-killing rate, and it won't bring you below expectations because no one expects high productivity when Java is the language of choice. However, if you're dropped into an existing codebase and the code has a bunch of VisitorFactory garbage, being an A programmer hurts you. Good programmers just don't have much patience (or experience, if they can help it) with shit code.
  - lucisferre 14y ago
    But I think that really invalidates this whole premise that there is no such thing as 'A' players and that they are primarily a product of the tooling and environment. Teams with shit code and poor unproductive environments, pretty much by definition, don't have 'A' players and the ones they do have don't stay long. Someone once told me "it's easy to retain mediocrity in a company, it's the talented people that are hard to keep." This is a chicken-and-egg problem, but in my mind it is the lack of quality team members and managers that leads to a poor environment all around. That being said I've worked in environments like this, where tooling was poor, the build chain almost non-existant and there was a legacy of extremely poor architecture. I was still able to make improvements, bring in better code, architectures and dev practices (albeit slowly). For that matter, so was every other 'A' player I know that worked there. The main thing is none of us stayed there more than a year.