Hacker News Reader

Comment by gregkerzhner | Hacker News Reader

Real time, remote communication through tools like zoom, slack, and lucidchart (in my humble opinion) has been solved. It might take some getting used to, but in the right environment a group of properly motivated individuals can achieve the same productivity as their peers in a conference room.

Asynchronous communication across timezones has not been solved, and I struggle to see how it would be. A lot of collaboration requires a conversation and instant feedback from another party. You can't collaborate like this when there is a delay of 8 hours instead of 8 seconds between responses.

So "anywhere" is a bit of a stretch. That being said, absolutely this will happen across the United States. There is nothing that makes developers in San Francisco more talented than their counterparts living in Tennessee, so if those can be gotten cheaper, I can see how the overall price would go down.

Presumably though, such an effect would also cause rents and property values to go down in big cities. I can see how the natural evolution of such an idea is that wealth will be more evenly spread out throughout the country, instead of being concentrated in cities.

I still think the Facebooks and Googles will pay a lot more - someone has to be the "top dog" attracting the top talent. The question is, how much more?

View on HN

> Real time, remote communication through tools like zoom, slack, and lucidchart (in my humble opinion) has been solved.

Unfortunately, that's not the case.

Remote meetings can be far more frustrating and inefficient because of latency, total lack of turn-taking cues, inability to read emotional expressions of concern or worry on one person or to "read the room", emotional fatigue from lack of cues, and so on. And that's all assuming best-case scenario that your equipment and internet are working well. People pay attention less, speak up less, and so on.

Now, this isn't to say that remote communication isn't useful -- it's obviously far better than not having it at all. And even when you're in the office, many teams are distributed anyways across offices.

But remote communication and meetings have in no way been "solved". They still present elementary problems like when someone asks "who has thoughts?", there's 10 seconds of excruciating silence followed by four people speaking simultaneously, then another 20 seconds trying to figure out which one person will actually speak, where nobody wants to seem like the aggressive bully OR never get to speak.

It's really hard.

There's another side to this coin where remote meetings have some benefits. In my experience people tend to schedule fewer pointless meetings and are more likely to get the info they need over slack/email. I don't have to feel like I have to hide my emotional queues, like I can make a "WTF" face any time without fear of reprisal. I can even mute and say really fucked up things out loud to help me get through stupid things that are happening. Many shy people are more comfortable typing what they want to say into a group chat than they are saying it out loud, so in this way text based meetings can be more inclusive.

I suspect after an adjustment period that we'll reach an equilibrium similar to what we had before as far as effectiveness.

There is an interesting social phenomenon going on here which I think is often missed. The old world was designed around the preferences of the most extroverted people. Those people are losing that privilege, and I understand how difficult it must be. Honestly, I'm extremely introverted, and somewhat autistic, enjoy isolation, etc. So if this whole thing has bothered me a little bit, I understand it must feel like torture for someone on the other end of the introvert/extrovert spectrum. Hopefully we'll settle one a better medium that is more amenable to the median person than what we had before.

And there is one unspoken piece. Real decisions happen in person, and then may be just repeated via email for CYA purposes. Remote communication may be solved, but the reality of making hard decisions was not.

My hunch though is that virtual meetings don't necessarily add new types of problems to real meetings, they just highlight the problems which already exist.

If you have a meeting with 12 people, and most of them are not engaged, the problem isn't necessarily the video call, its more like the majority of those people shouldn't be in the meeting at all, and would just benefit from a written summary.

If you have a meeting where 4 people are jumping in to share an opinion on one topic, that sounds like too many cooks in the kitchen, not a video call problem.

From my experience with remote meetings, the ones that work the best are those between two or three people where everyone is informed and the subject of discussion is concrete. These kinds of meetings are just as productive as the real thing. The kinds of meetings that tend to not be productive are the ones that have a dozen people in the call, with a few people talking and the rest watching the clock until the hour is over. These kinds of meetings are a drag in the real world as well.

Yes, 1-1 or 1-1-1 remote meetings are not too bad, especially for 1-1-1 if you can view both other participants simultaneously and latency is not too bad (e.g. New York to SF, not New York to Japan.)

But my comments are assuming, say, a 12-person meeting that has to happen. For reviews/approvals of a project with 10 stakeholders, it simply has to happen. And I never said anyone wasn't engaged -- participants usually are.

And 4 people having an opinion is the norm, absolutely not too many cooks. Just think -- a small feature idea is presented for approval in order to start work, a designer sees a potential problem, the user researcher realizes a use case was left out, the engineer is worried about feature creep, and marketing doesn't know if it'll be easy to explain. All of these have to be addressed.

So I'm highlighting that even when everything about the meeting is necessary and otherwise awesome and productive, the limitations of remote participation can add substantial difficulties to running it effectively. And that in this sense remote meetings are in no way "solved" yet.

If one needs to read the room or care about facial expressions in one's meetings rather than believing and trusting one's coworkers' actual responses, one is a shitty manager / executive. The video part of remote meetings is equivalent to micromanaging work except now one's micromanaging the meeting. The goals and outcome are the same. Doubly so for anything involving building software as it's clearly possible and often desirable to work almost completely asynchronously for most tasks as much of the open source community does.

I worked at a company that had a New York office and a remote country office. People basically sat in a videochat all day long. I'd say it is more efficient, because you don't need to be in the room all the time, and you can do other things while people are talking about subjects that are not interesting to you.

I've worked for Swiss companies from the west coast of North America (9 hours difference). It's not perfect, but I started early and they kept an eye on slack until late. Most of the time we communicated in the couple hours of overlap we had.

It works because as a developer it's a plus to have multiple hours of good focus time with no meetings or interruptions. Plus we can cover each other for pager duty so nobody has to normally wake in the middle of the night.

I think remote work greatly increases the circle of people you're competing with. I don't recommend trying to be remote only unless you're world class - because the world is technically your competition.

That said there are lots of reasons most people in Vietnam or India are not actually in competition with me. Being able to communicate fluently in English and divine requirements from non technical people who don't know what they want is still the most important part of the job. You can be the best programmer in the world, but if you can't do that, you'll just build the wrong things beautifully and ahead of time.

Then there is the trust issue. People need to know they can trust you with their code, customers, and business. That's a challenge if they've never met you in person. It's a bigger challenge if you live in the developing world - maybe that shouldn't be true, but it is. I had more trouble getting jobs when I lived in Panama.

Ive been on projects like this as well (the other way though - working from Spain for clients in San Francisco). You can definetly make it work, but its far from ideal. As you go through your day, questions inevitably pop up outside of the overlap hours. If you have to wait until the next day to get answers, you either have to pause what you are doing and switch to something else, or continue under assumptions that might be proven wrong the next day.

Coming back to the states and being able to collaborate real time throughout the day was always a boost to productivity.

In my digital nomad days, the golden place for a client was always New York. This is because it would allow me to have solid overlap from anywhere in the states, and also good enough overlap in Europe.

Yeah, I'm used to having to switch gears into another task. I'm also used to getting very creative with finding a way forward when that's not possible (the site is down and I don't know what to do about it, and the only people who know are unreachable.)

I had a job for a while that I hated where I never knew what my task was. It would seem clear when given to me, but then I would start and questions would come up and there was nobody to clarify. So I'd have to go back to first principles and try to divine what they wanted me to do, and then execute on that. I was over the moon when I got a better gig and was able to leave that one.

> I think remote work greatly increases the circle of people you're competing with. I don't recommend trying to be remote only unless you're world class - because the world is technically your competition.

Another perspective, from a remote-only employee away from all the world's tech hubs: there just aren't that many local jobs to choose from. Remote work really makes it possible for me to have a job in this field where every other company is complaining about shortage of talent.. and I don't have to leave home & everything behind and move into a big city (I don't like cities btw).

I don't think I'm world class.

I've only worked remote, initially for the same reason.

But I think you're better than you assume, because you got the job out of a very large pool of potential candidates. By definition, you must've beat everyone who applied in that hiring round.

Which reminds me of the first rule of finding a job - it's just like dating - is a numbers game. Your chance of success on any attempt might be low, but then you just need to make enough attempts and the limit of P(offer) approaches 1.

Even remote companies can only consider so many applicants. In our last three job searches that number started at 100 or so, was whittled down using resumes to 40 or so who were whittled down to a dozen or so by tech screens and finally we interviewed less than ten. One hour interview followed by a take home for the top three. We chose one of the three. No stupid whiteboard. No long ass interviews. The take home was an hour or two at most and the people doing it knew they were finalists. We're a small company. A bigger company will have a bigger pool. The irony is, they won't get better candidates and if they have a shit hiring process, they'll get much worse. Other than problems with a couple of people's background which would have been immediately flagged had we done a proper check, our hires have been great developers.

> problems with a couple of people's background

What kind of problems with people's backgrounds did you find relevant to doing a developer job?

Trust, overlap of working hours, language, and culture are huge -- and often insurmountable.

Having dealt with Tata, Cap Gemini, Genpack, CTS, HCL, and a handful of smaller groups in the Philippines, I'd avoid offshore workers if at all possible. Would absolutely hire qualified Indians and Filipinos in the US, but outsourcing is dicey.

When I was at Intel, they had outsourced graphics driver development to Panang. Within a year they had created a large number of US jobs for folks who had to rebuild the work from Panang and validate/test/fix any new working coming back from Panang.

There is a difference between a cheap foreign engineer without formal training and a trained domestic engineer. Anyone who thinks every type of labor can be outsourced to cheaper labor markets has no understanding of the phrase "You get what you pay for".

Sure, the call center guy telling you to reboot can be outsourced trivially, move up the stack and you may be making a large fiscal mistake. This is discounting the much higher fraud rate attached with outsourced labor as well.

> There is a difference between a cheap foreign engineer without formal training and a trained domestic engineer.

IMO there's no difference between a trained domestic engineer and a trained foreign engineer. Foreign vs domestic isn't a meaningful difference.

However. Existing tech hubs got their cachet for having the best and the brightest, which in turn draws in the best and the brightest. Companies have to pay more for talent on average in hubs because the talent has self-selected for a high concentration of great folks.

That doesn't mean there isn't an assortment of great folks elsewhere who just didn't feel like moving, but IMO, more than likely, the majority of the great folks are already in tech hubs. I think the risk is overstated.

He didn't say there wasn't talented people elsewhere. The title says anyone can take your job, and he drew a line between looking globally to save money and getting what you pay for. You seem to be bringing up counter points to something that wasn't said.

Of course there's a difference. A domestic engineer needs great software development skills and decent communication skills. A foreign engineer needs great software skills, great English skills and an extra measure of communications skills to bridge the cultural gap without ever meeting face-to-face. Clearly one of these workers is more highly skilled than the other and would be harder to recruit.

> IMO there's no difference between a trained domestic engineer and a trained foreign engineer. Foreign vs domestic isn't a meaningful difference.

This isn't supported by the research. American university graduates have much better knowledge of computer science than their Indian, Chinese and Russian counterparts.[1]

[1] https://www.pnas.org/content/116/14/6732

I guess it depends on what you mean by a "trained domestic" engineer. The implication of your paper is "domestically-trained" i.e. the caliber of US universities is higher. "Trained, domestic" implies US person, trained wherever, and "trained, foreign" implies non-US person trained wherever.

For instance, is someone who moves to the US from Malaysia, goes to UIUC, then moves back to Malaysia a "trained foreign", "trained domestic", or "foreign, trained" engineer in your view?

Nuanced, but important, and might be why people are talking past eachother.

Fun fact, you can get good foreign engineers as good as any SF engineer but they also tend to be as costly as their US counterpart maybe slightly less do to lower living costs.

That's exactly my experience, the foreign talent on par with domestic talent costs about the same or close enough that outsourcing becomes much less attractive.

Exactly, in general you get what you pay for.

I would not say "SF engineer" = "good engineer".

There are excellent engineers in SF, but that's not the standard. It's the result of strict selection processes.

This is nothing but racism. Foreign engineers are no inherently worse than "domestic" born and raised. For proof, just visit any Silicon Valley company office. You will see nothing but foreign born engineers.

> someone has to be the "top dog" attracting the top talent

As I said in my comment, this is the big shift I would be looking for. The shift in the top dogs. The top dog could become a Chinese company snagging US expertise rather than the other way around. That could then create effects where US workers are applying to jobs abroad.

The real competition might not be positioning yourself as the talent. The real competition of the future might be attracting the talent. Once you get _that_ shift, then this conversation takes a totally different turn.

I can't imagine any of my US coworkers every working for a Chinese company. The non-zero chance of being sent to a 're-education camp' if you ever have to travel is a big concern

It's a BIG concern? Really?

No US worker is going to get set to a re-education camp for a 2-5 day set of business meetings in Shanghai. Bug your phone or capture all your internet traffic? Maybe. Arresting a foreign national working for a Chinese firm? Unlikely.

Anyone who is 'unreliable' enough for the Chinese government to arrest them isn't going to get hired by a Chinese firm -- doubly so because the largest firms in CN are state-owned.

> Real time, remote communication through tools like zoom, slack, and lucidchart (in my humble opinion) has been solved. It might take some getting used to, but in the right environment a group of properly motivated individuals can achieve the same productivity as their peers in a conference room.

What is not solved, of course, is how a remote-only employee can build trust and relationships with peers.

In my opinion that’s the reason a lot of remote work is working well right now. Everybody already knows each other.

Through projects? I'm working remotely and it's the same as in person. First few months is about everyone feeling each other out once you understand more you give people more trust in those areas.

First few months is often the duration of a project, especially for those working on a contract basis.

Remote and in person can reach the same level of trust and productivity, but I do believe that people reach that level faster in person as opposed to oddly forced zoom happy hours.

It might be false trust. I wouldn't use conversation to judge in person or remotely. Is what is commited into the repo after a week or two what I expected. Is what documentation was produced what I expected?

Agreed. Also - one benefit of going remote is you can more easily avoid anyone you dislike! So that's a win over the office.

This can also backfire when it's easier to avoid confrontation which if resolved would be a net gain for everyone.

Most confrontations can be resolved beforehand. The confrontation is unnecessary, take small steps to improve relations. Even a firing shouldn't be a confrontation it should be part of a process .

> What is not solved, of course, is how a remote-only employee can build trust and relationships with peers.

You're saying that trust can't be built virtually? I think there are online communities whose members would say they trust each other, and can collaborate and work together just fine. A lot of open source communities certainly work on this basis.

Besides, working remote-only doesn't mean occasional meetups or virtual events (gaming, etc.) couldn't be held to bring the team more socially together, but I don't think this is a requirement.

Of course, trust is subjective, so others will feel differently about what it takes to establish it for all involved, but that applies for physical communication as well.

Trust can be built virtually, but it requires large and conscious effort, whereas in person most people who work closely will automatically develop trust.

I don't think that 'Tennessee' is the correct spelling for Shenzhen. The low cost of living states in the US are still expensive compared to low cost of living countries. There is engineering talent around the world, and I don't see how the rural parts of the US are going to compete with more urban populations in other well educated parts of the world.

Anectodal, but I spent a year on a recent project collaborating with a group of firmware engineers in Shenzhen, and it was an absolute nightmare. Apart from the timezones, the code quality was horrendous and basically never worked correctly. They also ignored all common standards, and made assumptions about things like ordering of fields in JSON. None of their engineers spoke english, so code communication had to go though the project manager who wasn't technical.

I can see how english fluent Mexican, South American and Canadian employees will be in competition - this is already happening, but I think that China might be one of the last places I would higher a developer due to the huge time difference and their poor english speaking ability.

You probably got what your company paid for.

My company has an office in Hyderabad India. My experience is that a US-equivalent developer in India isn't actually that much cheaper, and when you weigh the timezone disadvantage it may not really be worth the hassle.

We still have a thousand developers there and we pay $2500/mo for each of them. There are plenty of nice people, and a few rockstars, but on average this money doesn't buy top talent in India.

Are SV based companies getting what they pay for?

I’ve worked with Chinese developers and their English and programming skills were fine. Just check for English language skills in the interview if it’s important to your company.

Personally I think that non technical project managers are the bigger problem, remote or not.

I wouldn't higher a developer due to their poor English speaking quality either.

There are around 5 million software developers in China. Are you really sure it makes sense to assume that they all suck?

I'm sorry but that is a silly prejudice. You worked with one group.

China has the 7th lowest english speaking rate in the world. I doubt that they are going to be a large outsourcing hub to English speaking people any time soon. If you speak Mandarin though, its a great place to hire cheap developers - just look at Zoom.

He said they were all bad developers.

Offshoring has been a thing for years, we already know how it plays out. There are distinct disadvantages, and a lot of companies have been bringing development back into the US as a result. My company is one of them.

If you really want offshoring to work, you at least have to move 100% of your development staff overseas. Really you need to move 100% of your engineering altogether, and maybe a good chunk of your leadership as well.

Tennessee has a huge advantage over places like China and India simply due to communication. Language fluency, cultural similarity, and a low timezone offset all very much contribute to a successful team.

Actually if you look at cost of living data, the USA is in quite an interesting position. It contains both some of the most expensive and cheapest cost of living in the developed world. Salaries in some areas are some of the highest in the world, and in other places are closer to Eastern Europe or South America once you've accounted for things like taxes and healthcare. There's a seriously huge gap in pay when looking at Rust Belt Ohio vs the Bay Area.

Two kids go to school at Ohio State in the same program. One moves to SF and makes 200k right out of school. The other stays in Ohio and has a starting salary of 55k doing similar work. I don't think you need to worry about the Chinese coming for your tech jobs. In a remote world, the Buckeyes will get there first.

Exactly. Although if the Buckeye was motivated, he could currently get a remote gig and make 100k. It wouldn't be SF rates, but it would still be higher than the local shops. It will be interesting to see how such arbitrage gets affected by more remote companies entering the field.

It will be interesting since I am the "motivated Buckeye" and selfishly, don't want the arbitrage opportunity to go away.

Those salaries are not correct for either location.

> Asynchronous communication across timezones has not been solved, and I struggle to see how it would be.

I disagree, at least if we are talking about what tools to use. But many people who are used to being face-to-face aren't used to async. Async communications require patience, foresight, and good writing skills. You need to envision the end result of the collaboration, provide as much of your perspective as possible without writing a wall of text, and ask good questions. Then, in 8 hours, your coworkers do the same. And over a few days, consensus arrives.

Easier said than done, I admit. It takes time and deliberate practice to do this well. It is not how people are used to collaborating. But that does not mean it doesn't work - it means people only succeed when they put in the effort learn new communication skills.

Patience, foresight, and good writing skills don't solve the fundamental problem that a consensus in 3 days is less valuable than a consensus in 30 minutes. Any long sequence of consensus-based decisions becomes infeasible in the asynchronous model.

You may be trying to make all scenarios fit the same model. I did not mean to imply that. When you need quick answers, get on a video call and get real-time answers. When you don't, go async. Knowing when to use each method is again just a matter of learning communication skills.

As you improve, you'll also find that the urgency of decisions often isn't what it appears to be. That is where the patience comes in. If you truly constantly need consensus on problems within 30 minutes to prevent your business from crashing, then I'd suggest your organization may have deeper problems that need resolution.

> When you need quick answers, get on a video call and get real-time answers

Having worked with a distributed team (13 hours time difference) working on the same product under the same deadlines, it's not possible to just hop on a call because e.g. someone accidentally changed a config on a development API which I don't have direct access to because it would knock us out of SOC2 compliance. This is an issue which needs to be resolved immediately and blocks any further work on my end, which means I can't do my work until they wake up and get into the office.

> If you truly constantly need consensus on problems within 30 minutes to prevent your business from crashing, then I'd suggest your organization may have deeper problems that need resolution.

When you're overextended, working under an intense deadline to deliver a product to a client, tight turnaround is absolutely necessary. In theory all of this could be fixed with proper management, but small- to mid-size startups don't usually have the time or resources to do that.

>I still think the Facebooks and Googles will pay a lot more - someone has to be the "top dog" attracting the top talent. The question is, how much more?

They will pay more. But Facebook has already announced they'll readjust salaries to people who work from home in lower COL areas.

That’s not quite true. They said they’ll adjust salaries according to the “market rate” of the location they’re hiring in, which doesn’t always line up with cost of living.

This sucks for people living in London, for example, where developer salaries are low but the cost of living is high.

>Asynchronous communication across timezones has not been solved

True, but the workaround is I'm willing to adjust my work hour to fit my team. In a big city, life can still be 'lively' during the night.

> Asynchronous communication across timezones has not been solved

The company I work for has offices in Europe an throughout the US and Canada. We span 11 time zones, and we are absolutely able to make it work. My team has 7 people and only 2 are in the same office.

The trick is to have multiple communications channels, good collaboration tools, and to hire excellent communicators.

I agree from experience that straight outsourcing, where you throw a language barrier in with the time zone issue, is not a solved problem, but purely working across timezones is very doable,

> Asynchronous communication across timezones has not been solved, and I struggle to see how it would be.

By focusing on excellent written communication.

Great written comms is hard, and (like coding) requires lots of deliberate practice and training.

Most people and companies gloss over this, but it makes a world of difference if you're operating across time zones.

Great internal writing is what separate the great companies from the average.

No. Not even for a second.

Suppose you have two engineers, one in America, one in India. PRs cannot be merged without an approval. Suppose the average PR requires 3 back-and-forth comments before it gets merged.

In the same timezone this gets merged in an hour. In a different timezones its days.

> There is nothing that makes developers in San Francisco more talented than their counterparts living in Tennessee

I think there's more to this. There's a "network effect" of living in a place like SV. I felt that the bar was much higher in the West Coast due to the high density of companies and talent attracted.

Reply on news.ycombinator.com