Ask HN: Is programming ability inversely correlated to sociability?
Apologies in advance if the question is offensive to some.
Anecdotally, I have often noticed that the better programmers that I know are, while congenial and very well-mannered, also tend to be somewhat self-absorbed and not very open to chit chat.
Personally, although I consider myself only a decent programmer, on days that I am productive, I tend to be averse to social interactions, and instead want to focus on the program I'm building. I find that the more I socialize, the more of the code/structure gets out of my head and needs to be "reloaded". Conversely I have many days I spend almost entirely socializing (aka meetings) and on those days I get almost zero coding work done.
1. What do the more experienced folks here think of this? 2. Is there any serious/casual study done on the topic?
11 comments
[ 3.8 ms ] story [ 37.7 ms ] threadhttps://en.wikipedia.org/wiki/NeuroTribes
Where you spend your time is what you get good at.
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.
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.
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.
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.
I am not saying that I agree or disagree with the conclusion, mind you.