Honestly, contrarian opinion ahead, but I don't think so.

Software engineering is design just like anything else. Being able to clearly communicate the components, workflows, thought process, etc is a sign it's built well. (I'm interpreting "better programmer" to mean one who builds software well or better than average.) Whether that conversation is with a peer, maintainer, or end user, I think the same principle is at work.

This is premised on the idea that I believe peer reviews of code and designs are fundamentally a good thing. Talking with more people to get more relevant feedback makes for a better system overall.

Context switching is for sure a thing when in the moment of building a system, and having our time in meetings definitely spends our finite attention on those meetings rather than building things. Some amount of meetings is inevitable in any job though. Personally I try to cluster my meetings and prefer them later in the day.

Knuth was in a fraternity, meaning living with a dozen people and going to parties, so I don't think asocial = great programmer. I also agree with the other posts that in the end it's really just design skills that makes a great programmer. Designing these highly complex systems to somehow all fit seamlessly together, be self documenting, be maintainable, easy to reason about for future optimization and easy to add features to. The more professional programming I do the more I realize how bad I am at it when I come across a designer who is able to implement the above and make it look easy.

I don't think pointing out Knuth is valid in this case. What happens with people way outside the curve most likely does not apply to everyone within the standard deviation (or maybe even a few times it) .

I am not saying that I agree or disagree with the conclusion, mind you.

It's simple, the more time you spend programming, the less time you'll have for socializing and the more time you spend socializing, the less you'll have to improve your programming.

Where you spend your time is what you get good at.

> It's simple, the more time you spend programming, the less time you'll have for socializing and the more time you spend socializing, the less you'll have to improve your programming.

Totally agree.

Especially at the beginning, programming skills need time and constant dedication in order to be developed.

A busy social life may preclude this necessary initial time investment by beginners.

It's not just in technology. This applies to any field that does not require sociability to succeed.

I think it's about balance. The time one spends learning a new programming language,system,etc... Could also be spent learning sociability and social skills.

In my experience,someone is a better programmer because they invested more time into it.

I think it's possible,but very hard to strike a good balance.

I don’t think so, and the first thing I would point to is pair programming, particularly promiscuous pairing. Promiscuous pairing in particular requires a relatively large amount of social interaction throughout the day but improves code quality and skill level for teams who can actually pull it off.

Generally I would agree that the better IT professionals are often less social, nature or nurture I wouldn’t like to guess though.

I also don’t think it’s limited to our industry, I’ve seen it across most or all that I’ve worked in so far.

Anecdotally, yes, most definitely.

see

https://en.wikipedia.org/wiki/NeuroTribes

no