Building Software Remotely
My post a week ago about remote work really took off, receiving a lot of support and sparking some interesting discussions. I've summarized my thoughts and general notes on that, in this short article.
First of all, if you haven't seen the post yet, you can find it here. There are over a quarter million impressions, 1.7K reactions, and hundreds of comments. Even over a week later, it's receiving a lot of attention. I had to turn off the notifications as things
were getting out of hand. Also, it kinda broke LinkedIn for me; I can't find my own comments anymore, or even entire threads. Well, not the first time LinkedIn has acted up, but let's get back on topic.
Let me start by explaining the motivation for the post. As many know, there's been an RTO (return to office) policy/wave recently, being pushed by big and small players. I'll explain where I stand on that for the rest of the article (though you may have already figured that out), but it's a really big topic these days, especially on LinkedIn. While there are some merit and sensible arguments on all sides, every now and then I see a take that goes along the lines of "You can't build large software systems efficiently by being remote". That is something that I strongly disagree with, and my post was a spontaneous counter-reaction to that. Granted, it uses an oversimplified and generic example, and I tried to add more context in the comments, but this is LinkedIn after all. It is a post meant only to emphasize the point that you can in fact build great software remotely.
The post received overwhelming support, and it's no wonder why. A lot of us have been working remotely for some time now, and have benefited from the positive impact it has had on our work-life balance, professional satisfaction, and general wellbeing. It's a no-brainer that we'd like to keep that status quo. There's more to life than just a job, and if one can perform that job well remotely while allowing themselves more flexibility to cater to the other needs and issues of everyday life, well who wouldn't want that?
On the other hand, there were also commenters that eagerly disagreed. Some of them were company owners, also unsurprisingly. There is a clear conflict of interest, as employers want more flexibility by default, but at some threshold that extra flexibility does begin to impact productivity negatively, which in turn hurts the employers. I think if done right, remote work empowers all sides, and it shouldn't be treated as a negotiable perk/downside but as a common goal towards a better work relationship. But we don't live in an ideal world, and we have to keep that conflict of interest in mind for the rest of the article. I stand on one of the sides myself, so it might be difficult for me to address this in a bias-free and highly objective manner, but I'll try my best.
To begin with, I don't understand why this is still a rather controversial subject. Remote work actually works, and we have literal proof of that. We don't need to hypothesize about it. There are many success stories, recent and old, in open source or commercial software, in large or small projects, you name it. We've already seen this play out. There's startups that have been remote-first since their genesis. Tech giants that shipped new features and multiplied their market cap during COVID. And companies of different settings, happily continue to allow their employees to work remotely.
This is an experiment that has been already conducted. While the experience is still relatively new, for both workers and companies, we can judge this by real outcomes and results. The practice exposed all sides of remote work, good and bad, but we know for a fact that you can generally build software remotely without much compromise.
Sure, it's not suitable for every situation. There are niche settings in which physical presence is essential. Think of developing software close to the metal, where to you need to continuously test and integrate with the hardware. Or mission-critical/classified systems such as in banking, medicine or the military let's say.
But let's be honest, the average software project isn't that. The average software system is a web app for solving some business needs usually related to sales, CRM, marketing, utilities, entertainment, retail, logistics, education, real estate, transportation, social networking, hospitality, etc. In these circumstances, you can totally deliver value remotely without compromising speed or quality, as many of us have seen firsthand. If the goals are met, the company is doing great, and everyone is happy, it begs the question of why should the how matter.
To take explicit measures against a certain policy, you must have insight that some things didn't go well as a result. Was the project delayed? Was it abandoned completely? Was it delivered in poor quality? And, perhaps the most important question: would the problem have been mitigated, if everyone worked from the office? And to what extent? And to the sacrifice of what?
Here's something that never happened: me being halfway through a project, and going "Hey guys, this is not it. I don't think we can do this. We must absolutely assemble in a physical location asap, otherwise we're never going to complete this!". The thought of it alone is quite ridiculous. It just doesn't occur to you to find the remoteness as an impediment at all, as you're too busy doing focused work and reaping the benefits.
And, working remotely shouldn't be equated to working from your bed, waking up at 11 AM. Many of us have invested in home offices with much better equipment, comfort, and focus than most offices would offer. Many work from co-working spaces in other cities/countries, not that different from the experience the main office would provide (but without some of the downsides). Some work from a library, some from their favorite cafe, and some in some (literally) remote areas close to nature, where they can max out their focus. Some rent out an office with other colleagues working in different companies, where one could argue the exchange of knowledge is even greater, as each person brings the perspective and technical discussions of their own employer. And some do a combination of the various choices mentioned above.
Everyone finds out what works for them, eventually. Sometimes, that means coming back to the office. But there's no need to pretend it's impossible to build a professional context/setting remotely.
I have to address also the most frequent comment on the post, no, it doesn't just work for open-source software. Many had an issue with me bringing Linux as an example of a large and successful software system built remotely. Yes, open-source operates under very different circumstances compared to a commercial project, which we all know and there's no need to reiterate the how here. This would've actually been a fantastic counter-argument to my post if the only success stories of remote work came from the open-source world.
But that's nowhere near true. The number of companies that build commercial software, and do so remotely, is orders of magnitude larger than open-source projects. My own personal experience working remotely comes entirely from building commercial software in almost a dozen large companies. As a matter of fact, and one I'm not too fond of, I have never worked on an open-source project myself. Who knows, I might find remote work to actually be less efficient than in it in a commercial context. I see no basis whatsoever in the open source vs commercial software argument against remote work.
Another interesting aspect of this discussion, that I would like to bring forward, is that I hear companies regularly complain that they can't fill a certain position. This may sound absurd to some, with the ever-increasing tech literacy, computer science graduates, layoffs, and people looking for a job. In the current market, a company can surely fill a position within n day, right? Well, if you're only hiring locally, that's not true at all. I was a bit surprised myself when I helped with some hiring for my clients: it's actually quite difficult! I'll reuse an example I gave in the comments to my post:
"""
I live in an area with around 1m people. It's no major tech hub by any means, but there's a decent number of tech workforce present. If you want to hire, let's say, a Flutter expert, you're really only looking at 5-6 fitting candidates.
2 of them may be under contractual obligations and can't leave their current gig. 2 others may be happy with what they have going on (perhaps working remotely?) and don't even want to join you. 1 asks for more than you can afford. And the final guy bombs the behavioral interview. It's not at all that unlikely that you are left with no local option whatsoever.
"""
Of course, this is a problem companies cast on themselves, by only looking locally. When we talk about remote work from the POV of the employee, the main selling point is the flexibility gained in work-life balance. But from the POV of the employer, it's
the access to the global pool of talents with very competitive market rates. To deny yourself of that tremendous opportunity, it's very counter-productive, to say the least. Why wouldn't you want someone with the exact expertise you require, and within your affordability range? They're sitting there, eager to help you with your problem, while you are crying about not being able to find anyone. It just doesn't make sense. The local market can only provide so much, and guess what: you're competing for that talent with every other local company that thinks like you, and with every global company that doesn't. You are putting yourself at such a big competitive disadvantage, for no strong reason.
But yes, there are downsides to remote work too. Like with many things, it's a matter of trade-offs. First of all, when you work remotely, you just have to be a very disciplined person. You have to put in an intentional effort to create a good routine and make it possible for the work to flow smoothly. You have to explicitly separate work from the rest of your life, and not let things blend. When you work from an office, these things are there by default. You would have to put effort to go in the wrong direction, not to avoid traps.
And, I think most people, me included, would very much like to meet with their colleagues regularly, even if not every day. Shared physical spaces reinforce a sense of belonging and team culture, there's no denying it. I miss those spontaneous interactions and jokes with my colleagues or going out for lunch together. If I had to pick, I would personally prefer a hybrid approach, where I show up to the office 2-3 times a week.
But, under the right circumstances. I wouldn't do that If I had to commute over 2 hours a day just to get to the office. I wouldn't do it under heavy traffic, harsh weather conditions, subpar public transport, etc. I wouldn't do it if I had people to take care of at home. I wouldn't do it if the office at hand doesn't even provide the above-mentioned benefits that an office should in theory provide. Not all companies are built equal, and in some the office just means clocking in and sitting isolating in your cubicle for the rest of the day.
And even if the office does provide many of those benefits, it will always by default come with some cons as well. Ultimately you have to weigh things in depending on your context. The list of benefits is quite extensive though, and for many of us, it greatly outweighs the costs. At the end of the day, wouldn't a company want its employees to feel more flexible, happier, and motivated? That alone pays its own dividends in the long run.
As mentioned above, you need to put deliberate effort into making it work smoothly, and that applies to all parties involved. Async communication rules, documentation, and proper planning. All of that is necessary, but here's the thing: it is so inside an office as well!
An office is not a magical symposium of ideas and collaboration. You need to build a culture that enables that. An office facilitates it more perhaps, and that would be one of its strengths, but you can have brainstorming sessions, pair coding/design, or even random chats, remotely as well. And there are many offices where colleagues don't even greet each other. In real life, an office is not quite the epitome of flawless collaboration.
Ultimately, it is the decision of the employer. Whoever starts a business, can choose to run it however they see fit, within a legal frame. I think an employee doesn't have the right to feel entitled to remote work. But rest assured every employee will see it as a drawback at the end of the day. Yes, even the ones that would show up to the office every day anyway. Because I have yet to meet a person who would not prefer more flexibility as an option. And they will be particularly annoyed at you when they know the circumstances of the work at hand don't really necessitate everyday physical presence. So, be prepared to compensate for that. Or to lose top talent. Or to struggle to fill positions. You could choose to die on that hill, not just figuratively.
And, truth be told, there's many employees that also abused the remote option. It's still a job after all, and you have to put in the work, be available, attend the agreed-upon ceremonies, meet your expectations, and such. It's not a school trip.
Many remote workers didn't take that as seriously as they should've. I believe this is one of the reasons why companies are pushing for a mass RTO. Ideally, it should be treated on a case-by-case basis, and many shouldn't have to suffer for the mistakes of the few, but the easier solution is always the more tempting.
In my career, I've been perhaps privileged enough to manage, and be managed, by people who get it. By responsible and considerate professionals who understand that what ultimately matters is the value you deliver and the impact you make, not office politics, show-offs, or arbitrary bureaucracies. I am hopeful it will continue to be like that. Time will tell, but I see a future with fewer cubicles and a more globally interconnected collaboration in the software workforce.