HN2new | past | comments | ask | show | jobs | submitlogin

You don’t say. Great insight, guys.


"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://hackernews.hn/newsguidelines.html


Some people, even in tech, are so afraid of being alone (often subconsciously) that they lean heavily toward group collaboration as a sort of security blanket. Outside-point-of-reference studies like this are really useful as aids in getting them to loosen up and let the people they e.g. supervise have some quiet time.


We kind of have the opposite problem on my team... all the devs tend to work mostly alone (98+% of the time). Most of the dev communication is with the product owner and the product engineers (non-devs).

We talk about doing pair programming or something in the next release, then we all go back to our respective stacks of work and don’t feel like we have the time to collaborate on anything, unless it’s a question for someone who knows a part of the codebase better.


If the results in this study generalize, neither constant collaboration nor constant isolation are good. You want people to be able to crib ideas from you in a professional setting. You also want them to have enough time to think up their own ideas.

I know you didn't ask for advice, but perhaps code-review and design-review is actually all your team needs? i.e. instead of the constant collaboration of pair programming, you work on slightly lighter weight interaction by having pairs of people work on closely related projects code-reviewing each other and having times where they bounce ideas off each other, but who ultimately work alone till they produce something the other can see. A half-day boundary of interaction (non-formalized of course) may be sufficient to allow for the degree of collaboration to be fruitful.


> lean heavily toward group collaboration as a sort of security blanket

This happens and fosters groupthink and prevents critical thinking and creativity.

When a whole team (or company) comes up with a poorly designed product this is often the reason.

You can fight this by talking about the problem, encouraging constructive criticism, engaging with communities and other social groups, gathering anonymous feedback from other teams.


"It's warm inside the herd"



One hypothesis could be that communication is the biggest barrier, in which case constant contact could be a solution. It doesn't hurt to test your hypothesises or consider alternatives.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: