Live data from Hacker News

Scaling GitHub

zachholman.com

61–69 of 69 posts

Re: Scaling GitHub

#61

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…

"you have a PM screaming at your engineers" - and there lies your problem.

I'm the sole engineer for a distinctly non-engineering company (we deliver food, and I'm the only person with any sort of engineering background).

However, we work in a very similar way to GitHub. We have a motivated team who love our product - and that rubs off on our working practices. No one is ever told they have to work late, or they have to hit a deadline, but things get done at an amazing pace. At some point soon I'll be working on an internal CRM system, but because I care about the company, and the impact it will have on everyone else's ability to do good things I'm excited about that.

Re: Scaling GitHub

#62

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…

I'm in a similar company at the moment - it's not quite GitHub, but the atmosphere of smart people working on things they love is there. Since I started they've also started adapting to the "Work when you want, where you want" approach as well ;)

When looking for work a big requirement was that I could work from home, and have Wednesdays off - filtering down the opportunities was just a case of mentioning that in the initial contact with a company I was interested in. No one you want to work for is going to be offended at you pointing out something that could be a problem early on in the process so long as you go about it politely.

Re: Scaling GitHub

#63
post #48
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…

I like to know what I'm doing actually matters

I wish I could give you ten upvotes. I get a lot out of interacting with the people that actually use my software. It makes things more personal and that makes me more motivated to work on a project. And the feedback helps to make what they actually want instead of having to second-guess, or build to some abstract specs.

That the project is technically interesting/challenging also goes a long way, of course, but that's not everything.

Worst would be a project that is boring and you don't know whether anyone, including yourself, is ever going to use it.

Re: Scaling GitHub

#64

Earlier quoted context omitted.

+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…

I like this - I certainly lose steam when having to login to another service to do it. Certainly worth trying. Couple of follow up question: Which wiki do you use?

Re: Scaling GitHub

#65

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…

Filter based on if they're touting the work ethics you want. If they're not touting it from the tops of the hills, they probably don't do it. Places like GitHub and 37signals yell about how awesome their work environment is, if you want the places you're considering working at to be like GitHub or 37signals and these places aren't doing the same, I'd be wary.

If you're looking at bigger companies, find a list like Fortune's 100 best employers (for the US, sorry don't know other regions) and read it. There's a good chance what's written about the best employers is mostly true (not completely true, but it's a good guide). Also, ask other people who work for a place you're interviewing if you can buy them a beer / coffee the day after your interview. Pick their brain about the culture. If you're paying for the drinks and considering joining them, many people will be honest (I would be).

Don't feel you're being rude. I'd recommend telling the places that don't fit your desired culture exactly why you're not going to work for them. Worst it can do is nothing, at best, maybe the people who do work there see some tiny improvement.

Re: Scaling GitHub

#66
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 had the hardest time convincing anyone to use the wiki, possibly because several of the people who needed to be using it weren't technical and didn't really understand the benefit.

But then we moved away from our ISP's awful email service to Google Apps for Business and people started using Google Docs. Docs is now our de-facto wiki.

I think the reason people use it is a combination of familiarity (everyone understands a word processor), constant reminders (everyone gets an email when a new document is added), and peer pressure.

Re: Scaling GitHub

#67

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…

"It's an internal CRM system, so why not shove it full of in-jokes and vi-keybindings for navigation? Why not give it a REST API and a CLI app to consume it?"

Because the users of the system don't care about any of that crap, so it's a waste of time and money, which most companies don't have extra of to spare.

Re: Scaling GitHub

#68

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 fun…

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

That's a terrible thing to say.

Remember, documentation is like sex. When it's good then it's really, really good. And when it's not good then it's still better than nothing.

Re: Scaling GitHub

#69
>Every internal GitHub talk is automatically recorded, uploaded, and viewable to every future employee. ... on a Kinect-powered Arduino-based motion-detecting portable video recording platform.

Um, more please! Wtb a video of that in action or meetup presentation or something.

Post reply on HN