Since the global quarantine working-from-home, or remote work, seems to be everything anyone can talk about.
About 15 years ago when I started my career, software engineers were a rare, abstract breed of professionals. People knew of this profession, talked about it, but few had met someone who actually worked day-to-day writing code.
In that day (around 2005), the term ‘colocating’ became a thing. Colocating basically means, albeit confusing, when people work in the same office. So in other words, working onsite. (In the context of a computer or server that is co-located, and I realize I’m dating myself by even mentioning physical servers— yes, actual machines— colocate meant to host your physical server on-premises with your company or in an existing data center with other physical servers you also operate.)
In my experience, even by 2008 it was regular and normal for more non-tech employees to work from home (or “WFH” as is abbreviated) at least one day a week. Jobs were routinely advertised or negotiated with a certain number of ‘WFH’ days. Engineers worked from home even more, many working remote all of the time.
Then around 2013 some of the larger tech companies started to crack down on their employees working remotely. Marissa Meyer, the new head of Yahoo, famously set a no-work-from-home policy, vexing many of the Yahoo employees with families who had felt they had been hired under the auspices of workplace flexibility.
Years before this, a manager told me that they had no shortage of mediocre people who would show up onsite and work 9-5, but virtually no candidates who would work a regular 9-5 job and were exceptional. The exceptional candidates, she explained, all had demands—workplace flexibility chief among them.
My own experience has born this out too: The best developers I ever worked with were ones who worked remotely.
In fact, two that come to mind worked for companies in New York City — where I was an ‘onsite’ employee on the team — and did all of their work entirely remotely. While both of these people came to New York to visit— maybe once every six months — neither preferred to move to city that was more expensive than where they already had a good living.
Both of these guys were rockstars, and I mean rockstars in the truly respect-worthy sense. You’d have meetings with them and the next day they’d already been whipping up some sample code. They outperformed every member of the large team consistently week after week.
Except one time. Stan (one of these exceptional developers) and Peter (the product owner), and I built a system. It was a management workflow for an internal agency. In the agency, the projects had a natural step-by-step flow from concept to ideation to wire framing to production to delivery. Sounds straightforward enough.
Peter the product owner had written a complicated state diagram that showed while the normal set of steps was 1, 2, 3, 4, 5. Sometimes a project could go from step 5 back to 2, or from step 3 to step 2. His diagram had a number of complex transitions based on what the stakeholders had told him upfront about their needs.
So Peter, shows this to Stan (who happened to be my boss at the time) who immediately solves it using every developer’s favorite pattern: a state machine.
The state machine implementation was beautiful. It had gated locking mechanisms that allowed transitions only through the specified transition steps. We deployed it; everyone loved it. It was the first time the agency has had a custom workflow built around their needs.
“This thing is great,” someone tells me as feedback. “But why can’t I go from step 4 to step 2? Why must I advance to step 5 before going back to 2?”
Peter, me, and Stan have a meeting. “They love this product but we don’t need all these rules blocking people from just putting the project into the state they want it to be it.” Dammit, Stan thinks, then why did you draw me a fancy chart that said you did up-front?
Whether this was a failure of product development or imagination I can’t say, but it always struck me as funny that here I was, much more junior to Stan’s experience in Ruby on Rails, and I had an inkling that the fancy state machine he built wasn’t going to be as useful as he thought. (Of course, he was my boss, and obviously it is what ‘they’ had asked for, but I still pictured the agency’s chaotic workflow and thought to myself, they’re going to want to change the states back and forth and back and forth, why are we building this state machine that locks them into specific transitions? I didn’t bring up my objections to Stan at the time.)
Not only had he overbuilt something, but he’d in fact built something that was a hinderance to the end user (exactly what you don’t want in good software). In our case, our user base was small and forgiving (only the people in the company), and so the impact was minimal. We removed the transition locks (but still kept the underlying ‘state machine’ coding pattern) so that a project could be moved from any state to any state. All things considered, nobody creatives were harmed in the making of the software and the cost of being wrong was low.
But building that state machine wasn’t a small bit of coding. Not months of wasted work, but it probably was weeks of wasted work.
It always struck me that Stan, a bit of a left-brained nerd, always seemed to related to the code better than he could relate to the people.
And therein lies the heart of the tension between the ‘onsite’ world and the ‘remote work’ world: Are you relating on an empathic level to the company’s needs or are you relating on an technical level?
I’ve heard all sides of the onsite vs. remote-worker divide. Since it’s such a controversial topic, I’ll list just some of what I’ve heard about the benefits of letting your workers work remotely:
1) As a company, you can have access to a much more significant pool of talent
2) Your workforce is more likely to work harder
3) You can distribute workers at different times to allow for asynchronous work to be done— for example, an engineer codes a feature in afternoon and someone else does QA on that feature in the evening. (In a traditional onsite workplace, your features won’t get QAed until the following day when people come back into work.)
4) Workers can live somewhere significantly cheaper than the expensive tech hubs of San Francisco or New York City. While many people think the cost living difference might be a factor of 50%, I estimate the true cost of living difference, after taxes, between an expensive city like New York and the mid-west is probably 400% (that is, it’s 4 times more expensive to live a “city lifestyle” in an expensive city than it is to live “normal lifestyle” anywhere else.)
5) Offices are distracting and not conducice to concentraion. In their book Remote, Jason Fried and David Heinemeier Hansson ask
If you ask people where they go when they really need to get work done, very few will responde ‘the office.’ If they do say the office, they’ll include a qualifier such as “super early in the morning before anyone gets in” or “I stay late at night after everyone’s left” or “I sneak in on the weekend.’
I’ve seen both sides of this coin. On the onsite side, I’ve done onsite pairing, product development, white boarding, led and participated in onsite meetings, done mentoring of junior developers face-to-face, and also been the coder with headphones on at his desk (if you don’t know, when an engineer wears headphones you can think of it like he or she is wearing a “don’t talk to me right now” sign)
I worked remotely for years as a consultant, and I “worked from home” on and off though many jobs in New York City too.
I am ambivalent about the debate: one the one hand, I have found onsite work to be stimulating, connecting, and effective, especially when you have a strong team (one that makes you want to come in every day.) I’ve also found onsite work to be draining, exhausting, and, worst of all, distracting. How can both of these things be true?
To be effective at what we do, developers need something that we call ‘flow.’ For laymen, thinking about the last time you wrote something— something difficult. Maybe a paper for school or a presentation that required a lot of writing. Let’s say you sit and start writing. At first, your attention is easily diverted. What you’re going to have for lunch, what your wife said to you yesterday, the sound of the ticking clock. You know you aren’t concentrating, so you concentrate harder. After about 15-20 minutes, you are typing sentences and they seem to be flowing out of you. Then someone comes in the door and asks you a question. You look up, “Sorry, what did you say?” Half of your brain is still writing, but it was just jarred into something else by the event that distracted you.
Programming is like this every single day, and the need for focus is even more dramatic than most professions. Non-programers typically underestimate the significance of flow in software development.
Product development, which is a constant back-and-forth with stakeholders, is something that dramatically benefits from people being in the same place. If you sit with the people you are building software for you are more likely to connect with them on an empathic level, a key component to being a great product owner. As the state machine example with Stan demonstrates, sometimes if the only things you interact with are computers you begin to identify more with the computers than the people. (That’s not a good thing.)
Self-starters remote employees like Stan and Thomas (and yours truly, often) — partly because they have the privilege of working remotely— are focused on results precisely because nobody is looking over our shoulder or clocking our hours.
The Coronavirus is a paradigm shifting event to the WFH vs. onsite worker debate: Everybody has to stay home during the quarantine. Companies and teams that have never worked remotely are suddenly forced into this situation. I can only imagine CEOs and Human Resources people who have looked down on remote workers judgmentally— which sadly I fear are the majority— are going to loose their shit.
In the next post I’ll explore working onsite work, how it has changed, where it shines and what its pitfalls are.
Be sure to LIKE & FOLLOW for Part 2.