I’ll be honest: I feel somewhat vindicated due my own personal struggles with the open office[0] and people arguing for the status quo on hacker news[1].
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.
Everything is a mixed bag of good and bad. In fact this pandemic will probably save a lot more lives during the next pandemic in terms of preparations etc.
It’s also been great for remote work. No need for additional hand-wringing.
There is no silver lining and the next pandemic will play out raw, just like this one. Antivaxers will blame it on Bill Gate's son and 6G. That is because of human stupidity - it's immutable and ever present.
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.
Hopefully “the next pandemic” will not be like this one at all. Because how “the experts” handled this one was shamefully wrong. At virtually every decision point these “experts” did the exact wrong thing. From years of school closures to two years of forced masks to intentionally frightening the daylights out of people. They did everything wrong.
History will not look fondly at what was done. I hope to god we never repeat this massive mistake.
For one thing how about being open and honest about your own publicly available data . Maybe start by clearly articulating the actual risks of Covid instead of letting the media fly away with garbage like “4% kill rate”. To this day people still parrot back “Covid kills 4% of people who get it” when the actual rate is several orders of magnitude lower, even with OG Covid.
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.
To judge the way the pandemic has been handled, you have to be an expert yourself. Because right now it's like telling a physicist how stupid his theory is while you're flipping his burger at BK. Sure, their theory may sound stupid to you, but that is your problem.
> 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.
I'm growing more and more frustrated with open offices, and with $management's unwillingness any concerns. Quitting isn't really an option: I haven't seen a single Belgian company that has an acceptable office layout for software engineers. Even desk sizes seem to be getting smaller and smaller. Remote options are few and far between (and I don't want to WFH anymore).
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)?
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.
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.
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.
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).
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.
Not really. For whatever reason, company cars (and trains, but at least those make sense) are taxed way less than salaries. There's no way in hell I'd fork up 3000EUR/year to get a train pass if $work wasn't paying for it.
It seems like your government has chosen one specific way for you to live, and not given you much financial flexibility to live any other way. Know that it is not the same everywhere. Where I live there are no government–imposed financial incentives to encourage people to commute. (A lot of _employers_ encourage commuting, but not all of them do).
> Even desk sizes seem to be getting smaller and smaller.
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.
My employer replaced all of our 180cm wide desks with 140cm wide desks during lockdown. Needless to say, I'm not too thrilled to be back in the office. That's barely enough space for a laptop and a monitor. Second monitor? Notepad? Forgetaboutit.
I’d be interested to know how RTO dissatisfaction correlates to open office environments. I’d be willing to bet that companies that have the big room full of lined up desks and elbow to elbow developers might be getting some pushback.
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.
The open office is a bad idea for a lot of people, but that’s not why it’s cost efficient. It’s cost efficient because it keeps rent, heating/cooling down, lets you have desks for only 60-80% of your workforce and it plays really well with the middle managers handbook of “watching people be busy”. Or in other words it basically checks all the boxes that you care about when you move into the E&Y level of executive power. The entire system is flawed or course. Even the 37-40 hour work week is sort of a left over from when we worked assembly lines. That doesn’t really matter when it’s what gets taught at every management education and is what gets adviced at any management consulting agency, and, because it works. It doesn’t work for every employee (or even manager), but it works for every company.
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.
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.
As someone who has been fully remote the past two years, and in a team that is gradually exploring/adopting more async work practices over the past year, I would be curious to hear more too.
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.
I’m a startup co-founder, so day to day can be a lot of different things. But it’s something like this:
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 like the concept of async work but I’m also scared of how transactional that would make work. Most companies that preach async now have a very strong, “friendly” culture. If async catches on more widely I’m worried it would be the final push to make software development purely transactional and performance/pay would be directly tied to metrics.
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.
>If async catches on more widely I’m worried it would be the final push to make software development purely transactional and performance/pay would be directly tied to metrics.
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.
> Here's the thing; that doesn't actually work well to make good products. Sure, a bunch of companies (...)
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.
Sure, there are multiple ways to run a company, but people aren't machines. A pure focus on measurables to the exclusion of soft motivation and skill has proven to be less effective. I'm honestly surprised you believe otherwise.
This has borne out time and again from artisan shops to factories to software.
I am beginning to think that many remote developers will eventually become 1099 contractors who can pick up random gigs.
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've been working remotely for years, and for companies that literally didn't have offices to work from. Everyone was 100% remote, and I can assure you that didn't have any impact whatsoever on people's passion for their work or the company they worked for.
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.
Is one supposed to be anything but a mercenary? Should I believe in the product for the sake of making the CEO a billionaire?
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.
I don't know that "should" is the right word. It's possible and reasonably common in software to obtain career fulfillment beyond simply making a lot of money; I don't think you have some moral obligation to do that, but you should understand that other people do and that this is why they may have work style preferences which seem strange or confusing to you.
Totally agree, and I wouldn't have it any other way. I suppose I'm a bit of a strange case on HN, in that I'm coming to programming from being a film composer, i.e. I've pretty much always been freelance, and so working as a "real" employee is infinitely weird to me even at the best of times. I worked at a large corporation one time, and while I loved the work and my co-workers, the subtle office politics, the whole idea of a "culture," the routine day in and day out...it just did not vibe with me. I'm not totally against going back to being a W2 employee, but it would take an awful lot to convince me.
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?
Your comment is definitely centralized in a US mindset but I promise you can still have rights as an employee and not have some much company culture stuff at other companies outside of the US. Being 1099 contractor has too much exposure to risk as an employee IME.
> 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.
I'm of the view that it works best for some, while for others some other solution works best. There is no right or wrong, just personal preference.
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.
Incompetent engineers need to share work hours, otherwise they will get stuck and not get much done if nobody has overlapping times to help them. Not all engineers are high caliber.
If needing help at some point in time means being incompetent, I think that describes everyone I've ever worked with, including some really high caliber folk. Even a simple rubber duck conversation can beat useful thing now and then.
No Google or Stack Oveflow, just everything from my memory into the IDE until the test case written into the JIRAs assigned to me all pass. No internet connection for employees, only test env access.
At least, that’s how too many places still do technical interviews.
What about founders - they don’t just get stuck and give up on random technical things. There are many incompetent people who will sit around and twiddle their thumbs if nobody is actively communicating with them.
Wouldn't you go to experts outside of your companies? I may go to the company who makes the product for support or to a popular forum and ask a question.. none of this needs to be sync vs async
Exactly - what I mean by incompetent engineers is they will get “blocked” and then wait for someone else on the team to eventually find out and rescue them. Synchronous communication helps for these types of people. For engineers who can more independently work, and figure things out on their own (such as reaching out to experts if needed), asynchronous works fine in most situations.
You may be the best engineer in the world but if your newborn is teething and then spent the whole night crying, you are going to need some help the next day. Sadly this is often obvious only in hindsight.
Maybe this works as an IC that has no collaborative aspect to their day-to-day but as an IC leader async adds material pauses and latency into projects. If everybody is ok with everything taking longer at the start and end of projects then cool (the middle implementation phase is less impacted) but taking a day to answer a question that could have taken minutes is not a bonus.
I’m a CTO and startup founder. We ship faster and more often than any team I’ve worked on or observed (multiple times per week). I think your assumption are bad.
Without being dismissive of your opinion, being the CTO of a startup doesn’t really say much. I can be the CTO of a startup after I finish an undergrad in computer science or I can be the CTO of a multiple rounds of funding unicorn. So qualifying your opinion with the generic “I’m a CTO and founder” perhaps isn’t a sufficient credence to suggest your experience holds clout.
Asking a quick question that only takes a few minutes is a nice bonus for you, but for the person you asked it was an interruption that cost them 20 minutes or more of focus. That might be ok if the person you asked has a job that is designed to be interrupt–driven (aka a manager), but if this was another engineer then this wasn’t a net benefit.
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.
Seems like there are two very different modes of development being mentioned here. You seem to be describing a mode where you just need to concentrate and bang out your lines of code for the day. The previous comment seems to be referring to creative, collaborative development. The industry probably needs both, but I’m much more personally interested in the latter, and I’m worried that async/remote is disastrous for that mode in ways that might not be realized for years. To use a crude example, if you’re in a rock band composing songs together, you would never consider that suggesting a change to the riff the bass player is playing would be “an interruption that cost them 20 minutes of focus.”
> To use a crude example, if you’re in a rock band composing songs together, you would never consider that interrupting the bass player to suggest a slightly different riff would be “an interruption that cost them 20 minutes of focus
This analogy sucks because a rock band cannot make songs without actually playing together over and over again. You can however build software in modules or independent parts as long as you have clear specs about what each part should do and proper testing. Thats why you can outsource some software dev but you cannot outsource a rock band.
Terrible analogy.
If you want to pick something that makes more sense to compare, it would be something that is engineering related.
Asking a question in slack is exactly what I’m referring to. It is async but if we’re on the same schedule then chances are you’ll reply within a couple minutes if not an hour. I massively prefer this style as opposed to walking over to somebody’s desk. However OP is suggesting async also implies you can be working on different schedules with no downside but it’s the differing schedule that is causing the problem.
I agree, we have a sister team which resides half-way around the world (we’re west coast of US, they are in Germany). Over the years, we’ve found the asynchronous communication between us to be a point of friction that has slowed down progress. Waiting for a peer review from them introduces days of lag on what should be faster iterative development cycle.
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 agree with you, there are absolutely pros and cons to async work, and sometimes the cons outweigh the pros.
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.
Yes, but synchronous communication can and should be the exception. In loco working policy basically requires entire teams to live by and commute just so some manager doesn’t have to have the discipline of scheduling meetings in advance and ask things across the desk.
You recognize yourself that async working means more latency. Latency and throughput are often sitting on the opposite ends of a spectrum. With async you can have less interruptions for ICs and increase their throughput.
Writing is always going to be slower, especially if done well. When it comes to UI, tight feedback loops are crucial at virtually every step of the way.
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; that’s delegation.
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.
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.
Sync is, occasionally, essential to me as an IC. I think it would be reasonable for a company to require a few hours per week, with the precise time negotiated between the people involved.
> I think async is the next thing that will happen.
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.
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 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).
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, 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
“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.
> 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 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-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.
> 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.
>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.
I'll agree with you that it can definitely be useful. I just don't see the usefulness in this particular instance. Work From Home is a heated topic that is sharply divided between types of personalities so articles like this will just cause circular arguments IMHO.
I think the issue being taken is that it’s not even clear their data is coming directly from the workers in question as opposed to “I heard anecdotes” ie 3rd party stories.
Some poll results can be found in the 3rd paragraph:
"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 frankly dishonest for the article to characterize Blind, a well-known "complain about your job" app, as a "polling site" which might have meaningful results.
Are you seriously unable to comprehend the nuance between "peer reviewed article" and "journalist pulling something our of their arse with zero supporting data"?
Like, what's hard to understand about "there should be at least some general evidence outside personal anecdotes for conclusions about groups of people"?
Quitting for that is only possible as a solution if you have remote friendly alternative to go to after you quit, but if, like in Austria, all the employers in the country went back to the office then you pretty much have no other options than to go to the office as your employer demands, since you quitting won't fix this issues :(
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.
There are plenty of companies out there that hire internationally, especially since you’re in the EU it should be little issue finding one if you’re a competent engineer. Pay is often better that way as well
The issues here are taxes and labor laws. If you work remotely for a company abroad then taxes are now higher for you, since now you're paying the share your employer was paying for you, since you work as a freelancer (Austria does not allow direct employment for companies not headquartered in Austria), and you also loose social benefits like PTO and sick leave despite paying higher taxes.
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.
I have worked remotely more often than not in the last 10 years. I think it absolutely works in some cases, and hybrid (e.g. 3 days remote per week) works for more cases. But...
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.
Remote workers should be mostly contract in the first place. If you look at how most are operating odds are good they’d pass almost every test from the IRS. All they’d need is to take a couple gigs at once.
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.
The main test has nothing to do with remoteness and everything to do with how much influence your employer has over your day to day work. None of the companies I’m familiar with that are in this struggle have suddenly let the workers have more free determination over their work then before.
So Spotify employees in Stockholm would earn differently than the ones in the US? Doesn't really sound like "continuing to pay New York City-level salaries to workers no matter where they're based" if that's the case.
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).
My guess is that they still pay US higher but I have no evidence of it. AirBnB also allows you to work from anywhere but if you look at their job-listing they still show location as San Francisco for pretty much all of the jobs.
Of course. Pay is always set as low as possible to retain the right level of employee. If the market for engineers in the US is higher than Europe (it is) it will pay higher.
There's a lot of "considering" and "thinking" in this article, but how many people are ACTUALLY quitting over that?
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.
I have worked from home for the past two years, and my company has started the return-to-work policy last week. I applied for, and was given, full remote status. If they had not done this, I would have definitely found another job that was willing.
Click-bait indeed, but while I'm a small sample size, the idea checks-out to me.
I tried to do the same thing. On the first day back in the office I was venting to my manager about all the issues I had with working at the office (noise, smells, talkative coworkers) and I requested the ability to resume remote work. Later that day I was pulled into an impromptu meeting with my manager, our VP, the CEO, and the HR manager. They explained that they knew I had a great work ethic and that I was one of the top developers, however, I couldn't work remotely because it would be "unfair" to the developers. The claimed the rest of the team could not be trusted to work remotely therefor I couldn't either. I'm not sure if what they said was true but I applied at 4 jobs that evening, scheduled all 3 interviews within the week, and put in my notice by the end of the second week.
I'm also a small sample size but the idea checks-out to me too.
I'm glad the market is segmenting into people who want to work remote and people who don't. I am among the latter but lots of people I respect are in the former group.
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.
Some types of tech work well with remote, largely unalignable staff. Some don’t.
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?
Just wanted to echo this - the lack of in-person discourse leads to strained relationships IME.
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.
> even "come out swinging" (i.e. angry/forcefully) if they feel their work/decisions/etc are being questioned
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.
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.
Instead of structuring your team around the architecture of the software, you architect the software around the structure of your team. It is a corrolary of Conways law. Promote selfishness (call it ownership) and get just get rid of code review. As you may imagine, this approach has fat tail risk, but that is not necessarily a problem in a high failure rate environment.
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% 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.
> 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).
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.
> 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.
> 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.
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.
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.
"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"
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.
This sounds like an interesting perspective. Could you elaborate a bit more on what it is different today, and what you are comparing the present situation to?
This is just my opinion, but I think we have compartmentalized development too much. Atomized it a level where the individual parts only care about themselves and are now too simple that the parts lose sight of the whole.
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.
Many companies try to! The problem is that paying extra for the commute deterministically implies that people who do end up working remote are penalized, which they understandably aren't happy about. As the article describes, when companies like Spotify try to come up with an employee friendly policy they inevitably conclude that remote employees should be paid the same as in office ones.
I think just wiping the fees/charges off commuting would be a good start. PT / Fuel costs are still a thing as they continue to increase. Not everyone is using EV. Yet.
Counterpoint: For many careers remote work deprives young workers of mentoring, relationship building, and learning by osmosis. This is already being seen at law firms for example.
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.
Some things you cannot teach by intentionally saying "do X" or writing down "code of conduct".
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.
I've been mentored remotely. I think the drawback to remote is far and away the lack of face-to-face interaction on the daily, and as you allude to this can build closer connections. The virtual substitutes are lackluster. However, some of us already have social needs met otherwise and don't put a premium on what is missed.
Counterpoint: For many careers remote work deprives young workers of mentoring, relationship building, and learning by osmosis. This is already being seen at law firms for example.
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.
I’ve worked remotely for 25 years, at a combination of companies and as an independent contractor. As an independent contractor of course I was responsible for learning things on my own. At some companies I’ve worked for, mentoring was always accidental; they never planned for it or deliberately tried to do it well. The results were pretty mixed. At others, they deliberately set out to train and mentor people well, even if they were remote. The results were much, much better, and people’s careers did not suffer merely because they were remote.
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.
I observed at my current company that the worse the manager the more they wanted people to be in the office. If you're a bad manager that no one tells anything to due to lack of trust and who doesn't tell the team anything then working remotely is basically a giant mess. In the office a manager can more easily spy and micromanage people while organic cross-team communication can work around the manager's lack of communication.
It's because it's much more difficult to brainwash you into the company culture while you're remote. Even when they run large video chats, most people probably just leave the laptop on and go and do something actually enjoyable.
I genuinely believe MGMT-types enjoy face-to-face interaction, but would not discount the theatrical power of it all.
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.
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 like my coworkers professionally and enjoy building stuff together, but hate contacting with them otherwise, like team-events, lunches, smalltalk near the coffee machine. Remote work has been such a blessing.
I love that stuff. My company is remote optional, but most days I'm the only person in the office which defeats the point. I wish I could find a hiring board for in-office only companies.
This will evolve. I think 100% remote is great for some people (small children, busy schedules, health issues) but many people would also benefit from being with their teams.
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.
A company has every right to build its culture, so I'd disagree with this. It's really the "you must be at a desk in our office for 8 hours just because" part that most people object to.
I actually like talking to people in person and having those chats at their desk or coffee machine. However even I wasn’t ready for the noisy environment at a cubicle. Over the course of the pandemic I forgot how tough they make it to focus and now would much rather work from home!
If they want people to come into office willingly, something needs to seriously change. Perhaps change hours from 9-17 to 9-14 for people coming into the office. The output would likely drop but perhaps that's what you need to do if you want people to want to come back to the office.
The worst of many options where you are forced to live in a city and work in a small apartment or drive from a distance in and you lose your desk and other perks.
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-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 :)
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.
Yes you're right. Has anyone who's been successfully hired as an international contractor by SV companies got any tips for how they made the relevant contacts?
I may consider full-time but I hear people in the US work insane hours which I've no intention of doing.
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?
I got Covid last month. I have the vaccine and a booster and it still took me out for a week. Why should I continue to risk re-infection and long Covid? Do I wear a mask while in Zoom calls if I'm sitting in a shared area? Do I have to call out coworkers not wearing a mask? Will the next variants actually cause less severe symptoms or is that just wishful thinking? Am I overreacting or not? There are a thousand questions that I just don't have to deal with if I just choose to work from home permanently.
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 had to go into the office for the Fortune 500 company I work for; talked to the security guard and was told that every Monday they are handed a stack of security badges to process and remove from the system--people inform their managers they are leaving on Friday and hand in their badge.
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 curious part is that the Green New Deal invest in WFH, at least in advertisement, and IT giants have formally done the same to sell services...
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.
It’s just so ridiculous to me that all these companies were forced to experience how remote work can work, yet they are choosing to pursue hard-line RTO policies, talent be damned.
I’m loving the companies that are trying to force workers back to the office. I just troll on LI for the announcements and then target their devs. It’s never been easier to recruit. Employers can’t win this but I’m glad so many are trying.
Maybe? I think it will take time to know who the winners and losers are. It might be good for your recruiting numbers right now, but market performance over an extended period will decide winners and losers.
It's weird this is even NEWS. So many jobs could always have been done remotely, and now post-COVID we can see that.
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.
193 comments
[ 2.7 ms ] story [ 253 ms ] threadI 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.
[0]: http://blog.dijit.sh/how-to-survive-an-open-office
[1]: https://news.ycombinator.com/item?id=20469880
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.
https://www.joelonsoftware.com/2003/09/24/bionic-office/
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.
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.
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"?
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.
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.
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 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.
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
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.
'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 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.
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.
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.
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.
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.
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.