Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How GitHub Works: Be Asynchronous

zachholman.com

Post reply on HN
Print view View original

41–50 of 62 posts

Re: How GitHub Works: Be Asynchronous

#41

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

Re: How GitHub Works: Be Asynchronous

#42

Post by argv_empty »

3pt14159 wrote: post #40
reemrevnivek wrote: post #37

Earlier quoted context omitted.

The article talks about using Campfire ( http://campfirenow.com/ ), which is a lot nicer than a huge email thread. From the campfire page: 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!

This is a point I've been making for a long time: "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 recollect…

Ideally, the hour-long meeting is a collection of many small communications from several different people. If meetings consist of getting talked at by one person for an hour, I think most would agree that something is wrong.

Re: How GitHub Works: Be Asynchronous

#43

Post by azov »

3pt14159 wrote: post #40
reemrevnivek wrote: post #37

Earlier quoted context omitted.

The article talks about using Campfire ( http://campfirenow.com/ ), which is a lot nicer than a huge email thread. From the campfire page: 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!

This is a point I've been making for a long time: "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 recollect…

You have a point. But you are assuming that meetings are about exchanging textual information. Usually there's more than that.

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.

Re: How GitHub Works: Be Asynchronous

#44

Post by rokhayakebe »

xbryanx wrote: post #41

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 product…

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

Re: How GitHub Works: Be Asynchronous

#45

Post by j_baker »

jrockway wrote: post #27
rgarcia wrote: post #19

...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/desi…

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 de…

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.

Re: How GitHub Works: Be Asynchronous

#46

Post by bostonvaulter2 »

holman wrote: post #5
colinhowe wrote: post #4

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.

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 down…

Do all 35 people share one campfire room?

Re: How GitHub Works: Be Asynchronous

#47

Post by jrockway »

j_baker wrote: post #45
jrockway wrote: post #27

Earlier quoted context omitted.

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 de…

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 fi…

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.

Re: How GitHub Works: Be Asynchronous

#48

Post by jrockway »

moe wrote: post #29
rgarcia wrote: post #19

...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/desi…

Weeks of coding can save you hours of planning!

Sure, if you don't know how to prototype.

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.

Re: How GitHub Works: Be Asynchronous

#49

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

Re: How GitHub Works: Be Asynchronous

#50

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

Post reply on HN