9 ms·

I rarely work remote even when I have the opportunity to do it; I'll explain. The author seems to have a single-mindedness about optimizing their own performan

I rarely work remote even when I have the opportunity to do it; I'll explain. The author seems to have a single-mindedness about optimizing their own performance. If performance in terms of your value to the business was about sitting down at a computer and coding, getting in a "flow" state, etc, I would agree. Problem is, personal efficiency doesn't necessarily align with value generated. I've seen engineers spend months regularly obtaining "flow" with few interruptions or meetings, only to have the projects scrapped because they weren't what the business needed. The fact that the code was immaculate didn't end up mattering at all. Informal, personal communication can make a big difference. Yes, getting up and talking to someone is more efficient than starting an email thread or slack conversation in many cases. Many of those conversations are engineer to engineer and involve important technical decisions. And, an aside: remote meetings are simply worse than in-person meetings. Having worked on several teams where some members were in completely different locations (and time zones), I never want to experience that again. Give me every person relevant to my work in the same physical space; I don't want to get blocked from doing my work because you've gone dark on slack. I promise, I get it. If I had my way, I'd work on whatever I wanted to work on, with no meetings or interruptions. I'd just be a lone wolf cranking out awesome features and feeling great about it. That's just not what any business needs, and it's certainly not what they pay me for.

NumberSix 10y ago
There are the notions of: o clear written requirements expressing the business and high level technical needs. o well defined acceptance test procedures to ensure that the delivered software (or hardware or whatever) meets those requirements o thoughtful partitioning of the work between team members to minimize the needed communication and enable the team members to focus and work on their part without having a committee meeting every few minutes on every minor issue. None of these are new practices. They, or something similar, is needed to work effectively remotely or for that matter in quiet offices with closed doors.
- d357r0y3r 10y ago
  These are good ideals and they're hard to get right in practice. There's always a certain amount of ambiguity that arises when pen meets paper and it's ambiguity that puts any given task at risk of being done incorrectly or not at all. A positive trait in an engineer is the ability to resolve ambiguity. That isn't to say that all ambiguity can be solved by a single engineer working in isolation, though. What you don't want is people going with their best guess in an isolated, unilateral fashion, so you need good ways of handling uncertainty when it inevitably comes up. My contention is that, according to my experience, remote work results in a "dead in the water" status more often than office work.
  - NumberSix 10y ago
    A few points. I have seen remote work go very smoothly and go very badly. It depends a lot on how well specified the remote work is. The "agile" and "issue tracker" methods currently popular do not teach good organizational and design skills needed to partition projects well for remote work. We've gone from one extreme -- rigid up front requirements and designs, the much maligned "waterfall" -- to the other extreme of disorganized, short-term chaos where the big picture is lost. Micromanagement without the big picture planning that is the proper role of project managers. The OP is arguing for remote work versus cramped, noisy, interruption filled open offices modeled on garment industry sweat shops. Somehow most companies are doing this as if they got together in a back room somewhere and formed a cartel to impose garment industry working conditions in a bizarre attempt to magically lower costs by pretending engineers are seamstresses from poverty stricken nations making sub-minimum wages doing piece-work. Are quiet offices either with high-walled quiet cubicles or offices with doors where engineers can concentrate and focus on difficult work but still walk over to someone and quietly discuss a pressing issue better than remote work? Probably so, but these sensible working environments seemed to have been banned by some mysterious executive decree.
- alanmackenzie 10y ago
  These are all valid points but many organisations are not at the level of maturity where the inputs to the engineering team are of the high quality you're describing. Additionally there's an element of negotiation or dialogue around requirements which can often lead to cheaper/quicker to market/better solutions with input from engineering. Both of these are much easier to do in person.
babyrainbow 10y ago
I don't get you. What does a developer has to do with deciding what the business needs? If your job is that, ie, figuring out what a business needs, then by all means work closely with people..But I am not sure that is the type of work being discussed in this context.
- d357r0y3r 10y ago
  > I don't get you. What does a developer has to do with deciding what the business needs? If your job is that, ie, figuring out what a business needs, then by all means work closely with people..But I am not sure that is the type of work being discussed in this context. Well, if you're a rank and file engineer, your "job" isn't explicitly to figure out what the business needs. However, if you care about becoming more valuable over time, you owe it to yourself to understand why the business values you. The business doesn't care about the code itself, it only cares about the solutions the code creates. If it's slow, that's a problem. If it's buggy, that's a problem. My instincts tell me to accept nothing less than purity, but a business needs pragmatism and "good enough".
  - nerdy 10y ago
    This is the fundamental difference between great engineers and the rest. Just giving a damn and being engaged. Seriously.
    - sotojuan 10y ago
      On the other hand, most jobs and companies don't warrant being caring about aside from the salary and resume padding (hence the trend of leaving a job every other year).
- discordianfish 10y ago
  I actually think this illustrates the main problem with all these opinion pieces: They depend heavily on the authors experience. I only work in startups where I feel people expect me to know the business needs, I wouldn't want to work at a place where somebody 'breaks down' the business needs in small packages which need no knowledge about the business needs to implement. I think 'the good' startups realize that this old pattern doesn't work if you try to be innovative and agile.
secstate 10y ago
I think we'll have to agree to disagree here. If you're heads-down on a project and it's not contributing to the value of the product, there are other issues with your business than remote-v-office culture. If pivoting your engineering goals requires hallway conversations, there's something wrong. To be sure, not everyone is cut out for remote work, the same way not everyone is cut out for office work. For my part, I can't fathom going back to regular office work. I found I was frequently disrupted by hallway conversations and "just want to bounce this off you" pivots and were nothing but frustrating. To say nothing about the fact that my commute time now hang out with my family time.
- discordianfish 10y ago
  > If pivoting your engineering goals requires hallway conversations, there's something wrong. I agree but isn't there always something wrong? I'm in that spot, I worked mostly remote for the past 4 years and at every company it would have helped a lot to have a casual hallway conversation from time to time. It shouldn't be necessary but in reality it often is. It seem to me like you need well thought out, light weight processes to make this work. I think it should work, but I never saw it working myself..
  - secstate 10y ago
    That's a fair point. But in my limited sample size, there are plenty of companies that at least for a few years function just fine with full remote.
  - elif 10y ago
    Do none of those companies utilize chat? My experience with "open office" arrangements is that most of the conversation (important and casual) takes place in chats anyway--even between people sitting right next to eachother--because generally people don't want to distract uninvolved parties.
    - gtaylor 10y ago
      > Do none of those companies utilize chat? Sure they do. But you're going to miss adhoc conversations that people in the same physical location have. Remote people aren't left out on purpose, but many times this chatter doesn't warrant saying "Hold on, let's not talk to each other's faces. Better do this on Slack.". Source: Worked remote for about four years, really missed these kinds of random chatter.
up_and_up 10y ago
> only to have the projects scrapped because they weren't what the business needed. That is most definitely not the programmers fault whatsoever. Scope, feature set, product/market fit, and current status should be reviewed on a weekly basis by a product owner or project manager. If a general contractor builds you the house you demanded 6 months ago but your not happy with it now, who's fault is that? > remote meetings are simply worse than in-person meetings You give no explanation as your reasoning for this. Generally speaking, all meetings need to have an organized flow. I work on a team of 15 people where we can easily cover all our checkins remotely in under an hour. One meeting per week.
- ryandrake 10y ago
  > If a general contractor builds you the house you demanded 6 months ago but your not happy with it now, who's fault is that? Blame is not easily assigned in this scenario. If your requirements changed have you conveyed these changes to the builder? Did the builder periodically reach out to checkpoint with you and get feedback? Communication is a two way street. No professional developer anymore can turn off their E-mail and phone and "turtle up" in their office, coding away in a vacuum. Only the most trivial software can be developed that way.
snarf21 10y ago
I agree with you. I personally am much more distracted at home because "I'm home". When I'm at work, I'm in work mode. I also find that I solve a lot of yesterdays roadblocks during my commute (20 mins each way) and the shower. Solving problems is not always about characters per second of new code. Over the years, I can't even count the number of times that I heard a conversation taking place and was able to step in and say "that's wrong" and stop several people from a multiple day detour. I do think 40 person open spaces are bad but small ones for a team of 2-5 that are all working on the same project are great (ideal imo), especially in a sealed room with lots of white boards, etc. I do think that remote will become more and more common as companies see it as a way to reduce costs. It seems like the author is mainly concerned about what is best for them, not the team. Requirements and clarifications constantly evolve. It is expensive to have every requirement exactly defined with full test cases when you aren't sure what you need to build. Being involved in that process gets everyone to good enough quicker. Also, I'm not sure what to do when a customer calls (8-6, presumably) and has an issue and the night owl is the one who knows that part of the system, telling the customer to call back at 1:00 cause that's when Bob is awake seems pretty silly. Most tech companies have hours ~8-6, because that is their customers hours too, not out of a mandate to irritate employees. I do agree with the author that if the employer only cares about butts in seats, then it is a bad place to work but that has nothing to do with remote vs on site.
- porpoisemonkey 10y ago
  > personally am much more distracted at home because "I'm home". When I'm at work, I'm in work mode. Not sure if you've tried this or if it's practical for you, but I've found that having a completely dedicated space, with dedicated tools, can create a working context that helps boost productivity. I won't name them due to privacy concerns but my company has been very good about dealing with remote workers and provides a basic set of office amenities to any worker who is selected to go remote (convertible standup desk, remote access point with office telephone, all-in-one printer w/ ink refills, etc.) > Over the years, I can't even count the number of times that I heard a conversation taking place and was able to step in and say "that's wrong" and stop several people from a multiple day detour. I'm not sure what your experience is but a trend I've noticed is that this tends to occur when only a subset of team members are remote - in fully-remote teams the use of collaboration tools (mailing lists, Jabber, IRC, etc) can often replicate these kinds of ad-hoc conversations with the added bonus of automatically capturing the information discussed. I generally think environments where ad-hoc conversations are necessary to maintain overall effectiveness as being tool deficient.
jasonpeacock 10y ago
"I don't want to get blocked from doing my work because you've gone dark on slack." That's poor project/task management if your whole day grinds to a halt because of a single blocker. There should always be more/other work to be done while waiting on a blocking issue to be resolved.
- xemdetia 10y ago
  Many people are in situations where task stand up and tear down are the most expensive things in their universe. If something comes up after you have spent 20 to an hour standing everything up but you need someone to do one thing, context switching will be brutal. If you are in the same physical location at worst case you can go find them, or you can ask around to know when they are next available. If they are 100 miles away on slack and not responding or otherwise not being able to get a hold of them, you are blocked and now have to swap to something else.
- deleted 10y ago
  [deleted]
dahart 10y ago
Really well said. It has taken me a long time in my career to realize the things I wanted - to be left alone to code - weren't translating into the product getting done any faster when I actually was left alone. I've watched other programmers fight for and get left alone, and then watched as they went off into the weeds coding things that solved problems we didn't have. Sometimes being left alone even increases my stress and reduces my productivity in the long run because I choose to work on harder problems and try to solve things I think people want, only to discover after I deliver that it wasn't very helpful and I could have chosen something much simpler to do and finished faster. In the mean time, I've delivered more code and increased technical debt more than I should have, and I end up getting interrupted with more maintenance issues down the road.
- citizens 10y ago
  > coding things that solved problems we didn't have Couldn't this be solved by using a project management app?
  - dahart 10y ago
    In my experience, no. Project management apps don't substitute for communication very well, and things tend to get worse and not better when apps are expected to carry important discussions. If tasks are cut and dried, specified precisely, with no decisions to make, and no input from the engineer, then apps might help a lot. I've never had very much work of that sort, I'm usually highly involved in the discussions about what should be done and how it should be done. Worth noting that the experiences I'm talking about, watching programmers go off the rails, and going off the rails myself, many involved the use of various project management, tracking and review tools. It's not true for all projects or all programmers, I make no absolute claims. But my personal experience has been that figuring out the right approach to anything that takes more than a couple of days takes multiple conversations no matter what. My personal experience has been that tasks that run longer than a week almost always need one or more course corrections before they're complete.
    - babyrainbow 10y ago
gozur88 10y ago
>I've seen engineers spend months regularly obtaining "flow" with few interruptions or meetings, only to have the projects scrapped because they weren't what the business needed. That's just a sign of bad or nonexistent management. If you're managing remote people you need to know what they're working on, and you need to make sure it's aligned with the company's goals. If that's not happening you're not doing your job.
taurath 10y ago
> Having worked on several teams where some members were in completely different locations (and time zones), I never want to experience that again. Give me every person relevant to my work in the same physical space; I don't want to get blocked from doing my work because you've gone dark on slack. If the office is online, going offline means leaving the office. There's a WORLD of difference between a meeting when 5 people are in an office and 5 are online, and a meeting when 10 people are all online. When everyone is online it works about as well as an in person meeting, and frequently better because conversations tend to be more direct. That said, having no personal rapport can be a big problem on remote teams - were I to set one up there would be minimum quarterly physical meetings, with most of the purpose being to socialize and sync on new models rather than sit and do normal work. Having 1-1 vidcalls just to "work together" has been very nice as well. Once you get out of the idea that a video call has to be a meeting I'd say you can get 95% of the way to a physical space. Does not work for every engineer however.
dennisgorelik 10y ago
Good points, but why not do voice (Skype) calls while working remotely? Voice + screen sharing is about as efficient as a face-to-face conversation. And if you need to sync your working time with other team members - how is that a problem in remote environment?
- free652 10y ago
  >Voice + screen sharing is about as efficient as a face-to-face conversation. Not even close. It's doable, but not as efficient.
- deleted 10y ago
  [deleted]
jasoncchild 10y ago
A good deal of this comes down personalities; yours and the rest of the team. Even with tooling it can be difficult to stay connected...but for someone else it could be difficult to stay focused with the ambiance that comes with a lot of "modern" office configs.

NumberSix 10y ago

There are the notions of: o clear written requirements expressing the business and high level technical needs. o well defined acceptance test procedures to ensure that the delivered software (or hardware or whatever) meets those requirements o thoughtful partitioning of the work between team members to minimize the needed communication and enable the team members to focus and work on their part without having a committee meeting every few minutes on every minor issue. None of these are new practices. They, or something similar, is needed to work effectively remotely or for that matter in quiet offices with closed doors.

d357r0y3r 10y ago
These are good ideals and they're hard to get right in practice. There's always a certain amount of ambiguity that arises when pen meets paper and it's ambiguity that puts any given task at risk of being done incorrectly or not at all. A positive trait in an engineer is the ability to resolve ambiguity. That isn't to say that all ambiguity can be solved by a single engineer working in isolation, though. What you don't want is people going with their best guess in an isolated, unilateral fashion, so you need good ways of handling uncertainty when it inevitably comes up. My contention is that, according to my experience, remote work results in a "dead in the water" status more often than office work.
- NumberSix 10y ago
  A few points. I have seen remote work go very smoothly and go very badly. It depends a lot on how well specified the remote work is. The "agile" and "issue tracker" methods currently popular do not teach good organizational and design skills needed to partition projects well for remote work. We've gone from one extreme -- rigid up front requirements and designs, the much maligned "waterfall" -- to the other extreme of disorganized, short-term chaos where the big picture is lost. Micromanagement without the big picture planning that is the proper role of project managers. The OP is arguing for remote work versus cramped, noisy, interruption filled open offices modeled on garment industry sweat shops. Somehow most companies are doing this as if they got together in a back room somewhere and formed a cartel to impose garment industry working conditions in a bizarre attempt to magically lower costs by pretending engineers are seamstresses from poverty stricken nations making sub-minimum wages doing piece-work. Are quiet offices either with high-walled quiet cubicles or offices with doors where engineers can concentrate and focus on difficult work but still walk over to someone and quietly discuss a pressing issue better than remote work? Probably so, but these sensible working environments seemed to have been banned by some mysterious executive decree.
alanmackenzie 10y ago
These are all valid points but many organisations are not at the level of maturity where the inputs to the engineering team are of the high quality you're describing. Additionally there's an element of negotiation or dialogue around requirements which can often lead to cheaper/quicker to market/better solutions with input from engineering. Both of these are much easier to do in person.

babyrainbow 10y ago

I don't get you. What does a developer has to do with deciding what the business needs? If your job is that, ie, figuring out what a business needs, then by all means work closely with people..But I am not sure that is the type of work being discussed in this context.

d357r0y3r 10y ago
> I don't get you. What does a developer has to do with deciding what the business needs? If your job is that, ie, figuring out what a business needs, then by all means work closely with people..But I am not sure that is the type of work being discussed in this context. Well, if you're a rank and file engineer, your "job" isn't explicitly to figure out what the business needs. However, if you care about becoming more valuable over time, you owe it to yourself to understand why the business values you. The business doesn't care about the code itself, it only cares about the solutions the code creates. If it's slow, that's a problem. If it's buggy, that's a problem. My instincts tell me to accept nothing less than purity, but a business needs pragmatism and "good enough".
- nerdy 10y ago
  This is the fundamental difference between great engineers and the rest. Just giving a damn and being engaged. Seriously.
  - sotojuan 10y ago
    On the other hand, most jobs and companies don't warrant being caring about aside from the salary and resume padding (hence the trend of leaving a job every other year).
discordianfish 10y ago
I actually think this illustrates the main problem with all these opinion pieces: They depend heavily on the authors experience. I only work in startups where I feel people expect me to know the business needs, I wouldn't want to work at a place where somebody 'breaks down' the business needs in small packages which need no knowledge about the business needs to implement. I think 'the good' startups realize that this old pattern doesn't work if you try to be innovative and agile.

secstate 10y ago

I think we'll have to agree to disagree here. If you're heads-down on a project and it's not contributing to the value of the product, there are other issues with your business than remote-v-office culture. If pivoting your engineering goals requires hallway conversations, there's something wrong. To be sure, not everyone is cut out for remote work, the same way not everyone is cut out for office work. For my part, I can't fathom going back to regular office work. I found I was frequently disrupted by hallway conversations and "just want to bounce this off you" pivots and were nothing but frustrating. To say nothing about the fact that my commute time now hang out with my family time.

discordianfish 10y ago
> If pivoting your engineering goals requires hallway conversations, there's something wrong. I agree but isn't there always something wrong? I'm in that spot, I worked mostly remote for the past 4 years and at every company it would have helped a lot to have a casual hallway conversation from time to time. It shouldn't be necessary but in reality it often is. It seem to me like you need well thought out, light weight processes to make this work. I think it should work, but I never saw it working myself..
- secstate 10y ago
  That's a fair point. But in my limited sample size, there are plenty of companies that at least for a few years function just fine with full remote.
- elif 10y ago
  Do none of those companies utilize chat? My experience with "open office" arrangements is that most of the conversation (important and casual) takes place in chats anyway--even between people sitting right next to eachother--because generally people don't want to distract uninvolved parties.
  - gtaylor 10y ago
    > Do none of those companies utilize chat? Sure they do. But you're going to miss adhoc conversations that people in the same physical location have. Remote people aren't left out on purpose, but many times this chatter doesn't warrant saying "Hold on, let's not talk to each other's faces. Better do this on Slack.". Source: Worked remote for about four years, really missed these kinds of random chatter.

up_and_up 10y ago

> only to have the projects scrapped because they weren't what the business needed. That is most definitely not the programmers fault whatsoever. Scope, feature set, product/market fit, and current status should be reviewed on a weekly basis by a product owner or project manager. If a general contractor builds you the house you demanded 6 months ago but your not happy with it now, who's fault is that? > remote meetings are simply worse than in-person meetings You give no explanation as your reasoning for this. Generally speaking, all meetings need to have an organized flow. I work on a team of 15 people where we can easily cover all our checkins remotely in under an hour. One meeting per week.

ryandrake 10y ago
> If a general contractor builds you the house you demanded 6 months ago but your not happy with it now, who's fault is that? Blame is not easily assigned in this scenario. If your requirements changed have you conveyed these changes to the builder? Did the builder periodically reach out to checkpoint with you and get feedback? Communication is a two way street. No professional developer anymore can turn off their E-mail and phone and "turtle up" in their office, coding away in a vacuum. Only the most trivial software can be developed that way.

snarf21 10y ago

I agree with you. I personally am much more distracted at home because "I'm home". When I'm at work, I'm in work mode. I also find that I solve a lot of yesterdays roadblocks during my commute (20 mins each way) and the shower. Solving problems is not always about characters per second of new code. Over the years, I can't even count the number of times that I heard a conversation taking place and was able to step in and say "that's wrong" and stop several people from a multiple day detour. I do think 40 person open spaces are bad but small ones for a team of 2-5 that are all working on the same project are great (ideal imo), especially in a sealed room with lots of white boards, etc. I do think that remote will become more and more common as companies see it as a way to reduce costs. It seems like the author is mainly concerned about what is best for them, not the team. Requirements and clarifications constantly evolve. It is expensive to have every requirement exactly defined with full test cases when you aren't sure what you need to build. Being involved in that process gets everyone to good enough quicker. Also, I'm not sure what to do when a customer calls (8-6, presumably) and has an issue and the night owl is the one who knows that part of the system, telling the customer to call back at 1:00 cause that's when Bob is awake seems pretty silly. Most tech companies have hours ~8-6, because that is their customers hours too, not out of a mandate to irritate employees. I do agree with the author that if the employer only cares about butts in seats, then it is a bad place to work but that has nothing to do with remote vs on site.

porpoisemonkey 10y ago
> personally am much more distracted at home because "I'm home". When I'm at work, I'm in work mode. Not sure if you've tried this or if it's practical for you, but I've found that having a completely dedicated space, with dedicated tools, can create a working context that helps boost productivity. I won't name them due to privacy concerns but my company has been very good about dealing with remote workers and provides a basic set of office amenities to any worker who is selected to go remote (convertible standup desk, remote access point with office telephone, all-in-one printer w/ ink refills, etc.) > Over the years, I can't even count the number of times that I heard a conversation taking place and was able to step in and say "that's wrong" and stop several people from a multiple day detour. I'm not sure what your experience is but a trend I've noticed is that this tends to occur when only a subset of team members are remote - in fully-remote teams the use of collaboration tools (mailing lists, Jabber, IRC, etc) can often replicate these kinds of ad-hoc conversations with the added bonus of automatically capturing the information discussed. I generally think environments where ad-hoc conversations are necessary to maintain overall effectiveness as being tool deficient.

jasonpeacock 10y ago

"I don't want to get blocked from doing my work because you've gone dark on slack." That's poor project/task management if your whole day grinds to a halt because of a single blocker. There should always be more/other work to be done while waiting on a blocking issue to be resolved.

xemdetia 10y ago
Many people are in situations where task stand up and tear down are the most expensive things in their universe. If something comes up after you have spent 20 to an hour standing everything up but you need someone to do one thing, context switching will be brutal. If you are in the same physical location at worst case you can go find them, or you can ask around to know when they are next available. If they are 100 miles away on slack and not responding or otherwise not being able to get a hold of them, you are blocked and now have to swap to something else.
deleted 10y ago
[deleted]

dahart 10y ago

Really well said. It has taken me a long time in my career to realize the things I wanted - to be left alone to code - weren't translating into the product getting done any faster when I actually was left alone. I've watched other programmers fight for and get left alone, and then watched as they went off into the weeds coding things that solved problems we didn't have. Sometimes being left alone even increases my stress and reduces my productivity in the long run because I choose to work on harder problems and try to solve things I think people want, only to discover after I deliver that it wasn't very helpful and I could have chosen something much simpler to do and finished faster. In the mean time, I've delivered more code and increased technical debt more than I should have, and I end up getting interrupted with more maintenance issues down the road.

citizens 10y ago
> coding things that solved problems we didn't have Couldn't this be solved by using a project management app?
- dahart 10y ago
  In my experience, no. Project management apps don't substitute for communication very well, and things tend to get worse and not better when apps are expected to carry important discussions. If tasks are cut and dried, specified precisely, with no decisions to make, and no input from the engineer, then apps might help a lot. I've never had very much work of that sort, I'm usually highly involved in the discussions about what should be done and how it should be done. Worth noting that the experiences I'm talking about, watching programmers go off the rails, and going off the rails myself, many involved the use of various project management, tracking and review tools. It's not true for all projects or all programmers, I make no absolute claims. But my personal experience has been that figuring out the right approach to anything that takes more than a couple of days takes multiple conversations no matter what. My personal experience has been that tasks that run longer than a week almost always need one or more course corrections before they're complete.
  - babyrainbow 10y ago

gozur88 10y ago

>I've seen engineers spend months regularly obtaining "flow" with few interruptions or meetings, only to have the projects scrapped because they weren't what the business needed. That's just a sign of bad or nonexistent management. If you're managing remote people you need to know what they're working on, and you need to make sure it's aligned with the company's goals. If that's not happening you're not doing your job.

taurath 10y ago

> Having worked on several teams where some members were in completely different locations (and time zones), I never want to experience that again. Give me every person relevant to my work in the same physical space; I don't want to get blocked from doing my work because you've gone dark on slack. If the office is online, going offline means leaving the office. There's a WORLD of difference between a meeting when 5 people are in an office and 5 are online, and a meeting when 10 people are all online. When everyone is online it works about as well as an in person meeting, and frequently better because conversations tend to be more direct. That said, having no personal rapport can be a big problem on remote teams - were I to set one up there would be minimum quarterly physical meetings, with most of the purpose being to socialize and sync on new models rather than sit and do normal work. Having 1-1 vidcalls just to "work together" has been very nice as well. Once you get out of the idea that a video call has to be a meeting I'd say you can get 95% of the way to a physical space. Does not work for every engineer however.

dennisgorelik 10y ago

Good points, but why not do voice (Skype) calls while working remotely? Voice + screen sharing is about as efficient as a face-to-face conversation. And if you need to sync your working time with other team members - how is that a problem in remote environment?

free652 10y ago
>Voice + screen sharing is about as efficient as a face-to-face conversation. Not even close. It's doable, but not as efficient.
deleted 10y ago
[deleted]

jasoncchild 10y ago

A good deal of this comes down personalities; yours and the rest of the team. Even with tooling it can be difficult to stay connected...but for someone else it could be difficult to stay focused with the ambiance that comes with a lot of "modern" office configs.