4 ms·

I've found, after coding+managing remotely[0], that it takes a specific set of traits to be a successful remote worker. - strong work ethic: no one needs to te

by mildbow 11y ago

I've found, after coding+managing remotely[0], that it takes a specific set of traits to be a successful remote worker. - strong work ethic: no one needs to tell you that it's time to start working for the day/after lunch etc. - strong communication: not the same as being an extrovert. might even help if you are an introvert. Just comfortable with text being the dominant means of articulation. - strong 9-5 boundaries: might not be 9-5, might not be exactly 8 hours, but they have work hours and non-work hours and adhere to them. - not junior: I've met a few junior devs who are good remote workers, but overwhelmingly most are seasoned. Maybe it just takes time to figure out the work-life balance/discipline integral to being an effective remote worker? - trustworthy: the kind of person you can hand off something to and know it will be done. - not great at ping pong: maybe those relate to the strong work ethic? That is, they never took/had time for honing ping pong skills at work ? Maybe that's just me :) I work remotely too so maybe the traits are biased towards the positive. [0] Team lead with one on ones + reviews for ~20 people.

err4nt 11y ago
Great list! I agree with all but the 9-5 premise. The thing that makes it easy for me is Git! Having all of our work stored in version control gives our team 100% accountability in a totally painless way. And if there's ever a project I'm working on outside of git, I do daily dump archives so each day is snapshotted. No need to track hours, no need to wonder what somebody did all day. If you want to know what I did last tuesday go check my commit! Version control = accountability and trust
- mildbow 11y ago
  The 9-5 premise is about having regular hours (whatever they are) so team members can get in touch if they need to. It's also about signaling when team members can't get in touch. Both are important since they are implicit to an office but something you need to be careful to correctly define/signal when you are working remotely. I don't really look at commit logs because, to me, they reflect how one prefers to work, rather than how productive they are being. 2 people can easily have 2 or 20 commits for the same feature set. I'm not going to be calling one a 10x engineer based on that :) To that end I don't believe in looking at commit log, or time tracking (!) because both can be falsified pretty easily: they are just another form of counting lines of code IMO. I prefer to look at how much customer value someone is delivering and how much other team members listen to them.
  - err4nt 11y ago
    I focus on delivering recurring value so we're on the same page. I also agree that communication should have clear hours regardless of when you work, so you can be reached when others need you, and you know when you can reach them. For us it gets a little stretched out because of the time zone difference too, but most of our communication happens through the ticket system. I'm not advocating numbers of lines of code or numbers of commits either, value is what's important, but having a daily, timestamped record of everything everybody did just takes all the question out of 'What did you do last Tuesday?', any of us could just go and check. Working with version control has been a _huge_ benefit to remote working because it provides a way that people who don't see each other can trust each other. It also ensures that nothing of value what was ever produced by anybody (and paid for) is ever lost, even if deleted. That's just smart business!
    - mildbow 11y ago
      That makes sense. I like the idea also of using it as a quick refresher to remind everyone/yourself what you were doing X days ago esp. during review time. Thanks!
enraged_camel 11y ago
Why the 9-5 boundary? Personally, I get my best work done during non-traditional hours, e.g. past midnight.
- firebones 11y ago
  I think it is figurative 9-5 rather than literal. In other words, knowing that there are boundaries and limits between work and non-work time instead of falling victim to the temptation of working all the time when you are at home.
- mildbow 11y ago
  From your team's perspective: It's so team members can get in touch if they need to. It's also about signaling when team members can't get in touch. Both are important since they are implicit to an office but something you need to be careful to correctly define/signal when you are working remotely. Note that it doesn't have to be 9-5 office time, just needs to be hours people expect to be able(and not able) to get in touch: 12-8 your local time? Go for it! Whatever works so you can maximize you and your team's work/life balance :) From a personal sanity perspective it's as firebones says in reply. FWIW, I -- and most engineers -- fall victim to the the personal sanity perspective rather more frequently.
  - enraged_camel 11y ago
    I'm available to the team most of the time, even on weekends. The more junior they are, the greater the effort I make to be available to them. But in my mind there is a difference between being available for questions/advice vs. actually working, e.g. designing a system or writing code. If someone messages me on a Saturday asking, "hey, which server do I log into to do X?" then taking the two minutes to reply means I'm available, but I don't think of it as "work".
    - mildbow 11y ago
      You are being a good short-term team member, but that might not be the best for you or the team in the long-term. If you/other senior devs are getting the same random questions, maybe create a faq/run book? I've usually made it a point to say: here's the answer, now can you add it to the FAQ? That way, ideally, I never have to answer it again/that's the first place people check.

by mildbow 11y ago

err4nt 11y ago

Great list! I agree with all but the 9-5 premise. The thing that makes it easy for me is Git! Having all of our work stored in version control gives our team 100% accountability in a totally painless way. And if there's ever a project I'm working on outside of git, I do daily dump archives so each day is snapshotted. No need to track hours, no need to wonder what somebody did all day. If you want to know what I did last tuesday go check my commit! Version control = accountability and trust

mildbow 11y ago
The 9-5 premise is about having regular hours (whatever they are) so team members can get in touch if they need to. It's also about signaling when team members can't get in touch. Both are important since they are implicit to an office but something you need to be careful to correctly define/signal when you are working remotely. I don't really look at commit logs because, to me, they reflect how one prefers to work, rather than how productive they are being. 2 people can easily have 2 or 20 commits for the same feature set. I'm not going to be calling one a 10x engineer based on that :) To that end I don't believe in looking at commit log, or time tracking (!) because both can be falsified pretty easily: they are just another form of counting lines of code IMO. I prefer to look at how much customer value someone is delivering and how much other team members listen to them.
- err4nt 11y ago
  I focus on delivering recurring value so we're on the same page. I also agree that communication should have clear hours regardless of when you work, so you can be reached when others need you, and you know when you can reach them. For us it gets a little stretched out because of the time zone difference too, but most of our communication happens through the ticket system. I'm not advocating numbers of lines of code or numbers of commits either, value is what's important, but having a daily, timestamped record of everything everybody did just takes all the question out of 'What did you do last Tuesday?', any of us could just go and check. Working with version control has been a _huge_ benefit to remote working because it provides a way that people who don't see each other can trust each other. It also ensures that nothing of value what was ever produced by anybody (and paid for) is ever lost, even if deleted. That's just smart business!
  - mildbow 11y ago
    That makes sense. I like the idea also of using it as a quick refresher to remind everyone/yourself what you were doing X days ago esp. during review time. Thanks!

enraged_camel 11y ago

Why the 9-5 boundary? Personally, I get my best work done during non-traditional hours, e.g. past midnight.

firebones 11y ago
I think it is figurative 9-5 rather than literal. In other words, knowing that there are boundaries and limits between work and non-work time instead of falling victim to the temptation of working all the time when you are at home.
mildbow 11y ago
From your team's perspective: It's so team members can get in touch if they need to. It's also about signaling when team members can't get in touch. Both are important since they are implicit to an office but something you need to be careful to correctly define/signal when you are working remotely. Note that it doesn't have to be 9-5 office time, just needs to be hours people expect to be able(and not able) to get in touch: 12-8 your local time? Go for it! Whatever works so you can maximize you and your team's work/life balance :) From a personal sanity perspective it's as firebones says in reply. FWIW, I -- and most engineers -- fall victim to the the personal sanity perspective rather more frequently.
- enraged_camel 11y ago
  I'm available to the team most of the time, even on weekends. The more junior they are, the greater the effort I make to be available to them. But in my mind there is a difference between being available for questions/advice vs. actually working, e.g. designing a system or writing code. If someone messages me on a Saturday asking, "hey, which server do I log into to do X?" then taking the two minutes to reply means I'm available, but I don't think of it as "work".
  - mildbow 11y ago
    You are being a good short-term team member, but that might not be the best for you or the team in the long-term. If you/other senior devs are getting the same random questions, maybe create a faq/run book? I've usually made it a point to say: here's the answer, now can you add it to the FAQ? That way, ideally, I never have to answer it again/that's the first place people check.