I Am a Programmer – No, I Don't Want to Be a Team Player

I've come to the conclusion that this is easily explained. Managers are extroverts or they wouldn't have become managers. Extroverts think that working with others is best and can't understand introverts who would rather work alone. To an extrovert that is anti-social and a sign of deeper issues.

On the other hand, a lot of great software I've run across has been written by introverts, but I can't think of any that has been written by extroverts. Where do they find the time to devote the focus required when they are busy socializing?

I'm confident about my first paragraph above, not as much about the second.

I think this misses the point about the sorts of team players these companies are trying to get, who are usually decent solo programmers but who also are often fun, light and friendly, actively work to build trust with a team through socialization, promote good practices and patterns and don't begrudge the fact that a portion of their day is to be spent in meetings, reviewing others' code and generally communicating. These people exist, I've met some of them. I've met some of their opposites too, who are usually more quiet, sometimes cranky people who just want to be left alone all the time, and I can definitely see why the former is more attractive from a management perspective.

There probably are tens of thousands of developers readily available who say they like to work in long uninterrupted blocks, and who will be happy to just own something like a dog with a bone before they throw it over the fence for others to look at, and I just don't think that's that special in a person - I think most humans like to work this way naturally, so when you talk about this to a hiring manager or team lead, I can certainly imagine why they aren't energized by the prospect. Also, you have to remember that these people aren't naive, and have probably seen enough staff and candidates to suspect that this sort of description is a cover for general irritability or other personality qualities that interfere with team harmony.

Also, in my experience, in a company that's scaling, with software with lots of interlocking pieces and projects large enough that an individual can't tackle them solo, these people tend not to do so well when compared to "social developers", I would imagine.

Being a team player in my mind (an IC turned manager) is helping the organization optimize for building the right thing, not building things right. You can find a lot of programmers that are decent technically, but the best ones I've worked with cared about making sure what we're building makes sense. It allows us to design architectures that are fit for future changes in regards to how the product evolves. For this to happen you need to communicate and acknowledge that sometimes not coding, but aligning makes the coding part of the job much more efficient.

I wouldn't hire this person either if I had interviewed them.

When I think of a team player, I think of someone who recognizes that a team is composed of people with various skill-sets and being a team player is helping to enable the other teammates to grow at their job. Being a team player is about contributing to the team outside of just your code such as teaching the strategies you use, and your mental model for solving problems you face. It sounds like the author expects everyone to discuss a spec, and then go into their cave and solve the problem by themselves which seems very individualistic to me.

Overall, if you don't want to contribute to the overall growth of your team, than I wouldn't expect those teams to want to work with you either.

Maybe off topic, this article seems like it's main purpose is to drive traffic as the author is selling an ebook.

Pen’s description of pair-programming’s origins is incorrect:

> Besides, pair programming is an industry fad. Someone created a great tool to teach kids how to code, then decided to sell it to companies (because they got deeper pockets than schools and governments paying for kids' programming classes). Instead of selling just the tool (that possibly costs millions in licensing every year), they nowadays come up with a methodology (Agile, anyone?).

This is so far off-base, I wonder where Pen got it from. For the record, pair programming originated at the C3 project (the Chrysler payroll project that gave birth to Extreme Programming). To the best of my knowledge, it was suggested by Ward Cunningham, or perhaps Kent Beck, based on the way the two of them worked together at Tektronix. There was no tool being sold and no school children.

Programming has gone from a great career choice for autists to pretty much an option for allistic extraverts only. After that management consultant taught Microsoft and other companies "beware a guy in a room" in the 90s, that guy in the room went from the layer of golden eggs to a liability almost overnight. The ask now is for CONSTANT collaboration and CONSTANT communication. Mainly because it provides an audit trail. All those Slack messages and Teams calls, together with stats from JIRA on when your stories get assigned and completed, and how complex they are (yes, story points WILL be transmuted into hours, if not in your scrum meetings then in your performance reviews) can be used to determine how you're performing with up-to-the-minute data, and allow management to either intervene to shape your behavior or take disciplinary action up to/including termination if that fails.

Another way to look at it is, you know how we don't trust AI, so we're developing tech to make AI disclose how it arrived at its conclusions so it can be tuned and tweaked to get the responses we want or at least avoid results we don't want?

You, developer, are an intelligence, and Corporate wants to tune and tweak you to get the results they want. An easy way of doing that is to reward you for gabbing with teammates and punish you for thinking on your own, so you are forced to disclose your thought process at all times as it happens so that management can observe, analyze, and modify it in real time.

If you work best by thinking on your own, don't get into programming unless you are co-owner of the business.

Somehow I suspect that a lot of managers who are looking for "team players" are really looking for people who are OK with being on real-time messaging all day where the managers can constantly lurk and feel involved. I'm not sure a dislike of that kind of working environment has anything whatsoever to do with whether you're an introvert or an extrovert or how open you are to discussions with colleagues at times when they're useful.

> Do you work in a team, or do you like to work solo

This question doesn't make any sense. Work is very overarching term here. There are may aspects of "work", some of them require you to do "thinking" (which is a solo activity) and some of them require you to communicate and discuss the outcome of your thinking (which is a team activity).

I found this article from Hbr.org (2017).

Collaboration Overload Is a Symptom of a Deeper Organizational Problem

https://hbr.org/2017/03/collaboration-overload-is-a-symptom-...

Why bother giving explanations of the true self and showing the other, a person with which you are going to have little to no contact, a glimpse of how you truly feel, more so in the event of trying to secure a position that will dictate how you live your live for the next months to years financially speaking. It is in my opinion, better to say what they want to listen, to sweeten every managers and upper management ears with faked feelings of team player and how amazing you are with people, rather than let them know how you feel deep inside, solely for their own satisfaction of believing they are making a top tier team. At the end the only thing that matters is how you perform, what you deliver and the quality of it.

The larger the code base gets, the less you can rely on loners to solve issues. It's why there is a mountain range of stagnating open source projects. It's all mostly from communication breakdown/lack of social skills. Not coding chops.

Beyond a point, most issues will require multiple people to work together and loners get more and more ineffective over time as their social skills degrade from lack of practice.

Software is getting more and more complex not less. Collaboration and communication will be prioritized, and things that interfere with it depriortized, by the ever optimizing corporate robot.

There is almost no such thing as a silo. "Silo" is a term invented to slander people who like to do good work in peace.

Only once in my career of decades have I seen an environment that was truly siloed, in the sense of people locking themselves away from each other. That was a government agency in Washington D.C. It was soul-destroying.

I frequently see teams that aren't in very close touch with other teams. But to call that a silo is too much.

> I read and re-read his reply. To me, it looked devoid of any substance. What was the tiniest amount of time period you had to visit your teammate to qualify as a team player?

Here is the thing, in workplace I am in now, you would suffer and not fit. It is very agile scrum-like. You dont get larger task to start-finish like op described as what he likes. Instead, task is split between multiple people and there are constant overlaps. You dont fix own bugs in own code, someone else does it while you fix third person bugs. There is nothing you "own", ever.

> and emerge victorious having nailed the problem, and/or designed the kickass solution. That victorious outcome takes months, sometimes years, yes.

There is no such aspect in agile teams. It is frustrating even for people who are significantly more "team like" then you sounds like.

What? This just seemed like a bunch of nonsense to me.

Like let me make this clear, I am a born introvert. I prefer being by myself and doing my own thing. That makes me happy. But that doesn't mean I hate being a team player, nor do I think programming is a solo activity. It is very much so a group one.

And in my experience, the people that tend to go into a cave for a few hours and produce a solution will tend to produce the wrong solution. Because no spec or ask is perfect; you should be asking clarification and follow-up questions (even obvious ones!) to understand what is actually wanted. In more complex systems you might be working on a very small part, and exiting into the sun with a system that doesn't fit the rest of the system means you've spent the past 7-8 hours engineering a solution to the wrong problem.

A great post. I would get the book if it was printed!

I'm going to get downvoted so hard for this.

But I agree with OP.

Thing is, OP is a _REAL_PROGRAMMER_ and the world have moved beyond those. The vast amount of shops have no tasks for _REAL_PRORGAMMERS_, what they need are hipsters with trouble hair and strong opinions on pronouns who know just enough to glue together this months random assortment of nodejs libraries for their web"app".

OPs points are valid, you can in fact work in a silo and function very well in a team at the same point. As long as you never tell anyone that matter that you do this.. You update your status, you help stuck team mates and you tell your part at the standup. You code not just for yourself but with the idea that others have a chance of taking it over when you jump in front of a trai.... get hit by a bus ;)