The problem is that when you tell people what you are planning to do, there is always some a**hole who knows less than you who is going to criticize your plan. It takes a brave developer to continue with their original plan after getting flamed in public.
If it’s a small team, you’ll probably get good feedback. If it’s a large team or publicly open source, the likelihood of getting flamed increases.
No doubt different programmers have different motivations for “going dark”. But, I wonder if there is similarity to other “artistic” endeavours? Many painters and authors loathe discussing work in progress. There is a feeling that talking about a project before it’s fleshed out can ruin or displace the train of thought before it is fully formed.
The concept must be universally human. As a feature film animator, I’ve witnessed animators who insist on locking themselves away for days or weeks intending on springing a glorious and completed shot upon the director. 9 times out of 10 it’s not what the director was thinking and it’s back to square one.
I think there’s an insecurity in not wanting to show your insides. An unfinished animated shot (much like code), reveals your thought process, and can be frankly, ugly to look at. In a collaborative environment however, it’s critical to be able to iterate these ideas out in the open.
Oh good, I guess this means I get to start reviewing the stackoverflow code soon! Yay!
One problem with such social interaction when writing code is when you have a weak team lead and at least one guy on the team with a completely different programming philosophy, strong opinions, and a love of debate. If you show it knowing that your brilliant idea will get turned into a committee-designed, mediocre compromise, it feels a lot better to wait until it’s done.
This happened to me on a team once. Two of the guys had a really strong MSSQL background, but less Java experience, and were always pushing for DB stored procedures to do everything. Every design decision was a massive lobbying effort, because two members of the team were guaranteed to have a radically different take on the decision.
I know this may be an edge case, and under most circumstances I agree with the post. But sometimes going dark is an act of self defense.
If this is indeed the problem and cause, I think it is perhaps a newer phenomenon and a reflection of working with people with different backgrounds and life experiences, leadership, and/or our current economic environment more than an inherit trait of people that are in the IT profession.
It seems programmers are enthusiastic to share their code and knowledge, because they can learn as much as they give, and they get satisfaction out of the interchange (as long as it is constructive and non-personal). If they are coding (“in the dark”) and dumping, I’d ask, “what is the root cause”, and address that issue.
From huge computer conventions to every size of computer user group out there, they exist to share information, learn, grow, and an opportunity to get out of “the dark”. If programmers only wanted to work in “the dark” these wouldn’t exist in the form they do, and generate millions in revenue in tourism dollars.
Certainly this isn’t localized to the IT profession. This topic often comes up when talking about telecommuting and work. Why hasn’t it caught on in corporate America? Everyone talked about it over a decade ago, bye-bye cubicle, hello home office. An accountant working from home, maybe even creating a desktop DB or spreadsheet, doesn’t that constitute working in “the dark”? No one is examining their technique, logic, or how it fits into the larger system. In this case, the answer usually boils down to management doesn’t know how to manage people without seeing them actually doing it (how do we explain outsourcing then, hhmmm %-? I guess you outsource the watching too. ;-)). Perhaps that is similar to your “going dark” though.
I always liked the book, “One Minute Manager” for its simple but effective analogy for creating a successful working relationship. Although, I think it was written before stock options which assumes only one motivating factor.
http://www.scribd.com/doc/335040/The-One-Minute-Manager
Another good book, “Becoming a technical leader: an organic problem-solving approach”.
http://www.amazon.com/Becoming-Technical-Leader-Problem-Solving-Approach/dp/0932633021
Or Weinberg’s other book, “The Psychology of Computer Programming” (although dated). Or “Mythical Man Month”"
The failure rate in IT projects in general, suggest there might be more to it 
http://www.computing.co.uk/computing/news/2197021/failed-projects-hit-half-uk
http://www.it-cortex.com/Stat_Failure_Rate.htm
http://www.itworld.com/Man/3883/041015poor/
Each of us occupy different positions in political environments (PEs) we work within. There are more or fewer lines which are risky to cross, for each person. The mature expertise knows when embedding a nice-sounding rule is worth it or not (unless they’re wrong, but at least they’re wrong less often …).
I’ve long preferred what I call “MIT-like” environments where there’s a healthy fraternity-like fun in being crazy and showing off. At a former small company, we had 3 senior developers and 3 or 4 juniors, and most of us had been there 6 years or more. We constantly hopped on code someone else had coded, to fix or revamp it, and usually we’d make occasional ‘ewww’ remarks about this or that, often with a q of what drugs the original coder was on at the time, or what relationship problems they had then. But most of the fun was in positivity — we improved what we came upon, and we made it all much better. My fave rules are: constantly improve, and disrespect shows respect.
I think a perfect example of not going dark is Scott Hanselman. He’s working on BabySmash to learn WPF and XAML. He’s using CodePlex to share it with others and learn from them as well as help others to learn along with him.
Often going dark points to a larger problem.
Sometimes people want to make a change they know other programmers won’t like, or they’re afraid that the other programmers won’t understand it. They fear their project will be derailed or misguided through ignorance.
This points to a lack of empowerment in the environment, whether it is the power of the individual to be heard or respected if they are not team leadership, or the lack of power to enforce decisions if they are. It can also point to a stifling environment where decision making is funneled through very few people, and those people don’t appreciate input or different points of view.
At that point, folks should ask if they really want to take part in the project or not. Maybe there’s no choice, maybe the project is too important to go wrong. On the other hand, there’s a billion problems to solve, work on one where the politics and society are better.
Sometimes with open source projects you can reach the same “code-bomb” status even if you are sharing your code every step of the way. I recently started writing a patch for a popular open-source media player. I posted each step of my process in the bug report, but did not get any responses. As a result the patch is now about 1000 lines and probably has no chance of getting committed. The onus is not only on the patch writer to remain transparent, but also on the project developers to keep on top of things.
“…and although there is a role for people of this disposition in the software world…”
i’m curious. what role would that be?
Hi Jeff,
I kind of find it ironic that going dark would be flagged as an anti-social pattern.
Isn’t it their anti-social traits that characterize great developers in the first place? i.e. their greater affinity with machines than with people…
Going dark is bad, sure, and I would also prefer it if gravity was a little lighter (kidding).
Going dark sometimes, as a act of self-defense, is something that makes sense to me when one lives in an hostile world. And who claims the world is always a nice place?
Once you go dark, you never look back…
Hi Jeff. I’m looking forward to seeing you post your articles paragraph by paragraph, as you write them, rather than going dark on us and springing your blogging gems upon us fully formed ;-).
Nice article. 100% agree.
I cannot write a single line of code without a svn/cvs repository, continuously committing at every compilation. Doing differently is suffering for me. (I don’t care of people watching my mistakes: I never do mistakes 
)
If you get code reviews frequently then the quality of the code you check-in improves. Even if the person you’re explaining it to says nothing you’ll probably notice potential improvements yourself while doing this.
Depends on what you think is most important, the quality of the software or how people perceive the quality of you.
This is a problem in two parts.
First, we coders tend to have (from my perception) rather soft and somewhat large egos that don’t like to get pressured by appearing wrong. I consciously try to not feel bad about public mistakes but it still gets to me. That’s part human nature, part the obsessive personality that tends to ‘fit’ better with the coding profession.
Second, not a lot of managers understand the value of things like code reviews. If my manager says I have 5 days to get a feature implemented, knowing that I can probably do it in 4-4.5 days with a bit of contingency, they never think that they need to schedule a co-worker or someone else to also review my code. Add on to this that my manager is a producer and doesn’t know an int from a double and there is a pretty big problem.
Of course it would be nice if the world was black and white, but it’s not. Sometimes it’s perfectly OK, and even necessary for a good eveloper to shut the fucking door for a week or two and get things done. If the dev is good, he will put flexibility into his design to satisfy fringe cases. If he’s really good, he will improve on the original design and produce reliable, tight code that will run like a clockwork and satisfy the requirements perfectly well. The “social” part is needed for people who can’t get shit done to put up this illusion that they’re actually doing something. You know the types, they sit around, socialize till they’re blue in the face, while the “anti-social” dude with skills locks himself up in a room and gets things done.
Committing lots is not always a good solution either, do you want to be the guy that breaks the nightly builds every day for the next four weeks? Adding small working bits is a must of course. BUt yeah better smaller working bits then bigger not working bits, makes it eassier to debug too.
Everybody writes crappy code. Everybody.
It’s just that some people don’t want to admit it.
Don’t get me wrong, we all occasionally have the light of inspiration shine down upon use and create something really beautiful.
However, it has been my experience, that most of the time we are programming solutions to mundane business problems and guess what? We wind up with mundane code.
Because of this, a lot of programmers don’t develope the ‘new’, ‘in’, ‘at the fore front’, ‘sizzelin’ coding styles that we all are taught is the ‘correct and cool and happenin’ way.
If you’r in this boat do you really want everyone else looking at your ‘sub-standard’ code?