How GitHub Works: Be Asynchronous
zachholman.com
zachholman.com
This seems over-broad to me, and seems to violate the accepted wisdom "Good programmers spend 10% of their time coding, and 90% of their time thinking." A good system/design meeting can go a long way to producing better code.
The problem is that these are so rare. The vast majority of meetings in every company I've worked at are of the "invite everyone so it turns into a contest to see who can make their point the loudest" variety, and almost always end up with a few people who view it as their chance to be the "star" to a captive audience and thus draw out the meeting as long as they possibly can.
Plus, if your programmers are any good, they're probably holding these meetings already without management having to formally call a meeting. I think that's the real problem: "formal" meetings almost always suck. Ad hoc meetings held by people who need communication to finish their job usually make up for themselves in increased productivity.
The main problem is that 99% of programmers don't know how to prototype. They assume that whatever they commit is what goes into production. No. Try an idea quickly and throw it away if it's bad. That's why we have languages like Perl, Python, and Ruby. While it's 50/50 on using them for production, they are absolutely the right tool for testing your ideas quickly.
And if you can test ideas quickly, you don't need meetings. Spend an hour coding what you would have talked about in the meeting. Share with coworkers. Get feedback. Tweak the prototype. Then write the "ready for production" version.
I've been to a lot of meetings but I've never seen any piece of code look anything like what was described in the meetings. As soon as you hit that one point where the computer's view of things and your meeting's view of things diverges, everything else you discussed in the meeting is invalidated. The computer is always right.
(Actually, one of the answers I got to an interview question at Google was so cool that I had to code it. And the code looked exactly like the design I sketched on the whiteboard. And it ran really fast on a large dataset. So maybe meetings are useful; but only for algorithm design, not for "real-world" stuff like "how should we refactor this thing".)
wouldn't this part be easier to do in a meeting than in a huge email thread?
Team collaboration with real time chat.
Campfire is like instant messaging, but designed exclusively for groups.
Share text, files, and code in real time.
I don't think anyone is advocating huge email threads here!
"What's a long email? 1000 words? 5000 words? 10,000? Let's call it 10,000, just to be over the top. I can scan read at 800 wpm, and finely read at 250 - 500. So absolute worst case scenario I'll have to spend 40 mins reading an extraordinarily long email. That is still better than an hour long meeting where I'll listen at 40 to 80 wpm and have completely no recollection of it two weeks from then. So why the fuck do we consider ten thousand word emails completely insane but we even entertain the idea of an hour long meeting?"
Obviously something like campfire or flow or whatever is better than emails, but I'll take long emails over meetings any day of the week.
It's often important to get an idea about how stakeholders feel about different ideas. You can see facial expressions of everyone in a room and hear the way people speak at the same time as you're processing what's being said. All this information will not be in your chat/email thread at all. Also, not everyone is a great writer, many people will communicate much less details in writing than in person. Part of the reason why management likes meetings more than developers is because non-verbal data tends to be more important for their jobs.
Plus, what about visuals? Drawing on a whiteboard is easier than drawing in any software package I know of (even if you've got stuff like Wacom tablets). It's also easier and much faster to point to something than to explain it verbally.
Overall, I think the benefits of asynchronous workflow far outweigh the drawbacks (btw, anyone got a list of companies that use it? :), but it's important to understand the drawbacks as well.
As for how people feel about certain things, I've always preferred informal lunches over meetings.
That's one possibility. However, I can't help but find the idea that you have some kind of arcane knowledge that 99% of all programmers don't have is a bit... well, egotistical. Prototyping certainly has its place, but its purpose is completely orthogonal to that of a meeting. Meetings serve to plan. They get everyone on the same page. Prototyping serves to test ideas out.
The problem is that meetings are almost always ruined by a small minority of people who insist on dragging them out. However, a good meeting is very helpful.
My main problem is other people having no concept of there being any difference between a proof of concept (or prototype) and production code...
More relevantly, it's why branching is such a lightweight operation in Git.
Think about it. Did Linus Torvalds sit down at a big meeting and design Linux on a whiteboard? Did the Mozilla team design Firefox at their daily stand-up meeting? Did Emacs evolve from detailed discussions and specs, or did someone write some macros for their favorite text editor and it evolved over time?
Great software isn't planned. Great software happens. Bitching about minor details in multi-person meetings is just a waste of time.
If you want to waste time, get a beer and read HN for a while.
"A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."
Without these meetings, you find yourself so lost you can't even start prototyping. Good luck with that.
This kind of project would be classified as Inventions as opposed to Implementations in Zed Shaw's C2I2 Hypothesis, which says that you need Collaborators for Inventions, and Clients for Implementations, see here : http://zedshaw.com/essays/c2i2_hypothesis.html).
I think the only reason GitHub does not need such meetings is that they are developers building solutions for developers. So think again before you start "despising" meetings.
However short and focused they are, my definition of a meeting is a schedule block of (any size of) time where a number of people are expected to party on something and decide on some action.
To extend Zach's metaphor, meetings are a communication mutex. They force a topic to be wrestled by a group of people at the lowest-common-denominator of pace. I think they're rarely the best or most efficient way to collaborate.
"""You don’t have this problem with chat transcripts. Forcing people to reduce their otherwise rambling thoughts into concrete sentences helps focus discussion, too.
We’ll have meetings at GitHub, but I can count the number of full “meetings” we’ve had in the last year and a half on one hand."""
The former bit implying that the focus of sentences helps, the latter bit implying to keep the membership of the meeting to only those required.
Again: siloing is far more toxic than meetings in my experience. It's far too easy for a dev to wander down a path that has no value when operating in a silo. Agile tells us that we need to exist in a state of constant communication and feedback. This necessitates meeting with people in some fashion.
Anyways. Maybe semantics.. My points were just that meetings are basically awful, and that there's a distinction between communication and meetings... Meetings aren't the only form of communication.
I echoed his sentiments in a post I wrote about working remotely - http://arandomurl.com/2011/09/03/working-remotely.html
I have worked under a similar model for almost a decade now. It comes with so many benefits over a traditional meeting that I am uncertain why any software development company would do it any other way.
The goal isn't to decide on anything, just to let everyone know where you're at.
That said, too many meetings are intensely toxic for any company, and nothing is worse than working at a company that thinks meetings are "getting things done".
That is nowhere in sight in the post. In fact, the content of the section is even more damning than the title:
> I tend to loathe meetings even more than 37signals. I despise them.
> meetings pull you from doing actual work in order to talk about doing work.
> meetings are utterly forgettable. Even if you take meeting notes, you can’t capture them all.
Zach does not say he likes "short, focused and tiny meetings", Zach says he hates meetings as much as a human being can hate a concept.
Sadly, people often think that everything needs to be done now and I think forcing less meetings on people helps that happen.
But it's still async... from the perspective of others. I'm not typically deep into the systems-level maintainability on GitHub, but I can check the transcript during or after the downtime happened and can figure out what happened, how the discussion around it went, and how it was dealt with.
Is there something special about Campfire that makes it non-urgent?
So you can use it as a synchronous "have a chat now" tool - or as an asynchronous "leave a message and I'll deal with it when I return" tool at the same time.
Pretty much everybody hangs out in the cat picture room and serious room. The rest are just people interested in that topic.
The ability to have two or three conversations going on simultaneously, share links and log messages, and have a transcript/timeline to use to guide a postmortem is fantastic.
One of the strangest things about working at Apple is they have meeting ALL THE FUCKING TIME. You spend more time in meetings than doing anything else.
And now they're the highest valued company in the world, and 37signals is ahem not.
Meetings I love:
- an expert pulls me and some others into a room to update us on some secrets where we can ask questions
- lunch
- a very busy production lead needs to "use" (not waste) everyone's time so that she can efficiently figure out where a team is at
Yes, all of this can be abused, but lots of well run meetings leave me with a sense of purpose and camaraderie. Rah rah.
Sounds like gossip.
- lunch
Nice. Nothing like food time to discuss business.
- a very busy production lead needs to "use" (not waste) everyone's time so that she can efficiently figure out where a team is at
Email or a status board are much better for this.
Zach, can you go into more detail? From the few things I’ve seen, you seem to admire them more than despise them. Is there a particular reason for your displeasure?
> I tend to loathe meetings even more than 37signals loathes meetings.
(assuming you are not being facetious)
Wanted to correct something. Skype's chat is NOT persistent (if I'm wrong, lemme know.. I'd love to find out there's a feature I'm missing). That is to say, the chat persists.. but only on the distributed hosts that participate in it. So if I sign off at 10pm, and wake up before any of my team members are signed on at 7am.. I won't see anything that happened in between.. until one of them signs on.
This feature alone is probably worth the price of admission to Campfire, IMHO...
Both solutions take about 15-20 minutes to set up and cost nothing, provided you have a VPS to host the server on.
The other way it's handled is by having a bot sitting in channels (doing things like pushing warnings and error notices from your server, too) that records logs. Then you can visit a webpage that the bot hosts with the transcripts on. I'm sure there are packages that perform the logging directly on the server and host them, but it's useful to have some unlogged rooms, too.
A lot of realtime problems got stymied by people thinking others were ignoring them.
If my understanding's accurate, then I'd agree with you: ignore someone's status, ask a question, don't expect an immediate answer.
If I could trust the away messages, as a team lead I always had a status board as to where my team was (since we were in five offices)
Not trying to be the grammar police, but after reading this sentence, I chuckled because I thought the author was expressing his hatred for 37signals :)