Years ago I was conversing with a friend in the field— a UX developer who worked at large Ruby consulting firm. It was the early teens, that is, 2010s, and Rails was taking off like wildfire within the startup scene of New York City. I too worked at this time in startups, first in advertising and marketing platforms, to app development, and eventually finding my way to e-commerce.
I don’t remember exactly which year he made this comment to me, but I remember the company: Gilt Groupe. I name-drop it here because neither he nor I have worked for Gilt so our observations are merely second-hand. (Typically I don’t reveal the names of the people or companies in my stories.)
Gilt employed 100 Ruby engineers, and bragged that at 12 noon, when their sales went on the site, they had traffic that was bigger than Amazon’s traffic. My friend came from a pair programming background— where everyone works in pairs. Each pair works on one thing on one computer, they use one monitor (typically, but can use two mirrored monitors) and two keyboards. In the old days, the actual advice from XP evangelists is to use one keyboard and slide it back and forth between the two developers.
(Obviously, the age of corona will challenge some of these old days of working.)
In a conversation about workplace culture my friend said to me that Gilt was a very “headphones on” kind of place.
What he meant, in short, was: a culture of overly intrusive management, little collaboration, perhaps even competitive behavior between the engineers, and people wearing headphones in an office setting to signify to their colleagues that they don’t want to be interrupted.
Many companies and the people who run them might find this challenging.
If your idea of building software is that you need developers to be available to you to be ‘responsive’ to changing needs— throughout the day— you probably aren’t planning your software very well. Constant interruptions will universally mean that your engineers won’t be able to truly focus on the really hard stuff.
But these aren’t great reasons to insist on growing your workforce on site. In fact, they are only reasons why you should question if you have the right tools in place.
Second, if you think you need developers to be onsite because you want to ‘talk’ to them about the product, then you probably don’t know what a product owner is or could do for you.
A strong development effort will be led by a Product owner, who will have onsite meetings, and will write everything down in a neat, codified way for your engineers.
Third, and this is one of the most important: 40 hour work weeks are arbitrary. In fact, laborers used to work in factories more than 40 hours/week, and it was only because of the rise of unions that we now have a Monday through Friday workweek.
What’s important to software development effort is:
1) Focus (getting ‘in the flow’) and not being interrupted
2) Comfortable workspace, with good lighting, and an ergonomic chair or standing desk
3) Being mentally and socially stimulated, through interactions with others (“interaction” here implies either face-to-face or any other kind of online interaction for someone remote)
4) Not overworking.
Great software is built with effort, and effort makes you tired.
It’s natural to be tired after a good day’s work. It’s so normal we have a nomenclature around it: “go home to recharge” we say.
The most effective way to work is to focus on efficacy and recharging adequately. Stop worrying about everything else.
Pros of working onsite:
1) You should code onsite because face to face meetings convey more than you can over written words, stories, video chat, etc.
2) You should code onsite because coding is a collaborative exercise
3) You should code onsite because CEOs and managers like to see occupied workstations to make it look like people are working
In 50 Ways To Find a Job, Dev Aujla says:
“There are two types of jobs that you can get. One is the type of job where you mentally check out, bide your time, and collect a paycheck. In this job you days are filled with a type of work that often feels stressful, frantic, meaningless. The second type of job is filled with the kind of work that feels natural, that comes easily, that rejuvenates you, and that isn’t motivated by stress or fear.”
Dev Aujla, 50 Ways To Find a Job
When I read this, it struck me a slightly simplistic but I knew exactly what she meant.
It would be ill-advised to argue that onsite work is naturally soul-crushing, or that remote work is naturally better— because it wouldn’t make sense.
Fried and Hanmeir Hanson are such advocates of remote work (they wrote a book about it) that they call offices “distraction factories.”
But it doesn’t have to be this way!
Mentoring & Pairing
In Extreme Programming Explained, Kent Beck proselytized a practice known as Extreme Programming, or “XP” for short. In it, programmers pair. Pair programming means, specifically, that two developers work at the same time on the same code. In fact, the classic way to pair is for both developers to sit at one computer with two separate sets of keyboard & mice (mouses?). The programmers sit equally distant from one another using a big flat screen monitor (not one person on their laptop and the other “looking over their shoulder.”)
Typically, one developer acts as the ‘navigator’ and the other the ‘driver,’ but an effective pair will swap roles naturally and without formality. (As mentioned before, another setup suggested by Beck is having one keyboard that is passed back and forth between them.) The ‘navigator’ will be thinking big-picture about the code, where they are going, the interactions between objects. The driver is the one doing the typing, typically paying attention to the syntax of the API and each little detail as they go. But even when you’re the driver, it’s still exponentially better to have a second pair of eyes catching for mistakes.
When I first read about pair programming I was inspired. Although I’ve done and seen many forms of light pairing over the years, I’ve only known a few companies that have a two-programmer policy for all of their onsite work.
When I can say from my decade and a half in this industry is that while there is no moralism to onsite vs. remote, there is often economy to it. To CEOs and managers, onsite workers seem like workers who can be managed, because they can see them. Onsite workers give CEOs and managers a sense of certainty. Onsite workers, especially engineers, artificially inflate the value of the company because investors and/or other companies who might buy you out will value a company more because of the perception created by having onsite workers.
Furthermore, there’s always been this thing in professional settings where people who work onsite schedule their own personal needs: doctor, dentist, the cable guy are all always seen as typical reasonable excuses for taking time off or working from home.
But what’s typically not so obvious to younger employees is that if you only take time away from your work for these “life necessities” things, you’re likely ignoring self-care in a dramatic way. I’m talking about things like exercise, eating well, doing your laundry, spending time outside. If you have kids, these might be the most important years of their lives: What parent wants to have to work until 6PM or later when their kid gets out of school at 3PM?
Most young parents I know in these scenarios have negotiated some degree of working from home or schedules that allow them to be with their kids after school (Like leaving a 3 pm to go pick them up.)
These kinds so of ideas make companies very nervous. They falsely equate time-on-the-clock with output, which is dangerous. Typically in that mindset, your onsite employees will produce a little as they can to keep their jobs and perform at the minimal output to make it look like they are good employees.
What if I told you a few dirty little secrets of onsite work.
Cons of working onsite:
1) Generally speaking, people who work onsite spend most of their time managing their boss’s expectations, going through what appears to be motions of looking productive and inserting themselves into structures of face-to-face interactions in your company to make themselves appear to be valuable. While I see this a lot from non-engineers, I’ve seen this plenty from engineers too.
2) Offices, especially open offices, are probably the most distracting place to code. People coming and going, other teams making noises, various managers coming up an interrupting you throughout the day. I think most engineers have all been there and know what I’m talking about.
3) Nobody actually works 40 hours per week or 8 hours per day. People come in at 9:45, they unpack their bag, they set up their computer, they go get some coffee. They stop at the ‘water cooler’ for a quick chat with their colleague. They might start about 30 minutes later (but even that isn’t a given.) They do a few minutes of what looks like work, but then they get distracted (see #2). At 10:30 maybe the team has stand-up, which should last 5 minutes but instead takes 20, and then they’re thinking about what someone said at stand-up. They take a few minutes to look up something new, or to check Facebook, or the news. All things considered, most ‘onsite’ employees typically have an effective workday that comes out to about 5 or 6 hours, or sometimes less.
This effect is compounded by being good. If you’re a rockstar, you actually have no incentive to work harder in this scenario. Why? Because the amount of energy you spend is related to the function of difficulty of the task you’re working on, not the number of minutes you are hypothetically sitting at your desk with that problem in front of you. If you get more done in less time, your company only gets more out of you but you (typically) make the same amount of money.
It’s a natural tenancy to manage our work in this way— what’s not natural is the concept that each hour equates to a linear amount of output.
Now, this is not to say that onsite work is the pits or to advocate for remote work— in some regards the opposite.
Some employees probably aren’t better working remotely. Some need guidance, supervision, or mentoring that can’t be done well remotely.
The thing I’ve been wanting to ask employers who insist that onsite work is better— often with something of an obsession with this subject as a moral divide is whether they’ve asked themselves some really deep questions about their own expectations:
1) Do really think that making people be onsite for 40 hours/week (or 38 hours, or 36 hours/week) actually makes them 40 hours of productive?
What if we had a 4-day workweek? What if we gave everyone the day off on Fridays, would they get 4/5ths of what they get done now get done in 5 days? Shocking to most suit & tie people, the answer is almost always no.
When you give people the freedom to work on their own schedule, employees nearly always work harder. Most engineers I know would rather work four 10-hour days (Mon-Thur) and take Fridays off. Why? Well, it comes back to flow. More compressed, focused work is almost always more effective.
2) As a CEO/manager, you know that programmers spend a lot of time at their keyboards. But what’s all this other stuff they do? Talking, diagrams, sometimes just walking around the block.
In software, we call this stuff at the computer GAK — short for “geek at keyboard.”
What software engineers don’t tell you is that lots of the hard problems aren’t solved at the keyboard. In fact, sometimes when you are solving the hardest problem, the best solution is to walk away from the keyboard and start to come up with a mental model of how to approach the problem.
This mental modeling can happen in many forms. Sometimes a team of people can do it (together) in front of a whiteboard. Sometimes you really need to take a walk around the block.
I’ve found personally that the best code I write I actually have to give a great deal of thought to before I write it. Sometimes these mental models take me hours of just thinking about how all of the parts might fit together. (Admittedly I might be doing more architecture work than coding in these cases, but the point is the same: A lot of the work is conceptual, not typing.)
3) Are 8 continuous hours of work, starting at some abstract time like 9AM or 10AM and running through 5PM or 6PM, really the most effective way to get coding done?
In my experience, I tend to work very hard in the morning for several hours. If I get 3 hours of focused, uninterrupted time in, I know I’ve had a good morning. (If I can get 3 ½ hours, I’ve had a great morning.)
The level of concentration required to code is intense.
If you still don’t believe me about the lack of a connection between hours on the clock and work produced take this anecdote: I noticed years ago that if i did very little in the mornings I wouldn’t get hungry to the late afternoon. If I worked very hard, I would get hungry earlier (like lunchtime). After thinking about it more, I realized that work is related to synapses firing in your brain.
Since many of the easy problems you will encounter will be solved quickly, as an experienced software engineer what I’ve seen most is that the hard problems are the ones where the work takes mental energy. It’s the hard problems that demand that I concentrate and focus. It’s the hard problems that make me more tired after 1 hour of coding than 3 hours of non-coding. It’s when I’m solving the hard problems that I don’t want you to talk to me.
Zoom
Now that’s not to say that working onsite is useless: in this age of quarantine, we are reminded of all of the subtle ways Zoom is inferior: 1) interactions are negotiated over email, Slack, or another messenger, any choice of which forces one to confront the explosion of messaging options we have available today (a task that could give anyone choice anxiety).
2) Sitting in front of Zoom screens involves both a kind of participation and acting at the same time, as you become keenly aware of looking at the feeds of the other participants and also the fact that they are looking at you.
3) There is something just slightly lost about the remote pairing. I’m not sure what it is, perhaps it is the added need to negotiate the control of the typing (something that comes a little more naturally while in person). Perhaps it is the fact that onsite pairing makes both partners focus precisely on one thing until it’s done. With everyone at home, there’s a propensity to be distractible with either activity in your home or other activity on your computer (that is, you can keep the ‘Zoom window open’ while doing something else). It just doesn’t seem equal to me to what we now call ‘f2f’ (face-to-face)
4) The actually productive meeting— you know, the elusive one that everyone dreams about having— in which ideas were written out onto whiteboards and then erased and re-worked and you felt like the meeting itself was the process of coming to the group decision. (Not those ill-managed ones with endless circles of indecision gripped by design by committee.)
Those things are lost, sadly, in our Corona-Zoom era.
Maybe Coronavirus and the new remote work paradigm will mean that working remotely becomes de facto. (Likely, when the quarantines are lifted the culture clash between onsite vs. remote will become even more stark.) Maybe not.
But one thing I can tell you is that a lot of people are experiencing this for the first time who’ve never even asked any of these tough questions— if you’re at your desk, are you really working? If you’re writing code, what’s the hardest part of what you’re doing and what’s the easiest? Are you really more effective working longer hours, or are you more effective working shorter, focused hours? What sacrifices are you making to be onsite at a job continuously throughout the day?
I’m not saying remote work is for everyone or every company, just like onsite work isn’t for everyone. But I know for sure that anyone who tries to tell you that one is morally better than the other is full of malarkey and that a huge number of engineers who never been pushed for efficacy simply don’t know what it is. In fact, I’ve also seen the dangerous opposite: A developer who is oriented by the company to put their energy into thinking in the ways of the existing structure and not outside the box. While this is a natural effect of being employed, it isn’t a normal or rational choice for any highly motivated engineer. That’s because the pace of change in this industry is lightning fast.