Hacker News Reader

Comment by ryanSrich | Hacker News Reader

Of course this is happening.

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.

View on HN

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.

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.

The reason I mentioned my title is that I don’t think many would consider a CTO an IC. Saying remote and async only works as an IC is wrong.

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

Bad analogies are not very persuasive

If you think software development can be a collaborative creative process, it’s really not a terrible analogy.

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.

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

Where do these clear specs come from? That’s the creative process I’m talking about.

Your not the bass player you are the record label worrying about if a single exists.

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.

Surely it would be managers or executives that would be analogous to the record label executives. We’re talking about ICs on a collaborative team.

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.

Remote doesn't mean asynchronous, unless timezones/working hours are very different.

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.

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.

respectfully, you completely misread my comment.

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

I don't feel like your arguments support your assertion. There are multiple ways to run a company/do business/ship products.

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 disagree. Y team sits in Montreal. Not my choice but I'm fine with it

I'm not less dedicated to my current company than before COVID.

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.

Football players are mercenaries but they still work synchronously with teamlmates.

I'm more than mercenary for my family, friends, co-religionists, and above all – god. But yeah, I don't care a bit about my boss, and "co-workers".

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 like most of my coworkers and are friends of some offline. But I see work transactional by definition.

What about brainstorming and problem solving?

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

How do you handle brainstorming sessions or design sessions where things are hard to solve, so there is no direct answer?

I love the idea of async, but there are just some sessions that are incredibly valuable and develop on others thoughts, evolving in a final solution.

At the company I work at, we compromise with a specific 4 hours overlap so that meetings can be scheduled only during those times

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

Personally I doubt that having face–to–face meetings is ever 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 was looking for my copy of Peopleware where I first read about it, but I cannot find it. Perhaps I loaned it out.

If you’re building software there’s really no reason you have to share working hours with anyone.

When I'm doing UI work, it's far more efficient to have a real-time session with a designer rather than multiple rounds of email/Figma comments.

Then one of you needs to work on your written communication skills.

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.

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

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

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

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.

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

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

And this can still happen under async. But I wouldn’t recommend it all the time. It just feels like a crutch for bad working practice.

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.

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.

Can you explain your day to day? And how do you keep up with company politics, changing requirements etc?

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.

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.

This is also true for competent engineers. No one knows everything.

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.

Reply on news.ycombinator.com