Workers quitting over return-to-office policies
bbc.com
bbc.com
I’m finding that where I can build small modules, by myself, that allow lots of flexibility to make final integration possible, I’m getting a lot of work done.
When I need to collaborate with a bunch of people and get small pieces of code landing in different places before I can start to see results, then I’m finding the remote angry nerd keyboard warriors harder to work with.
It’s much harder asking for trust and collaborating on a design when they don’t really care about anyones work except their own. Going into 100% selfish mode matches up with everyone’s culture, but it doesn’t feel great, and means I don’t really get much in the way of quality code review any more.
I’m trying, struggling, and failing to articulate what the good and bad patterns are here. Can anyone help me?
How do you structure a tech team, culturally, to promote progress in spite of everyone now having the social skills, flameyness, and diplomatic finesse of a faceless forum user?
There is so much nuance lost in pure digital (especially email/chat but also video calls) that it puts up communication barriers/friction. As a result people communicate less, or even "come out swinging" (i.e. angry/forcefully) if they feel their work/decisions/etc are being questioned.
I am sure pure remote works well when requirements are 100% understood, there is a perfectly groomed list of prioritised bugs/features to fix/implement, and the design/architecture is both correct (now and in the future) and understood by all engineers. If not then I don't understand how you can easily and efficiently resolve these problems in a remote way without taking hours and hours or even days and weeks for chat or stilted video calls. Sometimes nothing beats just getting in a room with everyone for 90 mins and talking things through around a whiteboard or whatever.
That is incredibly unprofessional, no matter where one is working from. No job descriptions include a blank check to do whatever one feels like without justifying it.
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.
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.
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% unrelated cleanup in the class/module/whatever that I can no longer determine if its safe to merge or not and that no regressions were introduced by the code review process itself.
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).
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.
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.
The key agent of the scientific method is making predictions and comparing them to reality. In other words, you should test if your code actually does what it should do. If so, peer review does not necessarily offer any net benefit.
If you absolutely insist on code review, then you do not belong on the team I am envisioning, which is totally fine. Like I said, the approach has obvious risks, but that is often a tradeoff worth making.
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.
This is more of a problem with the people you work with, not with remote work itself.
When my coworkers were nice people, interacting remotely with them was not a problem.
The main problem with remote work I've experienced was loneliness and isolation.
I long for the days when developers worked on big pieces of code and had ownership much more holistically in what they were developing
I hate the “well my piece works” attitude that I have seen grow over the last 5-10 years. Likely due to bastardized scrum/agile with tiny little bite sized dev stories and tasks that in my mind have turned developers into cogs in a assembly line. 30+ years ago, almost all devs were brilliant, creators, engineers and problem solvers. In my estimation 25% are brilliant today with the remaining seemingly unable to write a single line of code unless the requirements are spelled out in hyper levels of detail, with design standards, engineering guides, and all manners of cheat sheets to contain them in a box where their screwups are contained.
rant over
I’m coming up on year 10 of working remotely, and year 2 of completely async. The only forced-commute job I ever had was for 6 months right out of college.
I’ve been preaching remote work for almost the entire time I’ve been doing it. I thought it would catch on much sooner, but it’s here now.
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. It’s convenient at times, but it’s by no means required.
Our team stopped having a standup meeting- we just have a daily automated post in our chat, and we comment in the thread whenever it makes sense. If we’re working on the same thing for days with no blockers, it’s not a big deal to not provide an update.
We’ve reduced our synchronous communication by quite a bit. Some weeks I don’t have a single call I join. If you document everything well enough, you don’t really need to. I find myself on calls when I need to extract information from an architect that is just too busy to write everything down, or I’m mentoring a teammate. Or I’m in my monthly 1-on-1 with my manager.
Working outside of regular business hours is not off the table, but it is new. It helps that some of us are in the US and some in Poland. Normally, just blocking off time on the calendar and marking your status (out of office) is sufficient.
1. log on to Slack in the morning and see if there’s anything that needs attention. We use slack as a central hub. All of our tools funnel activity into slack. My team is small (3 full time, 2 part time contractors). Most of my team works over night and into the morning (very different time zones). Typically when I wake up, there’s a few PRs for me to review, or questions to answer on a ticket in linear. We also have a check in bot that runs once per week. No real need to do daily checkins.
2. After I catch up and respond to any questions (which most likely will be read by people that night or the next day) I see if I have any sales meetings. Since we’re a startup it’s still founders in sales mode. I might have a demo or 2 each day. This is probably my only non-async activity.
3. Outside of sales work, I also write code, review design work, and field customer support questions. So the rest of my day is a buffet of random stuff.
As far as politics go. There really isn’t any. The team is pretty small. We might have a disagreement on how a feature should be implemented or something like that, but I’m the deciding factor and everyone is a professional so it’s not a problem.
I enjoy the human component of work. I don’t like _all_ of my coworkers, but it’s still a net positive to interact with them.
When I think about the ideal software job, a lot of the aspects of day-to-day work informally become async. Especially as you work with people for longer periods of time and gain mutual trust, a good workplace allows both managers and individual contributors to structure their own time.
Here's the thing; that (a completely transactional relationship between all elements of a team) doesn't actually work well to make good products. Sure, a bunch of companies would probably do it as it's easier to measure worker production that way, but async also requires a different type of management and admin work that has to change as well. A lot of current managers won't be able to hack it, frankly, without the measured 'butts in seats' element.
Personally, I think it should be coupled with an investment in HR to get more qualified and motivated people working on the problem. It's a different concept for business and teams, that's all. Applying the older paradigm is going to be a problem and while a lot of companies will do just that they will also be less successful overall.
Respectfully,you know nothing about what you're talking about.
Async work is already the norm for some companies, even prior to moves to full remote work. I personally know teams in renowned companies which before COVID already split teams working on products between the US, Europe, and India. They stuck with full async because it worked, and worked better than alternatives.
With COVID, the whole world went full remote due to necessity, and I personally know teams whose output improved significantly with the move to full remote to the point where they stuck in remote by default.
> Personally, I think it should be coupled with an investment in HR to get more qualified and motivated people working on the problem.
I disagree. What I'm seeing is a lazy, conservative mindset of people who feel scared and threatened by a reform shaking up the very core of a system they feel benefits them personally.
"make software development purely transactional and performance/pay would be directly tied to metrics."
That's what doesn't work to make good products. A focus on individual metrics to the exclusion of team dynamics doesn't work that well.
"What I'm seeing is a lazy, conservative mindset of people who feel scared and threatened by a reform shaking up the very core of a system they feel benefits them personally. "
I mean that's kinda what I was talking about with a bunch of managers not being able to hack it. I don't think you get what I was saying; if HR doesn't change, you get the same people trying the same model and applying it to a new framework, which will fail. You need a better focus on the people individually and on the systems you build for them to work well together and that requires a "people" or "HR" department that actually functions well and has investment.
This has borne out time and again from artisan shops to factories to software.
Because let’s be honest, the reason most of these folks are doing this is because they don’t give a crap about the specific company or anything like that. They just want to build cool shit that other people spec out. As long as the pay is competitive one day they might be building a healthcare mobile app, another day an online car dealership portal.
Honestly, I think that is where it’s headed. I know if I went back to being a dev who did 95% of my shit remote, I would much rather be a 1099 “arms length” contractor then I’d be W2 “real employee”. If you are going for the flexibility that remote brings, you might as well make it fully flexible and just be a contract developer… after all you already decided you didn’t give a shit about company politics or culture… you just want to write code! So just become a contractor!
I'm not less dedicated to my current company than before COVID.
I've seen people in an office not give a damn (literally doing a phone interview for a position at a different company at his desk), and totally remote people probably care a little too much, and everything in-between.
People should care iff they are given meaningful equity, as in life changing, otherwise they should be professional, like accountants and lawyers, but jump ship whenever it’s convenient.
Like others in this thread, the reality that work is primarily a simple transaction of time for money, coupled with my experience being a "real" employee, has ingrained in me the understanding that, if you want to protect yourself as a worker, being at "arms length" as you put it is the way. At least for me.
I am a company of one (literally and figuratively). Unfortunately that's the logical endpoint of companies not feeling any loyalty towards their employees. So be it, I embrace it, because what else is there to do?
> Because let’s be honest, the reason most of these folks are doing this is because they don’t give a crap about the specific company or anything like that. They just want to build cool shit that other people spec out.
I do not build cool stuff everyday that other people spec out and wouldn’t consider my job being a developer these days. I would say I very much care and like the company I work for. The people that spec out things can also work remotely.
> As long as the pay is competitive one day they might be building a healthcare mobile app, another day an online car dealership portal.
I work in Cybersecurity and very much have a preference on what I work on and who I work for. I also have a strong preference on working remotely and having employment rights or benefits.
But even so, it seems to be a bit much to preach for something when you've never experienced another alternative, except from 6 months after college. It's hard to remain unbiased when you don't know anything else by experience.
Personally, I've spent lots of my career in an office, and also lots of career working remotely, about the same amount of companies in each category. I'm more of a fan of the in-person dynamic you can create while being in the same location, compared to the almost-human dynamic you can create if everyone and everything is remotely. But I tend to work in much smaller teams (although one office-job and one remote-job were in pretty large enterprises), so maybe that's why I prefer one vs the other.
Even though I prefer at-location work, I totally understand how others can prefer a different scenario. Depends on so many variables, so I guess my conclusion is just "it depends". Don't prescribe anything to others without knowing what they want, and don't let yourself be controlled by others opinions, just do what you feel is best for you.
At least, that’s how too many places still do technical interviews.
But the other side of the coin is that if you do need to ask a question and get an answer, then what is wrong with a text chat mechanism like IRC or Slack or whatever? These tools also work for real collaboration between engineers too.
Bad analogies are not very persuasive
Terrible analogy.
If you want to pick something that makes more sense to compare, it would be something that is engineering related.
Where do these clear specs come from? That’s the creative process I’m talking about.
If you interrupt the songwriter every 20 minutes because you have a question around lighting you end up without a song.
Many rock bands create their parts separately or one person creates it all and everyone else learns the material.
As a result, we’ve factored this into new architecture plans which further decouple the two teams to operate more independently. We may not have cared as much if we all were operating in approximately the same time zone but asynchronous work will undoubtedly slow development progress on any interface boundaries or when working with dependencies. In a micro-services oriented organization this will almost always be the case. For some areas I can see IC’s being sufficiently isolated in a way that asynchronous could work well but for my organization it would be a nightmare.
I would point out though that not everyone operates at the scale where everyone can come into the same office every day and meet face to face. I work closely with engineers on both us coasts, in india, and in western europe. whether I work out of my apartment or the nearest office does not really affect the speed or quality of communication with my colleagues.
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.
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.
Also, kill email use internally. It’s absolutely not needed in 2022 when literally every app you use on a daily basis has an activity feed.
Async or a few hours of common hour overlaps are really going to be a big contributor to work / life balance even though it sounds counter-intuitive. It's counter-intuitive because it could mean working outside of "normal business hours", but this is often exactly what you need to do if you want to do things on a whim (aka. having some type of work / life balance).
Right now a lot of remote companies expect working hours between 9am to 6pm, that doesn't really leave any room for much of a work / life balance. By the time you get a chance to relax, prepare dinner, etc. it's already 7pm or even 8pm if you need to run errands. Even if you wake up at 6:30am it very quickly becomes 9am after doing a bit of exercise, breakfast, shower, etc.. If you're up at 6:30am you're probably pretty drained by 10pm. After dinner that leaves you like 2 hours to live your life and maybe fall asleep to a movie or book.
Basecamp seems to have a very good policy on this. I forgot where I read it but I'm sure I once saw DHH mention that you can work any hours you want as long as you overlap 3-4 hours with CST and put in ~40 hours a week (~32 from May to September since every Friday is off). This is IMO a great first step towards async.
It means you can on a whim decide to leave at 2pm EST because you worked from 10am to 2pm EST (9am to 1pm CST) so that you can go swimming on a nice day but you make up the hours later in the evening, or maybe you shift your working hours so you always finish by 2-3pm EST because your best working hours are really early in the morning and occasionally deviate from that for special circumstances from the business as needed.
The hard 9-6 rule means pre-scheduling PTO with a lot of notice for things that often require little to no notice. I know some companies will let you occasionally take a couple of hours off without officially filing for PTO through HR but these often need a decent amount of prior notice unless it's an emergency. Basically it puts you into a position where you always need to ask permission instead of just doing it and be trusted to make up the hours.
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
Personally I doubt that having face–to–face meetings is ever truly necessary. Once everyone in the group has thought of several ideas, they can write a page or two description of it and why they think it is a good idea. Then the decision makers (which obviously might be the same group) can read those papers and decide between them. Mozilla used to work something like this specifically to allow contributions by volunteers outside the company (no idea if they still do though). The Rust programming language is developed in a similar way: anyone can write an RFC to propose making a change to the language (or the associated tooling, the standard library, etc).
Keep in mind that I never mentioned face-to-face, I just asked for synchronous time.
That being said, I'm open to explore the idea, I think I already do this for a certain subset of problems using Slack threads
> 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.
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.
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-based (I don't think we had a great lead over there, and I DO think he was afraid of hiring people smarter than he was), but a HUUUUUGE chunk of the issue was that any issue became much harder to resolve because of the lack of meaningful time zone overlap.
We ended the experiment and hired up more US folks, at greater cost, but with drastically better cohesion.
I get that anecdotes aren't data, but I do not think I would join any team that was spread over more than 4 or 5 time zones. 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.
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.
The commute time, the price of gas, and the nature of the work in this building (tech work for customers who are themselves remote, with everything handled by a ticket system) are no doubt all factors. It is seen as a power ploy by management, I think, to have "butts in seats" again.
The change I'd like to see is some sort of geographically centric pod office where it's not mandatory, but a team lead could say, "We need two days at Pod X to run through A, B, C initiatives."
No one is required to arbitrarily attend a physical office, but rather very task and team specific meetings.
I think many people that are against that arbitrary return would be open to task/team scheduled gatherings.
So, enjoy your remote work - and for many professions it won't be an issue - but for some careers watch as your in-person colleagues advance faster, earn more & enjoy greater trust and responsibility.
To know when to talk or shut up in a meeting or read other people emotions to see that someone might be polite but is actually pissed off takes quite a lot of working together and a lot of meetings.
If the bosses (the higher-ups, not the middle managers) don't like you, you're not going to get this anyway, and 99% of whether they decide they like you is based on preexisting social class similiarity. The pre-anointed winners with rich, connected daddies benefit from this--they're the ones who get tapped to be CEO's proteges--and they'll be just fine without going into an office.
The rest of us, if we have to go to an office, are just wasting our time so someone else feels important, and that's really it. They don't see us as one of them, so they're not going to invest in our careers, so we have no reason to care beyond the minimum and having to pretend otherwise (that is, indulge and uphold bourgeois false consciousness) is emotional labor we're better off without having to do.
The HN demographic is probably on the leading edge here. I work for a small software company, but I don't code anymore; I'm effectively the head of operations. I've been here 15 years. We have NEVER had an office anywhere. Our employees have been spread nationwide this whole time, working from home. It's fine.
I think the only thing we really miss about an office is that we think it would be difficult to onboard a baby dev. I DO think there's something to be said for learning the "professional programmer on commercial software" ropes in a place where you're physically near other people doing that.
But that's really just a suspicion; we don't actually KNOW, but hiring for us is still such a big deal (narrow expertise) that we're not likely to do so as an experiment.
'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.
A manager with a Hobbesian conceptualization of power in a raw physical sense sees their own power as the accumulation of the accumulated ceded power[1] of their direct reports. That is to say, the more of their workers in their physical presence, the more powerful they are and the more workers I have over you, the more power I have relative to you.
Social relations too become spatial relations. In this conceptualization, a manager seeks to display their own status(via power) in the dramatic interactions they have with other managers. Whole areas, floors, or even buildings comprise the managerial territory under control, complete with the material wealth of physical assets, both inanimate and human.
Finally, we have Hobbes instrumentall power or the corporate ladder climbing we all know - power for power's sake. Beyond the creation of wealth, good, and value lies the drive for power itself.
1. http://changingminds.org/explanations/power/hobbes_power.htm
Your occupation does not define your personality or your ability to work with others closely. Without someone capable of bringing others together socially, team standards and practices either get dictated by the manager or the loudest voice in the room. The ability to foster collaboration is woefully underappreciated as a skill in our field.
And yeah, I've met plenty of antisocial HR, Sales, and Marketing people.
I originally read that “sociopathic HR”, and thought no shit, then reread it correctly.
I am pretty much convinced that in 2022 the average HR person’s sole duty to to try and justify their own existence.
Better retention means a lower salary bill.
They never offered a pay increase for coming into the office.
The first time there is a bad labor market, most of the current remote jobs are going to disappear. Not all, but most, and in nearly all professions the remote jobs will mostly be contractors who have no long-term employment with the company anyway. Not saying this is the way it _should_ be, but when it comes time for layoffs, the people who were working remotely are just emotionally and practically so much easier to choose, than the people who show up in the office every day. Not saying it's right, just that it's so.
And why shouldn’t they take multiple gigs at once? It’s not like people working remote are at their current employer for the culture or politics or anything. In fact most do remote to avoid that crap.
Might as well formalize the relationship and just go 1099. Then you can deduct your very real home office expenses and whatnot. Then you can own your own equipment and office expenses. Then you can work “arms length” from your clients.
All I know is if I went full remote again, I would definitely restructure myself as an independent contractor. Turns out though that I actually like being in the office and working side by side with my team to build cool shit. But that is a bit because my role isn’t a developer. Developers are easy to do remote if they don’t care much about the actual product they are building. As long as you feed them fairly well speced work they are good to go.
If anyone wants an expensive, fully remote contractor with experience as an AWS SRE (golang, python, k8s, terraform, bash), full-stack web dev (django, vueJS, some react, forgotten PHP), rusty big data (scala & spark) a part-time MBA in progress, and a 30 day notice period, let me know :)
I may consider full-time but I hear people in the US work insane hours which I've no intention of doing.
Quote straight from the article.
Well, at least outside bunch of HNers which will ignore the article and just dump their personal WFH stories in this comment section as usual.
Just saying "they've heard anecdotes" does nothing but reinforce existing biases that everyone here will have.
Hard data will at least convince some people who have biases but trust scientific processes to change their opinions.
That's what a journalist does. They go out and listen to people and they tell you what they're hearing and provide context to it.
You want a scientist - that's a different thing.
Both are useful in practice.
"A recent survey of more than 650 Apple employees on third-party anonymous polling site Blind revealed 76% of respondents were dissatisfied with the company's return-to-office plans; 56% said they'd consider resigning over it."
It's legitimate for journalists to report what they're hearing less formally than that.
And that's how it's always been - it's not a new thing.
Like, what's hard to understand about "there should be at least some general evidence outside personal anecdotes for conclusions about groups of people"?
I don't think I'll work on a remote team for a long time but it's important that what's good for a lot of people is doable by them.
A solution to force the employers hand to allowing remote work might be mass resignations across the country, but Austrians in general are too submissive and fearful to collectively strike against their employers like the French for example.
So international remote work is kind of a loose-loose scenario here unless you get some super high compensation to make up for the disadvantages.
Also, I had a lot of negative experiences interviewing for remote only companies. Week long take home projects (basically free labor), multiple interview stages with IQ tests, culture and other hazing and then finally, either ghosting or rejection for whatever undisclosed reason. This is not a good use of my time, especially not for weeks on end, after 8 hours of actual work at my current employer. I was buying myself a one way ticket to burnout central.
Anyway any change is hard in general, any social change happen only in long timeframe, but it's clear to anybody that jobs eligible from remote work should be done as much as possible remotely. Surely we benefit from being together, so for certain activities, like schooling we must keep physical proximity, but for many others the trade off is far on the side of remote.
Is that true?
Will I get $200k in eastern eu?
Edit:
Here's a source that says they pay the same no matter if you're in the office or at home (basically), but it's limited to countries Spotify agrees you can be in:
> Location choices – we will also introduce more flexibility when it comes to what country and city each employee works from (with some limitations to address time zone difficulties, and regional entity laws in the initial rollout of this program).
- "Introducing Working From Anywhere" - https://hrblog.spotify.com/2021/02/12/introducing-working-fr...
- "Distributed-First Is the Future of Work at Spotify" - https://newsroom.spotify.com/2021-02-12/distributed-first-is...
What's the increase in turnover because of WFH policies? A few % total?
EDIT: Oh, just saw this in the article: >Although there isn’t any hard data to show increased quits due to ending flexible work specifically, anecdotes of worker exits are starting to trickle in.
Carry on then.
Click-bait indeed, but while I'm a small sample size, the idea checks-out to me.
I'm also a small sample size but the idea checks-out to me too.
I encourage everyone who gets a message from a recruiter to make it clear you'll only accept WFH, that feedback trickles back to hiring managers and might slowly change their minds.
I am extremely sad at the extreme loss of life and horrible conditions caused by the pandemic. So I feel exceedingly guilty for feeling glad that an upside of it is that we can finally do away with this horrible practice of crushing everyone together so the managers can marvel at their panopticon.
It’s also been great for remote work. No need for additional hand-wringing.
So my hope is that science will come up with better vaccines quickly and natural selection will trim off the Enlightened to a more tolerable level.
History will not look fondly at what was done. I hope to god we never repeat this massive mistake.
That would be a start. Hiding facts and data that goes against your narrative and then labeling people who point said stuff out as conspiracy theorists is not cool.
> frightening the daylights out of people
Yeah, infantilize the populations, shield them from reality, tell them "don't worry, Karen!" Virus will surely take notice and stop being so murderous.
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.
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.
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.
Meaning a dedicated room in your home of 18-38sqm (59-124sqf) can be the same price as a single desk in a co-working space.
Paying 1.5x the rent for an apartment would give a lot more space than just a desk.
[0]: https://www.gamehabitat.se/devhub/
*EDIT*: just realised a fixed desk is actually more than 4,200SEK
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).
Heh, I didn't realize this, but during covid my company mandated every other desk to stay empty, and suddenly it felt like I had as much space again as I used to have 20 years ago.
I recall reading this blog post a couple of decades ago and being jealous, because finally someone really understood developers and what they needed to be productive. I’m remote now, and thankfully not returning to office, but this would be one I would return to willingly. An open office? Not a chance, I’d fight it every step of the way.
That’s the “cog in the machine” part of the story, the other side is what you can do as that cog. If you posses a skill set that is in demand, you can actually get away with a lot of things in this world. Why people don’t do this is beyond me, especially for IT staff. Of course it’s not easy to find the remote job you want, but in my anecdotal experience I have met so many people who were so much smarter than me who got much fewer benefits. I’ve even heard people defend their low pay, using their bosses talking points. Like, what?
I’m not an asshole, I’m not hard to work with but I do have ADHD which is crippling for me when it comes to working on things I dislike for long periods. Maybe that’s part of why I’ve always asked to get things my way, but it’s not beyond me how lucky I am to be in a profession where we always have a couple or job openings available.