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

11–20 of 62 posts

Re: How GitHub Works: Be Asynchronous

#11

Post by famousactress »

jherdman wrote: post #10
famousactress wrote: post #6

Earlier quoted context omitted.

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

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

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.

Re: How GitHub Works: Be Asynchronous

#12

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

Re: How GitHub Works: Be Asynchronous

#13

Post by daleharvey »

jherdman wrote: post #10
famousactress wrote: post #6

Earlier quoted context omitted.

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

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

they are on campfire, they are constantly in communication

I echoed his sentiments in a post I wrote about working remotely - http://arandomurl.com/2011/09/03/working-remotely.html

Re: How GitHub Works: Be Asynchronous

#14

Post by billpaetzke »

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…

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?

Re: How GitHub Works: Be Asynchronous

#15

Post by mseebach »

ethank wrote: post #12

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.

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.

Re: How GitHub Works: Be Asynchronous

#16

Post by randomdata »

jherdman wrote: post #10
famousactress wrote: post #6

Earlier quoted context omitted.

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

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

They haven't really eliminated meetings, they have changed the way meetings are conducted. Thanks to the technology, you can step out of a meeting at any time to have lunch or, you know, work without missing out on anything. As a result, meetings never need to end.

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.

Re: How GitHub Works: Be Asynchronous

#17

Post by mseebach »

billpaetzke wrote: post #14
holman wrote: post #5

Earlier quoted context omitted.

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…

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?

Both IM and email is private. Chatrooms are public.

Re: How GitHub Works: Be Asynchronous

#18

Post by rahoulb »

billpaetzke wrote: post #14
holman wrote: post #5

Earlier quoted context omitted.

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…

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?

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.

Re: How GitHub Works: Be Asynchronous

#19

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

Re: How GitHub Works: Be Asynchronous

#20

Post by j_baker »

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…

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.

Post reply on HN