5 ms·

I have a question for anyone to answer who feels qualified to do so. I'm a dev who's been working for about 5 years, degree in CS, focus on JS front-end. I wo

I have a question for anyone to answer who feels qualified to do so. I'm a dev who's been working for about 5 years, degree in CS, focus on JS front-end. I would love to do remote and skip the commute, but I'm afraid to, mostly because impostor syndrome: while I'm a good coder, I tend to run into roadblocks involving the code written by other people (e.g. "I can't see where this is getting called from; I tried searching the codebase and don't see it anywhere...what is it for?" or else with the toolchain / build system (e.g. "The wiki really does not explain how to get this running locally at all, and these components are not compatible and I'm getting a version error from this, I'm really not sure what to do; tried googling extensively with no luck.") I always seem to be the only one who has these problems. While I tend to do well in person by being nice and asking a lot of questions, I'm concerned I may be a poor fit for a remote role as it requires a high degree of autonomy. What do you think? Have you encountered these problems and still succeeded at remote work?

brandon272 10y ago
I think increased autonomy is the wrong way to look at it. Typically you will still be part of a team and will be encouraged and required to collaborate with coworkers to solve problems and get questions answered. You'll just be doing it over Skype or Slack or whatever other communication tools are there instead of in person.
- tkhoven 10y ago
  Agreed - I've been in a fully remote team collaborating pretty intensively with other team members, screen sharing and pair programming over Skype/Screenhero/TeamViewer or whatever the designated tool is. Asking questions through irc/Slack means that communication is a little more asynchronous than face to face but we'd use short Skype sessions when we needed to be a little more involved. Increased autonomy can be part of it but it really depends on your workplace.
lazypenguin 10y ago
I can provide my anecdotal current experience. I just started a new role in a remote position with less "work experience" (vs. personal projects) than you and I can say that the autonomy is not an issue. I'm working on a complex, undocumented, "created-here" and over-engineered C++ code base left behind by a senior programmer and have found there to not be an issue. Granted there is a bit of a ramp-up time as I'm learning the code base but I ask questions in our chat application whenever I get stuck and my teammates are pretty responsive. I've actually found that I'm more productive/learn the code base more when I'm remote than when I visit and work in the office. In the office I use the other programmers as a crutch and they end up spoon-feeding me the solutions because it's easier for them. Remote, I make more of an effort to understand the components independently. I wouldn't be too worried about "getting stuck" in the code. The larger and uglier the project, the slower it is to learn the components but I've learned to embrace getting stuck. It's part of the process and once you've figured it out you know that small part of the code base a little better.
devman 10y ago
Yes, being autonomous is one of the most important traits I look for when hiring for my team (Disclaimer: I lead a distributed engineering team of 22). Whether you are can be a good fit or no depends on how frequently you need to ask your teammates a question. If you need to do that say once a day, I would say that is fine. If you are part of a distributed who are in different timezones then to be productive you will have to learn how to remove the roadblocks yourself. Now if you need to do that every 10 minutes then I would say it is a problem and not just a poor fit for remote work but a general problem that can be bad in a co-located team as well. Most of developers are going to dislike interruptions no matter how nicely you do that.
finnh 10y ago
This is a great question, and you're right - you may want to defer full-time remote work until you're most experienced. As a somewhat junior developer (don't take that the wrong way, I'm just talking about years-in-industry) one of the most important ways for you to get better is through osmosis with the more senior members of your team. A remote non-senior employee is less likely to witness, much less participate in, unscheduled design discussions or quick whiteboarding.
codingdave 10y ago
Everyone has questions for their team members, including remote devs. It is just a matter of getting used to asking them via different tools. For small, non-time sensitive questions, email still works. But frequently, we'll get on google hangouts with each other and spend 30 minutes or so not only answering the immediate questions, but chatting in general, about work and more. It is part of what keeps us working well as a team, and not turning into individual remote silos.
mikekchar 10y ago
My main advice if you want to work remotely and you have those kinds of issues is to stick to the timezone of the company you are working for. I've done pair programming effectively remotely for long periods of time. I actually enjoy doing it remotely better (more control over your environment, more comfort, etc). As long as the team is open to interaction and has a mechanism for doing it, there is no problem. If you get too far out of the timezone, though, it is really difficult to organise overlapping sessions (I'm currently +9 with my team mates and it means I almost never have a "normal" working day). Confidence is also quite important IMHO. It's easy to start doubting your ability when you have nobody else to compare to. If you have a bad day (as everyone does from time to time) and end up getting nothing done, you need to be OK with that. If you run and hide, it can pile up on you. One thing you might try is to convince your current employer to try doing 1 day a week remote. This will let you get your feet wet without a lot of risk. If you have problems, you're back at the office the next day. My current employer did that and it worked so well that most people are free to work in the office or not as they choose from day to day. There are many people who now work permanently remotely as well.

brandon272 10y ago

I think increased autonomy is the wrong way to look at it. Typically you will still be part of a team and will be encouraged and required to collaborate with coworkers to solve problems and get questions answered. You'll just be doing it over Skype or Slack or whatever other communication tools are there instead of in person.

tkhoven 10y ago
Agreed - I've been in a fully remote team collaborating pretty intensively with other team members, screen sharing and pair programming over Skype/Screenhero/TeamViewer or whatever the designated tool is. Asking questions through irc/Slack means that communication is a little more asynchronous than face to face but we'd use short Skype sessions when we needed to be a little more involved. Increased autonomy can be part of it but it really depends on your workplace.

lazypenguin 10y ago

I can provide my anecdotal current experience. I just started a new role in a remote position with less "work experience" (vs. personal projects) than you and I can say that the autonomy is not an issue. I'm working on a complex, undocumented, "created-here" and over-engineered C++ code base left behind by a senior programmer and have found there to not be an issue. Granted there is a bit of a ramp-up time as I'm learning the code base but I ask questions in our chat application whenever I get stuck and my teammates are pretty responsive. I've actually found that I'm more productive/learn the code base more when I'm remote than when I visit and work in the office. In the office I use the other programmers as a crutch and they end up spoon-feeding me the solutions because it's easier for them. Remote, I make more of an effort to understand the components independently. I wouldn't be too worried about "getting stuck" in the code. The larger and uglier the project, the slower it is to learn the components but I've learned to embrace getting stuck. It's part of the process and once you've figured it out you know that small part of the code base a little better.

devman 10y ago

Yes, being autonomous is one of the most important traits I look for when hiring for my team (Disclaimer: I lead a distributed engineering team of 22). Whether you are can be a good fit or no depends on how frequently you need to ask your teammates a question. If you need to do that say once a day, I would say that is fine. If you are part of a distributed who are in different timezones then to be productive you will have to learn how to remove the roadblocks yourself. Now if you need to do that every 10 minutes then I would say it is a problem and not just a poor fit for remote work but a general problem that can be bad in a co-located team as well. Most of developers are going to dislike interruptions no matter how nicely you do that.

finnh 10y ago

This is a great question, and you're right - you may want to defer full-time remote work until you're most experienced. As a somewhat junior developer (don't take that the wrong way, I'm just talking about years-in-industry) one of the most important ways for you to get better is through osmosis with the more senior members of your team. A remote non-senior employee is less likely to witness, much less participate in, unscheduled design discussions or quick whiteboarding.

codingdave 10y ago

Everyone has questions for their team members, including remote devs. It is just a matter of getting used to asking them via different tools. For small, non-time sensitive questions, email still works. But frequently, we'll get on google hangouts with each other and spend 30 minutes or so not only answering the immediate questions, but chatting in general, about work and more. It is part of what keeps us working well as a team, and not turning into individual remote silos.

mikekchar 10y ago

My main advice if you want to work remotely and you have those kinds of issues is to stick to the timezone of the company you are working for. I've done pair programming effectively remotely for long periods of time. I actually enjoy doing it remotely better (more control over your environment, more comfort, etc). As long as the team is open to interaction and has a mechanism for doing it, there is no problem. If you get too far out of the timezone, though, it is really difficult to organise overlapping sessions (I'm currently +9 with my team mates and it means I almost never have a "normal" working day). Confidence is also quite important IMHO. It's easy to start doubting your ability when you have nobody else to compare to. If you have a bad day (as everyone does from time to time) and end up getting nothing done, you need to be OK with that. If you run and hide, it can pile up on you. One thing you might try is to convince your current employer to try doing 1 day a week remote. This will let you get your feet wet without a lot of risk. If you have problems, you're back at the office the next day. My current employer did that and it worked so well that most people are free to work in the office or not as they choose from day to day. There are many people who now work permanently remotely as well.