Working Remotely as a Junior Developer


This article is based on my talk at RedDotRubyConf 2015 in Singapore, with a few additions and touch-ups. You can find the video here .

Working remotely is one of the cooler perks that being a web developer (or generally anyone working in the digital trade) creates. There are tradeoffs, there are things you have to figure out or work around, but all in all the the freedom it offers is really awesome.

There is this silent assumption that working remotely is something you can do only once you have achieved the "senior developer" title, and I’m the first person to say that I’m nowhere close! Here’s my secret though: I’m currently employed as a junior developer and I’ve been working remotely for over a year now. It isn’t something you see many junior developers doing (or maybe they’re just hiding really well?); most companies are rather worried about allowing their juniors to work remotely.

I get a lot of questions about how I managed to convince my company to agree to this, how I ensure I keep improving and how my team and I are making it work - not only from other juniors, but from developers in general and from people who manage technical teams. I’m sharing this story in the hope that this way, I will help you make it work for you (and your team too).

The story begins

About two years ago, in 2013, I graduated from my university in the pretty town of Passau, Germany, and moved to Berlin to start working for testcloud (now test IO). I enjoyed the work, I got along well with my coworkers and I was learning a lot; everything was great and I was happy. But after going to the office every day for a year or so, I was starting to get tired of living in Germany. Germany is a great place, don’t get me wrong, but I had been back for four, five years after living in Bangkok for two years, and I desperately felt like I needed to be somewhere new again.

It all boiled down to the fact that I loved working at my company and I didn’t really want to quit, but I also didn’t really want to be in Berlin anymore. I thought about this back and forth for some time, until one day the thought popped into my head: “Working remotely would be the perfect solution for this! I wouldn’t have to quit, but I could go live somewhere else!” Then the worry set in: “But… I’m a junior dev. Can I really do this? Would that work at all? And how the hell do I get my company to agree to this?”

Preparations before asking

I finally decided to talk to my boss (who is our CTO), because I figured that the worst thing he could say was ‘no’, after all. If you are a junior dev and decide to do the same, here are three things I did before even asking which helped me to get to a yes in the end:

1. Figure out your alternatives

First of all, figure out what your alternatives are. Will you quit if they say no, and find a new job in the place you want to move to? Will you stay and just continue working there? In negotiation theory, this is called your BATNA1, or “best alternative to negotiated agreement”. You shouldn’t usually disclose it - unless it’s beneficial - but it will give you an idea about the leverage you have when talking to your boss about working remotely and help you focus your arguments.

2. Come up with benefits for the company

If you show up and your only argument is “I want to work remotely because I want to”, that’s probably not going to get you very far. Benefits for your company could be anything from “I’m more productive when I’m by myself than when I’m in an office with lots of other people” to "You won't have to find, hire and train a new developer”. In my case, one of these points was “When I am in a different time zone, we’ll have a longer time slot where someone is awake and can immediately take care of upcoming issues”. That way, you show that you’re not only thinking about your own benefits, but are considering what would be beneficial for the company as well.

3. Prepare to address their concerns

With a very high probability, your boss or the person responsible for the decision to let you work remotely will voice some concerns about your plan. Research common concerns and objections that come up in negotiations about remote working agreements and be prepared to answer them in a way that reassures them and shows them how you would solve or avoid that kind of possible issue.

The talk

Armed with all my preparations, I waited until my boss seemed not busy and in a good mood (this is important!), then walked up to him and asked him for half an hour of his time. I told him about my plans to move to Tokyo, but that I would still like to keep working for this company because I really liked my job here. He was surprised and not exactly thrilled at first, probably also due to the fact that at that time we had nobody else working remotely. However, he did listen to what I had to say, and since I had answers to a bunch of the questions and concerns he had, he was willing to think about it and asked me for a week of time to consider.

After one week, he got back to me and told me he wanted to talk about it again. I was somewhat nervous because I didn’t know what was coming, but in the end he said that he wasn't generally opposed to the idea of me going remote. However, he was somewhat worried about the risk that we might find out the whole remote thing didn't work out only after I had moved to Tokyo. So we sat down together and figured out how to minimize that risk, which is the next point that I'd recommend you to do if you're planning on going remote as a junior developer or have a junior in your team wanting to go remote:

4. Do a trial run

This trial run is specifically meant to uncover and solve issues that might come up during working remotely. In my case, we did it in two stages: First, I worked from home at our regular Berlin office hours for one week, so we could focus on possible issues that would be purely related to me not physically being in the office.

Then, in step two, I worked from home for another two weeks, but this time we faked me actually working in the Japanese time zone: I worked for two weeks from 4am in the morning until 12 o'clock noon, so we could simulate the time difference and the actual overlap we'd have if I really were in Tokyo (this is not good testing standards, obviously I was off peak skill, but it was the closest we could get to the real thing). This way we were able to figure out issues that might result from us being in different time zones and not working at the same time all day long.

The important thing here is to actually iterate and fix problems as they pop up, to create a smoother process, and not to call the whole thing off after the first difficulties appears. You're really expecting issues to show up at this point, and now is the chance to fix them cheaply and with low risk.

I got the Yes!

So we did the trial run for three weeks where we uncovered and fixed a few issues - I’m going to mention these in a bit - and after that we had a meeting in the office including the dev team, my boss and me. We talked through our experiences during the trial run, and it turned out that even though there had been a few places where we had to change things or adapt some processes, everything had gone a lot smoother than expected. My coworkers were fine with me going remote after seeing that we’d be able to make it work, my boss didn’t have any more objections either. I had my Yes!

Making things run smoothly

A few months later, I moved to Tokyo and set up shop there. After taking a bit of time to settle in, I started working, sometimes from home, sometimes from cafes or co-working spaces, and even though I occasionally missed being around my coworkers, I really enjoyed being in Japan and the freedom working remotely gave me. Once in a while we ran into minor issues that happened because of the physical distance or the time difference, but the two major things we had found out about during the trial run helped immensely to make things run smoothly:

4. Communicate proactively

This is on you. You can’t expect to be the remote person and have everyone else make as much effort as you need to stay involved. Not being around your coworkers means not only that you’re not part of all the things that people talk about casually when they meet each other at the coffee machine or go for lunch together, but also the non-casual things, like decisions that are made during the day, changes in features, and all kinds of work-related topics.

To stay on top of what’s happening, make sure that you don’t disappear from your team’s perception by making an active effort to regularly communicate with them. If you have daily standups, like my team does, you basically have it covered, even though it doesn’t hurt to have a casual chat or Skype call with co-workers once in a while to get updates on how things are going in general and what’s been happening. If you don’t have daily standups, definitely make sure that communication happens on a regular basis.

Don’t wait for others to contact you: You are remote, and you want to touch base as often as possible, so do be proactive about it. Use Slack, Skype, email, whatever works for you and gives you and your team the best results.

5. Write things down

This goes somewhat hand in hand with the point I just made about communication, but it’s especially relevant if you and your team are in different time zones. Tokyo is currently 7 hours ahead of Berlin, where the rest of my team works, which means we generally have an overlap of about two or three hours in their morning and my evening. For them that’s fairly convenient because their workday starts when mine ends, so they get an update from me first thing in the morning.

For me, on the other hand, anything they do after I sign off I will be blissfully unaware of until we talk again 24 hours later - unless they write it down somewhere so I can read it in my morning when I start working. This was an issue we had at one point when a decision was made on how a certain feature was now to be implemented differently. I didn’t know about it until our next stand-up and spent a whole day working on stuff that wasn’t needed anymore. To fix the problem, the next day we started a Slack channel specifically for documenting decisions or plan changes, to keep everybody up to date regardless of their time zone.

This new importance of documenting and writing things down actually improved our workflows, because it forced us to be more strict with all kinds of things, from properly assigning issues on Github to descriptive commit messages to documenting decisions so everybody is informed and we can revisit them later. Turns out that me being the first person to go remote had some very real benefits for my company!

Keep learning and improving

One more thing that I asked myself was this: How am I going to keep learning and improving when I’m not physically in the office and around my coworkers every day? This is a very real issue, because as a junior, you’re in a period of your career where you’re not a total beginner anymore, but you probably still need work-related support and advice from coworkers on a fairly regular basis, and you still need to learn a lot about the technologies you’re working with. A more senior programmer would not have to deal with that as much, simply because they’re more experienced. And not only are you very invested in becoming better (or at least you should be), but your company has a very real stake in this as well. Both you and your team together can make it work:

6. Proactively ask for pair programming, code reviews and feedback

Make sure you get at least nearly the same amount of attention devoted to your improvement that you would get if you were physically in the office. This is something you should take a very active approach to.

Get your coworkers do some virtual pair programming with you once in a while. That’s a bit less convenient than in-person pair programming, but there are tools out there that are built for exactly that, so definitely give it a try.

Ask your co-workers for code reviews and make sure you get them. You can do this in any way you like, but I have made good experiences with a combination of comments by the reviewer in my pull requests on Github and a video call where we go through the comments together and the reviewer explains if necessary and suggests improvements.

Actively ask for general and specific feedback on your work performance and your co-workers’ experiences with you working remotely, and what you can do to improve that - and also, do the same for your co-workers and let them know if there’s anything they could do to make things go smoother for both of you.

Does it actually work?

After being remote for over a year now, here’s my take on things: Yes, I do still think it’s harder for a junior to work remotely. However, it’s definitely possible and can even be a great personal and professional experience. I learned a lot doing it, heck, we actually improved my company’s development workflows because of it!

Remote work is not for everyone, so make sure this is actually what you want to do - doing the trial run is a great opportunity to find out. Don’t just jump into it, but prepare in advance and take some time to make sure everything goes smoothly. Feedback and communication are essential, and if you and your team put in a little effort, you’ll be able make it a success for everyone involved.

1 You can read more about this in “Getting to YES: Negotiating Agreement Without Giving In”, a very useful book on principled negotiation by Roger Fisher and William Ury.