> 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.
See https://blog.codinghorror.com/dont-go-dark/ for more commentary.