~/posts/how-remote-work-made-me-a-better-dev
How Remote Work Made Me a Better Dev
I started my career remote, across time zones, and slightly in over my head. It worked out.
For the first year or so of my career as a developer, I took on all kinds of freelance and contract work. A couple of those roles required me to go into an office once or twice a week, but for the most part I was completing deliverables on my own time. By the time I decided to lock down a full-time position, I was also in the middle of moving to Europe. I had already been contracting with the company for 4 months, so the transition was smooth1. Another teammate had recently moved to Asia, so working across time zones wasn’t new territory for them.
Still, I was stepping into a relatively junior role. Not every company is comfortable with that setup and for good reason. Remote work demands a level of independence that can be difficult early in your career.
In my case, that pressure ended up accelerating my growth.
Learning How to Learn
Being six hours ahead of my team forced me to become a better problem solver. This was pre-AI, so there was no safety net beyond documentation, forums, and persistence. I got my development environment set up while I was still in the US with help from a senior engineer. Even with that head start, I quickly ran into the usual issues: dependency conflicts, environment mismatches, incorrect permissions, etc. Within my first week, I hit a point where I realized: if I couldn’t solve these problems on my own, my entire day would be a wash. Our standups were around 5–6pm my time, so waiting for help simply wasn’t an option.
I spent hours digging through Stack Overflow, reading documentation, and experimenting through trial and error. Some days meant 8–10 hours of focused troubleshooting just to get unstuck. Looking back, it wasn’t efficient, but it was effective.
Today, I usually tell junior developers to spend 24–48 hours seriously attempting to solve a problem before escalating it. With modern AI tools, that process is faster, but the underlying skill hasn’t changed. You still need to understand the problem well enough to evaluate the solution.
"Say Less"
Ironically, “say less” is now slang for “I get it" 2. But working remotely taught me a more practical version: say less, but say something useful. When I did need help, I learned quickly that how you ask matters. Early on, I had a bad habit: sending multiple Slack messages as I debugged in real time, often followed by a “whoops nevermind…” once I figured it out myself. No one wants to start their day by piecing together five fragmented messages just to understand one problem.
Working across time zones forced me to be more deliberate. My questions became clearer, more structured, and easier to answer. That habit stuck. Of course, learning how to communicate effectively applies to any kind of collaborative work.
When No One Assigns You Work
Being ahead of my team also meant I couldn’t rely on someone assigning me work in real time. To me, this is one of the clearest signals of a strong remote teammate, regardless of seniority. The ability to identify useful work without being told is incredibly valuable.
Early in my career, this meant exploring parts of our codebase that were unfamiliar and finding ways to optimize any of our current processes. Over time, that initiative compounded. It quickly turned into leading more complex projects.
Working remotely (especially across continents) isn’t for everyone. There is always a certain degree of trust needed to go through with such an arrangement and I get that. It removes a lot of the structure and support that traditional office environments provide. But in my case, that was exactly what I needed.
It forced me to learn independently, communicate clearly, and take initiative. And those are the skills that actually move your career forward. Remote work didn’t just make my job more flexible. It made me a better dev, faster.