Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling GitHub's Employees

zachholman.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Scaling GitHub's Employees

#31

Post by dabeeeenster »

SoftwareMaven wrote: post #25

People work on what they want to work on. Product development is driven by whoever wants to drive product. That is the surest way to reduce your startup's odds of survival. In this case, it would become a prototypical case study in survivor bias. GitHub is lucky that they are building a product that is tailored for developers. It makes their survival rate doing this slightly higher because the developers are (only va…

The interesting thing about GitHub is that they are in the unusual (and fortunate!) situation whereby they are their own prototypical user...

Re: Scaling GitHub's Employees

#32

Post by brown9-2 »

snprbob86 wrote: post #26
brown9-2 wrote: post #22

God I wish my team had a Hubot.

I coded up a HipChat bot in if msg[0] == '!' [cmd, args...] = msg.slice(1).split(' ') require("commands/#{cmd}").exec(chat, args) Just add a coffee file to the commands directory and export an `exec` function which callc `chat.reply` -- couldn't be easier!

Hmm, would you have any pointers on where to start with CoffeeScript to do something like this?

Re: Scaling GitHub's Employees

#33

Post by alecperkins »

captn3m0 wrote: post #21

What's the designer culture at github? Do you make them use git?

No doubt that's part of the motivation behind the excellent http://mac.github.com/

I love their philosophy of automating tasks to make them as simple as possible, so that anyone in the company can do them. It's really frustrating and time consuming to play sys admin every time you need to work on or deploy something, especially when you aren't at all a sys admin.

Re: Scaling GitHub's Employees

#34

Post by stonemetal »

SoftwareMaven wrote: post #25

People work on what they want to work on. Product development is driven by whoever wants to drive product. That is the surest way to reduce your startup's odds of survival. In this case, it would become a prototypical case study in survivor bias. GitHub is lucky that they are building a product that is tailored for developers. It makes their survival rate doing this slightly higher because the developers are (only va…

I wonder how they keep the product focused with a do whatever you want product development schedule. Rather sounds like a good way to end up with an elephant with a long neck and a short nose.

Re: Scaling GitHub's Employees

#35

Post by SoftwareMaven »

pjhyett wrote: post #29
SoftwareMaven wrote: post #25

People work on what they want to work on. Product development is driven by whoever wants to drive product. That is the surest way to reduce your startup's odds of survival. In this case, it would become a prototypical case study in survivor bias. GitHub is lucky that they are building a product that is tailored for developers. It makes their survival rate doing this slightly higher because the developers are (only va…

I'm not entirely sure what you mean by "only vaguely." The fact that passionate developers are building developer tools has a lot to do with why we've been successful. Chris, the CEO, has spoken at length about this topic. He and I built another site prior to GitHub where there was very little correlation between our interests and the product we were building. Not surprisingly, our hearts weren't in it and we threw i…

I say only vaguely because what you want to use may or may not have any correlation with what people want to buy, and it is extremely risky to assume that correlation exists.

just because you're working on something you're passionate about doesn't immediately mean you're bound for success; it just helps tremendously.

It helps immensely (in fact, if you don't have that, you are doing it wrong, IMO :), as long as you don't let your passion get in the way of figuring out what your customer wants.

Like I said, dev tools are a special breed that have more wiggle room for this, but as my experience shows, it is not immune from failure (in fact, developers are notoriously cheap because there are so many good, free dev tools out there, but I bet developers aren't your primary customer, but rather their managers).

My response can be summed up in one sentence: with all startup advice, beware survivor bias!

Re: Scaling GitHub's Employees

#36

Post by kaffeinecoma »

captn3m0 wrote: post #21

What's the designer culture at github? Do you make them use git?

"make them use git" - given that the entire business is built around git, I should hope so. Git isn't the most user-friendly VCS, but why shouldn't a competent designer be able to pick it up? I've even got our designer working with branches.

Re: Scaling GitHub's Employees

#37

Post by iffius »

Saying that automation "reduces institutional knowledge" seems a bit misleading in that the knowledge is still kept by the institution but is somewhat inaccessible because the information is held by only a few employees. Perhaps saying that automation "records institutional knowledge" would be more accurate.

Re: Scaling GitHub's Employees

#38

Post by snprbob86 »

brown9-2 wrote: post #32
snprbob86 wrote: post #26

Earlier quoted context omitted.

I coded up a HipChat bot in if msg[0] == '!' [cmd, args...] = msg.slice(1).split(' ') require("commands/#{cmd}").exec(chat, args) Just add a coffee file to the commands directory and export an `exec` function which callc `chat.reply` -- couldn't be easier!

Hmm, would you have any pointers on where to start with CoffeeScript to do something like this?

https://gist.github.com/940969

Re: Scaling GitHub's Employees

#39

Post by wonnage »

SoftwareMaven wrote: post #25

People work on what they want to work on. Product development is driven by whoever wants to drive product. That is the surest way to reduce your startup's odds of survival. In this case, it would become a prototypical case study in survivor bias. GitHub is lucky that they are building a product that is tailored for developers. It makes their survival rate doing this slightly higher because the developers are (only va…

I think the idea they're pushing is, why force a centralized structure for product development/design decisions, when your programmers are intelligent and independent enough to do it themselves? It's not just a free-for-all where people work on shiny toys; developers should be allowed to think about the customer too! It's quite a different energy when the same guy is recognizing what needs work (i.e, what a 'product manager' would do) and developing it.

Think about the Linux kernel - contributions are distributed and asynchronous, and most of the authority figures arise organically rather than by decree. I don't think you need product managers, they just relieve the developers of having to do that work themselves.

And yeah, it definitely helps that github uses github to write github. But dogfooding really isn't that unusual or difficult.

Post reply on HN