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

31–40 of 69 posts

Re: Scaling GitHub

#31

Post by rhizome »

akg wrote: post #21

I once worked at a "startup" that was the anti-culture. It hired a programmer after the current team had turned them down. That person was hired b/c she was a recommendation from of the VPs friends. At one point, we had more "Managers" in the company than people to manage...needless to say, no one got anything done. I think most companies don't realize that businesses are always about people; they are composed of peo…

The moment you hire someone who is average or doesn't fit, the entire work force degrades gradually.

I agree, as long as you're talking about a socially conservative work force. There are plenty of companies comprised and tolerant of unique people. This doesn't make anybody "average," either, and I'd venture that the less tolerant of outsiders a workgroup is, the more average they are. They're certainly insulating themselves, regardless, which can't be good in the long run.

Re: Scaling GitHub

#32

Post by prsimp »

victork2 wrote: post #3

Pretty nice, but the slides are only interesting from page 45 to 74 the rest is totally useless. I must be allergic to PR aimed at hipsgrammer (hipster programmer)...

Snide comments aside, I think you're missing a lot of value in slides 26 through 34, the section on communication. Reducing the 'spin-up' time for new employees and documenting even the one-off conversations seems like a great way to increase productivity.

Re: Scaling GitHub

#34

Post by newman314 »

GMali wrote: post #33

Can someone explain what exactly he meant by "throttling the google bot"?

It's telling googlebot to slow down and not be so aggressive.

You can use google webmaster tools to dial down the crawl rate.

Some think you can use Crawl-delay: in robots.txt but I have not tested this (and it may very well not work).

Re: Scaling GitHub

#35

Post by antirez »

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 guys, you can do something like that only if every piece of the company is skilled and independently able to handle his own work.

Re: Scaling GitHub

#36

Post by phillmv »

spitfire wrote: post #29
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'm not a fan of loudmouth hipster programmers either. But it's easy to see how a programmer was hired and came to work on a project he didn't like. He was hired to work on a project he was interested in, and was moved over to a project he dreads. They won't stay long though. Which is the difference GH has from many other places: The work is interesting (to many). Therefor they have an easy time hiring and retaining…

>I'm not a fan of loudmouth hipster programmers either.

I throwing hipster around is a waste of time, especially considering these are extremely successful hipster programmers.

Create product everyone loves, create environment everyone loves to work in, live in San Francisco: fucking hipsters.

>He was hired to work on a project he was interested in, and was moved over to a project he dreads. They won't stay long though.

There is always shit work to do. It's a constant of the universe - there will always be work you're not super interested in. The difference is, is the rest of your job good enough to suck it up and take one for the team?

(Do you even think of it in terms of taking one for the team, or do you think you are just being shat upon?)

Re: Scaling GitHub

#37

Post by kisielk »

generalk wrote: post #25
aiurtourist wrote: post #6

I'm usually wary of Holman's presentations and writing. GitHub is such a unique, special place — an engineering company with a product engineers use and are devoted to. This presentation is pretty good and has some good tenets. 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, or something else that engineers must wor…

> 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 you took the engineering team of GitHub (or one like it) and transplanted them to work on Widget Inc.'s CRM system that's primarily used by their sales, marketing and HR people. Instead of your end users being similarly savvy and motivated developers they're now your typical corporate office staff. They're not using your product by choice but only because it's what the corporate higher-ups handed to them. They couldn't care less about new whiz-bang features you add to the product, they're mostly concerned about getting their TPS report out on time. Interface changes only confuse them and slow them down. They're never going to tweet or post a blog post about how awesome the new thing you just rolled out is.

Do you think the engineers would be similarly motivated to work on such a product? I doubt it.

Re: Scaling GitHub

#39

Post by brown9-2 »

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?

Figure out what kind of traits the workers you want (diligent, documenting) exhibit in a job interview and hire that type of people.

Re: Scaling GitHub

#40

Post by getsat »

victork2 wrote: post #22
Pewpewarrows wrote: post #20

Earlier quoted context omitted.

Sorry to break it to you , but scaling isn't hard anymore. The tools we have at our disposal today makes it trivial compared to companies attempting to do the same thing 5-6 years ago. As soon as you figure out the scaling from 1 -> 2 servers, you're basically done until you hit top-1000 traffic. Because as soon as you spend a weekend doing that, scaling to 2 -> N is child's play. Oh look, I'll pick from any number o…

Well first I said I was in a bad mood. More seriously, scaling is not simple. Yes products have been introduced or have evolved and simplified greatly the task. But saying that scaling is simple is simply not true. Not everybody do simple web apps, some require very heavy processing behind the scene, Hadoop/ MapReduce operations that have to return complex results in memory constrained environment and all that while…

Reddit is a top 200 site. They do over two billion pageviews/month. A lot of their pages are loading 1,000+ nested replies. They use Postgres as their primary datastore.

Scaling is a solved problem until you're huge if you're not doing something really avante-garde.

Post reply on HN