
How GitHub Works: Be Asynchronous - jroes
http://zachholman.com/posts/how-github-works-asynchronous/
======
rgarcia
_...meetings pull you from doing actual work in order to talk about doing
work. It’s easier to push a branch up, check out the diff, and then iterate on
that diff rather than assuming you’re going to perfectly whiteboard system
design ahead of time._

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.

~~~
jrockway
The problem with the whiteboard design is that you have to defer, "oh, let's
see if that works" indefinitely. While you spend 90% of your time thinking and
10% typing, you don't spend 9 hours thinking and then 1 hour typing. You spend
5 seconds typing, then 30 seconds thinking, then a minute or so typing, and so
on. Getting feedback from the computer is important for anything that's
complicated enough to require a design. Seeing what the code looks like that
your design enables is as important as a conceptually-sound design.

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

~~~
j_baker
_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._

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.

~~~
jrockway
My experience is that 99% of the time in meeting is spent on some issue that
the computer could tell you very quickly. "This is O(n^2), but it's faster
than the O(n log n) algorithm on modern hardware." Rather than debate,
benchmark and explain the results to the group. Speculating gets us nowhere.

------
jdkoeck
When your project is innovative and solves a problem in a difficult domain
that you, hacker, are not familiar with (say, healthcare), meeting with domain
experts is invaluable because it enables a bidirectional exchange of ideas.

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.

------
jherdman
I really wish the author didn't use such an inciteful title for his section on
meetings. The title offers another catch phrase to avoid meetings. I'd much
rather have seen Zach focus more on his actual point: holding short, focused,
and tiny meetings. I fear that his title, and other catch phrases like it,
encourage siloing. Siloing is far more "fucking toxic".

~~~
famousactress
Where did you pick up the fact that his actual point was to hold tiny focused
meetings? Working asynchronously is pretty anti-meeting, and frankly it's
totally independent of a culture that supports silos. I work in a very
asynchronous culture right now. Very few meetings.. but that's not to say we
don't communicate. We communicate very thoroughly.

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.

~~~
jherdman
I'm reading a bit into his words, yes. Here's the part of interest:

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

~~~
famousactress
Apologies, but my brain turns off when the word 'Agile' is used in a sentence
in such a way that it could be comfortably replaced by the name of a deity.

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.

------
colinhowe
This seems a little far from the truth. What if someone needs to fix an urgent
live issue? You can't always work async. Sometimes things need to get done,
now. E.g. issues on a production system that are breaking the site for
everyone.

Sadly, people often think that everything needs to be done now and I think
forcing less meetings on people helps that happen.

~~~
holman
We'll still work in Campfire though. We have an infrastructure room where we
get all of our notices and systems-level logging piped to, and all of our on-
call sysops can get together and deal with stuff immediately when it's
necessary.

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.

~~~
billpaetzke
At my job, chat (via IM client) is urgent and email is (a little) less urgent.
This makes a lot of sense to me. If I want to not bother someone, I'll send
them an email. If I want to bother someone, I'll IM them.

Is there something special about Campfire that makes it non-urgent?

~~~
rahoulb
What I like about Campfire is looking back through the transcript is easy -
even for the times when you have left the room. Plus it has the ability to
star parts of the conversation so you can see the important points as you
scroll through.

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.

------
foobarbazoo
"Meetings are toxic."

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.

------
xbryanx
I'm tired of the "meetings are toxic" claim. If you're going to use such
bombastic and broad language you need to back it up with a broad set of
examples. Sure, business culture has gone overboard with the meetings, but
let's not throw the baby out with the bathwater.

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.

~~~
rokhayakebe
_\- an expert pulls me and some others into a room to update us on some
secrets where we can ask questions_

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.

------
famousactress
Useful terminology (working asynchronously). There was a discussion recently
about working remotely and I struggled to convey the difference between a
remote-employee and a remote-team
(<http://news.ycombinator.com/item?id=2847012>)... This is really the core of
it. Teams that operate like this have a much better ability to adopt remote
workers, for one thing.. and I suspect a much higher index of developer
happiness, for another.

------
mattparcher
> I tend to loathe meetings _even more_ than 37signals.

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?

~~~
jeff18
It should read as

> I tend to loathe meetings even more than 37signals loathes meetings.

(assuming you are not being facetious)

~~~
mattparcher
Doh. I honestly misread that line. Thank you.

------
whalesalad
Just a heads up we do async chat all the time here at my office, but we use
Skype instead of Campfire. I don't want anyone to feel like they need to pay a
monthly fee to get that service. Skype does persistent chat, you can add
people to rooms and they remain persistent as well. You can 'favorite' rooms
to keep them sort of pinned in one spot in your list of active convos. It's
handy.

<http://cl.ly/2d3d1M072M1H1h3P1A0i>

~~~
famousactress
We use Skype too.. and it's fine. By fine I mean, it sucks.. but it's a
chatroom so we have very few needs.

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

~~~
skeletonjelly
Yeah that's seems correct. You won't receive a message until you're both
online. We use it here at work for interstate chat and it works well as we
have our work machines on 24/7. So logging in from a laptop off site will sync
the messages. Note that the read status doesn't get synced.

------
markrandrus
I agree that most things called meetings today are toxic and unproductive, but
gatherings in the work place that occur organically and ones that resemble
group work sessions are healthy. For anyone who wants more detail on what Zach
mentions regarding "the zone", breaking flow and job autonomy lookup the book
Drive by Dan H. Pink. Great Post thanks!

------
palmerabollo
What do you think about some authors (i.e. The Clean Coder) that claims that
you should try to avoid entering "The Zone"?

------
ethank
For a number of years I had a team in five offices in four timezones, so
asynchronous working became the norm. We used Skype however. The only "rule"
that needed to be enforced was "Away means Away, Available means Available"

A lot of realtime problems got stymied by people thinking others were ignoring
them.

~~~
mseebach
The "away" rule seems counter productive. The value of async is that I can ask
you a question when convenient for me, and you can answer when convenient for
you. If I have to wait for your status to become available, I'm wasting my
attention.

~~~
famousactress
I wonder if by 'available' he means 'will answer immediately'. My group uses
Skype like campfire also.. and Away means 'I won't see this until I get
back'.. Available means "I'll be notified immediately, and am likely to
respond relatively soon". I still leave messages for people who are away all
the time.. I just know that it's unlikely we'll end up in a real-time
conversation at the moment, and as such.. I can just fire-and-forget until
they return and reply

------
donaq
This appeals to me immensely because I absorb information way faster by
reading than when someone talks at me. I wonder what percentage of the
population is like me as opposed to those who absorb better by listening?

------
samgro
"I tend to loathe meetings even more than 37signals."

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
:)

------
mise
With a private repo in GitHub, after adding a second user, can that second
user just start using "Pull Requests", even if they just cloned the repo
initially at the command line?

