Where Coders Code

Hello, welcome to Command Line Heroes, an original podcast from Red Hat. This is episode 2 of our special mini-season all about the work life of coders. From developers to sys admins, to architects, to engineers, to programmers. I'm your host Saron Yitbarek, and joining me for the run of the season is Clive Thompson, journalist, technology writer, and author of the book Coders. Hi, Clive.

Hi Saron. Good to be back.

Thanks for joining us Clive. In this episode, let's talk about something a large number of us, not just tech workers, are very familiar with by now, because most of us have had to do it since March of 2020. Remote work. Now, you might think that remote work in our industry is a relatively recent phenomenon. As technology has improved, the easier it's gotten to work from home. Think again, let's listen to this developer's story.

Well, my name is Mary Allen Wilkes. I was a computer programmer for approximately 12 or 13 years between 1959 and 1972.

Mary Allen is 82 years old. When she was a teenager, she fell in love with law and wanted to be a lawyer, but back in the fifties that wasn't a wise career choice for a woman. Mentors discouraged her and told her it would be too much of an uphill climb. By chance, one of her teachers pictured another route for her.

I had been told when I was in the eighth grade by a geography teacher in class one day, apparently I was giving him some kind of argument about something, and he just stopped and he looked at me and he said, "Mary Allen, when you grow up, you ought to be a computer programmer." Well, I had no idea what he was talking about. Years later, I wondered how he knew what he was talking about. He taught geography and French, nobody taught computer programming. But I never forgot what he said. And I think one of the reasons that stuck with me for so many years was that it was something positive that an adult told me I could do when I grew up.

When Mary Allen finished college and started applying for jobs, the only place that had a job for a computer programmer was at MIT. Nobody had any training in computer programming. Her main qualification was two logic courses she'd taken in college, but that was more than her MIT colleagues had.

I started off at Lincoln Laboratory in Lexington, Massachusetts, a big MIT research facility that is funded by the Department of Defense. We're talking 1959, and I first learned they were using these big behemoth computers, the ones that occupied a whole room. That's what I first learned to program. They were IBM computers. You wrote your programs out line by line in assembly language, and then you handed these sheets of paper to a punch card operator who punched each line of code. Then you took that to the computer room and you gave it to a computer operator.

In 1961, Mary Allen got assigned to a group to work on the Link computer, a laboratory instrument mini-computer. It was one of the first truly interactive computers, not too dissimilar to a desktop computer today.

The Link had a display screen. We called it “the scope” because it was really just a laboratory oscilloscope. It had four boxes that you could set on a tabletop or a desktop, and one box held this oscilloscope, one box held two little magnetic tape units that were pocket-sized. That was basically your permanent storage, your hard drive, if you will. That was where you stored your programs, and you read in your programs. Another box was called a console box. You could use the switches to load some code, some bootstrapping code for example, into the memory of the Link. It also had a keyboard. So, you had the basic interactive setup that you have today, with a keyboard and a screen and some means of permanent storage. And then of course there were all the electronics, which were housed in a big box about the size of a refrigerator.

In 1964 the Link Group made a tough decision to relocate for MIT to Washington University in St. Louis, Missouri, but Mary Allen didn't want to go.

I didn't want to move to St. Louis right away. I wasn't sure I wanted to move there at all. What I wanted to do was write a proper operating system for the Link, because up to that time, all we had was pretty basic little assembly programs that I had written in 1962 and ‘63. And I said, "I could do that. I could write it at home."

Wesley Clark, the lead of the Link Group thought it was a great idea.

I said to him, "I want to write the operating system." I was probably the only person who could write the operating system at that point. So, Wesley just said, "Well, no problem. We'll send you a Link. You can have it at home." And that's how it came about. A couple of guys from our laboratory arrived one day in a small moving van and wheeled the various four boxes, the four modules and the refrigerator size thing that held the electronics and the memories and so forth. They wheeled those into my parents' living room in Baltimore. They might've had to create 20-amp circuits for it, but otherwise, you just plugged it into the wall socket.

And what did her parents think of this large new intrusion in their home?

My father was an Episcopal clergyman and he would tell everybody he saw, "I bet you don't have a computer in your living room." It was quite a novelty to say the least. Quite a novelty.

Mary Allen's parents were gone all day, so she was able to concentrate. She wrote the operating system right on the Link, no need for punch cards, so she could debug much faster. She communicated with her team by phone or good old-fashioned snail mail, and would take the odd trip to St. Louis if necessary. In just under a year, she completed the OS and wrote the programming manual.

I never felt isolated, and I never felt frustrated. I felt challenged. I think programming is basically a job for introverts, people who work well in isolation, people who work well independently, who don't need a lot of support or interaction with others.

Over the years, Mary Allen has worked in other jobs that required her to work at an office. Her preference though, is working from home.

I've been working at home now for several years, since I quit my last day job in 2001. So, I'm a work-at-home person. And in fact, when I left that day job, I said to myself, I'm going to keep working, but I do not want to go to an office, and I do not want to sit at a desk. But by that time, of course we had laptops, so I was able to sit in an easy chair.

So Clive, Mary Allen has such a great story and you got to interview her for Coders. She was not just a computer programming pioneer, but a remote work pioneer as well, wasn't she?

Yeah. I mean, as far as I can tell, she is the first person to have a personal computer at home that she's doing her work on. There's this amazing photo online of her and she's sitting there at the foot of her parents stairs. It was downstairs from the top floor, it’s where they have all these components where she's sitting there, a little table, and working. And it's a glimpse of the future, right? I mean, what she was doing then would take 30, 40 years to be realized en mass, that she was completely ahead of her time.

Programming is that ideal kind of work to do remotely. Even my own experience with self-isolation has made me realize that I've been doing exactly that for a number of years. So when you talk to coders, how many of them prefer this work method? How popular has it become?

Well, it's very popular, and that's because coders love working from home. The vast majority of coders, if they were given the choice, they would say, yes, I would work from home all the time. And the reason why is because it just gives them a quiet and a focus and a lack of interruptions from people tapping them on the shoulder in the cubicle. If you were to say to them, "Hey guys, everyone, where would you prefer to work?" They would all prefer to work from home.

One tech company that is a big advocate for remote work is Basecamp. They've been around for 20 years and they've been remote from the start, even before it became popular. Their staff work from home around the world. Let's listen to David Heinemeier Hansson. He co-founded Basecamp with Jason Fried. He's also the creator of Ruby on Rails.

Actually, for the first six months after I started working with Jason, we just emailed and IMed. We didn't even talk on the phone. So it took six months, I think, before we had our first phone call, and it took over a year until we met each other in person. So for a very long time, this was not conventional wisdom. We got access to this huge talent pool of people who realized that they don't want to live in San Francisco. They didn't want to live in New York. They didn't want to live in Seattle. They didn't want to live in any of these big tech hubs, yet they're really proficient, qualified people. So the fact that Basecamp allowed them to do this was a huge factor in both our hiring strategy and our retention strategy.

In 2012, I had a series of conversations with other entrepreneurs where I would ask them about their work practice, and we'd talk about remote, and they would just give me these trite defenses for why remote couldn't work. "Oh, you can't do collaboration. The magic only happens around the white board." And I thought like, what, people still think like this? How is that possible? The whiteboard is basically nonexistent at Basecamp. The number one tool we have is writing. It's asynchronous, by yourself writing and you post it, and you let some time pass by. Good collaboration happens when creative people get time and space to do deep thinking and they compile that deep thinking into deep writing. The deep writing consists not of one chat line at the time, but fully composed sentences, that form paragraphs, that form complete arguments.

Then you consider those arguments with the advantage and calm of time. 90% is considered writing, then 5% chat, and then maybe 5%, I don't know, Zoom or Tubal or some other video connection—share-my-screen kind of collaboration.

So Clive, David is making some super interesting points here. Some I never would've thought of. Are there other ways of working that coders were using that make remote work as success?

Yeah, absolutely. They arrange times when they know that they're going to be in contact and maybe in face-to-face contact. So there were definitely companies I spoke to that said, "Okay, we know our developers do their best work when they're not here, but we want them to be here some of the time, we want to have some face-to-face meetings." They still believe in that. And so they would have these schedules that were like, okay, on Tuesday and Thursday, from 1 - 5 PM, we need everyone to be in the office just so we can have some time to talk. The rest of the time, go wherever you want. You can work in the office if you want to, you can work wherever you want. It could be at a Starbucks, it could be at home. So this sort of interesting latticing of new arrangements is one thing that works really well.

Another thing that I think works really well is figuring out what's the sort of mode of chat or communication that everyone likes the most. And in David's case, he likes, and his team likes, long-form email conversations. I've definitely talked to people that like that, but other ones, they actually really like Slack, or they really like good old fashioned IRC, right? Like green text on a black background. But they worked out what their co-presence was, because there's this phenomenon that psychologists who talk about online communication describe as ambient awareness, which is the ability to know what other people are sort of thinking about and doing when you're not physically there with them. There's a lot of technologies that allow us to do that. And the best remote teams think carefully about what their ambient awareness method is, and they lock in on it and they use it.

One thing that I found to be really useful in my own remote working experience is to co-work via a Hangout session or a Zoom session, just letting the stream run and just having that connection open. It's been a really great way of feeling less isolated, kind of having company with the expectation that each person is still doing their own thing, but it gives that opportunity to tap someone on the shoulder, because I can just say, "Hey, I'm stuck on this one feature. Do you mind for the next 5, 10 minutes, can you pair with me and help me get unstuck?" So it's been a really useful way of having some type of social interaction and having those opportunities to get help when you need it.

That makes total sense. I mean, I think a lot of people try to figure out some way to do that with an experienced person or even frankly, even just with a peer because you can get a lot, even if someone's not senior to you, but is just a different brain.

Yep. Absolutely. I think it's a different type of communication, but I'm not convinced it's a lower quality of communication.

No, not at all. It's like what psychologists would call metacognition, thinking about thinking. Really, the task at hand is: what type of thinking am I trying to do today? And is that thinking better served by being physically with someone, or chatting with them online?

So now that we've all been forced to work from home, companies are realizing that they can still get work done. Have attitudes changed to the point that remote work will go mainstream?

That is a really big question that I don't think we have an answer for yet. I think what's going to happen is that a good chunk of the workers out there, including the developers who have never worked or been allowed to work from home a lot, I'm going to say more than 50%, are going to ask to have that be made semi-permanent. They're going to discover that they're way more productive and they'd like to do it more often, and that a certain amount of those meetings were just not necessary and interrupted their flow in their workspace.

So if remote work is a great way to be productive, it's getting more popular over time, and especially for coders it's such a great way to get work done it can be a lot more convenient, and our type of work is really meant to work from home, why do these big tech companies keep building such large campuses for their workers to work in?

It's partly based on their idea or their concern that creative thinking only happens when people are face-to-face, and have unexpected connections to each other. And that's based in some actual science. I mean, there is a fair amount of research that shows that a certain type of communication and loose collaboration and loose idea generation happens when people in a company encounter each other that maybe didn't really know each other's existence. I mean, it's a classic water cooler effect. 3M, the big paper company that famously invented Post-it Notes, just a multibillion dollar invention, when one person that had invented this kind of sticky substance encountered someone else who was looking for a way to hold pieces of paper in place. And because of that chance running into each other, they created one of the most iconic products of that company.

Steve Jobs literally created Apple's headquarters to maximize the chance that people wouldn’t just work together, but they would have to sort of convene in places to create those creative sparks.

So I've done remote work for a number of years, I've done it just working for myself, and then once I had a team, I had a couple people that were working with me, but my experience with remote work has been a maximum of four people, and they were everywhere. We had someone in LA and Brooklyn and Chicago, but I'm wondering: is remote work only really successful for small teams like that, for smaller companies like Basecamp?

Yeah, that's a great question. I have seen it most successfully deployed when development teams were small, at the startup level, where they had five or six people, and in fact, the reason why they were able to get the talent they wanted is that they said, "Okay, you are in Russia. I'm in Toronto. Our other person is in Tennessee, and we're just going to work together." So you see it a lot in a certain type of startup that has a specific skill set they need and they need to get people that they think are the best and they're not going to demand or ask those people to move. Those are small teams.

I think it's a little easier to manage the communications because you can almost think of this as the communications between a set of nodes, and as the nodes grow, the number of people that need to communicate grows dramatically. So with four or five people it works really well, with like 50, it gets really hard, 150, oh my god. It gets a lot harder for a company that is 10,000 people to figure out how they're going to do that.

Let's hear another argument about working remotely. Dave West is CEO of scrum.org. Fundamental to the work at this company is the first rule of the Agile Manifesto, individuals and interactions over processes and tools. Here's Dave.

I think that the reality is that if you really want to build a product at vast speed, working together in a really effective way, face-to-face is still probably the best. That doesn't mean it's the only, and it doesn't mean you can't be as effective in other forms of communication, in other forms of distribution, as it were, however, the best and the easiest is face-to-face communication. I, to this day, still believe that the most enjoyable software projects that I've ever worked on and development projects and teams I've ever worked within have been located in the same physical geographic, same office. And that's for so many reasons. It's because of going out and getting a few beers on a Friday night, the ability to really get that extra level of understanding about a human being when something's going wrong that may be challenging their work, like their dog's died or something like that.

You get that sort of extra stuff that's a lot harder to get from a distributed team. But on the other hand, I don't think all the best software engineers live in Silicon Valley. So I'm conflicted, I think the value of a co-located team is huge, but I also think the benefits, particularly around diversity of people in different locations, is also huge. So, there's a balance that you have to make, and it's incredibly hard. What I do know is that if you are going to distribute your team, then you must pay particular attention to facilitating and enabling the environment to actually replicate as near as possible that co-located team. Which means bringing them together frequently. So you do a lot of screen-sharing, and you spend time together, and maybe you shove on a Google Hangout and just leave it running and just share. Those sorts of things become very, very important.

So Clive, open source projects are built on collaboration and teamwork. So does remote work hinder that? How conducive is remote work to real collaboration?

Well, the first part of that question about open source is easy to answer, which is that I actually think most of the big successes in open source have been extremely remote because by definition, the magic of an open source project is a developer saying, "Hey, I've got this code base I'm working on. Does anyone have any ideas?" And instead of just asking the 50 people in your company, you ask the millions and millions and millions of people online. Because only 1% of 1% of 1% of 1% are going to actually have a good idea for you. No one in your 50-person organization might care about the weird little library you're building, whereas scaled across the planet, you're going to find nine people that are just unbelievably passionate and interested in helping with that thing. So in one sense, open source is by definition heavily catalyzed by remote work, by remote collaboration.

It's challenged by it too though, because all the sort of stuff that Dave was just talking about is true, which is that with no face-to-face contact, it's really easy for all the social glue that helps an organization work to fall apart. And you see that in open source projects. They can really turn into nightmares of antisocial behavior online because people are bad at reading each other's tone. They'll think they're just being direct and other people read them as being unbelievably curt and insulting. And things that could be cleared up in like 30 seconds with face-to-face social interaction can tear open source communities, and have torn open source communities, apart online.

Maude Mensah Simpson is a front-end developer who works from home while being a mom to two young kids. She explains one of her early challenges with remote work after she had her second child.

I had only been a developer for a year when I had my second. So there's so much you miss when everybody else is in the office and you're not. One of the things was the little side conversations that people have about work in general. My senior developer would, when I'm coding, he would pass by behind me, and then he would see things that I'm doing and he'd be like, "Oh yeah, I like how you did that." Or, "What are you doing?" The act of him just passing by my workspace gave him the opportunity to talk to me about coding and how to do things properly. It just might be your personal confidence to work remotely, because you just miss some of the teaching and the tutoring when you're not working inside the office.

Clive, I'm wondering if the experience of working remotely is different for an experienced coder versus an early career coder, because I can imagine for an experienced coder, who's used to working in an office environment and then has to switch to remote work the change probably isn't too bad; it's probably not too challenging. But for an early career coder, I can see them really benefiting from being around mentors, people with more experience, being able to tap people on the shoulder and ask them a question. So, are early career coders losing something by not being physically around other coders?

I think they are. Yeah. I think that's a very legitimate concern, and I've definitely heard it from older developers who came up through face-to-face collaboration and knew that wow, they could learn an enormous amount and get unblocked with a 30-second conversation, face-to-face with a senior developer. So Jeff Dean is a senior, senior engineering manager at Google. I heard from lots of people who worked alongside him, that he is just this incredibly useful senior resource because people would come to him with a problem, and he could literally just see the vector straight through it, and in like 20 seconds go, "Oh..." He wouldn't give him the answer, but he would tell them here's where I think the issue really lies, and they would get unblocked and they would go back and they would be unbelievably productive.

And so the junior people would benefit greatly from interactions like that. I wouldn't say you never get them remote, but they're harder to get. Then there's also code reviews. So at a good company, that's well-managed, you're going to have code reviews where your peers, and ideally senior people who have been around the block a bit, are looking at your code and sitting down and talking about it and asking you how and why you did it this way. And that to-and-fro takes a lot of unconscious decisions that you might've made and makes them conscious, and that's incredibly valuable for learning. To be able to understand why you did what you did, to externalize that for someone else, is incredibly valuable.

One of the problems I've heard of with working remotely is this idea of blending, which is when you start work and then it's 6:00 and you kind of should stop working, but you're at work, you're comfortable, you'll work an extra hour or two, and you end up overworking when you're working remotely. Is that a thing? And then kind of the opposite of that, can you underwork by working remotely?

You possibly could underwork, but I never heard about that in all my interviews, both with developers and their managers. In fact, the opposite. I tended to hear that managers were worried that people were never turning off, never stepping away from the work. I also heard that from the developers, too, that it was hard; it's always hard to stop thinking about a problem for developers. When you work from home, you'll spend your eight hours of deep immersion and you'll get a lot of stuff done, but because you don't physically go somewhere else, your body can't help trick your mind into turning itself off. Like if you leave the office and you get in the car or the bus or the scooter or you walk home, you physically go from one place to another, and that physical signal helps your brain reset itself.

There's just lots and lots of science on this. I mean, literally physically going from one room to another helps your brain reset itself. When you don't have the ability to do that, when you work from home, the natural chess-like mental space of a coding problem becomes very hard to tell your brain to stop working on it. And so there's a lot of reasons why people who work from home just keep on going in a way that they know is unhealthy, but they have trouble stopping.

David Heinemeier Hansson.

We have some funny anecdotes of how people at Basecamp have dealt with this over time. We had a data analyst at one time who had two sets of slippers. He had his work slippers that he would get into when he walked into the office and then you would have his home slippers. They were both just a set of slippers. They just provided the separation between work and home. And I think that separation is pretty important. I think for a lot of people who do use their home, being able to segregate one room of the house for that and then when you leave that room, you're no longer at work is also a healthy practice.

I love the slipper idea, like Mr. Rogers. Here's Maude again. After years of working from home with kids, she's figured out her own formula to make working from home work for her.

It's very easy to lose track of time. You could be sitting there for a few hours and not know how long you've been coding away because you're at home. How I fixed that was I had a Pomodoro timer and I would make sure to take dedicated breaks every hour or so. Then just being able to like separate home from work. I have an office at home, and I don't let my home life come into the office to make sure I separate the two. So when I'm outside, I can be mommy or whoever I am when I'm not at work, but then when I come inside the office, it's go-time and it's a lot easier to get into the flow of working. I would do a quick status update every day. In the morning, I'd let them know this is what I'm working on today and then in the evening, I'd let them know where I was. I don't think there's any such thing as over-communication when you're working remotely. So yeah, just communicate, communicate.

So Clive, are there other tips or tricks to managing a workforce remotely or even being a remote worker?

Sure, if a company is going to have a serious remote culture, one important thing is for people at the top to also work remotely so that there isn't this sense that remote is this secondary status and that big decisions are being made face-to-face by important people and the remote people are not part of that. An example of that, that I ran into while researching my book, was when I was talking to some of the engineers for Postlight, which is a terrific company here in New York City. They develop apps mostly for the media industries. The head of engineering was remote, and he was working in the woods south of Nashville. When I talked to him, he said, “This is a really important thing, because we have a lot of remote engineers, and they like knowing that I'm heading up the engineering workforce, and I myself am remote." It means that everyone in the company thinks very mindfully about how to make remote work, because the person running the show in that part of it was himself remote.

Most of us had to make a drastic shift in how we work since March of 2020—working from home, whether we did that already or not. And when we work from home, it comes down to our personal work style and making sure that whatever project we're working on, whatever company we're with, whoever we're managing or being managed by, our individual preferences are respected and we're allowed the flexibility to work how we work best. Putting people over process isn't just the first rule of the Agile Manifesto, it's the open source way, and it's the approach that yields the best results. For more research on this episode, go to redhat.com/commandlineheroes. Next time, our final episode of this career-minded mini-season, Clive will be back and we'll tackle the question, what kind of coder will you become? Thank you so much for joining us Clive.

Thanks, Saron.

You've been listening to Command Line Heroes, an original podcast from Red Hat. I'm Saron Yitbarek.

And I'm Clive Thompson.

All right. How are we going to do this?

Oh my god. Can we use the “keep on coding” for the last time?

Keep on coding.

Keep on coding.