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

51–60 of 62 posts

Re: How GitHub Works: Be Asynchronous

#51

Post by chexton »

mtogo wrote: post #31
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…

Skype is really terrible imho. If you're looking to move away from skype because it sucks, you can try an XMPP server + Candy, or an IRC server plus CGI:IRC or qwebirc. Both solutions take about 15-20 minutes to set up and cost nothing, provided you have a VPS to host the server on.

I'm tempted to move to IRC...does it persist messages? I assume so, based on the discussion above. I'm quite sure that when I've used IRC in the past I haven't been able to see what has occured after I've left a channel but I imagine if I run my own server there is a simple solution to this problem. Anyone care to share (though I'm Googling as we speak)?

Re: How GitHub Works: Be Asynchronous

#53

Post by v21 »

chexton wrote: post #51
mtogo wrote: post #31

Earlier quoted context omitted.

Skype is really terrible imho. If you're looking to move away from skype because it sucks, you can try an XMPP server + Candy, or an IRC server plus CGI:IRC or qwebirc. Both solutions take about 15-20 minutes to set up and cost nothing, provided you have a VPS to host the server on.

I'm tempted to move to IRC...does it persist messages? I assume so, based on the discussion above. I'm quite sure that when I've used IRC in the past I haven't been able to see what has occured after I've left a channel but I imagine if I run my own server there is a simple solution to this problem. Anyone care to share (though I'm Googling as we speak)?

It does not! But the usual way people get around this is connecting to IRC using an IRC bouncer or irssi on a server somewhere and then connecting to that. This way you are "online" the whole time. But it's a thing everyone has to set up individually.

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.

Re: How GitHub Works: Be Asynchronous

#54

Post by arethuza »

jrockway wrote: post #48
moe wrote: post #29

Earlier quoted context omitted.

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

Gall's Law:

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

http://en.wikipedia.org/wiki/Gall%27s_law

Re: How GitHub Works: Be Asynchronous

#55

Post by dspillett »

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.

My main problem is other people having no concept of there being any difference between a proof of concept (or prototype) and production code...

Re: How GitHub Works: Be Asynchronous

#56

Post by joshaber »

bostonvaulter2 wrote: post #46
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…

Do all 35 people share one campfire room?

We have a bunch of topic- or project-specific rooms, one room for animated gifs and pictures of cats, and one room for serious business stuff.

Pretty much everybody hangs out in the cat picture room and serious room. The rest are just people interested in that topic.

Re: How GitHub Works: Be Asynchronous

#57

Post by masto »

I don't like sitting in meetings either, but it seems to be that they're necessary when your company is building anything even moderately complicated. I honestly want to understand this no-meetings culture, especially if it can help cut down on the number of meetings I have to go to.

How do you even know what you're supposed to code if you don't go to meetings? Sure, GitHub is a very simple system that could be built by a couple of smart guys over a few weekends, but even granting that, what about something like the decision to build GitHub Firewall Install? Did you really never sit down in a room to figure out what the product should actually do? Or, if you have Product Managers who do that job, did they never call a meeting with the engineers to explain their idea, solicit feedback, determine whether it's feasible, how long it will take, and what other projects might be affected?

I'm a fairly typical programming geek, I got my start on a C64 in my bedroom, and have spent many years of my life writing code entirely on my own, so I know the joy of not having to answer to anyone. On the other hand, having worked in the "real world" for companies that are trying to solve a market need, I find that we can't get away from having some meeting overhead, even if we make a concerted effort to minimize it. No meetings at all leads to developers complaining that they don't have an adequate understanding of what they're trying to build. Institute a few more meetings to get everyone up to speed, and they complain that they're being taken away from valuable coding time. I would love to find the magic bullet solution to this, but I don't see how an IRC chat room is in any way a _realistic_ substitute.

Re: How GitHub Works: Be Asynchronous

#58

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

Re: How GitHub Works: Be Asynchronous

#59

Post by 3pt14159 »

azov wrote: post #43
3pt14159 wrote: post #40

Earlier quoted context omitted.

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

You definitely have a point with the visuals.

As for how people feel about certain things, I've always preferred informal lunches over meetings.

Re: How GitHub Works: Be Asynchronous

#60

Post by gaius »

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…

That's why we have languages like Perl, Python, and Ruby.

More relevantly, it's why branching is such a lightweight operation in Git.

Post reply on HN