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.
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.
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.
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).
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.
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 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.
> 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.
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.
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.
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 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.
[+] [-] labrador|3 years ago|reply
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.
[+] [-] brnt|3 years ago|reply
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.
[+] [-] NoPicklez|3 years ago|reply
I know plenty of supposed introverts that cannot focus.
Being an introvert doesn't necessarily mean you aren't necessarily social or sociable.
[+] [-] superchroma|3 years ago|reply
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.
[+] [-] loldk|3 years ago|reply
[deleted]
[+] [-] superchroma|3 years ago|reply
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.
[+] [-] rgavuliak|3 years ago|reply
[+] [-] YourGrace|3 years ago|reply
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.
[+] [-] jdlshore|3 years ago|reply
> 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.
[+] [-] bitwize|3 years ago|reply
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.
[+] [-] Silhouette|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] ankurdhama|3 years ago|reply
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).
[+] [-] nbzso|3 years ago|reply
Collaboration Overload Is a Symptom of a Deeper Organizational Problem
https://hbr.org/2017/03/collaboration-overload-is-a-symptom-...
[+] [-] themenomen|3 years ago|reply
[+] [-] HellDunkel|3 years ago|reply
Now of course you don’t need all of that if it was the case that everything that counts is what you deliver.
[+] [-] gsatic|3 years ago|reply
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.
[+] [-] satisfice|3 years ago|reply
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.
[+] [-] NoPicklez|3 years ago|reply
[+] [-] watwut|3 years ago|reply
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.
[+] [-] fzeroracer|3 years ago|reply
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.
[+] [-] satisfice|3 years ago|reply
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.
[+] [-] ResearchCode|3 years ago|reply
You seem to be describing micromanagement.
[+] [-] watwut|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] HellDunkel|3 years ago|reply
[+] [-] dusted|3 years ago|reply
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 ;)
[+] [-] kramerger|3 years ago|reply
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
;)
[+] [-] watwut|3 years ago|reply
Both these go on regardless of how little information is available about one coding skills.
[+] [-] eesmith|3 years ago|reply
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.