Hacker News Reader

Comment by elguyosupremo | Hacker News Reader

This piece goes from talking about meta layoffs to an indictment of remote work surprisingly quick.

I love remote work, because I grew up in a small city with no companies operating in my industry and when covid hit I was able to go full remote, move back home, and be around my friends and family while contributing to my company and to my local economy.

The biggest thing that has helped my dev team thrive and be able to onboard new members is mob programming (https://en.wikipedia.org/wiki/Mob_programming). We have our own take on exactly how we do it, but the gist is that all our software engineers are in a video conference with each other as much as possible and focus on a single task.

We're starting to add new members in timezones that are 5+ hours offset from the rest of the team and that integration is proving to be hard. If anyone has advice on building TZ-distributed teams I would love to hear advice!

View on HN

>To me, although I’d certainly concede that WFH pares down meeting culture and certainly has benefits in logistics, it’s always been fairly obvious that in-person collaboration is more effective, produces a much stronger culture, and I suspect is important especially to larger orgs because it helps to even out performance.

The anti-WFH screeds are always nearly indentical: extremely vague and non-quantifiable in a way that makes them technically impossible to argue against. I can't argue against the idea that they produce a much "stronger culture" I guess because how would anyone even begin to prove that one way or another? We probably couldn't come to a consensus on what that even means.

If coming in to the office had the positive impact pro-office people said it did I promise you that by now, 3 years after COVID lockdowns started, someone would have managed to put together some actual hard data instead of the same "culture", "watercooler ideas", "ad hoc collaboration" nonsense we've been seeing constantly since then.

> extremely vague and non-quantifiable in a way that makes them technically impossible to argue against

this is why it's a shame people are ridiculing Zuckerberg's post ... they actually did quantify it and actually did come up with some nuanced insight into what works well and what doesn't and he says they are going to keep studying it to learn more.

To me, it seems like there are two tenets to this. (a) remote / distributed anything is hard. but at the same time (b) remote / distribute anything is powerful. Do it well and you will have enormous advantages that your competitors, shackled to their mere physical earthly pinprick of a location on this planet can never match.

Which is to say, it's actually worth trying to do well and I respect that Zuckerberg has taken this more nuanced approach to try and get there.

They didn’t quantify it. The made an assertion that people who started in person at Meta were more productive than those who started remotely, but there was no data provided to back the assertion up. What’s more, we have no way of knowing if that assertion is valid. The majority of people who started at Meta in the last few years would have been overwhelmingly skewed to remote, while in-person starts would be skewed to those from more than a few years ago. How are they comparing these two groups? Are the actually comparing the productivity of in-person vs remote, or are they unintentionally (or intentionally) comparing the productivity of people who have been at Meta for >3 years vs those with <3 years. They didn’t provide any kind of data or quantitative measures at all, and they fall into the exact category the person you responded to is describing.

> We have our own take on exactly how we do it, but the gist is that all our software engineers are in a video conference with each other as much as possible and focus on a single task.

This is a pretty fucked up way of working. People can't get anything useful done if there is a mob of people on a zoom call. It's just a talkfest or more likely an opportunity for 1-2 people to dominate the conversation while the other folks tune out.

Even pair programming is a ridiculous waste of time a lot of the time, but this 'mob programming' seems to multiply the waste while achieving nothing much more useful than pairing. At least with pairing, the two people involved are building a relationship.

I've found it to be quite the opposite. It's also important to note that mob programming recommends rotating who is "driving" the session, so we change who is sharing every 15 minutes.

I don't think this approach scales to more than a team of 4-6 people but we've been able to forge strong bonds on our team, solve complex problems (in domain definition, actual code, ci/cd issues, and more) in ways that the entire team feels are appropriate and while also keeping the whole team abreast of all the changes. We get far more done than we used to and we've successfully onboarded several new team members.

I think the trick is that instances of being stuck will tend to zero as you get more brainpower at the problem, or even the watchers spotting mistakes. And what I love about pairing is the code review comes for free. I hate being sent 1000 line change PRs blind :-0

> If anyone has advice on building TZ-distributed teams I would love to hear advice!

You won't love to hear it, because the general way to handle large TZ offsets it to make work async, and it sounds like "mob programing" as you do it is quite sync.

What I've seen work is strong document culture - write docs, leave comments, etc. Have clear expectations on deliverables from the start ("this doc will design service X, impl can start when 3/3 senior engineers approve design by leaving an "I approve" comment). Everyone does their thing, and you don't need to be talking to someone to do it.

> mob programming

That sounds... horrendous. I really enjoy "pairing" when chasing down bugs, but doing that when trying to write new features would be nigh-on impossible.

I was really skeptical at first, but we've been doing it for over a year now and I've come to thoroughly enjoy it. I find that I get stuck on issues much less frequently because I have other people to talk through them, knowledge transfer is inherent, and when you have multiple people writing and reviewing the code as it's written PR reviews become basically instant and you can deploy much faster.

I'm thinking of it more like team practice in a sport - it sounds like a way to get some team cohesion and pass around some knowledge in a group setting. You aren't going to be doing this all the time but it doesn't sound like the worse thing to do for an hour - people aren't exactly going to lunch together when remote.

For an hour, sure. But it sounds like the GP was saying this is how they work 9-5.

Ohhhh. Interesting.

The problem w mob programming is that measured purely on a man-hour cost it sounds extremely stupid and expensive for a company. It has always sounded to me like a hare brained idea that a dev shop came up with to sell more man hours per feature delivered.

Depends - I have seen enough throw a mythical manmonth worth of developers at embarrassingly unparallelizable work and watch the tech debt pile up like it’s a 2007 mortgage bubble. And that code then trips people up day after day as more features are added.

> We're starting to add new members in timezones that are 5+ hours

I am all for remote work, but large time zone differences is a massive hurdle to proper remote collaboration.

The only way to smooth it out in my experience is with a decent documentation culture (not only one that gives incentives for documentation to exist, but also for it to be kept up-to-date).

On places with only tacit knowledge that spreads around through communication (and those can very well happen through slack, screen shares and so on), it becomes hard for the people that are seldom working at the same time as the "main team".

Like 5 or 10 developers try to add a css button? Fight breaks out over a ternary operator.. most annoying person wins? You can have too many cooks in the kitchen.

I don't think it scales much beyond 4-6 developers, if you have bigger teams than that you could try a couple of sub-mobs.

WFH is very good and convenient for the _worker_! It's great being at your small town, or beach at Bali, or your favourite coffee.

I just don't think it's very good for the company and for the overall productivity.

This is one of the reasons I have become an advocate for mob programming, I think it allows people to have a best-of-both-worlds kind of experience; allowing the flexibility of remote work while facilitating the direct collaboration of in-person work.

Meh. Could say the same about weekends, right.

Reply on news.ycombinator.com