4 ms·

On your first point, I agree, I've seen extroverted employees enter the management track and get promoted to such positions over others. On the topic of great

On your first point, I agree, I've seen extroverted employees enter the management track and get promoted to such positions over others. On the topic of great software, I would offer that maybe this is beside the point. I'm not convinced that in most organizations of sufficient size that you can even get great software, because they fall down a road of lowest common denominator development to tackle issues of huge scale, complexity and managing varying levels of talent. In my experience there tends to be so much intertia and process created to corrall people that usually inspired people are left shackled at the hand and foot and prevented from effecting meaningful change. Once this happens, it comes down to the capacity for individuals to bring people on board (usually not an advertised developer skill) and sell ideas to others to effect change, which I think informs at least part of the thinking in hiring "team players" - which really is management engineering around the problems that they've created.

labrador 4y ago
There are too many examples to list of one programmer inventing software that the rest of take for granted now. The best example of more than one is probably Jeff Dean and Sanjay Ghemawat at Google, but that's just two people. It's possible the companies who want team players are acknowledging that their programmers aren't the best so everyone needs to work together to make something that works.
- superchroma 4y ago
  I've revised my comment a little. Yes, it's definitely possible. The example that comes to my mind now is the guy who runs Krita, which is a project with huge scope, but I think that to do this effectively requires a high level of discipline and patience that many people don't have and that is difficult to test for when hiring, which is why companies are forced to turn to bureaucracy instead.
  - labrador 4y ago
    I recently watched a documentary on Henry Ford. One of his innovations was to move manufacture from a craftsmen model that required high skills to an assembly line model that used more people with less skill to get the same result. The managing engineer is the one holding it together. With this in mind it makes sense to hire team players who are good enough over highly skilled workers who work in isolation. The trick then becomes finding highly skilled workers who are able to engineer and manage solutions for the lower skilled workers to implement.
    - Silhouette 4y ago
      Does that analogy really hold when you're making software and not a physical product? In software development you don't need a production line staffed by minimally skilled workers to implement the plan of the expert. Automation is what we do. Of course you still often need those experts to have decent soft skills because many commercial projects will still need multiple developers even if everyone involved is very good. But the communication and management overheads scale far more than linearly with the size of the team so a relatively small team of very skilled developers can easily outperform a much larger team of mediocre developers in practice.
      - superchroma 4y ago
        Well, maybe? For every hard problem which requires smart people to actually innovate, there's 100 which involve writing boilerplate to get information from a form to a database and back again.
      - labrador 4y ago
        > Does that analogy really hold when you're making software and not a physical product? I think it does. Of course the minimal skill required is higher than hiring some person off the street to bolt on a few parts as the product proceeds down the assembly line. I worked at Microsoft many years ago and it was a lot like a software factory
    - bitwize 4y ago
      Two problems. One is with the Ford model itself: deskilling workers to the absolute maximum extent possible makes the whole assembly line more brittle. If you have a guy whose only job is to put a screw in a specific joint, what happens when he gets sick? Whole assembly line gets held up. You could hire two screw guys but you'd be paying twice as much and one of them sits there idle. Plus, germs spread quickly, what if they both get sick? My father realized this in the late 60s or early 70s as an engineering manager at a tech company (back when tech was Tech and tech companies actually made stuff). His solution was as follows: Line jobs were ranked A, B, and C, for high, medium, and low skill. Especially the C and B jobs, you could teach multiple jobs to a single worker, and give them a workbench at which they could do several tasks in the manufacturing process, not just one -- and have several workers at workbenches doing all these tasks. The assembly line gets slowed down when one worker gets sick, but it still proceeds because whatever job that worker was doing, their colleagues also know how to do. My father's idea was dismissed by the higher-ups to implement companywide, but it's part of the "Toyota method" now, so I guess it was independently discovered in Japan. Good ideas are like that, plus, the Japanese actually respect craftsmanship; at the end of the day, American businesses only respect money and metrics. Secondly, how many times must it be repeated? Software engineering is not like manufacturing. It takes zero skill and next to zero cost to manufacture an additional copy of a program because a program is just bits that are trivially copied by computer. To develop new software requires a moderate to high level of skill, so you want to cultivate craftsmanship in your software developers, unless you like the current state of enterprise webshit and think that software that's slow to develop, slow to run, fraught with bugs and integration issues is just fine.
- bitwize 4y ago
  Team-playerism is an attempt to do for developers what RAID does for storage or the cloud does for compute. It is an attempt to simulate a great programmer with a redundant array of good programmers, and get more reliability out of the deal. (Great programmers are highly sensitive to their work environment, and the more scrupulous ones will quit when they aren't getting the work conditions, respect, or compensation they feel they're entitled to for their work. The less scrupulous ones will sabotage your company from the inside, or sprinkle backdoors in to sabotage it from without once they've left.) It never works, of course. Insights come from individuals, not collectives, and while having similarly skilled colleagues to bounce ideas off of and refine them with works well for great programmers, they have to come up with the ideas themselves in the first place. The communication overhead in a team of good programmers prevents them from having great-programmer insights at great-programmer speeds. The way to fight communication overhead is to ensure that each team member has a large corpus of shared information. In other words, a shared, standardized coding style which further hampers insight because insightful solutions have little regard for "the rules". But most companies just want CRUD+business rules, so RAID (Redundant Array of Intransigent Developers) works well.
  - CRConrad 4y ago
    > Insights come from individuals, not collectives, and while having similarly skilled colleagues to bounce ideas off of and refine them with works well for great programmers, they have to come up with the ideas themselves in the first place. Bouncing insights off each other in a team might lead to someone else taking up and working on something that to the originator was just a fleeting side idea in a train of thought, but can turn out to be valid on its on / viewed from a slightly different angle / in a slightly different context. Whereas if the individual works entirely on their own, valid ideas / insights may be forgotten and fall by the wayside forever. (Personally I probably tend more towards the solo side, but have to admit there are advantages to teamwork too.)
  - galaxyLogic 4y ago
    Programming is essentially mathematics. Imagine if mathematicians were required to do pair-proving. Pair- programming is a case in point. It emerged from "Xtreme Programming" which emphasized "values" and "people", not problem solving skills. So why didn't they go further and require "triple programming", then "quatro programming" and so on? The way to tackle complex problems is by divide-and-conquer: Divide the problem into smaller parts which can be solved independently. Pair-programming is not that, it doesn't divide the problem into two and then let each programmer work on one part of it individually. Instead there's a pair of chefs in the same kitchen team-cooking the same spaghetti. To put it bluntly I think people who demand "team-players" are typically those who don't have the skills to solve any part of the problem by themselves. By building a team around them they can hide that fact. If the project fails it is nobody's fault, the whole team did their best and still it couldn't succeed. We followed the best agile practices you know. Or maybe it succeeds, because of a few good men and women. (Successful) team-playing is when each team-member plays their part, not when they all play the same part. Think volley-ball, that's a great team-sport.

labrador 4y ago

There are too many examples to list of one programmer inventing software that the rest of take for granted now. The best example of more than one is probably Jeff Dean and Sanjay Ghemawat at Google, but that's just two people. It's possible the companies who want team players are acknowledging that their programmers aren't the best so everyone needs to work together to make something that works.

superchroma 4y ago
I've revised my comment a little. Yes, it's definitely possible. The example that comes to my mind now is the guy who runs Krita, which is a project with huge scope, but I think that to do this effectively requires a high level of discipline and patience that many people don't have and that is difficult to test for when hiring, which is why companies are forced to turn to bureaucracy instead.
- labrador 4y ago
  I recently watched a documentary on Henry Ford. One of his innovations was to move manufacture from a craftsmen model that required high skills to an assembly line model that used more people with less skill to get the same result. The managing engineer is the one holding it together. With this in mind it makes sense to hire team players who are good enough over highly skilled workers who work in isolation. The trick then becomes finding highly skilled workers who are able to engineer and manage solutions for the lower skilled workers to implement.
  - Silhouette 4y ago
    Does that analogy really hold when you're making software and not a physical product? In software development you don't need a production line staffed by minimally skilled workers to implement the plan of the expert. Automation is what we do. Of course you still often need those experts to have decent soft skills because many commercial projects will still need multiple developers even if everyone involved is very good. But the communication and management overheads scale far more than linearly with the size of the team so a relatively small team of very skilled developers can easily outperform a much larger team of mediocre developers in practice.
    - superchroma 4y ago
      Well, maybe? For every hard problem which requires smart people to actually innovate, there's 100 which involve writing boilerplate to get information from a form to a database and back again.
    - labrador 4y ago
      > Does that analogy really hold when you're making software and not a physical product? I think it does. Of course the minimal skill required is higher than hiring some person off the street to bolt on a few parts as the product proceeds down the assembly line. I worked at Microsoft many years ago and it was a lot like a software factory
  - bitwize 4y ago
    Two problems. One is with the Ford model itself: deskilling workers to the absolute maximum extent possible makes the whole assembly line more brittle. If you have a guy whose only job is to put a screw in a specific joint, what happens when he gets sick? Whole assembly line gets held up. You could hire two screw guys but you'd be paying twice as much and one of them sits there idle. Plus, germs spread quickly, what if they both get sick? My father realized this in the late 60s or early 70s as an engineering manager at a tech company (back when tech was Tech and tech companies actually made stuff). His solution was as follows: Line jobs were ranked A, B, and C, for high, medium, and low skill. Especially the C and B jobs, you could teach multiple jobs to a single worker, and give them a workbench at which they could do several tasks in the manufacturing process, not just one -- and have several workers at workbenches doing all these tasks. The assembly line gets slowed down when one worker gets sick, but it still proceeds because whatever job that worker was doing, their colleagues also know how to do. My father's idea was dismissed by the higher-ups to implement companywide, but it's part of the "Toyota method" now, so I guess it was independently discovered in Japan. Good ideas are like that, plus, the Japanese actually respect craftsmanship; at the end of the day, American businesses only respect money and metrics. Secondly, how many times must it be repeated? Software engineering is not like manufacturing. It takes zero skill and next to zero cost to manufacture an additional copy of a program because a program is just bits that are trivially copied by computer. To develop new software requires a moderate to high level of skill, so you want to cultivate craftsmanship in your software developers, unless you like the current state of enterprise webshit and think that software that's slow to develop, slow to run, fraught with bugs and integration issues is just fine.
bitwize 4y ago
Team-playerism is an attempt to do for developers what RAID does for storage or the cloud does for compute. It is an attempt to simulate a great programmer with a redundant array of good programmers, and get more reliability out of the deal. (Great programmers are highly sensitive to their work environment, and the more scrupulous ones will quit when they aren't getting the work conditions, respect, or compensation they feel they're entitled to for their work. The less scrupulous ones will sabotage your company from the inside, or sprinkle backdoors in to sabotage it from without once they've left.) It never works, of course. Insights come from individuals, not collectives, and while having similarly skilled colleagues to bounce ideas off of and refine them with works well for great programmers, they have to come up with the ideas themselves in the first place. The communication overhead in a team of good programmers prevents them from having great-programmer insights at great-programmer speeds. The way to fight communication overhead is to ensure that each team member has a large corpus of shared information. In other words, a shared, standardized coding style which further hampers insight because insightful solutions have little regard for "the rules". But most companies just want CRUD+business rules, so RAID (Redundant Array of Intransigent Developers) works well.
- CRConrad 4y ago
  > Insights come from individuals, not collectives, and while having similarly skilled colleagues to bounce ideas off of and refine them with works well for great programmers, they have to come up with the ideas themselves in the first place. Bouncing insights off each other in a team might lead to someone else taking up and working on something that to the originator was just a fleeting side idea in a train of thought, but can turn out to be valid on its on / viewed from a slightly different angle / in a slightly different context. Whereas if the individual works entirely on their own, valid ideas / insights may be forgotten and fall by the wayside forever. (Personally I probably tend more towards the solo side, but have to admit there are advantages to teamwork too.)
- galaxyLogic 4y ago
  Programming is essentially mathematics. Imagine if mathematicians were required to do pair-proving. Pair- programming is a case in point. It emerged from "Xtreme Programming" which emphasized "values" and "people", not problem solving skills. So why didn't they go further and require "triple programming", then "quatro programming" and so on? The way to tackle complex problems is by divide-and-conquer: Divide the problem into smaller parts which can be solved independently. Pair-programming is not that, it doesn't divide the problem into two and then let each programmer work on one part of it individually. Instead there's a pair of chefs in the same kitchen team-cooking the same spaghetti. To put it bluntly I think people who demand "team-players" are typically those who don't have the skills to solve any part of the problem by themselves. By building a team around them they can hide that fact. If the project fails it is nobody's fault, the whole team did their best and still it couldn't succeed. We followed the best agile practices you know. Or maybe it succeeds, because of a few good men and women. (Successful) team-playing is when each team-member plays their part, not when they all play the same part. Think volley-ball, that's a great team-sport.