How long do new developers need to work at an office job before going remote?
If you're a new or less-experienced developer that wants to eventually work remotely full-time, you may already be wondering how long you need to stay at your current on-site job (or future job if you're still looking for one) before you have the skills to go remote.
New programmers face the daunting task of drinking from the firehose when first learning how to "do" real world software development. As a new programmer you might assume that you'll flounder without having someone there to provide support and hold your hand as needed. You might already feel like you're in over your head. This is fine and to be expected. Assuming your company either has processes in place or a culture that supports mentoring and working alongside more advanced coworkers, working in an office does give you the benefits of being able to learn from these coworkers and get help when you're stuck.
Note: it's possible to get similar benefits working remotely, which begs the question of whether or not you should work in an office vs. remotely when starting out, a question that is too large to discuss here. This post is addressed to new developers who are either already working at an office job or who feel more comfortable starting off in an office while they ramp up their knowledge and skill-set. Those that want to cross one hurdle before tackling the challenges that come with working remotely.
The short answer to the original question posed is: however long you need to feel comfortable taking on more intermediate/advanced functionality and to work without much supervision.
But this answer alone is not quite helpful enough to be actionable.
What you need is a guideline to follow. Use the below as a barometer to assess when you're ready.
When you feel comfortable with the following:
- Managing tasks on your own, without a lot of help from other developers
- Proactively identifying what to work on, without being told what to work on
- Communicating synchronously and asynchronously within your team and the organization
Let's take a look at each of these in more detail...
Manage tasks on your own
Being able to manage tasks of increasing complexity on your own is a great sign you're ready to work more independently. This complexity will vary from project to project and from company to company, and as such there is not a steadfast way to gauge this, but a general rule is that you're able to take a piece of non-trivial functionality or user story, understand the tasks involved, and implement it without constantly having to ask the senior and lead devs on your team for guidance. For example maybe you implement a piece of an internal API or refactor some critical piece of the application.
If you find you're consistently getting stuck on tasks due to lack of development knowledge, don't let it bother you. Just give it more time. Understand the gaps you have and keep practicing.
It should be noted that remote developer roles require a lot of self-managing, but that doesn't mean you can or should work without having support from managers and other developers. Even when you reach more senior roles, you're always going to be requesting help from others whether that's talking through an architecture or taking a look at some piece of code you're stuck on.
Proactively identify things to work on
When you're able to take on more complex work the next step is being able to identify things that need to be worked on, things that have not already been identified. This may take many different forms - some part of the codebase that is in dire need of refactoring, some usability improvement that will greatly help your customers/users, or an internal tool you can build that will save your team loads of time. It could even be project red flags that need to be raised to your manager.
Being able to identify such things really might seem unrelated to working remotely. But if you're figuring out what needs to be worked out without passively being assigned tasks, it shows two things: 1) - you understand the "big picture" - the larger context - enough to be able to identify weak spots, a skill that comes with experience and understanding of development and the problem domain, and 2) - you've built up the leadership and "self-leadership" required to be able to work more independently, a critical skills in working remotely.
Know how to communicate synchronously and asynchronously
A bulk of the communication within in-office/on-site companies happens synchronously - meetings, people interrupting you at your desk, phone calls, etc. Distributed teams need to communicate in a more asynchronous fashion - email, Slack, GitHub threads, etc. Certainly not every on-site company operates majority synchronously and not every remote company operates majority asynchronously, but in general they do.
It's more than just knowing the tools - plenty of people use email in a synchronous way. It's about purposefully structuring your communication to be read and replied to several hours or even days later, while allowing for the rest of the work to continue to happen. This takes practice.
Work towards achieving the items on the above list and you'll be more prepared to take on the challenges of remote work without having to worry about also taking on the challenges of being new to the field at the same time.