Live data from Hacker News

How Paul Graham Is Wrong

ma.tt

151–160 of 206 posts

Re: How Paul Graham Is Wrong

#151
post #113

Earlier quoted context omitted.

As another veteran of working remotely, I disagree. Conscious use of collaboration tools offsets not being in the same office together nicely. Real time communication via Hangouts or Skype are at a level where you can hold a good conversation without having to be in the same physical location. Also, most offices (and businesses) are not really built to support proper collaboration and working conditions. As an exampl…

> Real time communication That implies a time zone with a lot of overlap. Rome/Berlin time is 9 hours ahead of San Francisco, meaning there really isn't a lot of overlap. Real time communication also means that you need to consciously set up the call and pay attention to it. Sometimes I overhear something at work, or we talk about something interesting at lunch, or there's an "oh shit" moment (not often:-) when it's…

Yeah, time zones are easily the biggest problem. Even then, however, it's not that hard to find an overlap.

I worked successfully with developers from England, Ukraine, and India for several years. Took effort on both of our parts to make it work, but work it did.

Re: How Paul Graham Is Wrong

#152
post #125
post #49

Earlier quoted context omitted.

> A lot of startups have ambitious goals and very hard technical challenges and you can't compete with a team made up of 99% remote workers. I see no evidence that this has ever been successfully done. MySQL was a 1B company and built with a remote team: http://developers.slashdot.org/story/13/03/07/1826212/former...

If you're bringing up MySQL as a counterexample, I think we've lost sight of the original conversation. The original Paul Graham essay[1] had a lot of focus on "startups". The companies in the early days scratching and clawing trying to make things work. I thought that was the context. MySQL was started by 3 guys in Sweden working in the same office. Even if they wanted to have everyone working remotely in 1995, ther…

Remote does not necessarily imply international. There are over 300 million Americans who don't live in the Bay Area, so there are plenty of potential remote devs that are still in the US. Domestic remote devs are in the same or nearly the same time zone and can easily travel for regular, in-person meetings.

A startup I helped build over the last nine years was acquired earlier this year. Our entire company was distributed, and we thrived with email, persistent chat, weekly meetings via phone, and occasional in-person meetings.

Re: How Paul Graham Is Wrong

#153
post #130

Earlier quoted context omitted.

As another veteran of working remotely, I disagree. Conscious use of collaboration tools offsets not being in the same office together nicely. Real time communication via Hangouts or Skype are at a level where you can hold a good conversation without having to be in the same physical location. Also, most offices (and businesses) are not really built to support proper collaboration and working conditions. As an exampl…

Thing I've learned through hard experience: programmers (and yes, I am one) generally over-value individual productivity and under-value communication. So yeah, you can "hold a good conversation" via Skype, but you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person…

I feel that TheOtherHobbs covered most of the points really well, but I feel that this point needs a bit more direct discussion:

> you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work.

If you value developer productivity at all, that little bit of friction is a _good_ thing. It means that you have to think for a second about the most appropriate forum for that discussion. And if you decide that you do need to talk to someone, the friction isn't really that high. Click on a user, click on the green button with the camera on it, and you're talking.

In-person spontaneous collaboration is, in my experience as both a developer and a development manager, highly overrated, and the value is very rarely worth the costs. Those costs include lost productivity, developer stress, bikeshedding, and an implicit culture of hostility to anything that doesn't _look_ like productivity (like thinking).

Taking a moment to put on my development manager hat, one of the things I never want to do to my developer employees is interrupt their flow. I go to meetings, so I can give them a brief summary which contains only the information they need to do their job. I work with the customers and listen to 50 minutes of rambling so I can glean the 5 minutes of information my employees need to do their work.

I've hired them, and I'm paying them ludicrous amounts of money, to create programs; to create value for the customer. Anything that gets in that way is up to me to address and remove. And based on my experience as both a developer and a manager, those "spontaneous collaboration" interruptions are usually something that needs to be addressed and removed.

Re: How Paul Graham Is Wrong

#154
post #152
post #125

Earlier quoted context omitted.

If you're bringing up MySQL as a counterexample, I think we've lost sight of the original conversation. The original Paul Graham essay[1] had a lot of focus on "startups". The companies in the early days scratching and clawing trying to make things work. I thought that was the context. MySQL was started by 3 guys in Sweden working in the same office. Even if they wanted to have everyone working remotely in 1995, ther…

Remote does not necessarily imply international. There are over 300 million Americans who don't live in the Bay Area, so there are plenty of potential remote devs that are still in the US. Domestic remote devs are in the same or nearly the same time zone and can easily travel for regular, in-person meetings. A startup I helped build over the last nine years was acquired earlier this year. Our entire company was distr…

>Remote does not necessarily imply international.

It does in Paul Graham's essay and OP's response to it. Again, we're losing sight of the thread's discussion. (Please read PG's essay that started this.)

PG's essay was about H1-B visas (recruiting foreign talent into the USA) and the OP (MA.TT) said the answer was remote workers. This means international remote workers that are 6+ to 12+ hours ahead in timezones.

We're not talking about hiring remote workers in Maine and Rhode Island to work as a distributed team for California companies. We're talking about remote workers in far off timezones like France, Japan, Australia, etc. I know of zero examples where the type of company that Y-Combinator likes to fund (e.g. billion-dollar ideas) was built with remote workers to the extent that the H1-B conversation can be rendered a moot point.

Re: How Paul Graham Is Wrong

#155
post #140

Earlier quoted context omitted.

You know what else sucks? Driving in to an office for pointless meetings to take up half your day. Getting sucked in to office politics whether you like it or not. All those things suck. I think you're underestimating the degree to which day to day office crap weighs on people and makes them far less effective than they might otherwise be, even if they get to have someone come over and "pair" with them. Remote workin…

I agree with your first paragraph 1000%. One of my old start-ups had white boards everywhere (when we ran out, there were windows...) and ad-hoc bi-lateral marker-of-death struggles would spring up anywhere all day long. That was super handy. I've mostly been an independent lone-ranger type for a long time now, and have rarely met most of my clients face-to-face -- but I do miss at-the-drop-of-a-hat white board sessi…

Did you mean "disagree"? Can't tell what your point is.

I like f2f problem solving too - whiteboarding, high energy, etc - it has its place.

Re: How Paul Graham Is Wrong

#156
post #154
post #152

Earlier quoted context omitted.

Remote does not necessarily imply international. There are over 300 million Americans who don't live in the Bay Area, so there are plenty of potential remote devs that are still in the US. Domestic remote devs are in the same or nearly the same time zone and can easily travel for regular, in-person meetings. A startup I helped build over the last nine years was acquired earlier this year. Our entire company was distr…

>Remote does not necessarily imply international. It does in Paul Graham's essay and OP's response to it. Again, we're losing sight of the thread's discussion. (Please read PG's essay that started this.) PG's essay was about H1-B visas (recruiting foreign talent into the USA) and the OP (MA.TT) said the answer was remote workers. This means international remote workers that are 6+ to 12+ hours ahead in timezones . We…

I read PG's original essay and ma.tt's, and while I agree that PG is talking explicitly about international, I disagree that ma.tt is doing the same, to the exclusion of domestic remote workers. He writes "If 95% of great programmers aren’t in the US, and an even higher percentage not in the Bay Area, set up your company to take advantage of that fact as a strength, not a weakness." That comment about "not in the Bay Area" is indeed explicitly pointing to US developers outside SF.

Re: How Paul Graham Is Wrong

#157
post #154
post #152

Earlier quoted context omitted.

Remote does not necessarily imply international. There are over 300 million Americans who don't live in the Bay Area, so there are plenty of potential remote devs that are still in the US. Domestic remote devs are in the same or nearly the same time zone and can easily travel for regular, in-person meetings. A startup I helped build over the last nine years was acquired earlier this year. Our entire company was distr…

>Remote does not necessarily imply international. It does in Paul Graham's essay and OP's response to it. Again, we're losing sight of the thread's discussion. (Please read PG's essay that started this.) PG's essay was about H1-B visas (recruiting foreign talent into the USA) and the OP (MA.TT) said the answer was remote workers. This means international remote workers that are 6+ to 12+ hours ahead in timezones . We…

Actually, we are talking about both. YC and PG are very strongly pro "everyone in the same office", so it's not that those workers could come to US and then live in Maine. No, they will come to US and live in SF or NYC areas.

Re: How Paul Graham Is Wrong

#158
post #144

Earlier quoted context omitted.

The disease is, to a large extent, myopic and self-serving reasoning. It goes like this: we want larger number of "highly skilled" developers to come to the US, preferably, permanently and preferably, working for VC-backed firms. Let's think about the consequences. If this is implemented, it will hurt the sender countries (brain-drain) and may even lower the salaries for people who are already here. I'll go back to t…

Hurt the sender countries? Maybe in some cases. But in many, opportunities were limited there. They come here, not just for money, but for meaningful work that engages their skills at a challenging level. Good for everybody.

This used to be true in the old days. These days both India and China are extremely hot markets for good software engineers. Europe always had a shortage of developers. They are also not markets where people from other countries can go and work.

So, that means all things being equal, when really good developers leave their countries they are depriving the local market of their talent.

If you think of the equation this way -- when engineers immigrate to the US they are bringing with them the investments that their own countries had made. Outside the US many countries subsidize higher education, especially engineering.

It used to be that the money that these engineers sent back would more than offset the local productivity gains. Given the growth in China and India and the salaries there it is hard to argue that the remittance is a good compensation for this "brain drain".

Re: How Paul Graham Is Wrong

#159

Earlier quoted context omitted.

Those aren't the options people are referring to on Twitter (at least not in the threads I've seen [0]). It's about hiring US/Canada based people and not forcing them to relocate. Using Slack, Skype, screen-sharing, co-working spaces, etc. to collaborate and stay on top of everything. The kind of companies you see hiring at: https://weworkremotely.com/ I'm doing it at a great startup now and it's awesome. I've got ki…

Oh, I think I see. The argument isn't that remote-work makes it easy to hire foreigners without dealing with visas. It's that you don't need to source workers from abroad if you can just source them from Tulsa. Totally valid point! Thanks. (We're doing a startup from Chicago, with one very, very remote team member.)

Exactly.

A cursory glance at the HN/YC jobs page shows 1 remote-friendly position out of 20+. Why?

I'll admit, people are probably wrongly ascribing bad intentions to PG's essay and sama's related tweets. But that's what happens when you fail to address the other options.

Re: How Paul Graham Is Wrong

#160
post #130

Earlier quoted context omitted.

Thing I've learned through hard experience: programmers (and yes, I am one) generally over-value individual productivity and under-value communication. So yeah, you can "hold a good conversation" via Skype, but you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person…

I feel that TheOtherHobbs covered most of the points really well, but I feel that this point needs a bit more direct discussion: > you still have to plan the call, set up a time, etc. There's friction to spontaneous collaboration, and spontaneous collaboration is what people really care about when they talk about the benefits of in-person work. If you value developer productivity at all, that little bit of friction i…

This still doesn't refute the point timr was making: sometimes the most productive thing you can do is stop a programmer from writing code. As a programmer (and an employee), what you're ultimately responsible for is happy customers and solved problems. If your code solves the wrong problem, it has negative value to the organization, as it's just something that all the other programmers will have to trip over later.

The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem. Whether that outweighs the increased individual productivity from eliminating distractions is very much case-specific, which is perhaps why there's so much heat and so little light on this issue. You'll never capture all the complexities on a web forum.

Post reply on HN