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.
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
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.
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!
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.
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"
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.