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.

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.

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.

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.

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.

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.

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.

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!

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?

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'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.

> 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 not less dedicated to my current company than before COVID.

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.

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.

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.

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.

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.

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.

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.

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.

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.

At least, that’s how too many places still do technical interviews.