3 ms·

Don't go dark

45 points by bdfh42 18y ago

DaniFong 18y ago
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 18y ago
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 18y ago
  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.
bayareaguy 18y ago
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.
drawkbox 18y ago
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 18y ago
  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.
deleted 18y ago
[deleted]
goodgoblin 18y ago
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.
noonespecial 18y ago
"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.
TrevorJ 18y ago
I gotta tell you, this is good advice for ANY line of work.

45 points by bdfh42 18y ago

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 18y ago

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 18y ago
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.

bayareaguy 18y ago

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.

drawkbox 18y ago

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 18y ago
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.

deleted 18y ago

[deleted]

goodgoblin 18y ago

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.

noonespecial 18y ago

"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.

TrevorJ 18y ago

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