From ShipIt Days | Atlassian:

ShipIt

24 hours to innovate. It's like 20% time. On steroids.

That's, um, nothing like 20% time.

Though, of course, 20% time was never 20% time either:

Yahoo CEO and formal Googler Marissa Mayer once bluntly denied its true existence. 

"It’s funny, people have been asking me since I got here, 'When is Yahoo going to have 20% time?'" she said on stage during an all-employee meeting at Yahoo. "I’ve got to tell you the dirty little secret of Google’s 20% time. It’s really 120% time."

That said, I think I'd take 10% time:

"It's not technically something that gets formal management oversight — Googlers aren't forced to work on additional projects and there are no written guidelines about it. Typically, employees who have an idea separate from their regular jobs will focus 5 or 10% of their time on it, until starts to "demonstrate impact." At that point, it will take up more of their time and more volunteers will join, until it becomes a real project." [attributed to "Google HR boss Laszlo Bock"]

Interesting final quote from Bock: "[The informal 20% time policy] operates somewhat outside the lines of formal management oversight, and always will, because the most talented and creative people can't be forced to work."

The interesting lesson is that you win when you convince your employee to produce more work. Maybe 20% time isn't such a bad idea for either side of the management fence. X hours of required work versus 1.2X of work the employee actively wants to give. Sounds like a win-win.

Labels: business, culture, Google, management, time

TIL there's a "conflict of interest" "behavioral guideline" at Wikipedia. Seems this would be easy to misuse, but it would've been useful when I tried to make the entry for the Midwest Book Review a little more informative, a site that I'm suspicious sells positive Amazon reviews, back when I stumbled over them in 2010.

Fwiw, I'd found an insanely positive review for a book I was considering buying, and the review didn't seem to include the sorts of specifics someone who'd really read the book would've used. I looked over the Midwest Book Review's history, and -- I'm doing this on memory; could be off a little -- the reviews were all very high, with the gross majority 5's. Turned out they took review solicitations.

There was a dude who wouldn't quit editing out some flavor of the following passage:

Jordan Lapp, an author, asked Mr. Cox [Midwest Book Review's Editor in Chief] why Mr. Cox felt that Amazon's rating system was flawed, and why "all of the books [Midwest Book Review] rate merit a 5 star rating." Mr. Cox answered by saying, "So I instructed our webmaster (who does all the posting for reviews generated 'in-house' by the Midwest Book Review editorial staff) to use 5 if the book was given a positive recommendation." Mr. Cox continued by explaining that, "for a book to make it all the way through the Midwest Book Review process... it merited the highest recommendation available under the Amazon rating system. Inferior books, flawed books, substandard books are assumed to have been weeded out and never made it to the 'finish line' of publication in one of our book review magazines."

They do realize those less than 5 star "reviews" would be just as more useful than the ones they let out, right? That is, I'm going out on a limb and say that those sub-5 reviews don't exist. Or at least the "in-house" team isn't paid for writing them.

Reminds you of the Seinfeld episode about car reservations, doesn't it?

"We know why we have the reviews."

"I don't think you do. If you did, I'd have a clue about the book. See, you know how to write the review, you just don't know how to put critique in there. And that's really the most important part of the review. The reading and critiquing. Anybody can just write them..."

Sure, that's my take on the quote, but do note I didn't include anything from Seinfeld in my Wikipedia edit. You're welcome to make your own conclusions. ;^)

And the controversial source for this potentially damning material from Mr. Cox? The Midwest Book Review's website. The page with that quote is still there.

Anyhow, I think once you googled Cirt, the anti-editor who kept taking out my changes, enough, you found a connection. If true, this flag would've really helped.

sigh I've probably detailed that here before. The strange thing to me is how much of what's on Wikipedia can be control by those with the most endurance for making edits. Not exactly a merit-based environment at its edges (core?).

Of course what's most interesting is that it'd be possible to algorithmically track places where folks used this tool to influence Wikipedia's contents, and see if there are any obvious categories of COI usages.

Labels: culture, noteToSelf, pseudo-academic, wikipedia

I wanted to see if JSHint had a provision for checking imported packages for property names in a file it was, um, "hint"ing, and ran into a link to the, "Why I forked JSLint" post (which was down -- domain now points to github? -- but lives at archive.org) again. The post is interesting. The representative example given to fork JSLint is a horrible one, imo. Kovalyov argues that he should be able to put a var before a iterator variable, like this...

for ( var name in obj ) { ...

That's really not a good reason to leave JSLint. Forcing you to acknowledge variable hoisting doesn't seem that objectionable. There are other things that it forces you to do that I don't see as much wisdom in, but this really isn't one of them. And that his snippet has "Example taken from jQuery 1.4.2 source" as if that made it automatically something worth emulating also gnaws at my craw a bit.

But the post's epigraph from Crockford does resonate:

Your sadly pathetic bleatings are harshing my mellow. —Douglas Crockford.

Wow. Reminds me of the link I use in my StackOverflow profile to undercut where I quote, "You should take JSLint's advice," a bit. The guy's a great coder, and I enjoy his very strict approach to JavaScript 99.44% of the time, but Kovalyov is right: Crockford's social skills (and, from what I've seen, hubris) are awful.

But again, bad social skills don't make the tool just as toxic. Kovalyov links to Brenan Eich, "creator of JavaScript", where Eich says, "JS Lint can suck it" That's said, sure (Eich is using automatic semicolon insertion, though he's doing it to make his code look like CoffeeScript, so Kovalyov has already taken the quote well out of context), but there's an interesting counterpoint Kovalyov misses in that same blog post from Eich:

Here's my pitch: committees do not design well, period. Given a solid design, a committee with fundamental disagreements can stall or eviscerate that design out of conservatism or just nay-saying, until the proposal is hardly worth the trouble. At best, the language grows larger more quickly, with conservative add-ons instead of holistic rethinkings.

What I like most about JSLint is that I know I'm getting similar code across the board. JSLint honestly enforces well-considered conventions. When Kovalyov says, "It is quickly transforming from a tool that helps developers to prevent bugs to a tool that makes sure you write your code like Douglas Crockford," my reply would be, "And you think your committee is going to do better?"

So many questions about JSLint on StackOverflow get answered with, "You should use JSHint." But if we all use JSHint to turn off whatever bugs us, as we'd do if we followed that advice each time, what do we leave turned on? Just the things that aren't troublesome? Isn't our code getting lint-i-er each time? Show me an example of where what Crockford requires from you is wrong -- not just annoying, but undeniably worse than an alternative. I don't think it exists, yet.

Isn't the point of a linter to challenge us all to write better code?

Labels: coding, culture, JSLint, style

But writing innovative software cannot be done on an assembly line. It requires hard-to-find development and design skills. Farming out development to legions of programmers overseas will not create a differentiation advantage. When a technology company outsources software development, that company loses its capacity to innovate and its competitive advantage.

Labels: business, coding, culture, hats of money, outsourcing