Hacker News Reader

Comment by hnriot | Hacker News Reader

my takeaway was amazed that something posted in "the kitchen" is even read by anybody. For a technology company that's a pretty low tech multicast.

as for the actual point of the article, it seems highly inefficient to post problems and assume the right (interested) people will take them on. The obvious problems with this is scaling, and how do you account for people not working on the things that they were supposed to be doing. Basically, it's only something tenable in very few situations and only when a company is at a certain size. It wouldn't work today, for the most obvious reason that Google has a lot of kitchens!

View on HN

I wonder if you'd be more or less impressed by the back of bathroom stall door postings by the QA team, "Testing on the Toilet." http://googletesting.blogspot.com/2007/01/introducing-testin...

> as for the actual point of the article, it seems highly inefficient to post problems and assume the right (interested) people will take them on

The question is: Is it more or less efficient than alternatives, such as the fairly common practice of picking a software engineer out of a creatively-named-or-architected-hat and saying "You, you do it"?

If your selection process doesn't account for interest, you're losing significant efficiency on interest mis-fit. Nobody procrastinates harder than a software engineer with an ill-fitting problem.

Perhaps the point was that company culture let this work despite the obvious issues with efficiency and priority conflicts. You're absolutely correct that this tactic wouldn't work in today's Google, but if company culture has persisted, it might still work within internal teams (albeit in a much less visible fashion).

The kitchen was replaced with memegen[0]. The same principle still applies though. Someone complains about a problem. Engineers all around the company brainstorm and implement a solution to said problem. It's a unique and difficult atmosphere to grow in a company.

[0] http://thefw.com/take-a-peek-inside-googles-internal-meme-ge...

During my one year at Google, the problem with the most complaints by far on memegen is Android L's "safety lock," requiring an extra swipe up before entering the unlock code.

This is an edict from the design team, which engineering brainstorming cannot overcome. Furthermore, the majority of engineers cannot implement a solution even if they cared to try: they lack permission to access the development Android source repository.

Maybe it's different in other product areas, but from where I sit, the atmosphere you describe feels like a myth that Googlers tell each other, and not part of its culture today.

I can't speak to your particular experience but it's a single datapoint from one year for one person.

I no longer work at Google but for the nearly 7 years I was there while not every complaint got handled by a group of engineers like described in the article, a startling number of them were. It was still very much a part of the culture when I left and I would not be surprised to discover that it still was.

Considering the problem was solved over the weekend, it seems like this problem was solved in engineers' spare time. Since only the people who were interested would solve the problem, I imagine it wouldn't be too far fetched to think they could do this in addition to whatever else they were supposed to do as it would be fun for them.

I imagine an ideal scenario would be something between just letting everyone do whatever they want and having some tasks assigned, as there might be things that nobody wants to do but obviously still need to be done.

The right balance probably depends on the size of the company as well. For example I believe Valve is famous for not managing its employees and letting them work on whatever they want. I suppose they can only really do that because they are a private company though.

Weekend != spare time, once you are in an on-call rotation.

Reply on news.ycombinator.com