

Don't go dark - bdfh42
http://www.codinghorror.com/blog/archives/001134.html

======
drawkbox
Guido worked almost alone on Python for a good 5 years. The best ideas are
made by 1-3 people. I agree dont' go dark, but coding by community/design by
committee can be horrible on the other extreme.

At a certain point projects can be ready for more collaboration, at a certain
point they are too young and might get spoiled by project wreckers. Showing
incomplete code/systems to the wrong people (i.e. non programmers in many
cases) can be the death of good ideas.

Look it up, find your favorite tool, platform, language etc, I guarantee you
there is 1-3 guys that made it happen at the first iteration at least.

~~~
mechanical_fish
The first iteration is not what "don't go dark" is about. The aphorism refers
to releases 2, 3.. N, where the code you're writing needs to mesh with the
expectations, needs, and codebase of other people.

Sure, if you haven't released your code yet and you have no users, you can be
as dark as you like. You can change your API on a whim. Nobody cares! There's
still a risk, of course -- the risk that you're wasting time developing
something that everyone else will just ignore -- but that's just _your_
problem. The problem with "going dark" after the initial release is that it
causes trouble not just for you, but for _everyone else_ whose work depends on
your work.

------
DaniFong
But if something is _too_ visible, or _too_ scheduled, many big ideas will be
shied away from, many projects won't even start. I suspect this is one major
reason Google's 20% time is so productive (50% of new Google products started
in it, and if you consider that a large proportion of other products are
acquired, it starts to sound like a pretty big deal). In the earliest, nascent
phases of project development, you don't always have good justifications for
what you're doing, or much to show. Projects, like companies, are at their
most fragile at this time and the random perturbations and throttling from
following a fixed methodology may kill them.

Mostly, while we should recognize what we gain having teams more closely
manged, scheduled, with greater visibility and contact, we should also
recognize what we lose. Balance is important, but I think there's a different
optimal point for every market, company, and project, and every executive or
engineer.

One important, crucial example comes from PayPal. Max Levchin went dark for a
year, and came up with the something that really mattered -- a way to fight
fraud. But there were hypothesis galore. I'm not sure this work would have
been done any other way.

------
bprater
The question is how to allay people's fear of showing off something that isn't
polished or finished yet.

Part of the onus is on the rest of us -- to be good critics of other people's
code. Constructive critism without the ego gives lots of introverted know-it-
all hackers real trouble.

~~~
raganwald
I agree.

Look at programming.reddit.com. Many posts have a bushel of upmods but the
majority of comments on those posts are negative.

Thus, you have a weird behaviour where peopel who like something are less
likely to speak up than people who dislike something.

It may have something to do with the fact that praising something doesn't seem
to add value--what's the point of a comment that says "great idea"??? Thus,
people who like something upmod it but have little to say.

On the other hand, people who dislike it have lots to say, and it feels like
criticism is adding value to the community.

But from the perspective of the person doing the work, putting something on
display before it is bulletproof and perfect is much more likely to attract
flames than praise. You hvae to have an asbestos ego to deal with that on a
regular basis.

------
noonespecial
"Going dark" might be more acceptable to senior programmer types who already
have a strong grasp of software development concept, accepted idioms, and
basic coding style.

They seasoned expert is like likely to return after his dark period with
something consistent, clearly written and mostly bug free. (Especially the
troublesome design flaw bugs).

The junior programmer who goes dark mostly out of fear of criticism is likely
to return with something that has no consistent style, mixed up idioms and
likely fundamental system-wide design flaws that require rewrite.

The important difference here is the _reason_ these two different classes of
developers choose these long dark periods. The first developer wants to be
free of politics, interruptions and nitpicking while he builds what he knows
how to build. The second is afraid of criticism as he stumbles through
unfamiliar territory hoping that if he can get it to "just work" it will hide
his ignorance.

Denying the first his time might cost you something truly great that you
otherwise won't be able to get. Allowing the second cheats the junior of a
valuable learning experience and simply allows him to continue in bad
practices, gaining _"experience"_ without any real increase in know-how, thus
generating the strange coder we;ve all met with "20 years of experience in
blub" who writes unusable code.

------
goodgoblin
I personally love 'going dark' - it is exhilarating - though I recognize the
risks. On my last project I went dark for about 6 months developing a
configuration tool for another part of the project. My code ended up looking
nothing like the rest of the codebase, I didn't use the same approach to just
about anything, but I've got to say, the tool itself is amazing.

I don't know if I could have built just as good a piece of software without
going dark, but I do know it wouldn't have been as much fun. For all of the
differences with the rest of the codebase, my own section has a cohesiveness
of design that sets it apart. I'm actually trying to get better at staying
with the pack, but sometimes I see that gnarly problem out of the corner of my
eye and I just want to bolt.

------
bayareaguy
Whenever there are negative consequences to those who express concern or doubt
about aspects of the design or implementation, there will be a strong
temptation for developers to "go dark" for a little bit while they investigate
assumptions that they can't discuss publically with the rest of the group.

------
TrevorJ
I gotta tell you, this is good advice for ANY line of work.

