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

Scaling GitHub

zachholman.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Scaling GitHub

#51

Post by heimidal »

bengl3rt wrote: post #50

This is of particular interest to me because I'll be starting my full-time job hunt early next year (or even earlier because I get neurotic about these things), and I really only want to work somewhere that understands the appeal/necessity of "work where you want/when you want/on what you want". How do I filter potential job opportunities on that criteria without being rude to anyone? I don't want anyone to think I t…

Github is a very, very special company, and there aren't many companies out there that operate this way. Unless the organization as a whole adopts the philosophy you're looking for from the top down, this kind of freedom usually doesn't exist.

I think a good start is to begin early and search for companies that fit your criteria, then find ways to demonstrate why you would be a good employee to those companies directly. Don't go through the normal channels; find a way to stick out and be seen before you even apply.

Best bet: contribute a ton to a high-profile, well-known open source project that will stick out like a bright, shining beacon of light to your potential employers.

Re: Scaling GitHub

#52

Post by nosequel »

gavingmiller wrote: post #11
epenn wrote: post #8

One thing the slides mention in passing that I cannot stress the usefulness of enough is an internal wiki. There are so many common tips, issues, ideas, etc. that can be more effectively communicated and expanded upon when they're in a centralized location for all to see. So many conversations of the form "I've never dealt with that, but I know $coworker ran into that once. Go ask him." can be reduced or eliminated i…

+1 But the issue I always face is that many coworkers aren't diligent enough to document in the wiki. How would you address that?

Move the wiki somewhere where they don't even have to leave their normal flow of work. We moved ours to github. Just make a private & empty repo, add a wiki to it, and now you have a wiki you can edit in your favorite editor, search with grep, and save / revert with git. Back of the napkin estimate, I would say we have 4 to 5 time the activity on the wiki that we did before. We found that developers really don't want to leave what they are doing, open a browser, possibly log in somewhere to edit in some embedded editor that doesn't have emacs/vim/whatever bindings. If your team still doesn't use it, well then it might be time to polish off that CV.

Re: Scaling GitHub

#53

Post by nosequel »

RandallBrown wrote: post #42
antirez wrote: post #35

Github is a bit special but I guess this can work every time you have a few basic ingredients: a product that has final customers (no busines-to-business), and a company that is completely focused in developing this single product. It is not very common but also not rare either for web startups to have this kind of setup, so I think this may work for many... of course a fundamental thing here is that they hire smart…

I think saying that GitHub is a special case is a copout. The real meaning of this presentation is that if you treat your employees well and let them do their job, they'll build great stuff. Yes, not all companies will have the same success as GitHub with this approach, but I bet for most it would be a huge improvement over what they have now.

I don't necessarily think it is a copout. They are bootstrapped, are making a ton of money, and hit the market with a good product right off the bat. Not many companies can afford to do the things they do and still pull a profit. How many startups can afford and justify having an artist (not graphic artist mind you) permanently on staff? Don't get me wrong, I love github and they have a great team, but not every company can do the things they do and still be in business.

Re: Scaling GitHub

#54

Post by snprbob86 »

gavingmiller wrote: post #11
epenn wrote: post #8

One thing the slides mention in passing that I cannot stress the usefulness of enough is an internal wiki. There are so many common tips, issues, ideas, etc. that can be more effectively communicated and expanded upon when they're in a centralized location for all to see. So many conversations of the form "I've never dealt with that, but I know $coworker ran into that once. Go ask him." can be reduced or eliminated i…

+1 But the issue I always face is that many coworkers aren't diligent enough to document in the wiki. How would you address that?

I'm not a huge wiki proponent for mostly that reason. However, the other big factor is that a lot of the time the Wiki becomes an excuse for not automating something. A surprisingly good place to start is to add a README and a Makefile. Both of those things show up in recursive greps ;-)

Re: Scaling GitHub

#55

Post by jdunck »

kisielk wrote: post #37
generalk wrote: post #25

Earlier quoted context omitted.

> However, I have trouble believing that all of these > ideals will work when you have a PM screaming at your > engineers to finish the internal CRM system [...] That's the point. The point of these things is that instead of having a screaming PM demanding that deadlines be met, you hire self-starting employees who have fun with their job. It's an internal CRM system, so why not shove it full of in-jokes and vi-keybi…

There's also the issue of exposure industry cred. I mean, we're talking about GitHub here, one of the hottest websites amongst developers. Working on it comes with a certain amount of prestige and every feature they add results in a massive amount of industry press on sites like HN. Of course engineers working there are going to be extremely driven and motivated, it's a very rewarding product to work on. Now imagine…

I agree with what you're saying, but the solution is not to make the situation worse by having a PM screaming at them about TPS reports. That will only drive away what talent is in the pull of Widget Inc; a net negative for the company.

Widget Inc does not need to have the best devs, so this is largely moot. Widget Inc does not compete on IT, does not need their apps to be good, does not care if the best devs work there, no matter what they say.

And so, github has the prestige.

Re: Scaling GitHub

#56

Post by jdunck »

sbov wrote: post #48
phillmv wrote: post #16

Earlier quoted context omitted.

GH is a special case. They're darlings of the tech community, and they throw a ton of events. Even if they were crappy to work for they would probably have an easy time hiring. THAT SAID, "finishing the internal CRM system" is a problem that happens in organizations an order of magnitude larger, methinks. My finishing platitude is, how did you hire - and why do you retain - engineers that don't give a shit about the…

I work on several projects that I have never used. However, my employer doesn't completely shield me from people who do use it. At least for me, the satisfaction comes from interacting with people who the project helps and seeing how it helps them. I think part of why (some)? engineers may not give a shit about the project they're working on isn't necessarily because they have no interest in it, but because they have…

My best experiences in corporate IT were when I escaped the department for short times - a flight to an office whose processes were on fire, a deployment of a new warehouse management system where all the workers were counting on me, a 3-month 5-person project sprint to deliver a late, overbudget project without adult supervision.

Whatever the purpose of IT middle management, it does not appear to accomplish much.

Re: Scaling GitHub

#57

Post by joeshaw »

technoweenie wrote: post #46
redidas wrote: post #41

Earlier quoted context omitted.

What about for the dashboards, like on slide 63? Is that generated by Graphite as well?

Just basic HTML/CSS/Javascript built around the Graphite JSON APIs. We have Hubot integration to build graphs on demand through commands in Campfire, a Graph Store to save graph configurations, and static HTML pages that arrange these graphs nicely.

They are beautiful, especially compared to the built-in dashboard UIs. If you're looking for yet another piece of infrastructure code to give away for free, I'd love to see it open-sourced.

Re: Scaling GitHub

#58

Post by ans »

phillmv wrote: post #13
victork2 wrote: post #10

Earlier quoted context omitted.

Agreed, but sadly this is the state of passing information now in "new age" startup/ companies. It's like Twitter: some nice pastel colors, very little text, no information but it's easy access and people can say "Oh yeah, I know about scaling I have read this on a blog post". Sorry to break it everyone but scaling is hard, totally unfunny or uncool, with tons of problems and stressful. But to answer your question an…

1) It's a slide deck for a talk. What were you expecting, a detailed tutorial? I also don't think you got the most important bit: focus on employees. 2) Scaling is also… really custom. I'm extremely unlikely to have to find a way to shard git repositories across a network of users. And they do cover their architecture and release back a fair number of their tools.

Re.: 1) OK-why post it then? Post the talk.

Re.: 2) Doesn't matter if it might not be useful, it sure would be interesting. :)

Re: Scaling GitHub

#59

Post by wfarr »

joeshaw wrote: post #57
technoweenie wrote: post #46

Earlier quoted context omitted.

Just basic HTML/CSS/Javascript built around the Graphite JSON APIs. We have Hubot integration to build graphs on demand through commands in Campfire, a Graph Store to save graph configurations, and static HTML pages that arrange these graphs nicely.

They are beautiful, especially compared to the built-in dashboard UIs. If you're looking for yet another piece of infrastructure code to give away for free, I'd love to see it open-sourced.

You might be interested in https://github.com/paperlesspost/graphiti

It's somewhat based on some of the stuff Github uses internall for graph generation (so the README says).

Re: Scaling GitHub

#60

Post by aiurtourist »

Promoting these practices does little good for companies that aren't GitHub, and believing in them might be woefully idealistic.

Let's look at GitHub:

* Most of GitHub's 50 or so employees are engineers[1], not sales or marketing or product management or art directors or logistics or accounting.

* GitHub's primary product is github.com[2], a product which is primarily used by engineers.

* The company hasn't taken funding outside of friends & family[3].

* They claim to be "very profitable"[4].

* Their team is distributed[1], which can work well for engineers who enjoy time alone.

Compare this to my startup: Engineers are Our customers are normal humans, not engineers (no offense, I'm one too), and our products need to be sold and marketed so that people understand why they're good. We don't have the benefit of a customer base who intrinsically know why the product is great once they use it like engineers do. Our products want to make our customers come work for us.

We're all in one place because we need to collaborate with non-engineers to build our product. Good in-person relationships with the sales and marketing people lets us work together very well and is important for non-engineers, who especially can't use a DVCS to collaborate.

We iterate quickly, so systems like Campfire or wikis are useless. There's no point in writing documentation and employee on-boarding instructions if they're going to be out of date in two weeks or if it's easier to walk over to The Guy Who Knows That Stuff and ask. Yes, our bus factor is horribly low, but it's not worth documenting a system that will change wildly in two months.

We also have a board of directors who are demanding. We have monthly and quarterly goals we need to meet. We don't have time to work on cool things like bots and music players because we're busy experimenting and building products which we're still defining. Sure, we add a few easter eggs here and there, but I need to finish the damn CRM improvements, otherwise the sales team can't handle our customers in the way we want, the customers won't have the best experience, we won't hit our January numbers, and the board will be angry.

I love GitHub. It's one of the greatest things to happen to open source and software project collaboration. But whenever Zach Holman shows off a well-manicured presentation or blog post about how awesome GitHub's ideals and work environment are, I have to roll my eyes a little. His intentions are good and he's a swell writer and presenter, but I can't help but wonder what kind of magical, mystical fairyland he think's he in.

(No offense, Zach. I think you're great. Let's get a beer.)

  [1] https://github.com/humans.txt
  [2] Probably. What else do they do?
  [3] http://news.ycombinator.com/item?id=1454597
  [4] http://techcrunch.com/2010/07/24/github-one-million/
Post reply on HN