Hacker News new | past | comments | ask | show | jobs | submit login
How Paul Graham Is Wrong (ma.tt)
301 points by kaws on Dec 29, 2014 | hide | past | favorite | 198 comments

>Use WordPress and P2, use Slack, use G+ Hangouts, use Skype, use any of the amazing technology that allows us to collaborate as effectively online as previous generations of company did offline.

I've been a 100% remote worker for 5+ years but I think we have to be honest here. All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace. Yes, they do help mitigate many issues of isolation and they do help collaboration but there's still some "bandwidth loss" when people are not in the same room or even down the hall from each other.

I'm not advocating an open floor plan with noise and distractions. Even a set of private offices that share a common corridor to facilitate spontaneous conversation with a side conference room for group brainstorming, is superior to keeping Skype windows open.

Yes, there are the common examples of virtual remote workers at basecamp, Automattic, github etc. Those are not billion dollar companies. 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. Small scale modest businesses, yes, but not big ones.

Maybe you can hire a 5-person 100% remote team to launch a new web magazine. Journalists and editors by their nature seem to fit the remote work paradigm quite nicely. At first glance, it seems programming also fits, but only for modest projects.

Yes, the remote workers themselves will insist "I'm 100% just as effective offsite as onsite -- in fact, I'm more productive because I'm not interrupted by office nonsense." No doubt they feel that way but the whole team isn't more effective.

Remote workers even with today's fanciest collaboration technology is not the answer to finding the best talent.

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 example, due to a recent job move, I'm stuck in an office 80% of the time right now, and it's pretty miserable. It's an open office plan so there's constant noise and visual distractions, my boss can (and does) come over and interrupt me constantly on issues completely unrelated to my work, and in a former life the office was a welding garage, so I'm pretty cold most days this winter.

I hear of the unicorn offices, where they were built to support collaboration and focused development work, but I've always found reality has more in common with Dilbert than Valve.

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

Programmers tend to want to squirrel themselves away and work on stuff to maximize their own personal productivity, whereas organizations want to get a bunch of people working at a group optimum. That means that every individual takes a productivity hit for communication purposes, but that the organizational output is much higher than any individual could achieve. Hence, we get the fruitless debates about working conditions: what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.

There's definitely a fine line between communication and distraction and it's hard to hit the balance (I've worked in some horrible "open-plan" environments too), but in my experience, programmers nearly always err on the side of too little communication, especially early in their career.

Companies that want that sort of environment need to structure the entire business process around spontaneous collaboration, not just pay lip service to it.

The reason I didn't hit deadline X? 5 "spontaneous collaborations" happened at my desk in 3 days. Wait... I don't get my bonus because we missed the deadline? But... my collaborations helped the marketing dept hit their goal ahead of time, and they did it by coming to my desk and asking me questions. Oh... that'a a different budget?

If you want to foster that sort of behavior, make sure all of the aspects of the business line up in support of it, not just the facilities budget because "open plan" is cheaper than private offices with doors.

This seems fairly anecdotal. Do you believe this is a larger issue that the spontaneous collaboration is causing you to miss deadlines? Ultimately if the marketing goals are met through your efforts why not use this as leverage?

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.

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.

> sometimes the most productive thing you can do is stop a programmer from writing code.

I have little to dispute about this statement, but I disagree that being colocated has any effect on this (unless stopping them 4-5 times a day will truly make the team more productive; at which point a manager needs to step in and fire that person ASAP).

> The value of colocated employees is being able to really quickly recognize and correct for when the code is solving the wrong problem.

How does colocation solve this where remote does not? Do you expect that your co-workers would somehow notice this from looking over someone's shoulder, as opposed to when you pull in a branch of code from your VCS?

Once you've pulled in the code and notice the problem, you can bring it up in the next scheduled standup or hit the little green button next to their name in Hangouts/Skype/...

I can not see how being colocated would do anything to help speed the discovery of this particular class of problem in a way which is not practical using modern telecommunication software. As a point of reference, I have personally pair coded (with anywhere from 2 to 5 people) with folks in England with great success.

From personal experience, the most common way this comes up is that you have a casual hallway conversation with a colleague, they ask "So what are you working on these days?", you tell them, and they respond with "You should talk to so-and-so, he worked on that a year ago and may have some insights" or "Have you heard about technology Foo that's designed just for that problem?" And then you follow up on that lead and realize that the project you just budgeted a week for (and will end up spending a month on, given all the unexpected problems that come up) can be solved in a couple days if you approach it slightly differently.

These are not hypotheticals - there have been numerous points in my career, ranging from being a sole technical cofounder to working in a 50K+ employee company, where a chance meeting has saved me weeks-to-months of implementation effort. And in each of those cases, the solution they suggested was not something I would've thought to look for on my own, because my starting assumption was that it needed code to solve. And similarly, it probably would not have been spotted until the feature was done and the time spent, because usually your coworkers' assumption when you embark on writing a solution is that the solution is necessary.

This still makes the assumption that these kinds of watercolor conversations are unable to occur online. They do, either in the form of chat logs, or voice calls prior and after meetings, or just as two people get the desire to BS for awhile after coding.

These behaviors are simply not constrained by the environment, not anymore.

it's very easy to make sure that it doesn't happen - for example in Scrum there is a term called "morning meetings", where team is talking about what they are planning to do, what they did previously, and talks about some issues if there are any.

I've seen many examples that exactly the same problem as you've written happens even in co-located team, so it's a problem of lack of communication, not of being co-located (or not).

>whereas organizations want to get a bunch of people working at a group optimum.

It's an exceptional and rare organisation where this is even remotely realistic as a goal.

The appearance of productivity is usually far more important than the reality - especially in mid/late corporations, where the most significant outputs are primate status plays and politics.

>what you see as interruption might be, from the context of the company you work for, be the most globally productive use of your time.

I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity.

No sane manager is going to want to do that without a really good reason.

>programmers nearly always err on the side of too little communication

That's because programmers like to be left in peace to work on small, relatively well-defined problems. Communication can be limited to progress and code reviews and goal-setting by team leaders. Everything else is noise.

The real problem with remote working is that too few corps understand it, and too many managers believe employees aren't functional adults who can work without constant supervision.

It's a management issue, not a programmer issue.

I think at some point we're going to see some faddy Harvard Review type write a faddy Harvard Review type book about remote, and it's suddenly going to become the new outsourcing. Because cheap.

But meanwhile - Paul Graham's problem is that he has a nostalgic hankering for a vision of SV and start-up culture that's already well on its way to being disrupted by the global talent he wants to move to the US.

If you're a world-class five percenter, why on earth would you want to move somewhere with insane living expenses and in-bred VC culture of the Valley when you can bootstrap and innovate around it elsewhere?

Does he really believe all that funding and schmoozing and presentation is essential to getting a business up and running on a planet with an Internet?

Graham maybe needs to consider the possibility that those five percenters aren't his future employees - they're his future direct competitors.

Pretty much nothing you've written here refutes what I'm saying. You're a programmer, so naturally, you assume that your optimal use is programming, and you draw conclusions starting from that assumption. But if you moderate that assumption a bit (you're also well-used as a planner, an organizer and as a communicator, among other things), you arrive at a different set of conclusions.

"The appearance of productivity is usually far more important than the reality"

No, that's just cynicism talking. Larger organizations care about your personal productivity, but they care less than small organizations. Part of the brilliance of modern corporations is that you don't always have to be at peak productivity as an individual in order for the company to profit. Which means, in turn, that you can do things like get sick or have a family without having to give up your job. The flip side of feeling less efficient is that you have some cushion when you actually are less efficient.

"I think Joel Spolsky covered this neatly somewhere. If you kick a programmer out of The Zone with a distraction, you can lose whole hours of useful productivity."

You obviously don't want to interrupt someone gratuitously, but the point is that your perspective on what's important can differ wildly from your employer's perspective. Keeping someone in "The Zone" is not the only goal. An employee in "The Zone" who is churning out "The Wrong Thing" is worse than no employee at all. So you need communication. And as soon as you need communication overhead, people are going to be interrupted. It's a cost of doing business.

The 5% thing in the original article doesn't add up for me at all. The top 5% of the programmers that I have come across are able to do things that the typical YC company doesn't need at all. He talks about someone who would hire 30 of them if they could. Really? What kind of team would that be? Could you keep them motivated doing all the bits and pieces a startup needs to do? Maybe they are building a new OS. (I doubt it)

It sounds a bit like people shooting the shit about great footballers or something where you up the ante to large it up ;)

> 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 really convenient to have everyone jump in.

I've been doing open source and IRC and 'the internet' for more or less 20 years, so I'm pretty comfortable with the whole thing, and happy with it, but when there is a sense of urgency, it can sometimes be less efficient.

Run a mumble server and give each developer their own "office" as a chat room.

If you chose not to talk casually when remote that is really up to you.

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.

> Even then, however, it's not that hard to find an overlap

0900 my time is 2400 west coast time. No overlap there. 1700 here is 0800 west coast time. Granted, I don't leave that early from work, but not all programmers are "in the office by 9" people either. There's not a lot of 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.

I don't doubt it's possible, and even the best solution for some people in some situations. But not for everyone.

> Conscious use of collaboration tools

The key word being "conscious." Finding good developers is hard, and finding good ones that communicate well remotely is even harder.

Shameless self-promotion: we (nearly 100% remote) explain some of soft skills we look for in an engineer here: http://www.staunchrobots.com/blog/staunch/

There's probably a training business opportunity in this sector.

Harder problems than the Linux kernel?

I've been remote for eight years now and I work on a codebase so huge that no one person understands it all beneath the 10,000 foot level. Nearly all of us are remote (only the managers are "local" to San Jose). Once a quarter we get together and meet up, coming from Vancouver, Toronto, Bangalore, Colorado and northern California.

Yes, kernels are not difficult because most of the problems are purely technical problems, that programmers can just decide for themselves any ambiguities, and many of the parts can be worked on separately. Software with users is 10-100x more difficult.


Sorry if I was unclear. I was just using Linux as an example. The product I work on has plenty of users. I don't agree that it's orders of magnitude more difficult but that's beside the point.

> the Linux kernel?

Although it's insanely technically challenging, many computer science projects are more difficult than the Linux kernel to do remotely. For example, watching users interact with the software, anything that involves expensive test equipment, anything that runs on embedded/custom hardware.

Because no one has ever run the linux kernel on embedded/custom hardware?

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


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, there was no technology (high speed internet) at the time to do it. Sure, as a company becomes bigger, and also as technologies improve, there are possibilities for organizing remote work.

Anyways, back to the context and constraints of startups: If you're a startup, it would be great to recruit the "exceptional" talent in South Africa, Ukraine, China, New Zealand, etc (because 95% of the best programmers are not in the USA).

The MA.TT says remote work is the answer. I don't see how because I've not seen any evidence of any billion-dollar American startup that was built by a 100% virtual team from multiple timezones of Europe/Africa/Asia.

If you're creating a 24/7 tech support department that "follows the sun", having staff in far off timezones is awesome and necessary. If you're trying to build a product with hard challenges for the team to solve, MA.TT's "answer" of international remote workers is not an answer.


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.

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

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.

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.

While I concede that's not the "billion-dollar American startup that was built by a 100% virtual team", I've worked for a startup where half of the team was distributed across america and europe. It was an amazing team, highly collaborative and flexible, successfully tackling a hard problem. (I used to joke that the code base was CS funland: all the interesting problems in one place)

We failed mostly because our product was overly ambitious, solving a broad problem.

Yes, is just an anecdote, but my point is that distributed team can run circles around most of colocated teams and we wouldn't have been able to assemble that team if we insisted that everybody had to be on the same place.

Here at Sococo we hope to be that team! We're in several time zones, 6 states and three countries. Not to a billion yet; not hardly. But growing!

Not that valuations are the end-all be-all, but Automattic was valued above a billion earlier in the year, and has risen since then: http://www.techmeme.com/140505/p14#a140505p14

Having experienced different setups, it seems that collaboration is OK if everyone is at the same place. It's also OK is everyone is remote. Where it gets troublesome is when part of the team is collocated and part is remote. What you get is two unequal classes of employees which leads to all kinds of problems.

I work part time remotely, and we have other devs full time remote. I definitely feel like I'm "missing out" just being OOO part time, be it the hoc discussions or just going out for beers.

Of course, it only matters if you let it matter. Some people don't care or need that stuff. They worry about their own work and leave work at work, which I'm working on doing :)

I think you might be falling into the trap of overt generalization.

I agree that remote removes critical bandwidth for cross team communications.

On the other hand, lots of programming projects are parallizable to n crafty individuals who need colocate only once in a while to " totally sync their mindstate" and can communicate effectively enough in the mean time using other ways without loss of critical bandwidth if the need for that bandwidth is not needed.

Not all teams need the same kind of cross individual bandwidth. Of course loss of colocation leads to loss of serendiptuous talks to create novel insights but if the insividuals working together were located far apart in the first place then they might not be working together at all if not remote.

Personal anecdote to give a practical example:

I recently moved to another team within the same organization working on the same product but on a different level. The team from where I moved developed the stuff that got CI:d to customer builds and it would have been really difficult for me to imagine working remotely there as the work required often going around the floor asking about stuff (lots of undocumented legacy).

My new team focuses on tech and middleware and creates libraries for downstream to consume. Programmers work on their own libraries and I can go on for days without requiring input from anyone. On this team I could easily work remotely.

Based on my experience I would claim it depends on the designed team duties wether remote works or not. And I think this means that team organization must be tightly coupled with the software architecture design. I have no idea which should drive which but I'm pretty sure any changes in one should also be consciously reflected in another.

"A lot of startups have ambitious goals and very hard technical challenges"

And those companies aren't billion dollar companies either.

"All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace"

But they're more effective than those people not working together at all.

"Remote workers even with today's fanciest collaboration technology is not the answer to finding the best talent."

You have to define 'best'. If the definition of 'best' has to include "people who are willing to uproot their entire life to spend a portion of it in someone else's office", then yes, you're correct.

"I see no evidence that this has ever been successfully done. Small scale modest businesses, yes, but not big ones."

I see little evidence that co-located teams are all that much more successful at becoming billion dollar behemoths than virtual teams.

You get access to a wider breadth of experience of worker when you embrace remote. Just because management hasn't had enough experience with the model yet to be able to grow a billion dollar company doesn't mean a) it's bad or that b) it may not happen in the future.

Videoconferencing sucks -- it's not as effective as having your coworker come over to your screen for pair programming, or talking face-to-face with your UXer. Anyone who has done any amount of remote work will realize that the OP is dramatically overstating the value of teleconferencing solutions compared to working in house.

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 working is an approach that really needs to be embraced by the entire company, and refined over time to match the needs and skills of the team as they change. Some people need more one on one time, some need more group time, maybe you do some face to face meetings quarterly instead of annually. It's not a one-size fits all, but nothing (including f2f office work) is.

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

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.

I mean "agree". My point is that the hassle is a hassle -- the f2f problem solving sometimes makes it worth it. Not often enough to make the decision cut-and-dried.

Gotcha. Agreed. There are times when I want/need that face to face - whether it's project team mates or just other tech/dev/biz folks, to brainstorm, troubleshoot, etc. It's part of the reason I'm in a coworking space.

Videoconferencing _used_ to suck. Four years ago, having a voice conversation while sharing a screen was neigh on impossible. Now, however, it's dirt simple and works really well.

I'm kind of split... I think it depends on your home environment. Spouse, kids, other distractions? Sometimes the workplace has fewer distractions than home.

Meh, that's an easy fix. I've got an actual office outside of my house that takes 30 seconds to get to. (AC and hardwired ethernet, of course)

So as a remote worker, you would be more productive in the office 5 days a week?

If everyone on the team has a 2 hour commute, that is a guarantee that there will be less time available to the individual and thus the team. Commutes are a big problem aside from the communication.

I have also found that companies that do remote or allow it, just communicate better, to all parties, even clients or stakeholders. They are more external focused companies without internal blinders, they take an external view of the company instead of internal. Lots of employees time is commuting and dealing with office politics which become a bigger part of your job than working at some places.

Personally I think companies that are remote or allow remote are much better at communication overall and have a saner external view of themselves coupled with the internal view, rather than just an internal view of what matters. I have seen this across many companies I have worked for or with. Some internal places I have worked that didn't allow remote made it very hard to get information because they expect people to barge into offices to ask.

Overall I feel remote companies have the benefit here and make for more robust teams if they do it right, not to mention the benefit of attracting great developers all over the country or world.

Today, virtual communication is how we communicate to most of our clients, customers and stakeholders. Companies that allow remote just do this better because they also communicate that way. Remote companies value external views of the company and communication much higher than non remote capable companies.

Two more benefits of remote capable: When you setup another office upon growth the new office will not have the virtual communication problem (office to office within the same company is typically virtual communication and non remote companies do this badly), also remote companies root out non-contributors more quickly as you can't just hide behind being there physically as work you must contribute and build.

VCs are so against remote that it seems like they almost have some tax hookups and own lots of real estate in SF as some of the logic makes no sense, ultimately labor costs would be cheaper and the companies would be more robust to changes.

"If everyone on the team has a 2 hour commute, that is a guarantee that there will be less time available to the individual and thus the team."

I am willing to sacrifice 2-4 hours of personal time per day commuting => I am willing to sacrifice myself to the company's wishes => I am a 'good employee'

A portion of the advantage of office work comes down to employer control of employee. The differing communication systems with clients, customers and stakeholders illustrate the different balances of power accurately.

As such, I agree that remote companies make for more robust teams if they do it right - but it's much harder to do it right.

Remote companies lose some advantage of easy communication (in order to survive as a remote, you have to be better at communication), and you lose some advantage of having a clearly indicated power structure.

I feel the same way. I have lived in a tech hub city and worked on-site for major tech companies. I now live in a non-tech hub, with very few technology jobs to choose from, but I live here for personal quality of life reasons. Since I've lived here, I've worked both remotely and on-site for a few different companies. Selfishly, I'd like to see far more companies allow remote workers, because it would give me so many more job opportunities. But I also have to admit that my experience is that overall team/company productivity is markedly better when the people are all in the same location. I know that there are exceptions, but I really don't think they're the norm.

Yes, it's a matter of how much the team gets done, not only how much you personally get done. I used exactly this example in "Programmer Productivity – Interruptions, Meetings and Working Remotely" http://henrikwarne.com/2013/04/02/programmer-productivity-in...

Github was valued at $750mil in 2012, should be worth a whole lot more now.

Basecamp, has not gotten outside valuation for a long time, but they are just as if not popular that Asana who was valued at $280mm back in 2012.

Agreed. I don't have a solution, but this frustrates me to no end.

As a software engineer that previously worked in an open floor plan I can testify that they absolutely crush individual productivity. Headphones are no solution. I think I'd need a potato sack on my head too.

But as a software engineer that currently works with geographically distributed teams, there's no way to deny that certain elements of communication can't be reproduced with chats and hangouts. It's not just technical discussions either - it's much harder to build cultural cohesion in distributed teams as well. Which is a bummer because it's a lot easier to engage in blame and scapegoating when the guy that wrote something is just some email address and not a friend.

I wonder if anybody has had success with some sort of 80/20 (remote/on-site) model...

hand raised I have been doing 4 days remote, 1 at the office for 7 years. I live 150 miles from the office. That once a week face time is very helpful.

I haven't read the entire thread of comments, but as I read about the mishmash of remote tools, I'll throw in an endorsement for Microsoft Lync. The full blown integration of email, video, audio, screenshare works really well.

What you typically do is work remote and meet in person once in a (long) while. This is how lot of open source projects work.

> All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace.

Totally agree. But also feel collaborative periods make up a small amount of our time - remote workers allow having more/better/cheaper developers (whichever of the three you want) which can easily offset the less effective collaborative times.

If software development were a field where we spent most of our time collaborating with others remote work wouldn't make sense. But most developers are spending most of their time alone at their desk coding or communicating with others in a manner that doesn't differ based on location (i.e. you still email people in the same office).

> 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

Sorry, this just isn't true, the IT team in my old place was 100% remote (there were sales and marketing in local office), and we had very big growth and success solving quite a few technical problems scaling the business for millions of users. It's more of recruiting people with right skills and right mindset. After scrums/whatever we spend 90% of our time solving the problems - being on site doesn't really help unless you do do some specific R&D that requires constant team consultation - which 99.99% of startups here DON'T do.

I am in bay area & do not work remote, but I often think future is all about working remote to avoid commute & pollution. Software Engineering is one such job where we can get things done remotely. Like open source community :)

>> I've been 100% remote worker for 5+ years but I think we have to be honest here. All those teleconferencing/videoconferencing/virtualwhiteboards/etc are not as effective as everyone sharing the same physical workspace.

As someone who worked remote for 6 years (with a few face to face meetings over those years) and now works in an office I think each have their trade offs and it balances out largely. In an office you can get quick questions answered much faster. If you forget to ask something in a meeting you can find the person and quickly get the answer later that day. Discussions are more natural too. However I've found that when working via email or Skype discussions are much more focussed. We ask our questions, get out answers and get back to work. In a face to face discussions people tend to add words to their sentences to make what they're saying seem longer/more important. Discussions deviate from their intended purpose. Sometimes that can be useful but often it's a waste of time. I've been in meetings which I could have wrapped up in under 5 mins - and the people I'm with are there for 30-60 mins. They talk about irrelevant things, repeat themselves with slight variations etc. etc. Sometimes this can be necessary if you're building a relationship with someone but most of the time it's a waste of time.

Couple of thoughts to throw out: (1) retention, keeping somebody in the family who has or wants to move out of SV/NYC. (2) Getting that 35x rockstar on board who's not interested in SV/NYC. (3) Stretching the $$ (of company or staff), as most parts of the US if not the world are cheaper than these two areas. (4) Customer proximity, in that there are markets that aren't the (western) US, etc.

"are not as effective as everyone sharing the same physical workspace. Yes, they do help mitigate many issues of isolation and they do help collaboration but there's still some "bandwidth loss" when people are not in the same room or even down the hall from each other."

Agree. Which, in fact, was one of the reasons that both Bell Labs and the Manhattan Project achieved what they did. (For sure a different time which lacked many of the advantages we have today.) And you could also argue about the negatives, the distractions etc. [1] But there is no question that in many cases it's an advantage to be located near others working in the same area and not in near isolation.

[1] If you don't like listening to music (I don't) use a set of 3M "tarmac" grade earmuffs which will block out nearly everything.

"Which, in fact, was one of the reasons that both Bell Labs and the Manhattan Project achieved what they did."

Err, no. The Manhattan Project succeeded because it has most of the available physicists of the world, a blank-check budget, top priority and rather severe real-world pressure. No startup idea will ever have that kind of staff...


Yep its buying into the hype of teleconferencing that the Big Telcos sell to the CEO on the Golf course. The REAL point here is to build software you need teams that work well together not a bunch of solo contributors

Mullenweg is in kind of a unique situation with WordPress/Automattic - they have regular staff meetings all over the world, under the monicker "WordCamp". Sure they don't have all the staff at any of them (except SF, presumably), but a lot of the people working for the company attend various ones regularly, so they can get together in-person for periodic meetings, while at the same time keeping people in touch with what their users are doing.

Programmers, if they have a choice, like remote or at least some remote.

Managers + VCs, if they have a choice, prefer all in the office so they can keep power but this actually makes them less competitive and more susceptible to physical disruptions: moving an office, an employee moving, time, office politics, commute, distractions, over meeting and more.

The PG essay on this was glaringly overlooking that you can be a US based programmer and be good or great even if you aren't in SF. Tech companies have a responsibility to not be so monoculture and they currently have a single point of failure in Silicon Valley, which from an engineering perspective is poor distributed design and very little redundancy.

There are benefits of being in one place, the ability to meet physically and be on the same page but we all know the real work gets done back at our desks in our solitary focused modes when it comes to programming and making products. Then we open up for feedback and iteration, then again back to work.

The work part should be setup so programmers perform their best. Just like some of the best scientists, writers, etc, they need their lab/office where they can get somewhere with the problem at hand, not an open office in SF.

Glad Ma.tt mentioned this as he is a leader in the right kind of tech leadership we need: spread it around, live better, work hard, deliver solid products, from anywhere...

there's a pretty big difference between "remote" and "some remote".

No bigger than the difference between "in the office" and "some remote"

some remote requires a visa

I'd add that the PG post is a symptom of a disease. A disease that that is brewing in the echo-chambers of SV. Note also the recent post where PG claims that "mean people fail".

The more the VC community gets un-hinged from the reality the quicker the inflation of the bubble and the crazier the assertions.

Time to get out of the bubble.

Part of the problem is that investors might understand the businesses they invest in from 30,000 feet, but they frequently have no idea how their portfolio companies are actually run. If some of them went undercover and applied for jobs at their own portfolio companies, they'd probably have a different perspective about the "talent shortage."

They'd probably get rejected for jobs at their own portfolio companies. That's how out of whack hiring is.

Not sure why you're down voted, graduation year alone would get all VCs fall at the first reading of their CVs.

Yes. As a job search candidate myself, I see your point. It was not as it used to be before. Maybe something to do with a lot more competition and focus on competitive programming in interviews may be?

What disease is that, (very) specifically? I'm having a hard time nailing down what you mean, and how you arrived at that conclusion, but think it would be worthwhile to understand more.

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 the brain-drain again. The REST OF THE WORLD NEEDS DEVELOPERS TOO. Maybe even more than the US.

Once here, these people will toil long and hard and face very steep challenges in making serious money. Maybe 1-2% of them will see millions. Most will make sub-par wages as immigrants. Yes, H1-B wages are lower.

Meanwhile, VCs, since their bets are widely hedged will get to play many rounds of the same game increasing the odds of the payout.

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

Being one of those Indian developers, I'd happily switch with you (assuming you're one of those US devs)

Morally we'd both be better off, I would like a better quality of life (subjective I know) and you'd be able to contribute to Indian development.

Meh. Here is the tradeoff.

If everyone is co-located, you have inconvenience and higher productivity. If everyone is remote, you have an inherent overhead, but enormous flexibility. If some people are co-located and others are remote, you naturally tend towards a divide where people who are co-located without thinking about it wind up networking with each other and excluding the remotes.

If you are a small startup, the productivity difference really can be the margin between success and failure. Hence the pressure to co-locate. But conversely the availability of better talent in theory can allow for a better workforce which might outweigh the productivity overhead of remote work. But when there are just founders, by definition you can't assume that there are better people available. And the need for close working at the initial stages gives strong pressure to co-locate.

Therefore there is a natural tendency for startups to co-locate. And once the seed of the company is co-located, switching to a remote model is going to involve crossing a difficult cultural barrier that not everyone will succeed in. Thus the continuing pressure to co-locate.

I think you might be mistaken in the assumption that remote working leads to less productivity than co-located.

This is purely up to the team. Sometimes being co-located leads to over meeting and lots of time spent on disruptions and chats, while remote working lead you to be more professional and talk to your co-workers only when necessary for the job.

I think my assumption is justified. To address your suggestion, it is safe to say tht early stage startups which are inclined to over meeting are guaranteed failures no matter what.

Yep, I too think same

The article assumes its conclusion:

> amazing technology that allows us to collaborate as effectively online as previous generations of company did offline

That's a huge claim, and it's disputable. For example, I've worked both ways a lot and find remote work to be dramatically less effective.

If you accept the claim, then sure, the startups PG was writing about are missing the obvious, and for the most ironic of reasons—technical backwardness. That's possible. But there's also a lot of wishful thinking and saying-makes-it-so on this subject, which comes up on HN all the time. A lot of people just really, really want this to be true. That alone doesn't make it true, and I think it's at least as possible that desire is distorting the analysis. (Which, as someone whose whole career has been plagued by an unsolvable constraint problem of family, work, and geography, I can easily understand.)

Fortunately, we're going to find out. If all those startups are doing it wrong, then there's a gigantic market inefficiency and we'll soon see a new wave of smarter, less backward companies doing much better.

What you say about the article may very well be true, but the surrounding discussion is not as bad as that. I recognize that the problems pointed out by PG ("chance meetings") and others are genuine problems that haven't yet been solved by technology. However, what I object to is that the rallying cry (and a lot of PG's essays are now rallying cries for how the industry should be, even if he just thinks "I'm just a dude that likes to post my thoughts on the internet, I don't know why everyone objects") of the industry is "move more people into open offices in SV and NYC", rather than "improve the remoting process".

Twitter = chance meetings as a platform.

I just finished a remote job search. I'm in Los Angeles, and most of the companies I talked to were in SF. I had previously worked remotely for a company in New York (Etsy), and I was honestly really surprised how hostile SF companies were to the idea. I was mostly going through personal connections, so I assume that I was getting the gigantic break of having a solid recommendation that most people can't get. (I feel bad about this, but it is what it is.)

I have been on both sides of remote work, so I totally get that it's not a slam dunk. It works a lot better for companies that have a strong culture established in a home base, and it works a lot better for experienced folks than green college hires. I have shut down the interview process myself when I felt like working remotely wouldn't work out at particular companies.

Even given all of that, I was pretty amazed how quickly some of the conversations got shut down. No remotes, we don't care who you are or what your experience is. I didn't talk to any companies outside of SF that were that quick to say no.

FWIW I landed at Stripe, which in fairness is probably one of the companies pg had in mind when writing his original article. I agree with the spirit of this, and I also don't really agree with a lot of things in pg's essay. But the particulars here might be totally wrong. At least one company in his network is really remote friendly.

How does remote working get done at Stripe? what tools? What practices are a consolidated standard? It would be really useful to the discussion if you could share something with us.

I am still convinced that before anyone can confidently determine if a talent shortage really exists, they must first fix the transportation issues. I've made this comment a few times already, but if I had a magic wand and made a BART-like bullet train materialize that connected San Francisco to San Jose, Danville, San Ramon, Mountain View, Palo alto, Cupertino, Foster City, the "out-of-reach"'ish areas of SF like where SF Zoo is and where the House-Of-Air is located, and the Persidio... we'd would be having a very different conversation.

In short, I believe it's the commute that engineers don't want causing a big part of all this gentrification and talent shortage talk. Personally, my Linkedin says I won't take any job that I can't walk to from a BART station. Google is an exception though; the whole GoogleBus at MacArthur BART situation.

I don't know if I'm one of the great engineers PG and others are talking about but I have no interest in living in the Bay area, whether as it currently exists or with even more people.

You can solve the "transportation" issue by avoiding having to transport anyone in the first place, which is exactly what the author is speaking to when they suggest remote working arrangements.

Or maybe even transporting some of those opportunities to areas closer to you. Starting new VC-backed companies in Detroit, Denver, Boston, Durham, Austin, Memphis, Nashville, Louisville or other regions would give you access to some great talent that simply prefers to live in other areas of the country.

For an industry that often derides 'monoculture', the SF tech scene sure resembles one.

PG ignored current trends and recent history to an absurd degree in his recent blog post.

Not factored into the equation: An actual, provable, verifiable history of illegal salary-fixing. The experiential reality that most immigrant programmers get a lot of mistreatment, both from racism and from their own incompetence - and the related experiential fact that a lot of immigrant programmers are utterly incompetent.

The rhetoric of these arguments talks about 10x programmers, but companies really seem to prefer importing 0.1x programmers or even -10x programmers.

Meanwhile, tons of companies have immense success with remote work, and the wage changes associated with the last ten years are not at all commensurate with the increased value of programming work. (See aforementioned illegal salary-fixing.)

Is remote work easy? No. But is PG's business about doing easy things? No.

I literally just ran grep -c "table" against a text dump of this comments page. The count was 122. 122 uses of the table tag. Since that includes </table>, 61 tables.

This whole argument is as up-to-date as the HTML on this page.

So much this. I have pretty much stopped clicking on the HN posts from HN companies looking for employees, because almost none of them offer remote work. Which is too bad, because there are quite a few HN companies that I would love to work for.

I highly suspect that it's a consequence of being a YC company. The president of YC has even publicly denounced allowing remote work.

> As a side note, avoid remote employees in the early days. As a culture is still gelling, it’s important to have everyone in the same building. [1]

1. http://blog.samaltman.com/how-to-hire

Actually, I think truly remote teams are just rare regardless of affiliation - we're YC, 20 employees, and only hire remote for all the reasons outlined in this thread and others.

Seems like setting yourself up to have an 'everyone is remote' culture at that point in time would make the most sense.

That makes the most sense to me as well. If you're planning on having a distributed team, doing it early on is the best, and perhaps the only, time to do it.

The idea that remote work is a solution to immigration is also a meme on Twitter. I'm not sure I understand it.

A San Francisco tech company can employ developers in Krakow to work remotely without dealing with visas. But those developers either need to be 1099 contractors, or loaned out from an outsourcing firm.

Both options are poor. Outsourcing firms for obvious reasons (introducing a middleman that serves no purpose whatsoever except to serve as a legal fig leaf). 1099 because (a) it creates a second class of employee and (b) because it's technically unlawful to classify full-time employees as contractors.

Just because someone is on a different kind of contract (say a monthly retainer paid by wire, versus employee of US company paid with direct deposit) doesn't mean you need to treat them differently. Every "Automattician" at Automattic is viewed the same regardless of how their employment contract happens to work, and as you scale larger you can set up subsidiaries overseas to directly employ people. (We look at this once we have about 5 people in a given country.)

Also remote work doesn't mean overseas, there is amazing talent all over the USA too that doesn't happen to live in the SF area.

I really liked this sentence: "The US has less than 5% of the world's population. Which means if the qualities that make someone a great programmer are evenly distributed, 95% of great programmers are born outside the US."

There are about 7 million people in the Bay area, 322M in the US total, so let's say 98% of the great people in the US are born outside of Bay area. There are no visa issues moving between cities or states in the US, but many many other barriers that have nothing to do with visas.

How are you handling the tax implications of foreign workers? Are you doing something to withhold FICA/FUTA? I'm doing some research and I don't see the exception that says that workers that would otherwise be classified as full-time employees can instead be 1099 contractors simply because they're foreign; on the contrary, the SSA seems to say that you're required to ensure that foreign employees obtain social security numbers.

I'm not a lawyer, but I am an employer, and it is not clear to me that the "1099 remote worker" strategy is as clean a solution to the immigration problem as it's being made out to be.

> the SSA seems to say that you're required to ensure that foreign employees obtain social security numbers

But you cannot issue Social Security Number (SSN) for foreigner without going through immigration process.

I think the same immigration process that would block employers from issuing SSN would also block any foreign contractor from winning "I was de-facto employee" case in court.


There is a way to get something like a SSN as a foreigner who isn't eligible for immigration. It's called a Taxpayer Identification Number and it does in some way allow you to file and pay american taxes as someone who is not American or in the immigration pipeline, afaik. I have not had or had to use one, though, so I am unclear on the specifics.

I have a relative who snowbirds in the US on the max visitor visa from Canada and she has all sorts of problems dealing with even basic things like cable companies who want a SSN to do tech support for some reason.


I wonder if the tax situation is any easier if you're dealing with US companies & employees who are citizens, but living elsewhere. At least the SSN number would be already dealt with, but there would still be tax implications that would be affected by any tax treaty between the US and the other country.

I have done about half my career as a 1099 or equivalent. There is no question that those are treated differently.

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 kids and my wife is in college–I'm not relocating to SF.

Maybe there are intricacies to being in a heavily-funded, high-growth SF startup that prevent this ... I just don't know what they are and PG & sama aren't elaborating on them.

[0] https://twitter.com/sama/status/549053726409768960

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


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.

Remote work isn't a solution to immigration, and I'm not sure that was the point of the article.

For me remote is the solution to the so called talent shortage in the Valley. If companies were really interested in hiring the best developers they'd drop their archaic view of remote work and remove location-dicated working.

Part of the talent shortage is the SV is competing with other higher paying and higher social status professions.

Its even more pronounced in the UK and Europe.

In all fairness, it would require a major sea change for, say, Microsoft, to get to where they could make remote workers a significant portion of their development staff.

Fine distinctions get lost on Twitter, unfortunately. Your points about hiring people in other countries are valid. Remote work is also an alternative to moving everyone in the US to Chicago, NYC, or San Francisco; I understand that PG's essay was about immigration, but PG is an on-going advocate of people working in the same office due to the "great ideas happen in chance meetings, and those are hard to replicate", which means that that only does he want great programmers to move to the USA, he also wants them to move to cities that are tech hubs.

Do you know how Automattic, Github, and say Basecamp do it?

Automattic "employees" outside of the US and Canada are contractors.

(I used to work at Automattic)

This is no longer accurate. Some remain "contractors" still officially due to regulatory issues, but we now have employees in multiple locations outside North America. And that list of locations is growing.

(I work at Automattic)

Figured this was the case but assumed it didn't changed the gist of the answer too much. tl;dr actually employing people in other countries is difficult

In my experience I have encountered several firms that use oDesk with VERY healthy hourly pay to make up for healthcare benefits, retirement, etc. Equity becomes a mess, but the folks I talked to were definitely not 'second class citizens' in the company, and were just as respected as any non-remote dev.

The contract with foreign contractors is NOT "1099".

AFAIK you do not have to file 1099 form in order to deduct foreign contractor expense from US business revenue.

I'm not a lawyer or CPA, but I run my own business and pay to foreign contractors.

You're right; it's 1042-S.

Is filing 1042-S mandatory?

It may or may not be the case, but when foreign contractor works as a business entity then "Foreign Person’s U.S. Source Income" seems to be irrelevant.

Work with a US nexus is subject to withholding. More broadly, this article does a good job of summing up my concerns:


Thanks - that's an interesting point of view.

If I were running a company with hundreds of employees&contractors that would be a point of concern.

However from a bootstrapped startup perspective that probably does not even worth investigating further.

Everyone is free to sue for anything. That's the cost of doing business.

Hiring foreigners directly as employees has many other risks in addition to having inevitable overhead.

This is an example of what I think is a common and very damaging metafallacy in startup entrepreneurship: the basic business safeguards we don't pay attention to because they don't seem to matter until our companies get big.

But these are some of the worst problems, because they submarine. You pour the money, sweat, and (most importantly) time into an enterprise, risking its total failure. You stick with it, your company gets its footing, you're poised to see a return. Then bam, disaster: some stupid thing you weren't careful about when you were 4 people explodes, counterfeiting your success.

You'd have been better off it exploded when you were just 4 people big. You'd have known you were screwed, and could have saved yourself the time and energy, and used the opportunity to move on to something that had a chance of succeeding. Instead: you lose 90-100% of your outcome to a lawsuit.

I don't get it.

There is no reason to sue struggling startup, because if you sue for too much then the startup would simply fold.

That's the main way startup protects itself.

Struggling startup usually does not have funds to lawyer up.

BigCo on the other hand is a very attractive target, but has funds to lawyer up.

If struggling startup successfully transitioned to BigCo then potential exposure from past shortcuts is small (relative to BigCo revenue).

How could "contractor vs employee" shortcuts applied in 4 people startup be a significant problem for BigCo (which already transitioned into lawyered up way of doing business)?

> 1099 because (a) it creates a second class of employee

Care to elaborate why this is so bad? As far as I can tell, most employee (FTE) related laws in the US are suited for, well, people living in the US.

It's spooky to read that while eating dinner and thinking that I cloud get a remote job and go back to Krakow.

This is one of my concerns - to be a second class employee. Company has to have remote modus operandi.

I have completely 180'ed on this topic. I used to think to be a successful startup, you all had to be in the same room, ideally at a big huge desk etc.

After working at my current startup, I realize I was wrong. We are an entirely remote operation, and have been since day 1. A few of us are in Austin, and rarely meet for a face-to-face, but it's more of a 'oh yeah, you actually exist' meeting rather than a hash-it-out sort of meeting.

I think the reason we have been successful is because being remote has forced us to write things down, in our wiki (in the form of product specs) and in JIRA (in the form of specific features and bug fixes). With just those two forms of written communication, we've solved 95% of our communication needs. We almost never skype or use video conferencing... it's just not needed.

The other reason we are successful is due to experience. We've all done startups before, so we know the drill. I can't emphasis how important this is enough, but does deserve more explanation. (unfortunately I can't muster the amount of typing atm).

IN the end, we can focus on getting work done... without the distraction of office chatter, commuting, long lunches.

> The other reason we are successful is due to experience. We've all done startups before, so we know the drill. I can't emphasis how important this is enough

I've worked remotely for a few years now and think this is the key. I would not advocate hiring junior developers remotely. There's too much risk in it. I was once faced with the task of trying to mentor a junior dev remotely and it just didn't work.

In general I would agree, but I think it also depends on junior developer in question. Every now and then you meet someone whose overflowing intelligence, talent and work ethic will make them an exceptional engineer, but are not there yet. It would be a shame not to support that.

I recently mentored such person and she is already one of our most productive developers.

For argument's sake, if remote work isn't the solution, how about taking the middle ground? I don't see a lot of companies setting up offices in other parts of the world until much later on the growth curve. Is there a fundamental reason for this? Is it simply cost? Seems to me that SV companies can do great things by even opening up 2-3 person shops elsewhere in the world. You then have the compromise situation of having a few people collocated, which should cut down the need to continuous remote meetings, and at the same time provide simultaneous access to new growth markets. In effect, you have remote offices as opposed to remote employees, which seems like a much more efficient organization of resources.

If you do this right, there's no "remote", there's no "overseas", there's no day-to-day distinction in how someone works between whether that person happens to live in the country the company was founded or not.

Isn't there a tremendous upside to being physically co-located? Even if the teams are remote, are the founders not usually located in a 'tech hub' city (SF, NY, etc.)?

Matt says to let people 'live someplace remarkable', but for most of the world that want to work in technology SF is someplace remarkable.

The benefits of using group collaboration tools are still available, but you have other people working on overlapping problems on your doorstep, support and service companies, and access to intelligent finance.

The Bay Area is pretty awesome however the housing prices are not, I would say it's the single biggest issue here. I've been told my $2000/mo Rent for a 500Sqft 1Br Apartment in San Mateo is a "good deal".. to contrast that the mortgage on my 2000Sqft house back in Miami (not far from the beach) is $650/mo including Taxes and Insurance.

The downsides of mass immigration are have a tremendous downside, comparable to the upside of being physically co-located. For example, the skyrocketing living costs in US cities.

Trying to solve the problems that get in the way of making remote work as seamless as co-location seem to be technical, which are easier than the fundamental problems of economics.

Most people would think so, but apparently this changes if you work for Yahoo!. Then you are a lot more productive if you work remotely. This is what I learned on Hacker News. ;)

It's worth repeating that I absolutely believe we should improve and dramatically open up immigration in the US, and applaud PG's and other's work there, but in the meantime you don't have to handicap your company because of the current politics around this issue.

There are companies like teleport http://teleport.org that try to visualise this potential with data.

Also recommend this YCombinator startup school talk by Balaji Srinivasan on this topic: Silicon Valleys Ultimate Exit https://www.youtube.com/watch?v=cOubCHLXT6A

Spot on! Seems the "shortage" isn't in labor but in deference to employees as people. Wouldn't you want a horde of folks willing to work 80+ hours for Ramen? </cynic>

It's interesting how many commenters read "remote" as "contract" or even "overseas". There are lots of developers outside of SF, NYC, Chicago, etc. that would relish the opportunity to still live their suburban/rural lifestyle and avoid a lengthy commute.

One advantage for companies in big cities is they can usually hire these remote employees at a discount. It can get a bit hairy when two remote employees doing the same job are paid differently, but that is already the case in many situations.

The other obvious advantage is that companies that hire remote employees have an almost unlimited candidate pool. Even if a company chose to limit hires to their own country, the only group they cannot hire would be candidates unwilling to work remotely. Based on my discussions with thousands of programmers over the years, I'd suspect this is a very small group.

This is where I think Paul Graham gets it wrong:

> Exceptional programmers have an aptitude for and interest in programming that is not merely the product of training.

This is the old "you're either an exceptional programmer or you're not" myth. This is one reason why diversity in tech has regressed since the 80s.

I agree that geopolitical boundaries should matter less in the software business. However, I strongly disagree that this is the solution to programmer scarcity. Expanding your source of resumes to the entire world only delays the inevitable. Why focus on removing the dependency on the passport variable, when we still have such a strong dependency on gender and race?

I find this post and many remote-advocacy posts like it are overly optimistic about the problem of timezone differences. A critical flaw is that most of the "solutions" mentioned assume you're all working at the same time. (Skype, G+ Hangouts, chatrooms.) That may be ok for workers living in less expensive parts of America or the western hemisphere, but that certainly doesn't hold true for overseas workers, which is what Paul Graham is mostly talking about with immigration.

An 8-12 hour timezone gap is not something easily bridged by chatrooms and videoconferences. To even have a conversation with the remote worker/team, one or both of you need to schedule time at very early or late hours and even then you only get a little bit of overlap. For the most part you are left to collaborate by email or blogs -- which is a significantly degraded way of collaborating, much moreso than just not being face-to-face. Without an easy way to have a realtime conversation, closing the loop on an issue can take 24 hours.. or several days if there is a lot of back and forth.

This style of working can be very difficult in a highly dynamic, less structured, fast moving startup environment. It is not magically solved by "modern communication tools" or high-latency asynchronous working styles. The fundamental issue is.. daylight and human sleep schedules.

I wish all conversations about remote work would qualify which context they're talking about -- near or far timezones -- instead of just lumping it all together as "remote work from anywhere".

I've worked both onsite and remote as a software dev / data engineer. I started out onsite. There are major disadvantages to remote work:

* Amount you learn from the office community is orders of magnitude lower than onsite. If you're good at pushing yourself to learn new things, that can help, but your knowledge will almost certainly end up less diversified living remotely. You're just not exposed to the company's tech challenges as deeply, yet that's usually one of the main reasons for working at the company.

* You don't necessarily get top projects, but rather perhaps good projects that fit remote work. Taking a remote role almost certainly hurts your career if you want to compete with traditionally onsite roles.

* You likely don't get to participate in hiring or shaping the culture in a substantial way.

* You'll have a much harder time building the network needed to get access to key resources (e.g. data, people, etc).

* Your company better have a nice VPN or you're going to be doing a lot of systems-oriented stuff for yourself. It can be fun but can slow you down.

* You're probably more likely to be laid off.

The company I worked for started offering remote much more frequently due to recruiting and retention problems. I don't think the net result had a very positive impact on the Eng org. In particular, a lot of junior people were allowed to go remote for retention reasons but they didn't end up doing much in that role-- they would have been much better off just joining a different company (either local to them or one with a much much stronger remote culture).

Agree with the poster that PG's essay has some holes; seems orders of magnitude less polished than his older essays.

Downvotes because I insulted pg or because I argued remote was bad??

This is a great how to article on remote management. The tools he lists are all there. The author mentions Skype, Slack, G+ Hangouts, and then surprisingly WordPress. Would the author care to discuss how he specifically has used WordPress to remote manage a team? I think the issue is that most managers don't want to remote manage which makes me wonder, "Why?"

I worked for Mullenweg for a year at WordPress.com to write a book about all of these questions. It documents all the tools I used and what life was like as a remote manager of a development team.


You can read a free chapter about culture from the book here:


Do you recommend this book to understand remote working dynamics at Wordpress ? Learning from companies that succeeded in setting up the remote working practice is definitely the best way to understand if you can put the process in a bottle. Anyway thanks for sharing this title.

The direct answer is most managers have no experience managing remote workers. Certainly that's not the entire story but it's a new way of working and many organizations reject it for its novelty without understanding it's advantages or what investments have to be made to get them.

It's all been tried and people know the tradeoffs, and there are tradeoffs no matter what you might think. The drive and culture that can develop when a small focused team spends every waking hour together can become almost cult-like. This culture is what VCs want to foment. It's also why they like hiring 22 year olds that can be more impressionable.

Under jasode's thread, you can see that people are missing Paul's point. He's not saying that working with close proximity is the "best" way of working. Yet most people here are debating which type of work is. Each company, market, vertical, team, etc. will vary in manifold ways.

What I believe Paul is asking for is that companies have the option to choose. Right now the option is available to anyone to hire remotely in one way or another. This is not the case with physically hiring into the country. Almost every startup I've worked at has had issues trying to hire exceptional people from another country. In almost every case, we lost those hires to the system and were forced to start the search again.

If a small, remote, international startup grows fast enough and they decide that working together under one roof in the U.S. fits their new needs, they should have the freedom and choice to do so.

The topics of remote work and of immigration reform seem unrelated to me.

A better immigration system would be better for the U.S., in that it would allow the best programmers to come here if they want to. That is clearly better for the U.S. as a whole, since it would make it easier to raise the national technical talent level relative to other nations. These new Americans would hopefully become citizens, raise families, vote, sit on school boards, run for elected office, start companies, etc.--improving the nation from within over time with their perspectives, talents, desires, and hard work (as past generations of immigrants have).

Contracting with foreign workers through the Internet does not achieve any of those long-term national goals.

Once new workers are legally within the U.S., I agree that they should have the freedom to choose remote work if they want to, or colocating work if they want to.

Paul Graham is deferring to his portfolio founders' words and actions. Does author believe all these smart and highly incentivized founders are wrong, too? I hope he realizes how strong that claim is and that by doing so he should accept the burden of proof.

I would love to have remote work, but I am honestly unsure about whether I'm good enough at my job to enjoy it. My concern isn't with performing my current job, but every promotion/job change I've had has been because of the things I learned in some free time from somebody sitting next to me. It's so nice to be able to wander over to a smart person and ask about some random problem I've been having in an area in which they're an expert. I have no doubt I learn more in an office than I would in my living room.

...then again, that's probably why remote workers say they're more productive.

The problem with this argument is that it lumps all versions of "Remote" together, but that's not really true. There's a huge difference between the guy who is remote because he has a long commute, vs the guy who is remote because he lives on the east coast, vs the guy who is remote because he's in china or london.

The common theme of all that is: timezones matter a lot. It's hard to collaborate with someone really far away because they'll tend to be asleep when you're awake. Programmers like async communication for a lot of reasons, but real-time is important too.

I would be interested in reading a PG essay responding to this very point.

Meh. Keep the barriers high and the labor market tight for as long as possible. Let companies compete for workers like the good ol' days. Let startups use more of that VC cash on its workers and also help keep rates up for IT workers across the country.

I know we Yanks get no sympathy from the rest of the world, but labor here has taken a beaten long enough.

And, I say this as a dev-turned-founder who would presumably now want to see low rates and a bigger pool. I guess I just appreciate more a little "economic justice" from time-to-time!

Let us assume a company where everyone works from home and meetings are held in Starbucks or airport lounges. Such a company would save many thousands of dollars per employee per year, maybe tens of thousands. No real estate, no receptionist, no cleaners, no equipment to buy or IT dept to support it...

Such a company would probably pay less than market rates, due to the "perk" of allowing remote work? But where's that money going? If you are an engineer considering remote working, make sure YOU get a slice of the pie.

It is clear various tools can be effective or ineffective for companies and individuals – this is a very subjective topic. However, since many tech companies, who have subjectively decided they want to have all of their employees in the same physical location, have a talent shortage problem, it would seem only beneficial to modify our immigration policy to allow more of these highly skilled individuals to work in the US. There outcomes of making such changes are almost exclusively positive.

I was part of a virtual team many years ago, before all these tools existed. I was the only one on the West Coast, not in a position to meet others face to face -- at least not more than once, for a conference I attended -- and was the newest to the group, younger than most of the others, etc. There were several dimensions in which I was an outlier for the group. Ultimately, it ended on something of a sour note. I was basically accused of being a "traitor" for doing my actual job. I and the person at the top had very different ideas about how things should be handled and my domain expertise was not really respected. (After my departure, the project that had benefited the most from my input kind of died back down again.)

I spend a lot of my time online and I have taken a lot of online college classes. When I had a job at BigCo, I got in the habit of emailing my questions to my immediate boss, whose role included answering technical questions. For various reasons, I was unable to master the art of catching her at her desk or whatever. Emailing worked better for me.

I and some of my teammates got transferred to a new team that initially did not have someone in the technical role she filled. Until the new team got their own technical lead, we were all still assigned to our old lead. Other teammates of mine who were used to having face-time with our lead were incredibly frustrated. My transition was quite smooth. I rarely needed face-time with her to get good results. I just continued emailing my questions as usual. I also was not particularly "likable." I was quite ill at the time and not at my smoothest socially. I also just come from a more formal cultural background than the people I was surrounded by. I was not interested in being too schmoozy. In the short run, this seemed to hurt me a bit. But once I got transferred to a new team, it was to my benefit: Getting my questions answered had been a purely professional function, not something rooted in being friendly or whatever.

So I think there are good points on both sides of this argument. I see several really good comments here falling on either side. And I think the disconnect probably has to do with some social thing that can be fostered remotely but many people aren't good at it. As we develop more online/virtual/long distance cultural practices, I think this will become less of a divide for some people.

Great points. I'm actually working on a longer piece with actual numbers as a follow up to remote working as a solution to the talent "shortage".

Just to jump on the point of being physically co-located: I've done both. There are pros and cons to each. What I've found is: it all depends on the people in the company. Some work best when they're right next to you, able to share a drink after work to decompress. Others want to run to the beach to go surfing right after a meeting. Both can be equally talented, but vary significantly in their modus operandi.

For entry-level people, I've really found an office helps with mentoring and culture assimilation in a way that fully-remote cannot even remotely reach.

I still don't feel there's any reason you need to physically exist in the Bay area though. Open an office somewhere that's both attractive and affordable for people to live and you enable the best of both worlds.

If my business pays for a great programmer, I want that programmer's knowledge, experience and attitude to diffuse to the rest of my team (... not that I have a business, just sayin' :-). Much harder to do this if that great programmer isn't in the office.

None of those things actually require physical proximity. It might take a little more effort to get right, but there are a lot of great programmers out there that don't want to relocate (or be tied to an office) and some of the might be worth it.

In my eight years' remote working experience, your statement is false.

What he is saying is that it is harder, not impossible.

Are you saying that remote work is as good if not better than being physically-located?

I'm saying that's it's not harder. Thus his statement is false.

In my thirty years experience in IT, my statement might be right.

How many years working remotely?

I’ve written an article on this issue recently as well.


The next question is what happens to people who want to work in the US?

This is my inspiration to create https://github.com/lukasz-madon/awesome-remote-job/

As I work remotely, it is the best. I think it is up to the individual. If the individual does not want to work, he or she does not want to work regardless at home or at the work place.

The author is forgetting that this is very unattractive for remote developers. Maybe not so bad if you live in a country without decent health insurance and retirement, but for others you'd lose these benefits by becoming a contractor.

EDIT: being more explicit I was specifically thinking of remote workers from other countries when writing this statement. Obviously, remote work within the U.S. wouldn't make you a contractor. But how would this work for non us-citizens?

Getting SF type pay in a place with rural US type cost of living makes it quite easy to afford decent health insurance and your own personal retirement savings. Not everyone can be a contractor, and there is a lot more planning and responsibility with managing the larger pool of money yourself and getting the key things you need, but saying it's very unattractive is extreme. In fact, I'd be more comfortable with funding my own retirement by setting aside money out of higher pay than hoping the government is in a financial position to make good on it. I've seen a lot of aggressive reductions of pensions in the past 10 years and for people taking lower pay to get those pensions over a lifetime of work it's been grossly unfair and life altering. At the same time they are nearly powerless to do anything about it, if it's your money it's a little more stable (assuming you don't have it in the bank of an unstable country that could seize it).

From my perspective "living in germany" it would be very unattractive unless I were to earn substantially large sums. I would never be eligible for german retirement, would have to purchase the more expensive private ensurance, and would lose a lot of what I've paid in until now. So that is what I would stand to lose.

I definately see how looking at from within the US this could be completely different, and there you make many valid points.

So self employed people in Germany cannot set up their own company and pay the social security tax that way and build up an entitlement to benefits?

Would take me less than a week to do that in the UK for a PLC.

I think this would be possible, but then again it would also mean you the employee would have to setup your own company to be able to work remotely for another one, and although the UG cost only 1 euro to start, you need to set aside 25% of yearly earnings until obtaining the base 25k for ensuring your newly founded company (GmbH). So this means a lot of hastle for what? The remote companies would need to offer serious perks to get people to jump through all these loops.

Move to the UK and set up a PLC here would be one solution - I did not realise that self employment was so hedged around with red tape in Germany.

Excuse me for being completely ignorant of this kind of thing, but why does working remotely automatically mean you are a contractor? Is it not possible to work remotely as a normal employee?

Perhaps there needs to be a distinction between remote workers elsewhere in the US and international ones as well. I imagine there are many talented developers elsewhere in the US that don't want to live in SV.

Presumably you would have to set up and run a subsidiary in the country

The article didn't say anything explicitly about remote contractors. The two companies it did reference Automattic and Github have remote full time employees.

Another commenter in this thread said that Automattic workers outside the US and Canada are contractors:


How does github do it then? Wouldn't said company need to be registered in the country where the employee lived full-time and worked? Otherwise how are taxes, insurance, healthcare, etc going to be handled?

Remote workers present challenges.

Which is worth more a company with 5 employed engineers or 5 oversea contractors?

Managing developers across time zones can be a big problem. If the developer in the Ukraine has a question for a manger asleep in California, he has to wait.

There is no casual connection between people - no going to a bar to talk things over, no stepping away from the computer to talk. All communication is filtered down through the pipes.

The larger point of this discussion is that mass immigration presents other challenges, some much harder to overcome. For example, the nightmare that is the political discussion of immigration in the USA, and for another example, the skyrocketing living costs in US cities that are tech hubs.

Trying to solve the problems you outline seem to be technical, which are easier than the fundamental problems of politics or economics.

> Which is worth more a company with 5 employed engineers or 5 oversea contractors?

This is a false dichotomy. You could have 5 on-site contractors or 5 overseas employed engineers.

(However, the rest of your post contains very valid points.)

I read the PG article as a "grass is always greener" argument.

I just read the footnote:

[1] How much better is a great programmer than an ordinary one? So much better that you can't even measure the difference directly....

You do not get to hire those people. And if you do it's on their terms. Perhaps you get to invest in their ideas if you're lucky.


> In a region that prides itself on disruption and working from first principles, San Francisco’s scaling problem is pretty humorous if you look at it from the outside: otherwise smart and inventive founders continue to set up offices and try to hire or move people in the most overheated environment since there were carphones in Cadillac Allantes

This is the best rebuttal to the more-immigration-so-we-can-haz-programmers I've read in a long time. And its so true. The way the current work visa (h1-b) is setup makes it far more likely that good programmers get tied to stodgy plodding firms and not smaller innovative ones that tech needs them to work for. Remote work and rewriting the current h1-b laws to make it so that h1-bs can more easily transfer their work permits and work for whoever they like, whenever they like ... remotely as well ... just like their American contemporaries would open up lots of supply.

but what the big firms really want is more pliant programmers who will work within the rigid confines they set up. Thats why we're not talking more about the mechanics of the work visa and the green card process which is currently set up pretty restrictively.

Oh dear sorry to rain on your parade experience shows that the way to get the best performance is collocated teams of developers ideally coloacted with the end customer.

I know this isn't what a lot of HN readers want to hear but I bet Paul and many other VC's would bear me out.

Do you actually have data on this, or is this completely anecdotal?

30+ years of experience also read steve McConnell.

Sounds great, as long as you're only interested in selling to the Bay area I guess.

No based on experience building the control system for the UK's core TCP/IP network for one example.

Hey Matt, I'm so glad you felt it necessary to include that DHTML snowstorm. My laptop fan really needed the exercise and I have your ~500-line JavaScript workout to thank for it!

Of course, I closed the tab pretty much immediately after noticing it so I didn't read the article. Can't wait for unnecessary js to go out of style.

As soon as I saw the snowflakes falling, I thought, "Oh jeez, someone on HN is going to be having a meltdown over this!"

Sure enough.

You should check out NoScript if JavaScript is SUCH A BIG DEAL for you.

enjoy the downvote

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact