Thought balloons floating in a world full of needles.
Remote software engineering jobs, FTW
Software engineering is an exercise in comprehending and manipulating intangible worlds. Interruptions during critical phases of thought lead to costly, time-consuming, and frustrating delays in the process of executing a design.
This article shares some of my experiences as a remote worker, and some of my thoughts as to what makes a successful remote team.
Assertions:
- Remote teams are more efficient
- Remote employees experience less frivolous interruptions
- Remote teams are made up of self-motivated individuals
- Remote workers leverage asynchronous communication tools for non-urgent matters, and real-time communication technologies for troubleshooting, brainstorming, meetings, and stand-ups.
- Remote work has a stigma attached to it.
- Remote work highlights the burden of coordinating project strategy, product management, and market research/feedback as a process that is wholly separate from engineering.
After working remotely for over 2 years at a previous job, I’m of the opinion that remote engineering culture creates the ideal support for an engineer to maximize their ability to concentrate and deliver on-time quality software, by removing many unnecessary distractions.
Engineers are human beings, and caffeine is a slippery slope. Every human has a limited number of useful working hours per day, and one way to optimize within these limitations is to let every engineer, within reasonable bounds, set their own working hours. It has been one of my favorite aspects of the remote arrangement that I could organize the working hours of my day to overlap with my most productive and focused periods. I’m all too familiar with the phenomenon of working in a traditional office environment, feeling distracted, tired, or burned out, yet succumbing to the not-so-subtle peer pressure of remaining at one’s desk with no useful result. Alternately, when working remotely, I’m used to monitoring my level of focus as it ebbs and flows throughout the day, and at the low points, simply walking away from the computer, engaging for a moment in another unrelated task. The ability to be in control of these “scene changes” is not only supportive for maximizing quality output, but for creating the conditions for the mind to deliver unexpectedly creative solutions to problems which occur in the “negative space” of stepping back from the problem.
“I’m not going to make my team come into an office so they can put their headphones on.” — my former manager, who was also the vice president of engineering
This comment was shared with me by my manager, a veteran of the software industry with over 25 years of experience, including remote and on-site work. The angle and focus of this comment reveals to me that he was setting the culture of our engineering team based on the experience of on-site engineering being a frivolous exercise in moving one’s body into a location that is not conducive to coding, since the engineer would then be forced to alter their environment to better suit the mental demands of writing code.
There is a stigma attached to remote work.
“When I give your résumé to [our board member] to distribute to his network, don’t tell him up front that you’re looking for a remote position. He has a low opinion of remote teams. He doesn’t think you can succeed as a startup with a remote team. I actually agree with him.” — the CFO of my former remote company, on circulating my résumé after I was laid off.
I experienced the bias against remote work starting with my cohort at Hack Reactor in 2014. When I was discussing my job search experience with my colleagues, when I mentioned that I was leaning strongly towards accepting an offer with a remote company, the reactions almost always included follow-up questions about why I wanted to work remotely, and did I think that was the best choice? I noticed that I had internalized some of this attitude, even before actually talking much about it with my colleagues. I held a nagging feeling that I was perhaps going to miss out on something wholly important, yet undefinable. I found myself wondering what if everyone was right, what if I was really missing the boat by not putting myself into an office environment to maximize for mentoring, and career growth opportunities?
I still wonder where these negative views originate, being pervasive enough to have been mirrored by both my colleagues, and the CFO of a remote company!
So, what was my experience as a remote employee, managing sole ownership of our front end technologies for over 2 years?
Here are my observations and anecdotes about what remote life is actually like, presented as a set of comparisons around common lifestyle snippets between the traditional office, and remote life:
Some facts about my remote team:
- We shipped on-time, high-quality, tested software.
- We functioned well as a team.
- We supported each other and had good team chemistry.
- When we needed to collaborate in real-time, we used screen sharing and video chat technology, or in some cases got together in our physical office.
- We used agile/scrum methodologies for sprint tracking, including estimation and a ticket system.
So, given the fact that the product team was eventually laid off, what went wrong, and where did the problem with our remote team lie?
One theory that I have is that the product failed, not because of what the remote product team did or did not do, but because we executed on the product requirements we were asked to implement. Our product failed in the marketplace, not in the product team’s execution or delivery. Looking a little further back along the chain of events, the deal-breaking variance lay between our executive orders around product requirements, and the actual demands and trends of the market.
The next question that arises for me is: would we have done any better as a company in delivering a successful product, had we all worked together in an office? I can’t see how that would have had any effect on the broken part of our organizational efforts. Again, we were missing the concrete market feedback that comes from real user stories and product feedback. That involves research and methodology that falls outside of the purview of the engineering team.
Given everything that I’ve described above, it should be clear that I am biased towards remote culture, having found it an unexpectedly excellent match for my temperament and work style. Revisiting the inherent bias that was shared amongst my colleagues while we were all job searching, was there any merit? Have I felt like I’ve missed mentoring, or career growth opportunities because I accepted a roll with a remote team?
Actually, just the opposite. By not being surrounded by other engineers, and being solely responsible for everything related to JavaScript on our team, a powerful motivation for personal development arose. Since I was never able to tap someone on the shoulder for help, it forced me to engage in a lot of systematic thought and organization around workflow and problem-solving strategies. I quickly ramped up on my google-fu, and stack overflow/MDN research chops. I employed shortcuts such as using Dash for documentation reference, and text snippet creation for common sequences and text entry patterns. And what it did for my confidence is both immeasurable and invaluable. I developed a sense of security around being able to progress through difficult stages of growth, handle steep learning curves, and keep my head up even while harboring feelings of despair or “hitting the wall”. And the repetition of this experience has led to a stamina and determination that has been conducive to constant progress within the discipline of software engineering.
I would like to see remote culture continue to grow. In summary, my plea to companies that are in charge of setting up engineering teams:
“Let your coders write code”
