Live data from Hacker News

Workers quitting over return-to-office policies

bbc.com

151–160 of 194 posts

Re: Workers quitting over return-to-office policies

#151

Earlier quoted context omitted.

> just get rid of code review You’ve lost me there and will never get me back. I can’t abide any workflow that doesn’t put code review as top priority, regardless of remote or in person, sync or async.

A lot of code review is needless nitpicking that doesn't help to produce bug free software and mostly provides friction. Particularly with senior devs reviewing other senior devs work. I don't think I'd say that code review needs to be abolished, but it often needs to be put on a bit of a diet. And I've seen PRs where code beautification feedback has gotten so out of hand and the PR is now 10% code fixes and 90% unre…

> I don't think I'd say that code review needs to be abolished, but it often needs to be put on a bit of a diet.

To clarify: You mean whole team meeting for code-review needs a diet?

Because i agree. I actually think code review is always positive in pair programming situation, and often a waste of time in a team meeting (even with smallish teams). Maybe include the new dev during the code review just to witness (and ask questions later for his enboarding).

Re: Workers quitting over return-to-office policies

#152
post #113

Earlier quoted context omitted.

If you’re building software there’s really no reason you have to share working hours with anyone. When I'm doing UI work, it's far more efficient to have a real-time session with a designer rather than multiple rounds of email/Figma comments.

Can't you schedule a meeting at a time that works for both of you when necessary, instead of forcing the whole team to be synchronous by default?

Sure. It was just a counterexample to the claim that there's no reason to have any overlap in working hours.

Re: Workers quitting over return-to-office policies

#153

I've decided to quit since my remote job won't let me work abroad. That's a dealbreaker now given the summer. I'm just left wondering why I should be tied to the UK instead of being able to explore all of Europe and further afield. There's no real reason, so I've started looking around. If anyone wants an expensive, fully remote contractor with experience as an AWS SRE (golang, python, k8s, terraform, bash), full-sta…

Correct me if I’m wrong, but “expensive dev” in the UK means $100-200k, whereas in SV it’s more like $600k-1m. Hope you find what you’re looking for, consider SV firms as they pay way better AFAICT.

Re: Workers quitting over return-to-office policies

#154

I've decided to quit since my remote job won't let me work abroad. That's a dealbreaker now given the summer. I'm just left wondering why I should be tied to the UK instead of being able to explore all of Europe and further afield. There's no real reason, so I've started looking around. If anyone wants an expensive, fully remote contractor with experience as an AWS SRE (golang, python, k8s, terraform, bash), full-sta…

How would they know if you are abroad? Couldn't you just setup a static IP in a data center in the country you are supposed to be in and VPN through it?

Re: Workers quitting over return-to-office policies

#155
post #98

Earlier quoted context omitted.

I'm also burnt out on WFH. At this point, I'd appreciate an workplace to go in to. But I'd also appreciate that workplace giving me my own office with a door that closes. I've had that only once in my career and it was bliss.

If you work from home, can’t you acquire an office with a door that closes? Perhaps by building an extension on your house, or a workshop in the yard, or renting an office over a restaurant a mile from home (you know the ones that are usually rented by local lawyers, insurance agents, etc)?

Of course, but renting a solo office somewhere else is still isolating and lacking the social interaction I'm missing.

Re: Workers quitting over return-to-office policies

#156
post #151

Earlier quoted context omitted.

A lot of code review is needless nitpicking that doesn't help to produce bug free software and mostly provides friction. Particularly with senior devs reviewing other senior devs work. I don't think I'd say that code review needs to be abolished, but it often needs to be put on a bit of a diet. And I've seen PRs where code beautification feedback has gotten so out of hand and the PR is now 10% code fixes and 90% unre…

> I don't think I'd say that code review needs to be abolished, but it often needs to be put on a bit of a diet. To clarify: You mean whole team meeting for code-review needs a diet? Because i agree. I actually think code review is always positive in pair programming situation, and often a waste of time in a team meeting (even with smallish teams). Maybe include the new dev during the code review just to witness (and…

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 to learn some new tricks. If code review for new devs is just beating them into submission with your own code standards for the sake of your own code standards, then it becomes more of an ego-flexing exercise.

But day-to-day it can get very repetitive and if I'm looking at a PR by a dev who has been around for a long time, doing work which is repetitive work that we've already beaten to death how to do it all correctly, I'm going to give it a very thin skim--that would probably absolutely horrify people who deify code review--before just approving it.

And most of the regressions that I've seen shipped went through code review and everyone missed the edge condition, and done 100 more times everyone would have missed it again, and nobody would have seen the deficiency in the tests. Donald Rumsfeld's unknown-unknowns.

This obviously doesn't apply at all to externally-contributed code to open source software, because you can't really trust external contributors to think through all the edge conditions, you have to assume they're operating in "just-fix-my-bug" mentality and the fix may not be correct or may not be (adequately) tested. That's where you need to be very defensive and need to have your "steward of the codebase" hat on. But for teammates that you've worked with for years, everyone should have their own hat pretty well-developed and its good for velocity and reduction of frustration to trust them a lot more.

Re: Workers quitting over return-to-office policies

#157
post #98

Earlier quoted context omitted.

If you work from home, can’t you acquire an office with a door that closes? Perhaps by building an extension on your house, or a workshop in the yard, or renting an office over a restaurant a mile from home (you know the ones that are usually rented by local lawyers, insurance agents, etc)?

Of course, but renting a solo office somewhere else is still isolating and lacking the social interaction I'm missing.

Find like–minded individuals in your neighborhood and meet for lunch occasionally. It doesn’t have to be expensive; just take sandwiches to the park or whatever. You don’t need an office to get social interaction.

Re: Workers quitting over return-to-office policies

#158

I'm still genuinely uncertain why companies are so desperate to get staff into the office. 'Business people' like HR, sales, marketing LOVE being together in person; Engineers somewhat less so. Given that companies tend to be run by 'business people' then yeah I think I just answered my own question.

It's better for retention.

Better retention means a lower salary bill.

They never offered a pay increase for coming into the office.

Re: Workers quitting over return-to-office policies

#159
post #157

Earlier quoted context omitted.

Of course, but renting a solo office somewhere else is still isolating and lacking the social interaction I'm missing.

Find like–minded individuals in your neighborhood and meet for lunch occasionally. It doesn’t have to be expensive; just take sandwiches to the park or whatever. You don’t need an office to get social interaction.

I've done remote work off and on (mostly on) for 15 years now. I don't see the appeal of doing the legwork myself when I can just go into an office and see people I already have a connection with. Especially since it seems I'll be able to command a premium for being on-site at some point if everyone insists on being remote.

Re: Workers quitting over return-to-office policies

#160
post #151

Earlier quoted context omitted.

> I don't think I'd say that code review needs to be abolished, but it often needs to be put on a bit of a diet. To clarify: You mean whole team meeting for code-review needs a diet? Because i agree. I actually think code review is always positive in pair programming situation, and often a waste of time in a team meeting (even with smallish teams). Maybe include the new dev during the code review just to witness (and…

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. Code review is a culture issue. If you have people who are so unfamiliar with code as to not be able to review it, then that’s a clear knowledge silo that seems perfectly addressable by _code review_.

It’s not about the code, it’s about the knowledge transfer and peer enforcement.

Post reply on HN