How Paul Graham Is Wrong

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.

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

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.

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.