Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday September 24 2017, @03:45PM   Printer-friendly
from the just-need-a-thousand-monkeys dept.

[The] main problem here is that software development is not an individual sport. Assessing technical traits means that we are looking at candidates as individuals. At the same time, we will put them in a team context and the project's success will depend on their teamwork. A person's resume or LinkedIn profile says close to nothing about their team skills.

What's more, we know quite a lot about what makes teams effective. Anita Woolley's research on collective intelligence [DOI: 10.1126/science.1193147] [DX] provides extremely valuable insight on the topic. First of all, how do we define collective intelligence? It's basically the skill of a group to solve complex problems. Well, it sounds like the definition of everyday work for software development teams if you ask me.

Why is collective intelligence so important? Exploiting collective intelligence, as opposed to going with the opinion of the smartest person in a room, is a winning strategy. To put in Anita Woolley's words: "Collective intelligence was much more predictive in terms of succeeding in complex tasks than average individual intelligence or maximal individual intelligence."

The power is in the team.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Informative) by Thexalon on Sunday September 24 2017, @10:02PM (2 children)

    by Thexalon (636) on Sunday September 24 2017, @10:02PM (#572467)

    You go to work to produce good work, not to be chums with everyone.

    Actually, I don't know about you, but I always went to work to get a paycheck. Sure, doing good work might help in that regard, but I'm well aware that my pride in workmanship can and will be ruthlessly exploited by management to convince to, say, take lower salaries than I should, or work longer hours than I should.

    As for being chums, no, that's not the goal, but if there's someone who's really hard to work with, that will definitely affect the quality of my work. Behaviors I've seen from the folks who are lousy at collaboration:
    - Refusal to document anything, so the only way I can figure out how to use their sections of the code is to read it over and guess at what they're trying to do (which it may or may not do, of course).
    - Refusal to put their stuff through the same kind of testing us mere mortals need, because their stuff is obviously so much better it doesn't need to be tested thoroughly. (And of course, it frequently doesn't work!)
    - Refusal to negotiate designs, leaving the wrong components doing the wrong jobs and making everyone else code around their mistakes.
    - Refusal to show up for meetings in a reasonably timely manner, leaving the rest of us sitting there waiting. We'd just get started without them, but if we don't wait they're just going to do whatever they feel like without knowing the details we've all worked out.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Informative=1, Total=2
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by hendrikboom on Sunday September 24 2017, @11:16PM

    by hendrikboom (1125) Subscriber Badge on Sunday September 24 2017, @11:16PM (#572479) Homepage Journal

    That which is not tested is broken.

  • (Score: 2) by JoeMerchant on Monday September 25 2017, @12:32PM

    by JoeMerchant (3937) on Monday September 25 2017, @12:32PM (#572628)

    The mythical man month still holds true in that: six coders given six months can produce the same output as one coder in one month.

    Quality depends mostly on the individual(s) involved and the team's work style - a good team of six will be producing code that all six understand to some reasonable level, and as such it's generally more accessible to newcomers too.

    If your projects are relatively simple, well budgeted, long running, and subject to turnover during the maintenance lifetime - sometimes the team of six makes a lot of sense for a product in the long run.

    If you're making throwaway prototypes - just hire the genius and make six throwaways in the time of one for 1/4th the cost. Once you've got something that marketing can sell, then hire the team of six to rebuild and maintain it, because you're going to build an ecosystem of hundreds (hopefully thousands or millions) of people around this thing and you don't want it to all come crashing down when your genius checks out.

    --
    🌻🌻 [google.com]