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

21–30 of 62 posts

Re: How GitHub Works: Be Asynchronous

#21

Post by famousactress »

mseebach wrote: post #15
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.

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

Re: How GitHub Works: Be Asynchronous

#22

Post by famousactress »

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…

Thinking != Meeting..

Re: How GitHub Works: Be Asynchronous

#23

Post by mbthomas »

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.

Totally agree that something have to be sync. However, from my experience Campfire is the single best place to "meet" and address an urgent issue.

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.

Re: How GitHub Works: Be Asynchronous

#24

Post by rgarcia »

j_baker wrote: post #20
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 meeti…

Agreed. I should nave been more specific with what I meant by a "good" meeting.

Re: How GitHub Works: Be Asynchronous

#25

Post by eric-hu »

mseebach wrote: post #15
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.

This seemed implicit in the article to me, but the way they use chat seems to be the way IRC chat is used for devs (though I haven't used IRC that much).

If my understanding's accurate, then I'd agree with you: ignore someone's status, ask a question, don't expect an immediate answer.

Re: How GitHub Works: Be Asynchronous

#27

Post by jrockway »

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

Re: How GitHub Works: Be Asynchronous

#28

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

Re: How GitHub Works: Be Asynchronous

#29

Post by moe »

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!

Re: How GitHub Works: Be Asynchronous

#30

Post by famousactress »

whalesalad wrote: post #28

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/2d3d1M072M1H1h3P1A0…

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

Post reply on HN