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.
On your first point, I agree, I've seen extroverted employees enter the management track and get promoted to such positions over others.
On the topic of great software, I would offer that maybe this is beside the point. I'm not convinced that in most organizations of sufficient size that you can even get great software, because they fall down a road of lowest common denominator development to tackle issues of huge scale, complexity and managing varying levels of talent. In my experience there tends to be so much intertia and process created to corrall people that usually inspired people are left shackled at the hand and foot and prevented from effecting meaningful change. Once this happens, it comes down to the capacity for individuals to bring people on board (usually not an advertised developer skill) and sell ideas to others to effect change, which I think informs at least part of the thinking in hiring "team players" - which really is management engineering around the problems that they've created.
There are too many examples to list of one programmer inventing software that the rest of take for granted now. The best example of more than one is probably Jeff Dean and Sanjay Ghemawat at Google, but that's just two people.
It's possible the companies who want team players are acknowledging that their programmers aren't the best so everyone needs to work together to make something that works.
I've revised my comment a little. Yes, it's definitely possible. The example that comes to my mind now is the guy who runs Krita, which is a project with huge scope, but I think that to do this effectively requires a high level of discipline and patience that many people don't have and that is difficult to test for when hiring, which is why companies are forced to turn to bureaucracy instead.
I recently watched a documentary on Henry Ford. One of his innovations was to move manufacture from a craftsmen model that required high skills to an assembly line model that used more people with less skill to get the same result. The managing engineer is the one holding it together.
With this in mind it makes sense to hire team players who are good enough over highly skilled workers who work in isolation. The trick then becomes finding highly skilled workers who are able to engineer and manage solutions for the lower skilled workers to implement.
Does that analogy really hold when you're making software and not a physical product? In software development you don't need a production line staffed by minimally skilled workers to implement the plan of the expert. Automation is what we do.
Of course you still often need those experts to have decent soft skills because many commercial projects will still need multiple developers even if everyone involved is very good. But the communication and management overheads scale far more than linearly with the size of the team so a relatively small team of very skilled developers can easily outperform a much larger team of mediocre developers in practice.
Well, maybe? For every hard problem which requires smart people to actually innovate, there's 100 which involve writing boilerplate to get information from a form to a database and back again.
> Does that analogy really hold when you're making software and not a physical product?
I think it does. Of course the minimal skill required is higher than hiring some person off the street to bolt on a few parts as the product proceeds down the assembly line.
I worked at Microsoft many years ago and it was a lot like a software factory
Two problems. One is with the Ford model itself: deskilling workers to the absolute maximum extent possible makes the whole assembly line more brittle. If you have a guy whose only job is to put a screw in a specific joint, what happens when he gets sick? Whole assembly line gets held up. You could hire two screw guys but you'd be paying twice as much and one of them sits there idle. Plus, germs spread quickly, what if they both get sick?
My father realized this in the late 60s or early 70s as an engineering manager at a tech company (back when tech was Tech and tech companies actually made stuff). His solution was as follows: Line jobs were ranked A, B, and C, for high, medium, and low skill. Especially the C and B jobs, you could teach multiple jobs to a single worker, and give them a workbench at which they could do several tasks in the manufacturing process, not just one -- and have several workers at workbenches doing all these tasks. The assembly line gets slowed down when one worker gets sick, but it still proceeds because whatever job that worker was doing, their colleagues also know how to do. My father's idea was dismissed by the higher-ups to implement companywide, but it's part of the "Toyota method" now, so I guess it was independently discovered in Japan. Good ideas are like that, plus, the Japanese actually respect craftsmanship; at the end of the day, American businesses only respect money and metrics.
Secondly, how many times must it be repeated? Software engineering is not like manufacturing. It takes zero skill and next to zero cost to manufacture an additional copy of a program because a program is just bits that are trivially copied by computer. To develop new software requires a moderate to high level of skill, so you want to cultivate craftsmanship in your software developers, unless you like the current state of enterprise webshit and think that software that's slow to develop, slow to run, fraught with bugs and integration issues is just fine.
Fred Brooks proposed essentially that model, but it hasn’t really worked out in practice: software design too often needs radical modification on the fly, and it becomes inefficient to bottleneck everything through the managing engineer.
Team-playerism is an attempt to do for developers what RAID does for storage or the cloud does for compute. It is an attempt to simulate a great programmer with a redundant array of good programmers, and get more reliability out of the deal. (Great programmers are highly sensitive to their work environment, and the more scrupulous ones will quit when they aren't getting the work conditions, respect, or compensation they feel they're entitled to for their work. The less scrupulous ones will sabotage your company from the inside, or sprinkle backdoors in to sabotage it from without once they've left.)
It never works, of course. Insights come from individuals, not collectives, and while having similarly skilled colleagues to bounce ideas off of and refine them with works well for great programmers, they have to come up with the ideas themselves in the first place. The communication overhead in a team of good programmers prevents them from having great-programmer insights at great-programmer speeds. The way to fight communication overhead is to ensure that each team member has a large corpus of shared information. In other words, a shared, standardized coding style which further hampers insight because insightful solutions have little regard for "the rules".
But most companies just want CRUD+business rules, so RAID (Redundant Array of Intransigent Developers) works well.
Programming is essentially mathematics. Imagine if mathematicians were required to do pair-proving.
Pair- programming is a case in point. It emerged from "Xtreme Programming" which emphasized "values" and "people", not problem solving skills. So why didn't they go further and require "triple programming", then "quatro programming" and so on?
The way to tackle complex problems is by divide-and-conquer: Divide the problem into smaller parts which can be solved independently. Pair-programming is not that, it doesn't divide the problem into two and then let each programmer work on one part of it individually. Instead there's a pair of chefs in the same kitchen team-cooking the same spaghetti.
To put it bluntly I think people who demand "team-players" are typically those who don't have the skills to solve any part of the problem by themselves. By building a team around them they can hide that fact. If the project fails it is nobody's fault, the whole team did their best and still it couldn't succeed. We followed the best agile practices you know. Or maybe it succeeds, because of a few good men and women.
(Successful) team-playing is when each team-member plays their part, not when they all play the same part. Think volley-ball, that's a great team-sport.
The question remains: If pair-programming is so great, wouldn't triplet programming be even greater? Why not? Or why not "take it to the eleven"? Eleven programming. Why is 2 the answer? Why not 42?
I can see that pair-programming can help in some situations like getting new team-members up to speed. But I question those who say it should be applied universally, always, as a general rule.
> Insights come from individuals, not collectives, and while having similarly skilled colleagues to bounce ideas off of and refine them with works well for great programmers, they have to come up with the ideas themselves in the first place.
Bouncing insights off each other in a team might lead to someone else taking up and working on something that to the originator was just a fleeting side idea in a train of thought, but can turn out to be valid on its on / viewed from a slightly different angle / in a slightly different context. Whereas if the individual works entirely on their own, valid ideas / insights may be forgotten and fall by the wayside forever.
(Personally I probably tend more towards the solo side, but have to admit there are advantages to teamwork too.)
By no way am i an expert on the topic. My take is that i see extroverts as generally more extrinsically motivated. So in terms of archieving things i regard them as sprinters, beeing more dependent on feedback by other people, as opposed to marathon runners.
It's important to be aware that one isn't either an introvert or extravert; it's a scale. And you can move around it.
I use software everyday built by (large) teams which no doubt required some extroverts to get done. In fact, I don't think I use any software written by a single person?
Some people must not have worked in very good teams when I see the subject come up. Having my first proper training (it involved Belbin, but there are other models like it) openee my eyes to understanding interpersonal dynamics and what separates funtioning dynamics to non functioning ones (some diversity in attitudes and skills!). Writing great code means nothing if nobody knows about it, is able to use it, or needs it, etc. I recently organized a training like this for my current team (of highly skeptical software engineers) and it was a great succes.
It would be a good start if people wouldn't reduce themselves to a single stereotype. People can be and are multiple things at once, and I'd say it's extremely healthy and useful to be skilled in more than a single way.
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.
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.
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.
You don't want me to have even a FEW HOURS to work out a difficult problem? That is utterly unreasonable. I think you are imagining only a certain kind of problem while ignoring many other kinds. It took me hours to work out how to make a lovely visualization using the Plotly library in Python. No one else knew how to use Plotly. I figured it out and gave them a demo. They are glad I went into the cave.
Most of my work is doing blockbusting like that, not doing easy things. But certainly, if someone on the team knows something about the tech I'm researching, I check in with him.
What you are talking about is something that only exists as the result of teamwork. We all rely on documentation, people asking questions, people giving answers and people working as a team.
If you're working on rare things where you are the only expert on the team then yes, you can have the opportunity to go into full focus mode and hammer something out. And as the other poster said, sharing that knowledge after you've finished is part of being a team player. If you simply say 'I am an individual contributor, I turn in my work and then I'm done' that to me sounds like someone that's not interested in sharing knowledge.
> If you're working on rare things where you are the only expert on the team then yes,
You dont need to be ONLY expert on the team for the above. Other people knowing the same thing dont prevent your knowledge of the system. For the above, you need to have passing knowledge of the thing you work on. And you should have build that knowledge while doing previous taks.
The situation in which majority if tasks is assigned to developer who has no clue about that area of the system, again and again, is unreasonable.
You should ask (and preferably asynchronously, not by having random long meetings). Spending 7-8 hours working out a solution is however normal (on working with actual complex systems, like during a PhD, you might go a week between meetings but varies according to actual needs).
> 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.
Genuinely, if there are so many questions that few hours of solitude are red flag, then something is massively wrong with the process at hand. It really means that tasks are less then underspecified and likely means testing/demoing processes are completely lacking.
> 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.
Sure, you work in small part. But if all this is routine issue due to 7-8 hours if engineering, then the system is likely mess too difficult to decipher. It also means the development is overly chaotic. The developers working on the project should build up knowledge of the rest of the system overtime, this is somehow failing.
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 disagree, Silo is not a term invented to slander people its a broad term where two teams don't work or communicate with one another like they should.
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.
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 intention of this piece likely was to shed some light onto this hybris you are describing. Why bother? An open dialogue on such issues could help build healthier workplaces, better industry performance, improve sustainability and fairness.
Now of course you don’t need all of that if it was the case that everything that counts is what you deliver.
> 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).
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.
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.
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.
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.
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 ;)
I only want one pronoun, and it should mean "you're not interesting enough for me to care" :)
I don't know where it came from tbh, probably monday lack of caffeine and capacity to handle the many facets of being human.. A weariness of constantly seeing articles about why and how my gender and culture is toxic and must change to focus on stuff I don't care about.. I just want to program computers.. I don't care about the politics or culture, if I did, I'd have become something in the humanities.. And the constant pressure to extinguish the thing in my field that makes it comfortable for me to be there.. That I do in fact get to be left alone for long stretches of time to focus on doing something I _can_ do well, rather than a constant nagging about the things I find uncomfortable and can't do well.. Kinda gets to me the end, the constant hate on the oldfashioned stereotypical loner geek.. The constant pressure to push them out because they don't conform socially or enjoy working in teams..
Thing is, while functioning in a team is something that can be learnt to some degree, it's not the default mode of operation for all of us.. And the pressure to make it the default mode of operation for all software development nags me, because it means that there won't be a place for me in the future, I will be excluded, in the holy name of inclusivity (which means something very specific, namely defined by problem hair and pronouns).
Because, I'm one of the wrong ones, I've always been, but in the past, computers were the one place where I could be myself on my own terms.
Agile development and push for constant teamwork was here for years and years, at the time when being gay was openly mockable. The daily standups are the thing first introduced 20 years ago. If you really don't care about politics and culture, why are you venting your frustrations with collaborative process that exists entirely independently on trans people?
You wrote that you don't care about politics. Then you complained about agile style teamwork and related it to pronouns and trans politics, despite the two having zero with each other.
That is not just caring about politics, that is actively bringing it up. And it is not just taking side, but it is going out of way to blame the side youbare opposed to for stuff they have nothing to do with. (Like your issue to focus).
You do care about that stuff it seems to and you do care a lot about pronouns.
> Then you complained about agile style teamwork and related it to pronouns and trans politics, despite the two having zero with each other.
> That is not just caring about politics, that is actively bringing it up.
I read their complaint as not being about "pronouns and trans politics" per se, but with the fact that stuff like that is becoming so dominant in the workplace. GP was saying that that's all irrelevant to them[1], not taking sides pro or contra.
I have found this to be repeated assertion by conservatives - that your political leaning somehow has to do with whether you are programmer or not. The underlying assumption, literally always, is that if you are progressive leaning, you cant be good programmer. And the other assumption is also frequent: if you are right leaning or even sexist/racist, then the assumption is that you are unusually good coder.
Both these go on regardless of how little information is available about one coding skills.
> hipsters with trouble hair and strong opinions on pronouns
I guess you don't remember Boomer programmers complaining about Gen-X programmers, raised on BASIC, with trouble hair (male programmers with their ponytails and scraggly beards), and with strong opinions on how 'information wants to be free', who know just enough to plug a board into an EISA slot, but unable to use a soldering iron or oscilloscope.
It comes down to what "silo" means. Most people use something like https://en.wikipedia.org/wiki/Information_silo#In_organizati... - "a mindset present when certain departments or sectors do not wish to share information with others in the same company".
If you update your status, help stuck team mates, and tell your part at the standup then you aren't in a silo.
This has zilch to do with tired stereotypes of modern developers. Here's what the author wrote:
> A team player isn’t someone who shies away from going into a silo. In fact, the very nature that drags you to an unromantic profession like programming is your ability to go into a cave for hours, and emerge victorious having nailed the problem, and/or designed the kickass solution. That victorious outcome takes months, sometimes years, yes.
Compare that with what McCarthy wrote in 1995: "Rule #30: Don't go dark."
] You have to manage the granularity of development tasks in such a way that you emerge with visible deliverables over short intervals. In our group, we argue back and forth over how big the intervals should be: five days, ten days, three weeks? In our world, three weeks is going dark.
] I don't know what's appropriate for your world, but we want team members to have contracts with the other parts of the team so that they surface pretty often with visible components. When somebody surfaces and the deliverable isn't done, we know right away. We know that this week we slipped one day. That's worth knowing, much better than getting to the end of the project and observing, "Oh, we slipped six months!" At that point it's too late to even bother counting up how much you've slipped.
and: "Rule #31: Beware of a guy in a room"
] Specialist developers who lock themselves away in a room, who go dark for long stretches, are anathema to shipping great software on time. No matter how brilliant a developer might be, don't give the developer a significant assignment unless he or she understands and buys into the type of development program you intend to run. The brilliant developer must be capable of performing on a team, making his work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and although there is a role for people of this disposition in the software world, it is not as a part of a team devoted to shipping great software on time.
"Standups" are micromanagement. Which other high level profession does this. Doctors are not interrogated daily by some charlatan with a certificate for a 2 day course. PhD programs in CS/Maths tend not to do "standups". Asynchronous communication could replace most meetings at your regular CRUD sweatshop anyway.
Look up to dusted's comment, which I'll copy here:
"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."
I was pointing out that someone who is doing exactly what dusted wrote should be done, is not in a silo.
Your disagreement with dusted about the appropriateness of a standup is a tangent I am not able to participate in, having been in roughly 5 standups in my programming career.
> 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.
62 comments
[ 2.7 ms ] story [ 133 ms ] threadOn 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.
On the topic of great software, I would offer that maybe this is beside the point. I'm not convinced that in most organizations of sufficient size that you can even get great software, because they fall down a road of lowest common denominator development to tackle issues of huge scale, complexity and managing varying levels of talent. In my experience there tends to be so much intertia and process created to corrall people that usually inspired people are left shackled at the hand and foot and prevented from effecting meaningful change. Once this happens, it comes down to the capacity for individuals to bring people on board (usually not an advertised developer skill) and sell ideas to others to effect change, which I think informs at least part of the thinking in hiring "team players" - which really is management engineering around the problems that they've created.
It's possible the companies who want team players are acknowledging that their programmers aren't the best so everyone needs to work together to make something that works.
With this in mind it makes sense to hire team players who are good enough over highly skilled workers who work in isolation. The trick then becomes finding highly skilled workers who are able to engineer and manage solutions for the lower skilled workers to implement.
Of course you still often need those experts to have decent soft skills because many commercial projects will still need multiple developers even if everyone involved is very good. But the communication and management overheads scale far more than linearly with the size of the team so a relatively small team of very skilled developers can easily outperform a much larger team of mediocre developers in practice.
I think it does. Of course the minimal skill required is higher than hiring some person off the street to bolt on a few parts as the product proceeds down the assembly line.
I worked at Microsoft many years ago and it was a lot like a software factory
My father realized this in the late 60s or early 70s as an engineering manager at a tech company (back when tech was Tech and tech companies actually made stuff). His solution was as follows: Line jobs were ranked A, B, and C, for high, medium, and low skill. Especially the C and B jobs, you could teach multiple jobs to a single worker, and give them a workbench at which they could do several tasks in the manufacturing process, not just one -- and have several workers at workbenches doing all these tasks. The assembly line gets slowed down when one worker gets sick, but it still proceeds because whatever job that worker was doing, their colleagues also know how to do. My father's idea was dismissed by the higher-ups to implement companywide, but it's part of the "Toyota method" now, so I guess it was independently discovered in Japan. Good ideas are like that, plus, the Japanese actually respect craftsmanship; at the end of the day, American businesses only respect money and metrics.
Secondly, how many times must it be repeated? Software engineering is not like manufacturing. It takes zero skill and next to zero cost to manufacture an additional copy of a program because a program is just bits that are trivially copied by computer. To develop new software requires a moderate to high level of skill, so you want to cultivate craftsmanship in your software developers, unless you like the current state of enterprise webshit and think that software that's slow to develop, slow to run, fraught with bugs and integration issues is just fine.
It never works, of course. Insights come from individuals, not collectives, and while having similarly skilled colleagues to bounce ideas off of and refine them with works well for great programmers, they have to come up with the ideas themselves in the first place. The communication overhead in a team of good programmers prevents them from having great-programmer insights at great-programmer speeds. The way to fight communication overhead is to ensure that each team member has a large corpus of shared information. In other words, a shared, standardized coding style which further hampers insight because insightful solutions have little regard for "the rules".
But most companies just want CRUD+business rules, so RAID (Redundant Array of Intransigent Developers) works well.
Pair- programming is a case in point. It emerged from "Xtreme Programming" which emphasized "values" and "people", not problem solving skills. So why didn't they go further and require "triple programming", then "quatro programming" and so on?
The way to tackle complex problems is by divide-and-conquer: Divide the problem into smaller parts which can be solved independently. Pair-programming is not that, it doesn't divide the problem into two and then let each programmer work on one part of it individually. Instead there's a pair of chefs in the same kitchen team-cooking the same spaghetti.
To put it bluntly I think people who demand "team-players" are typically those who don't have the skills to solve any part of the problem by themselves. By building a team around them they can hide that fact. If the project fails it is nobody's fault, the whole team did their best and still it couldn't succeed. We followed the best agile practices you know. Or maybe it succeeds, because of a few good men and women.
(Successful) team-playing is when each team-member plays their part, not when they all play the same part. Think volley-ball, that's a great team-sport.
Article on them here: https://www.wired.com/2012/08/google-as-xerox-parc/
I can see that pair-programming can help in some situations like getting new team-members up to speed. But I question those who say it should be applied universally, always, as a general rule.
https://news.ycombinator.com/item?id=30383382
Bouncing insights off each other in a team might lead to someone else taking up and working on something that to the originator was just a fleeting side idea in a train of thought, but can turn out to be valid on its on / viewed from a slightly different angle / in a slightly different context. Whereas if the individual works entirely on their own, valid ideas / insights may be forgotten and fall by the wayside forever.
(Personally I probably tend more towards the solo side, but have to admit there are advantages to teamwork too.)
I know plenty of supposed introverts that cannot focus.
Being an introvert doesn't necessarily mean you aren't necessarily social or sociable.
There are plenty of lazy, unmotivated introverts.
That's also on a scale.
I use software everyday built by (large) teams which no doubt required some extroverts to get done. In fact, I don't think I use any software written by a single person?
Some people must not have worked in very good teams when I see the subject come up. Having my first proper training (it involved Belbin, but there are other models like it) openee my eyes to understanding interpersonal dynamics and what separates funtioning dynamics to non functioning ones (some diversity in attitudes and skills!). Writing great code means nothing if nobody knows about it, is able to use it, or needs it, etc. I recently organized a training like this for my current team (of highly skeptical software engineers) and it was a great succes.
It would be a good start if people wouldn't reduce themselves to a single stereotype. People can be and are multiple things at once, and I'd say it's extremely healthy and useful to be skilled in more than a single way.
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.
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.
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.
Most of my work is doing blockbusting like that, not doing easy things. But certainly, if someone on the team knows something about the tech I'm researching, I check in with him.
If you're working on rare things where you are the only expert on the team then yes, you can have the opportunity to go into full focus mode and hammer something out. And as the other poster said, sharing that knowledge after you've finished is part of being a team player. If you simply say 'I am an individual contributor, I turn in my work and then I'm done' that to me sounds like someone that's not interested in sharing knowledge.
You dont need to be ONLY expert on the team for the above. Other people knowing the same thing dont prevent your knowledge of the system. For the above, you need to have passing knowledge of the thing you work on. And you should have build that knowledge while doing previous taks.
The situation in which majority if tasks is assigned to developer who has no clue about that area of the system, again and again, is unreasonable.
You seem to be describing micromanagement.
Genuinely, if there are so many questions that few hours of solitude are red flag, then something is massively wrong with the process at hand. It really means that tasks are less then underspecified and likely means testing/demoing processes are completely lacking.
> 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.
Sure, you work in small part. But if all this is routine issue due to 7-8 hours if engineering, then the system is likely mess too difficult to decipher. It also means the development is overly chaotic. The developers working on the project should build up knowledge of the rest of the system overtime, this is somehow failing.
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.
Collaboration Overload Is a Symptom of a Deeper Organizational Problem
https://hbr.org/2017/03/collaboration-overload-is-a-symptom-...
Now of course you don’t need all of that if it was the case that everything that counts is what you deliver.
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).
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.
> 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.
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.
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 ;)
Mate, seriosly, where did _that_ come from?
I mean, as a _REAL PROGRAMMER_ myself, it sounds to me as _you_ have strong opinions about other peoples pronouns
;)
I don't know where it came from tbh, probably monday lack of caffeine and capacity to handle the many facets of being human.. A weariness of constantly seeing articles about why and how my gender and culture is toxic and must change to focus on stuff I don't care about.. I just want to program computers.. I don't care about the politics or culture, if I did, I'd have become something in the humanities.. And the constant pressure to extinguish the thing in my field that makes it comfortable for me to be there.. That I do in fact get to be left alone for long stretches of time to focus on doing something I _can_ do well, rather than a constant nagging about the things I find uncomfortable and can't do well.. Kinda gets to me the end, the constant hate on the oldfashioned stereotypical loner geek.. The constant pressure to push them out because they don't conform socially or enjoy working in teams..
Thing is, while functioning in a team is something that can be learnt to some degree, it's not the default mode of operation for all of us.. And the pressure to make it the default mode of operation for all software development nags me, because it means that there won't be a place for me in the future, I will be excluded, in the holy name of inclusivity (which means something very specific, namely defined by problem hair and pronouns).
Because, I'm one of the wrong ones, I've always been, but in the past, computers were the one place where I could be myself on my own terms.
That is not just caring about politics, that is actively bringing it up. And it is not just taking side, but it is going out of way to blame the side youbare opposed to for stuff they have nothing to do with. (Like your issue to focus).
You do care about that stuff it seems to and you do care a lot about pronouns.
> That is not just caring about politics, that is actively bringing it up.
I read their complaint as not being about "pronouns and trans politics" per se, but with the fact that stuff like that is becoming so dominant in the workplace. GP was saying that that's all irrelevant to them[1], not taking sides pro or contra.
___
[1]: Or, let's be honest, him.
Both these go on regardless of how little information is available about one coding skills.
I guess you don't remember Boomer programmers complaining about Gen-X programmers, raised on BASIC, with trouble hair (male programmers with their ponytails and scraggly beards), and with strong opinions on how 'information wants to be free', who know just enough to plug a board into an EISA slot, but unable to use a soldering iron or oscilloscope.
It comes down to what "silo" means. Most people use something like https://en.wikipedia.org/wiki/Information_silo#In_organizati... - "a mindset present when certain departments or sectors do not wish to share information with others in the same company".
If you update your status, help stuck team mates, and tell your part at the standup then you aren't in a silo.
This has zilch to do with tired stereotypes of modern developers. Here's what the author wrote:
> A team player isn’t someone who shies away from going into a silo. In fact, the very nature that drags you to an unromantic profession like programming is your ability to go into a cave for hours, and emerge victorious having nailed the problem, and/or designed the kickass solution. That victorious outcome takes months, sometimes years, yes.
Compare that with what McCarthy wrote in 1995: "Rule #30: Don't go dark."
] You have to manage the granularity of development tasks in such a way that you emerge with visible deliverables over short intervals. In our group, we argue back and forth over how big the intervals should be: five days, ten days, three weeks? In our world, three weeks is going dark.
] I don't know what's appropriate for your world, but we want team members to have contracts with the other parts of the team so that they surface pretty often with visible components. When somebody surfaces and the deliverable isn't done, we know right away. We know that this week we slipped one day. That's worth knowing, much better than getting to the end of the project and observing, "Oh, we slipped six months!" At that point it's too late to even bother counting up how much you've slipped.
and: "Rule #31: Beware of a guy in a room"
] Specialist developers who lock themselves away in a room, who go dark for long stretches, are anathema to shipping great software on time. No matter how brilliant a developer might be, don't give the developer a significant assignment unless he or she understands and buys into the type of development program you intend to run. The brilliant developer must be capable of performing on a team, making his work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and although there is a role for people of this disposition in the software world, it is not as a part of a team devoted to shipping great software on time.
See https://blog.codinghorror.com/dont-go-dark/ for more commentary.
"Standups" are micromanagement. Which other high level profession does this. Doctors are not interrogated daily by some charlatan with a certificate for a 2 day course. PhD programs in CS/Maths tend not to do "standups". Asynchronous communication could replace most meetings at your regular CRUD sweatshop anyway.
"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."
I was pointing out that someone who is doing exactly what dusted wrote should be done, is not in a silo.
Your disagreement with dusted about the appropriateness of a standup is a tangent I am not able to participate in, having been in roughly 5 standups in my programming career.
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.