There are many articles out there about being an effective remote worker. Most of them focus on the basics, like building the ideal home office, following strategies for effective video conferencing, managing cabin fever, avoiding becoming a remote developer black box or improving self-discipline, motivation and communication.

But where do you go from there? People often ask me that. Julia Evans at Stripe has done a great job writing about this, and I’d like to give you my take as well.

I have over 20 years of experience as an engineer or engineering manager. I’ve spent the last seven years working for The New York Times, and have been remote for the past three years. How do I keep myself constantly learning and growing, both personally and professionally, while at the same employer, especially now that I’m a remote worker?

Solve the right problems

As an engineer, you’re not paid to write code; you’re paid to solve problems. It’s also not enough to just solve any problems. You need to be solving the right ones. You should constantly make sure there’s alignment between what you want and what the business needs, as organizational context and business priorities are constantly changing. It’s the path with the greatest rewards:

• You’ll mature professionally. Solving the right problems means working on tasks that bring the most positive impact to your team. This can be at odds with what you might be most interested to learn at the time or what you personally think is the most important problem. Being right is usually not worth much if others don’t agree. It’s important to have personal interests and preferences, but at work, you have to learn how to live at the intersection of what your preferences are and what the business needs.
• You’ll find out if you’re working with the right manager and team. Working with them to discover the right problems to solve will give you the experience to decide if you are working with people you can trust and who can support you.
• You’ll learn how to bring others along for the journey. In almost every context, you should not jump in and try to solve problems on your own. That’s a lonely and ultimately unscalable path. You’ll need to convince others to join you by figuring out how they can grow alongside you. Learn to communicate that constantly and effectively.
• But how exactly do you figure out what the right problems are to solve? It depends on the situation, but you can look for patterns: Considering your roadmap and your goals, what is keeping you from doing things more efficiently, with more quality, or more reliably? A low-hanging fruit in the form of a simple or small task that can be easily added to your current workload can be best at testing if a type of problem is the right problem to solve.
• Remote pro-tip: As a remote worker, by necessity, I ended up becoming proficient at noticing what is going on across the organization by leveraging the company’s group messaging tool (Slack) and I use that proficiency to learn about some of the problems affecting multiple groups. I pick a relevant problem to solve (say, improving observability across our tech stack) and decide how far I’d like to get with it. I then convince my manager that I can work with others on a solution for the problem. Chances are, a problem that affects our team has the potential to be adopted more widely or to be done in partnership with others.

Find a theme and define a vision

Consistency is one of the main traits of a senior engineer. Even if you are solving the right problems, there are different classes of right problems to solve: standardization, performance, resiliency, quality, innovation, developer productivity and so on. Explicitly choosing a class of problems you want to tackle and defining what your world will look like when you have some solutions in place bodes well for your career:

• You’ll be increasingly recognized for it. You might not want to call it your specialty, so that you’re not pigeonholed, but solving problems that are related to each other will help you to successfully solve similar problems in the future. People will seek your expertise and will look for your leadership.
• You’ll be able to work at different levels of abstraction. By creating a recognizable theme around the work you do, you’ll be able to go deep but also lead a broader related effort when the need arises.
• You’ll develop perseverance. By defining a coherent vision of what you want to achieve and reminding yourself of it often, you’ll feel less bothered by short-term obstacles and you’ll come across as someone who is calm, collected and passionate.
• To avoid over-engineering, each solution you implement should stem from a vision that revolves around concrete use cases. Being remote, it’s especially important to work alongside others and share responsibility for these solutions.
• Remote pro-tip: In Slack, I get to watch a real-time feed of issues and problems facing the organization, so I keep tabs on the patterns that come up. I had originally been a full-stack developer, then a back-end engineer. Over the past few years though, especially since becoming remote, I have been able to witness a greater need for more automation at the operational level. So although I work up and down the tech stack as necessary, the theme around the problems I’ve worked on more recently lives at the intersection of application development and delivery engineering. This includes leveraging Consul for service discovery, Terraform for infrastructure configuration, Docker for portable workloads, Drone for continuous integration and Kubernetes for efficient resource scheduling. This year, I’m working with the web rendering platforms team at The Times — a team that has an established roadmap with existing milestones. So, while the theme I’ve chosen defines the nature of my work, my team’s collective vision helps to keep us all grounded and focused on a valuable delivery.

Strive for simplicity

As you progress in your career, you will learn that you have to prioritize both pragmatism in how you work and maintainability for the code you write. One of the most direct paths to achieve those objectives is by focusing on simple solutions:

• Spend some time planning what you need to do. Focus on the value that your solution is bringing to your organization and your users. Any architecture, technique, strategy, algorithm or component that increases complexity but makes no difference in the final result is superfluous and detrimental to the longevity of your solution.
• It’s easier to get something more focused when you do it a second time. So, when faced with an unfamiliar challenge, do a proof of concept. Use that proof of concept to measure the value of your solution. Use those metrics to make decisions on how to simplify what you actually end up building.
• Write a document that describes how you plan to solve your particular problem. Show it to others. Gather feedback early and often. Find out if you can make it even simpler.
• All that being said, sometimes the best way to implement a simple solution is to not write any code at all. Find out if a different team or group has already solved a similar problem and reuse or retrofit their solution for your needs. Leverage open-source components if you can. Or outsource it all to a vendor or service provider.

Work with and transfer to other teams

For some engineers with many years of experience, it’s as if each one of those years were the same, repeated over and over again, like a perpetual Groundhog Day. One of the best ways to learn is to challenge yourself, and one of the best ways to challenge yourself is to switch teams:

• Switching to a new team can be refreshing: new people, new problems, new processes, new goals. Yet, you’ll be at the same company, leveraging relationships you have already made over the years to get up to speed faster and more efficiently.
• Working with and eventually transferring to other teams will show to the company that you can be flexible, that you can adapt to different situations and work with all kinds of people. That is a valuable impression to give others around you, who will look to you as a person who might be able to help with tricky and unusual situations. Working with other teams will organically give you the experience needed to bring people together when they can’t seem to agree. You might even know people on both sides of the argument and can use that knowledge to more easily guide both sides to an agreement.
• Switching teams can lead to learning more about yourself and your organization. You might learn about what you don’t like or what is not a good fit for you, or that maybe it was a good fit and no longer is. When that happens, work with your manager and be upfront about what is working and not working for you. If you find that it’s really not going to work, prepare for the move by finishing your projects the best you can, doing explicit knowledge-sharing and documentation to make sure others in your team can do the work you are doing and maybe even working to find a replacement for your role. Trying your hardest on those efforts will consolidate your reputation as someone who is responsible and mindful of how your decisions affect your team and the organization as a whole.
• Remote pro-tip: In seven years at The Times, I have switched teams seven times. Being remote has made that process even easier. I don’t have to wait to switch desks and I don’t have to interact just with the folks who sit next to me. When remote, it doesn’t matter if someone is not on my team, not on my floor, or not on my city. It also matters less if they are an engineer, a manager, a director or a CTO. It’s just easier to talk to anyone. I talk and interact with more people now that I’m remote than before. Talking to more people increases the chances you’ll find out what other interesting work is out there in your organization and you’ll more easily build diverse relationships that can facilitate switching teams.

Automate yourself out of your job

This is sometimes counterintuitive: grow professionally by making yourself dispensable. By making yourself dispensable, you show that you can take on larger or more complex challenges:

• Instead of hoarding knowledge, processes and insight, write them down. Instead of doing the same task over and over again, teach others how to perform it or write a script to do it. Don’t do it all yourself. Break it apart and share in the ownership and implementation with others. You’ll most likely not be able to do this with everything, but with the time that you gain, think about the next best thing you could be doing.
• You’ll improve your strategic thinking in addition to improving the tactics you use to perform your job. In order to choose what you could automate about the work you do today, you have to think about priorities, your roadmap, your team, your goals and your future.
• Ultimately, by automating away the work you perform, you gain mastery over it and you show to your team, your manager and your organization that you’re ready to tackle the next challenge. You show that what you do is reproducible, can be done more efficiently, and can scale beyond what you can do by yourself.

Embrace being on call when it’s your turn

Being on call is one of the most powerful ways to learn more about the system you are responsible for. You don’t have to take just my word for it. Most importantly, when things break, figuring out what broke helps you to decide where improvements are most needed:

• You’ll find out how effective your testing strategy is based on how often you have obvious defects or regressions after you deploy a new release. After you find and fix a bug in production, write a test that reproduces the problem and make that test pass.
• You’ll learn how changes to other systems and their availability affect the behavior and output of your system, especially when you rely on external data sources. Make sure your system can degrade gracefully, including defaults for missing data, useful error messages and flexible business logic that can return meaningful results even when you get unexpected, badly formatted data or no data at all. Improve your integration tests and practice fuzzing.
• You’ll learn how resilient your architecture is to infrastructure failure and how it scales when encountering unexpected high load. Even when you have done load testing and chaos engineering, you might still encounter outages. When faced with an outage, write a blameless postmortem and take steps to minimize or eliminate the impact of a similar situation.
• You’ll find out how well your system is documented, how meaningful your alerts are and how useful your monitoring setup is. If you get an alert and it’s not actionable, it should not have been an alert. If you find gaps in your documentation or monitoring, fill them. Ultimately, you’ll find out how much observability you truly have.
• Remote pro-tip: When I get paged during off-hours, I’m usually able to react to the incident just as quickly as I react to problems during regular work hours, because I’m used to working from home. My co-located peers in the same off-hours situation sometimes have more trouble with that in terms of setting up their workstation at home and accessing various services outside of the office. To minimize that, I have written documentation about how others can set up their workstations at home to triage and diagnose problems more effectively, like running a script to open up all the different monitoring dashboards all at once.

Organize, lead and participate in different groups

In much of the work you do, you’ll grow faster if you work with others. What better way to do this than to create groups of people who have a common goal or interest? Show to your manager that you can lead others in becoming better professionals and better people outside as much as you do inside your own team:

• You’ll become a better practitioner of your craft by participating or leading a group focused on a specific technical aspect of your job. It can be a group focused on a programming language or tool that you use or a specific cross-cutting functional area like performance, security or architecture.
• You’ll become a better corporate citizen by participating or leading a group focused on non-technical aspects of your job, such as public speaking or improving diversity efforts.
• You’ll engage in more personal relationships with others who might share non-work related interests, such as different sports, physical activities or hobbies.
• Remote pro-tip: As a remote employee, you could help other folks in their own journey toward becoming remote themselves. I have done this, and it’s helped me to think about my own journey toward becoming a better remote employee. It has also given me the motivation to help craft a remote work policy for the engineering department, which eventually was adapted into overall corporate policy. Nowadays I’m known as someone who can help others learn how to work more efficiently from home or even make the decision and the transition to becoming remote employees themselves. I’m proud to say that I’ve helped retain some folks who otherwise would have left the company if they hadn’t been able to work remotely.

Diversify your 1:1 portfolio

If you’re an engineer in a fairly well-run team, you most likely have 1:1 meetings with your manager regularly. Why not have 1:1s with a couple of your peers as well? Or meet regularly with managers and engineers outside your team, folks from different backgrounds or who have mastered different skills, like designers or product managers?

• You’ll learn a more diverse set of points of view about your company and the world around you. Can you learn from them? Can you help them?
• You’ll find out more about how other engineers in your team approach their work and manage their careers so that you can learn from one another.
• You’ll increase your reach and influence by meeting engineers outside your team and finding out what else is going on that you could potentially help with, like increasing adoption of a standard or helping to solve a technical issue you have solved before.
• You’ll learn to have a more holistic perspective of the products and services your company creates.
• You’ll make long-term working relationships healthier and easier to come by if you seek to meet one-on-one with folks from different backgrounds than yours. By connecting at a more personal level, you’ll better understand their challenges, both at work and in life, and how they differ from your own.
• Remote pro-tip: Being remote makes it easy for me to reach across physical space over the entire organization and just talk to anyone, as they are just as close to my chat sessions and video conferencing as anyone else. I have 1:1s with my manager, my manager’s manager, a couple of my peers in my team, in my department and in other departments. As master of my own calendar, I then put those 1:1s as close together as possible to minimize context-switching with my other work.

Mentor and be mentored

One of the hallmarks of engineering seniority is the ability to mentor others. As you grow professionally, it’s important to allow yourself to be continually mentored by others and to make yourself vulnerable, open to accept and act on feedback from folks at all levels of experience.

• The best mentorship relationships have an element of mutual benefit, where both sides are expected to help each other with their own challenges. What that means is that when you’re mentoring someone, you should also ask your mentees how they can help. Allow them to contribute.
• As a mentor, try to refrain from telling your mentee what to do about a problem or how to approach a new situation, even when they explicitly ask you for it! Help them instead to figure it out for themselves. Be willing to listen and give constructive feedback rather than assume you know the best solution. Act as a facilitator and let them take control and come up with the narrative of their careers.
• As a mentee, you should not restrict yourself to mentors who have “more experience” or a “higher title” than you. Every single person, peer, intern, contractor, boss, young and old you meet has had a different life experience than you.

Be passionate, in moderation

Most senior engineers are passionate about something related to their work. You can almost see a twinkle in their eyes when the subject comes up. It’s not a requirement for growing professionally, though, as there are great engineers who are just happy to do the best job they can, efficiently and reliably, while their true passion lies elsewhere. Also, there’s some confusion about what being passionate about your work really means:

• Being passionate does not necessarily mean working more hours than required. That is just not sustainable and often leads to hopelessness, bitterness, burnout and regret.
• Being passionate does not necessarily mean coding on personal side projects. Lots of tasks at work and in life have the tendency of becoming not so fun when you do them too often or push too hard.
• Being passionate does not necessarily mean working on open-source projects. While open-source leadership can demonstrate entrepreneurship and creativity, one can demonstrate similar qualities by leading internal groups and discussions during regular work hours.
• It’s also possible to be too passionate about something. So passionate that it makes it hard to be humble, to listen and to admit imperfection and pragmatism, all of which will actually prevent your professional growth.
• Being passionate, as with being right, is not that useful if it’s done in a vacuum. Having passion productively means sharing, evangelizing and getting others just as excited as you are about a subject.

Have empathy

Empathy is the ingredient that will give you the greatest return on investment for your personal and professional growth. You need empathy toward past mistakes and technical debt. You need empathy toward everyone you work with, no matter what role. You also need it toward the people who will have to face the consequences of the decisions you make today. Ultimately you need to remember that software engineering is more about people and their relationships to their work and others than it is about coding.

• Remember: there are many factors that go into decision making. It’s especially important to remember this when confronted with seemingly illogical engineering decisions. Maybe the engineer or team was pressed for time, didn’t have the right experience, was faced with conflicting priorities, was crushed by an overwhelming amount of work, chose the wrong tasks due to mismanagement or was troubled by problems of a more personal nature. Try to understand the larger context and you’ll increase your chances of improving a snippet of code, a component or an entire system beyond what is possible by just focusing on the present situation. Don’t make superficial judgments about the work and, most erroneously, about the people responsible for it.
• Perform code reviews like they are a conversation. Don’t use them as an approval process. It’s a process for incremental course correction, mentorship and learning. It’s a friendly sanity check on the code, not a judgment on the person who submitted the code. It’s an opportunity to understand what your teammate wanted to accomplish and to be understood yourself, in your attempt to make things better and share responsibility. Reach out in person if you think that there are basic, fundamental problems with the code you’re reviewing to prevent you and others from overwhelming the code review with corrections and negative comments.
• Practice programming to an interface with other developers in mind. Sometimes in our field, we are told to design programming interfaces to foster code reuse and improve the extensibility of our solutions. But it’s more than that. You should design interfaces while thinking about your fellow engineers and even your future self. Ask yourself: how can you make it easier for them to understand intent? How can you make it easier for anyone to just take your code, read your documentation and run with it? How can you organize your code in such a consistent and coherent way so that it requires less maintenance and adheres to the principle of least surprise?
• Remote pro-tip: As a remote employee, I learned to have even more empathy for folks who might not be able to be present in all forms of informal work discussions, especially when those happen after work hours. Over time, I found that the groups that depend the most on those after-work interactions are the least mature in terms of promoting an inclusive and welcoming environment for people of all sorts of experiences and backgrounds.

It takes quite a bit of conscious effort to work toward your own professional growth, whether you work remotely or not. Being a remote worker might even give you some extra superpowers if you work thoughtfully enough to achieve them.

Thanks to Sara Simon, Julia Evans, Deep Kapadia, Jose Muanis Castro, Phil Calçado, Willian Molinari and others for their feedback.

How to Grow as an Engineer (Working Remotely) was originally published in NYT Open on Medium, where people are continuing the conversation by highlighting and responding to this story.