Hacker News new | comments | show | ask | jobs | submit login
Lessons from GitHub's First Year (preston-werner.com)
223 points by mojombo on Mar 29, 2011 | hide | past | web | favorite | 24 comments



This is a great article. I especially like this:

Here’s a seemingly paradoxical piece of advice for you: Listen to your customers, but don’t let them tell you what to do. Let me explain. Consider a feature request such as “GitHub should let me FTP up a documentation site for my project.” What this customer is really trying to say is “I want a simple way to publish content related to my project,” but they’re used to what’s already out there, and so they pose the request in terms that are familiar to them. We could have implemented some horrible FTP based solution as requested, but we looked deeper into the underlying question and now we allow you to publish content by simply pushing a Git repository to your account. This meets requirements of both functionality and elegance.


Customers want a solution to their problem. To save time they will formulate what they think is a solution and give it to you, in the hope that it will speed up proceedings.

Think like a doctor. When the patient turns up, he or she may have a diagnosis in mind. But it is up to you to study the symptoms and deduce the condition independently of what the patient thinks.

Remember: a potted request from a client is a symptom of some deeper problem they wish to solve.


"It's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them." Steve Jobs http://www.wired.com/gadgets/mac/commentary/cultofmac/2006/0...


This is one of the best startup articles I have read in a while. Some real gems in there. The metaphor by Martin Fowler that the article mentions is particularly noteworthy.

Imagine you’re tasked with building a computer controlled gun that can accurately hit a target about 50 meters distant. That is the only requirement. One way to do this is to build a complex machine that measures every possible variable (wind, elevation, temperature, etc.) before the shot and then takes aim and shoots. Another approach is to build a simple machine that fires rapidly and can detect where each shot hits. It then uses this information to adjust the aim of the next shot, quickly homing in on the target a little at a time.

The difference between these two approaches is to realize that bullets are cheap. By the time the former group has perfected their wind detection instrument, you’ll have finished your simple weapon and already hit the target.


Sounds very similar to the section of The Pragmatic Programmer on "Tracer Bullets". There's an interview with the authors that has more discussion here -> http://www.artima.com/intv/tracer.html


Very interesting to hear that a bunch of git early adopters "couldn't have done it" without Campfire. I would have pegged them in the IRC demographic.


Tom was very much an IRC guy. He begrudgingly moved to Campfire after Chris and I told him for months it was a better solution.


Why is Campfire a better solution? irssi is much more scriptable/customizable than a third-party web service.


* Aesthetically speaking, I can't stand irssi.

* It just works

* Inline image viewing

* You can customize anything via Propane[1]'s custom javascript support.

1. http://propaneapp.com/


I don't suppose it matters much at this point, but, have you tried a UI-based IRC client (like Colloquy for Mac or X-Chat for Linux)?

I don't know about any clients on Linux, but, Colloquy (and most IRC clients for Mac, I suppose) use a WebView from WebKit to display text, so they'll have points 1, 3 and 4 covered. And point 2, if you don't need chat history.

(disclaimer: I contribute to Colloquy for both iOS and Mac.)


Colloquy is the client I use when I'm on IRC, so I appreciate the work you've done on it.

Point 2 is actually the most important point for us. Since Tom was the only one that liked irssi, the rest of us lost the backlog and that was a deal-breaker.


Fair enough. I can definitely see why chat history is important to have -- and Campfire does make that very easy to have.

(And happy to hear you use Colloquy! :D)


IRC, by its nature, is very distracting. (why bother be on a network if you're not in multiple channels?)

OT: I think convore will go the same way, unless the crew can seriously address the SvN problem.


Web-based chat, by its nature, is also very distracting. One click and you are reading HN instead of your internal chat room :)

Anyway, when I worked at an all-remote company, we just ran our own IRC server. Then all the channels were work-related. Of course, it was pretty easy to also join other networks, which we did (but would do anyway).


Oy, I dunno. I actually use an IRC gateway for XMPP group chats because irssi does so well for the medium. My team at work uses an IRC channel for adhoc group conversations, and that's the only IRC channel most of us are in. I also have a separate irssi open to freenode, but that's unusual for my team, and the freenode irssi is tucked in a corner where I see it only during interrupts anyway.


Wow, that's a great article. Perhaps even more interesting because of Github's growth in the three years since it was written.

I wonder if he didn't publish it because he started with the idea of publishing ten lessons. Might have been better to assign the number after the article was written.


"Pay attention to Twitter". I was wondering if a service is doing exactly that? Watching twitter, "understanding" the post, and giving you a real-time update of your service/product? If not, that might be useful!


A lot. I work for one which has a similar product. Though we are much more than just twitter, a bit less real-time, more in-depth analysis though.


Check out http://www.radian6.com/ (just acquired by salesforce.com)


No, 9 1/2. That 1/2 a thing is killing. Great article! When DVCS's would be compared, GitHub would be a great plus in Git's favor.


he brings up about givign people what they want and not what you ask for. that is so hard to do. how many times have you built what you envisioned and then went, "This is what i asked for, but it doesn't feel right." The key is conversation, the more back and forth you have with customers, the more you will get a feel for what they really want.


How have the things in the article changed since then? Does GitHub still have no office and four employees?


From the 1st paragraph (it might be an updated section)

"In the time since I wrote this we’ve grown from four people to twenty-six, settled into an office, installed a kegerator, and still never taken outside funding"


They have an office and 26 employees.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: