[crazygringo]

This is great for creating new products, for innovation.

But I've never understood, who then does the grunt work? Who slogs through producing the documentation, and keeping it up-to-date? Once a new product/feature is launched, who sticks around for the bugfixes, support, etc., since presumably everyone will be more excited to allocate themselves to the next new big thing?

In every company, there's a lot of totally boring, unattractive stuff that needs to get done nevertheless. With open allocation, who does that?

[swampthing]

Zach Holman has an answer on Quora on this:

http://www.quora.com/GitHub/How-does-GitHub-handle-tasks-tha...

[eliot_sykes]

A link to the same page on Quora, but with ?share=1 appended to the URL so login isn't required: http://www.quora.com/GitHub/How-does-GitHub-handle-tasks-tha...

[mojuba]

More often than not, boring work that nobody wants to do at your company is an indication that something went wrong in the process of design & development of your product.

For example, from my experience as an end user, if a product or service relies heavily on documentation, "knowledge bases", forums etc. then it's pretty much fucked up already. Work of any kind at a company behind such a product would be boring: from management and engineering to QA and technical writing.

Github is obviously not among this kind of companies. And I wonder what would be considered "boring job" at GitHub then.

[sanderjd]

The idea that the existence of "boring" work at a company is an indication that the company did or is doing something wrong is specious, and as a user of lots of software, I really hope this mindset doesn't become common. I want the people making the software I use to be ready and willing to do tough and unglamorous work that makes my experience better. Github's solution seems to be for everyone to really own and care about the product, such that working on "boring" things is a matter of pride. That's a really good solution, but creating and sustaining that culture is really difficult. The lesson others should learn from them is not "don't ever have boring work to do", but rather "create a culture where employees hold themselves and each other responsible for getting the boring work done".

[chii]

management could incentivize "boring" work by allotting bonus equity/share/money to those who do it instead of the "glamorous" work. Then the individuals gets to decide for themselves what to work on. If not enough people are doing the boring work, it just means that the work isn't being compensated for enough.

[sanderjd]

Except we're talking about structures where there is no management to speak of. If there is strong management, they can just tell people to work on those things as part of their job. I suppose you could extend your idea to a loosely structured company where incentives would be created through consensus.

[Already__Taken]

You could offer straight bounties for the work. Those are great for motivating simple low cognitive tasks and getting good results.

[dasil003]

You're conflating good product design with good company processes, but those are completely separate concerns. Of course a good product shouldn't require documentation because the whole point as a consumer product company is you are bending time and space to make something that people want to pay for. However in order to accomplish that there will most likely be some shit that needs shoveling along the way. Who does the bookkeeping at Github for instance?

[mojuba]

My hypothesis is speculative. I think what we call "shit work" is in fact something that is less creative and as such is likely to be subject to automation/algorithmization.

In other words, with the right tools, platforms and algorithms you have less shit work to do.

A few things that can be considered "external bureaucracy", such as accounting, patents, legal stuff etc, that are kind of beyond your control, so they should simply be outsourced. For bookkeeping, hire a company. There will be some amount of interaction with them of course, but that itself shouldn't require full time involvement. I did that for one of my companies, worked OK for us.

[specialist]

+1

Word of support: Some people call this "technical debt".

At my current day gig, developing new "products", I spend a lot of time trying to understand what's what. Oversimplifying: dealing with terrible legacy code, overwraught design, poor implementations of poorly defined interfaces, supporting byzantine processes.

We have acres of documentation. Mostly out of date, useless, or both. We make up for the lack of clarity by having lots and lots of meetings, where we get to swap misunderstandings.

I experience recurring eurekas, each time I finally understand the actual end goal (business need, user's use case). Quickly followed by a face palm slap, wondering why anyone would make such a simple problem so frikkin hard.

[mojuba]

Often it's not just algorithms and approaches, but also the choice of tools. I once had a rare opportunity to rewrite a legacy application from scratch, and by simply switching from COM/DCOM to REST I got code base 20 times smaller than the original. 20 friggin' times!

[lttlrck]

There are plenty of industries where customers want to see documentation upfront before purchase and if you can't provide it you'll lose the sale, it's a clear indication of an immature product. Maybe not in your industry, maybe you don't care about lost sales, but to say any work in companies with such customers is boring is utterly naive.

[rfnslyr]

Honest question, have you worked a real job before?

Documentation, by virtue of existence, does not negate product integrity. There is so much extremely complex software with very specific applications out there with documentation that would take you very long to comprehend.

It's the behavioural nature of the system being documented that determines complexity.

[mojuba]

Have I worked before? Been in the industry for almost 25 years now.

The benefits from complex software should be so disproportionately massive that the users would be willing to adopt it. The C++ language and the compilers come to mind: they do come with documentation, are complex, but that's nothing compared to the entire worlds that you can create with C++.

On the other side of the spectrum you have things like Parallels Plesk: an awful piece of software that always creates more problems for you than it's trying to solve, even if you read their tomes of documentation, knowledge bases, searched their forums etc. The existence of Plesk and software alike can't be justified really.

[has2k1]

I think that is where "cultural fit" comes in, where everyone has a sense of ownership of everything for which they possess the required skill-set.

If that is so then the real magic happens at the hiring stage.

[bkbleikamp]

> Who slogs through producing the documentation, and keeping it up-to-date? Once a new product/feature is launched, who sticks around for the bugfixes, support, etc., since presumably everyone will be more excited to allocate themselves to the next new big thing?

Doing this work is part, and perhaps the most important part, of shipping a feature. It's not just boring work. If someone isn't prepared to support something, they shouldn't ship it.

[bshacklett]

I don't know how common this is, but I personally love working on documentation and fixing bugs. I can't imagine I'm the only one out there. Perhaps they just make sure they have enough people that are interested in that type of thing?

[kawsper]

I think there are different kind of developers. Some like to build new and shiny stuff, where others like to maintain and keep stuff running.

I like to do both things, and can't say that I like building new stuff more than maintaining.

[yeukhon]

I doubt they don't have assigned roles. It would be a chaos when everyone just write 100 lines for every project. Nothing will get done.

I am sure people work on specific tasks every day but they are free and welcome to contribute.