4 ms·

> 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 encount

by 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.

by arohner 14y ago

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.