Live data from Hacker News

How we keep GitHub fast

github.com

111–120 of 124 posts

Re: How we keep GitHub fast

#111
post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

Sorry, but with respect if I ever had to work under someone who thinks like you I would probably have to quit my job. If I was your boss, I would probably have to fire you (as someone else said). I can only imagine you would happily run a restaurant which is kept immaculate up front, but the kitchen and employee conditions are a disgusting mess because "who gives a fuck?". Design is not just some pointless eye candy to make "pretty stuff", design is integral to usability. If you want efficient and happy employees and love their job and want to make their company succeed, don't skimp on important details. As well as anything else, when you give your employees the shitty stick constantly, don't be surprised when all this shit starts to creep into the customer facing experience. I suppose this would just be more "romantic" thinking though.

Re: How we keep GitHub fast

#112
post #96

Earlier quoted context omitted.

Steve Jobs was a well-known woodcarver and carpenter. When he wasn't at Apple, he was usually found in his garage, finishing off a new wardrobe or a sturdy deck chair.

Source(s)? (More because I'm interested rather than doubting you)

I believe it was sarcasm intended to show that just because Steve Jobs gives an example in a field he has no experience in doesn't mean you should take it literally.

Re: How we keep GitHub fast

#113
post #64
post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

For me I see it as breeding a culture of passion . I'm sure there are tons of people who really want to work for GitHub . This is a small example of why that is true. Toward that end, I'd say it's a fantastic use of resources.

You know, I've been asked recently "what kind of company would you like to work for?". I had no answer then, just said that definitely not Google or Facebook. Now I think GitHub might be that kind of company :)

Re: How we keep GitHub fast

#114
post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

You could raise the same argument about all the time they spend releasing open-source software, or producing the really great presentation slide decks that they do.

Regardless of the fact that a well-designed application encourages people to use it more, the fact that GitHub provide their employees with the opportunity to produce such well-polished interfaces is an incredible marketing tool for potential new recruits.

At the end of the day, it all fosters an environment where developers want to be The Guy That Works at GitHub, and all the great talent they attract just bolsters their position even more.

Re: How we keep GitHub fast

#115
post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

A couple of non-romantic justifications/reasons for ya :-)

* It may well have taken substantially less time than you think. Once an organisation has a structure in place for how the UX of a web app should run, and infrastructure in place for making sure things are coded up to that standard (standard templates, test suites, process, etc.) then these things can go together very quickly. I don't know how github runs it's UX/design side - but they seem like the sort of folk who'd streamline the heck out of the process.

* Wearing my UX hat - most of what you see isn't hard. It's basically having decent typography choices, decent vertical rhythm, good visual hierarchy. The icons look off-the-shelf from somewhere. This stuff doesn't actually cost any more time to do right the first time if you already know what you're doing (just like good DBAs automatically write normalised schema).

* With something like this - which is a mode switch between the "nice" stuff that your customers see and the stuff that you see as a developer - it's easier to keep everything nice rather than make the context-switch in development between nice/nasty.

* Wearing my ux-speaking-to-developers hat - think of it like technical debt. Yeah - maybe you could throw something together quickly that would do the job. But if you leave it in it has a knock on effect with everything you do next. It makes tweaking and extending stuff in the future more difficult. Keeping the UI clean, like keeping the code clean, may cost a little more up-front but will save you time in anything but the short term.

* Good UIs are more effective. Making the tools that the internal folk use to make the site better more effective seems like a good choice to be making.

Re: How we keep GitHub fast

#116
post #66
post #2

Should I feel bad knowing that if I were project manager, I'd feel like someone wasted valuable time making the dashboard look so pretty? Am I an idiot just for assuming that was done in house? Edit: I'm not trying to make a case either way, but I look at the color scheme, specific typography decisions, and other small things that would have taken a non-trivial amount of time to work on or think about (ie, more than…

Let's have a look at how much marginal effort this takes: - time spent thinking about what needs to be on the page (not extra) - time spent thinking about what order the data should be displayed (not extra) - time spent laying out the data (extra) - time spent replacing the default font on the stylsheet (extra - minimal) - time spent with getting graphs together (extra - but it is a skill. Once having done it, they c…

I could quibble with the three "extras" too :-) Assuming the data needs to come out in some format or another there would be some work in displaying it, and some work in getting it out and doing useful stuff with it. They're "different" not "extra".

In my experience designing things nicely doesn't really cost more than designing it badly. In both cases "design" is being done - it's just that in once case you have an expert involved.

Re: How we keep GitHub fast

#117

Earlier quoted context omitted.

Key size of 1024 vs. 2048 bits should not account for 225 ms of latency. Here's the result of "openssl speed rsa" on a mid-grade desktop computer. sign verify sign/s verify/s rsa 512 bits 0.000217s 0.000014s 4608.1 72363.4 rsa 1024 bits 0.000711s 0.000032s 1406.0 30788.2 rsa 2048 bits 0.003630s 0.000092s 275.5 10825.0 rsa 4096 bits 0.021180s 0.000299s 47.2 3349.2 In other words, the difference between 1024 and 2048 b…

They use HAProxy for load balancing which doesn't natively support SSL termination (yet...). There's probably an extra layer in there to handle that (pound/nginx maybe?) which would bump up the latency.

It does for three days. :)

http://blog.exceliance.fr/2012/09/04/howto-ssl-native-in-hap...

Re: How we keep GitHub fast

#118
post #63

Earlier quoted context omitted.

That's the difference between Ikea and a company like http://www.urbancase.com/ . Craftsmen don't think that way.

Ikea uses particleboard (not plywood), and certainly not for its strength.

"shitboard" is what I've come to call it.

It's "strong enough" and very light to ship. That's the only reason.

It's not strong enough for a lot of tasks and is definitely not good quality. One water spill and throw it away as the laminate just peels off - even on the expensive stuff.

I've taken to buying second hand good quality furniture (which is usually available at the same price as the shitty Ikea stuff) and stripping and painting it.

Re: How we keep GitHub fast

#119
Reminds me of http://www.codinghorror.com/blog/2011/06/performance-is-a-fe... :

"The simple act of putting a render time in the upper right hand corner of every page we serve forced us to fix all our performance regressions and omissions. [...]

Most of the performance fixes were trivial, and even the ones that were not turned into fantastic opportunities to rearchitect and make things simpler and faster for all of our users."

Stackexchange open sourced their profiler at http://miniprofiler.com/ (.NET & Ruby)

The post provides some data showing how they improved their site performance over time where Github just states they have a strategy to use "powerful internal tools that expose and explain performance metrics". Guess it's just common sense now.

Re: How we keep GitHub fast

#120
post #18

Earlier quoted context omitted.

"When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through." -Steve Jobs

Perhaps a better analogy was made by (General Sir Peter de la Billiere I think) about UK troops patrolling in Helmand Province. He said something like "Even when they think no-one is watching, no sargents, no generals, they still monitor their surroundings, check the garden walls as they pass. No-one is letting the monotinity reduce their awareness." In short, if there is a job worth doing, its worth doing well.

Doing your duty in the military is serious business, especially in a war zone with insurgents, everyone's life is on the line. So your quote isn't an apt analogy to furniture or software interfaces. Not all jobs are worth doing well, many are worth doing "well enough" given budget,time constraints and no lives at stake.

(Not to be too harsh, but I'm speaking from the experience of having been in the military and having spent years in the software industry.)

Post reply on HN