Workers quitting over return-to-office policies • Hacker News Board

Re: Workers quitting over return-to-office policies

#181

Post by madmax108 » Mon, May 30, 2022, 7:25 PM UTC

db48x wrote: post #179

Fire-Dragon-DoL wrote: post #129

Earlier quoted context omitted.

How do you handle brainstorming sessions or design sessions where things are hard to solve, so there is no direct answer? I love the idea of async, but there are just some sessions that are incredibly valuable and develop on others thoughts, evolving in a final solution. At the company I work at, we compromise with a specific 4 hours overlap so that meetings can be scheduled only during those times

It seems that there is decent evidence that a group meeting that tries to come up with new ideas does worse than if the same people did so individually, and only then had a meeting to present their best ideas. And by “does worse” I mean that they come up with fewer good ideas, even when they are quite confident that they have completely explored a problem. Personally I doubt that having face–to–face meetings is ever…

> It seems that there is decent evidence that a group meeting that tries to come up with new ideas does worse than if the same people did so individually

Links to any research on this? Anecdotally (about a decade working across different sized orgs in various roles from IC to Staff Engineer), this simply does not pass the smell test for me.

Re: Workers quitting over return-to-office policies

#182

Post by db48x » Mon, May 30, 2022, 7:45 PM UTC

incrudible wrote: post #169

db48x wrote: post #87

Earlier quoted context omitted.

A feedback loop can be tight, or high–bandwidth, without having low latency. You just have to increase the sending window. Either that, or delegate more. If your designer tells you to implement X, and after that is done tells you to do Y, have them increase the sending window by telling you to do X, Y, Z and W up front. Then, when you implement W and it doesn’t feel quite right to you, you can implement W’ instead; t…

That is not a solution. You do not get to just decide on whether latency or bandwidth is the bottleneck of your task.

There’s no law of physics saying that a company cannot delegate decision–making authority to individual employees. If your employer doesn’t let you make that kind of decision, then that is a social problem rather than a physical one.

Note that I have not said that an individual employee can decide how their employer does business, only that your development processes can be arranged so that they do not require low–latency in–person meetings between employees. You can do your business with or without any overlap in working hours between employees that interact with each other; the overlap is not required.

Re: Workers quitting over return-to-office policies

#183

Post by db48x » Mon, May 30, 2022, 7:46 PM UTC

madmax108 wrote: post #181

db48x wrote: post #179

Earlier quoted context omitted.

It seems that there is decent evidence that a group meeting that tries to come up with new ideas does worse than if the same people did so individually, and only then had a meeting to present their best ideas. And by “does worse” I mean that they come up with fewer good ideas, even when they are quite confident that they have completely explored a problem. Personally I doubt that having face–to–face meetings is ever…

> It seems that there is decent evidence that a group meeting that tries to come up with new ideas does worse than if the same people did so individually Links to any research on this? Anecdotally (about a decade working across different sized orgs in various roles from IC to Staff Engineer), this simply does not pass the smell test for me.

I was looking for my copy of Peopleware where I first read about it, but I cannot find it. Perhaps I loaned it out.

Re: Workers quitting over return-to-office policies

#184

Post by db48x » Mon, May 30, 2022, 7:54 PM UTC

Fire-Dragon-DoL wrote: post #180

db48x wrote: post #179

Earlier quoted context omitted.

It seems that there is decent evidence that a group meeting that tries to come up with new ideas does worse than if the same people did so individually, and only then had a meeting to present their best ideas. And by “does worse” I mean that they come up with fewer good ideas, even when they are quite confident that they have completely explored a problem. Personally I doubt that having face–to–face meetings is ever…

I'm not convinced by this. It works but for a subset of problems, not all of them. And it overlooks the fact that people might build on top of each other, I don't think that was taken in consideration. What about exploratory meetings, where people are trying to understand a problem in the first place, those happen to be synchronous because answers evolve in other questions. Keep in mind that I never mentioned face-to…

“Face–to–face” here covers any type of video conferencing, telephone calls, or even text chat that is happening in real time. As you said, these are synchronous interactions instead of asynchronous interactions.

> And it overlooks the fact that people might build on top of each other,

In the research that I read, the researchers came to the conclusion that most of the meeting time went to building consensus instead of actually thinking of new ideas. Some subset of the people in the meeting would be charismatic enough to dominate the discussion, and everyone else would contribute less than they otherwise would have.

Re: Workers quitting over return-to-office policies

#185

Post by lamontcg » Mon, May 30, 2022, 7:58 PM UTC

shakezula wrote: post #160

lamontcg wrote: post #156

Earlier quoted context omitted.

Uh no, I mean the doctrine of code review in general needs to be put on a diet. I'm definitely opposed to everyone sitting around synchronously nitpicking everyone else's code in enforced meetings, but I wasn't considering that. Onboarding new devs is where code review and pair programming is obviously useful. And honestly I've seen it go both ways, where onboarding a new dev was an opportunity for the old veterans t…

> looking at a PR by a dev who has been around for a long time This is precisely the case where I think you need code review the most, because in my experience, time makes people complacent. Code review is peer review, the key agent of the scientific method. I just can’t abide a process that doesn’t include peer review. > Donald Rumsfeld's unknown-unknowns. are an excellent reason to have others question your code. C…

Well, as someone who had a decade of experience with the codebase I absolutely submitted PRs which were largely unreviewable because nobody else had that level of experience.

My safety net wasn't code review it was writing tests, and actually firing up the product and determining that it worked (which a large amount of people actually never bother doing, and I'd prefer that over code review any day).

In those cases we'd do some knowledge transfer, but I can't turn someone into a veteran with decades of experience in an hour or two of code review. I'd actually be happy to do a week of knowledge transfer on the issue and treat it like a PhD dissertation defense (which is about what they were sometimes), but nobody else would want to commit that kind of time, and no manager would want to commit the team to that kind of time.

And for knowledge transfer what usually works better is having more junior members of the team doing work on subsystems and guiding them through it. Even if it isn't peer review or pair programming, the iterative process of them hitting walls and asking questions is generally the best learning. That works better because they go off and commit the time to struggling with the problem, and then guidance has that platform to build on top of.

And you don't understand unknown-unknows... You can't address that by code review or knowledge transfer or peer enforcement, because it is all the absolute unknowns. A healthy skepticism can help prevent risky changes, but at some point the bugs that get through are often completely out of left field that literally nobody could have foreseen. There is no perfect process that can prevent those kinds of defects.

Re: Workers quitting over return-to-office policies

#186

Post by incrudible » Tue, May 31, 2022, 7:53 AM UTC

db48x wrote: post #182

incrudible wrote: post #169

Earlier quoted context omitted.

That is not a solution. You do not get to just decide on whether latency or bandwidth is the bottleneck of your task.

There’s no law of physics saying that a company cannot delegate decision–making authority to individual employees. If your employer doesn’t let you make that kind of decision, then that is a social problem rather than a physical one. Note that I have not said that an individual employee can decide how their employer does business, only that your development processes can be arranged so that they do not require low–la…

I am not saying it is impossible, I am saying it is slower. Maybe that is a worthwhile tradeoff for you, but at least to me, in this particular scenario, it is not. It would be a frustrating process. I do generally hold a favorable view towards remote work, but if I can not get you on the phone at all, that makes your work less valuable to me.

Re: Workers quitting over return-to-office policies

#187

Post by elric » Tue, May 31, 2022, 8:30 AM UTC

db48x wrote: post #177

elric wrote: post #172

Earlier quoted context omitted.

Who's going to pay for this? My employer? I doubt it. Me? Hell no. On a less grumpy note: I'd love to have an actual home office, worthy of the name, but real estate is very expensive, I can barely afford a home, but I definitely can't afford a big enough home for a home office.

They don’t generally pay people extra to commute either, but certainly do whichever is cheaper for you. The one time I had a long commute I was paying upwards of $200 a month for the train. Gas, maintenance, repairs, depreciation and so on for a car would have been even more. Add in the drudgery of the daily commute and the cost to me was not small.

My experience certainly isn't universal, but pretty much every knowledge worker in Belgium either has a company car or train pass.

Re: Workers quitting over return-to-office policies

#188

Post by elric » Tue, May 31, 2022, 8:48 AM UTC

dijit wrote: post #176

elric wrote: post #172

Earlier quoted context omitted.

Who's going to pay for this? My employer? I doubt it. Me? Hell no. On a less grumpy note: I'd love to have an actual home office, worthy of the name, but real estate is very expensive, I can barely afford a home, but I definitely can't afford a big enough home for a home office.

That's a shame, home space is much cheaper than office space. (based on Malmo, Sweden office real-estate prices). Co-working desks are as much as 50% of rent in a normal area of the city. For example an apartment of 82sqm (269sqf) in Malmo might be 9000 SEK ($900~) per month, a co-working desk might be 4,200 SEK ($420~)[0]. But an apartment for 13,200 SEK ($1.3k) would likely be 100-120sqm (328-392sqf) in size. Meani…

I'm not sure I'm understanding your point. You're saying you're willing to pay an additional ~400EUR/month so you can work for home? Or are you saying $employer should fork out the cash? That's 10% of my net pay, and I'm very well compensated by Belgian standards. No employer is going to give anyone a 10% net raise just so they can work from home.

It's much cheaper for $employer to invest in more office space. 100eur in office space gets you 100eur of office space, whereas every 100eur in net wages costs an employer roughly 250eur (wages+taxes+etc).

Re: Workers quitting over return-to-office policies

#189

Post by ubermonkey » Tue, May 31, 2022, 12:55 PM UTC

ryanSrich wrote: post #149

ubermonkey wrote: post #148

Earlier quoted context omitted.

>I think async is the next thing that will happen. If you’re building software there’s really no reason you have to share working hours with anyone. Whoooboy do I ever disagree with you there. We have never had offices, so everyone has always been remote, but we absolutely could NOT get in a groove with our former Indian subsidiary. There were a LOT of issues with us and them, some cultural and some just expertise-ba…

> The lack of overlap makes meaningful collaboration too difficult. Please describe in detail what meaningful collaboration even means. The reason why people don’t often explain what it means (especially in threads like this) is because if they actually write it out, they’ll realize how completely unimportant and unnecessary it is.

Peak HN right here. There's this vision that a Good Dev doesn't ever need to talk to anyone, because they'll always get the Perfect Specification, and no business needs will ever intrude and force adjustments, and no meetings will ever need to happen.

Candidly, that's crap.

If the spec is written well, there will STILL be points where you need to discuss things interactively. Bouncing emails back and forth during a workday is inefficient anyway; it's CRAZY inefficient if the time zones don't overlap, because then you're really only going to get one volley a day.

Sometimes, TALKING is the right answer. If your dev team is working a day that is totally outside the rest of the company's working hours, then somebody is going to be working weird times to have that meeting, and that sucks for somebody. The hassle of setting UP that sort of call means people don't want to do it, and so cans of misunderstanding get kicked down the road.

I'll never hire offshore again, and I won't work in an org that does it.

Re: Workers quitting over return-to-office policies

#190

Post by xeromal » Tue, May 31, 2022, 3:51 PM UTC

bradlys wrote: post #161

xeromal wrote: post #84

Earlier quoted context omitted.

Honestly, it sounds like what happens when you have too large a workforce that it's easy to behave this way. I work for a small company of about 50 devs and it's really hard to be "the angry nerd asshole(tm)" without no one wanting to work with you. I think the onus is mostly on leadership to sniff this behavior out and fix it or throw them out. Life is too short to be an asshole or to deal with them.

The problem is that leadership is also the same type of person. I’ve found that leadership is often more troubling than any ICs.

For sure. I'd try to avoid working at a place like that. At some point, it becomes a cultural problem and then that behavior is rewarded!