Command Line Heroes - Where Coders Code

Episode Date: July 28, 2020

Home office. Corporate park. Co-working space. Funland campus. Coders expect options when it comes to their workplace. The relocation of the average workspace from the office to the home has revealed the benefits of working from home—but also highlighted its tradeoffs.  Saron Yitbarek and Clive Thompson continue their discussion of coding careers by considering workspaces. Mary Allen Wilkes shares her experience as the first developer to work from home. David Heinemeier Hansson argues remote work gives his colleagues time for deep thinking. Dave West explains why he believes face-to-face work still produces the best results. And Maude Mensah Simpson weighs the freedoms of the home office against missing opportunities for in-person interactions. If you want to read up on some of our research on workspaces, you can check out all our bonus material over at redhat.com/commandlineheroes. Follow along with the episode transcript.

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 sysadmins to architects to engineers to programmers. I'm your host, Saran Yitbarek, and joining me for the run of this season is Clive Thompson, journalist, technology writer, and author of the book, Coders. Hi, Clive. Hi, Saran. 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 50s, 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, you know, behemoth computers, the ones that occupied a whole room.

And 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. And 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 minicomputer. It was one of the first truly interactive computers, not too dissimilar to a desktop computer today. The Link had a display screen. We call 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 like 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 from 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'd had was pretty basic little assembly programs that I had written in 1962 and 63. And I said, you know, 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, you know, 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 the small moving van

and wheeled the various, the four boxes, the four modules, and the refrigerator-sized thing that held the electronics and the memories and so forth. They wheeled those into my parents' living room in Baltimore. They might have 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'll 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 in 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 is where they have all these components. She's sitting there, a little table, and working. And it's just, it's a glimpse of the future, right? I mean, what she was doing then would take 30, 40 years to be realized en masse. But she was completely ahead of her time.

Programming is an 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 sort of, you know, 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 Hansen. 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 IM'd. 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. So we got access to this huge talent pool of people who've realized that they don't want to live in San Francisco. They don't want to live in New York. They don't want to live in Seattle. They don'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 whiteboard. And I thought like, what? People still think like this? How is that possible? The whiteboard is basically non-existent 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. And the deep writing consists not of one chat line at the time, but of fully composed sentences that form paragraphs, that form complete arguments.

And then you consider those arguments with the advantage and calm of time. 90% is the considered writing, then 5% chat, and then maybe 5%, I don't know, Zoom or Tuple 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 have thought of. Are there other ways of working that coders are using that make remote work a 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 was 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. You know, we, from Tuesday and Thursday, one till 5pm, 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, you know, at a Starbucks, it could be at home. So this sort of interesting latticing of new arrangements is, 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. In David's case, he likes and his team likes sort of long form, you know, email conversations. And I've definitely talked to people that like that, but other ones, they actually really liked Slack or they really liked, you know, good old fashioned IRC, right? Like, you know, green text on a black background, but they, they worked out what their co-presence was because there's this, there's this, you know, phenomena that sort of 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, you know. And 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. And 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 just for the next five, 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 and figure out some way to do that, you know, with an experienced person, or even frankly, even just with a peer, right? You know, because like, you can get a lot, even if someone's not senior to you, but it's just a different brain, right? You know? 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. And 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 kind of 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 since 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, right? 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 sort of encounter each other that maybe didn't really know of each other's existence. It's a classic water cooler effect. 3M, the big paper company, famously invented post-it notes, like, you know, just a multi-billion 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, you know, because of that chance running into each other, they created one of the most iconic products for that company. And Steve Jobs literally created Apple's headquarters to maximize the chance that people not just would 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 of 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, you know, at the startup level, right? Where, you know, 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, you know, 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. And those are small teams. And so 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, you know. 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. With 150, oh my God. And it gets a lot harder for a company that has 10,000 people to figure out how they're going to do that. Let's hear another argument to 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 the reality is that if you really want to build a product at vast speed, work 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, you know. And that's for so many reasons you know it's because of going out and getting you know a few beers on a on a friday night the 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 dogs died or something like that. You get that sort

of extra stuff, right? 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, right? 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 there's a balance that you have to make it's and it's incredibly hard what i 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, you know, bringing them together, you know, frequently. And so you do a lot of screen sharing and you spend time together and maybe you shove on a, you know, a Google Hangout and just leave it running and just share. Those sort 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, right? 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. And 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 I mean, you know, all the sort of stuff that Dave was just talking about is true, which is that like, with no face to face contact, it's really easy for all the sort of social glue

that helps an organization work to fall apart. And you see that in open source projects, right? Like they can really turn into, you know, 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, right? And things that could be cleared up in like 30 seconds with face-to-face social interaction can, you know, 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 where like the little side conversations that people have about work and like in general, my senior developer would, you know, 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? You know, he would, the act of him just passing by my workspace gave him the opportunity to kind of talk to me about coding

and like how to do things properly. And it just might be like your personal confidence to work remotely because you just miss some of the like teaching and like the tutoring when you're not working inside the office. Clive, I'm wondering if the experience of working remotely is different for an experience coder versus an early career coder. Because I can imagine for an experience 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, you know, sort of older developers who came up through face-to-face collaboration and knew that, wow, they could learn an enormous amount and get unblocked with like a 30 second conversation, you know, face-to-face with a senior developer. So Jeff Dean is a senior, senior engineering manager at Google. And I heard from lots of people

who worked alongside him that he is just as sort of incredibly useful senior resource, because people would come to him with a problem and he could literally just, you know, see the vector straight through it. And in like 20 seconds go, oh, you know, he wouldn't give them the answer, but he would tell them, here is 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. And it's, I wouldn't say you never get them remote, but they're harder to get. And then, you know, there's also, you know, code review. So at a good company that's well managed, you're going to have code review where your peers and ideally senior people who, you know, have been around the block a bit are looking at your code and sitting down and talking about it and saying, asking you, you know, how and why you did it this way. And that to and fro, you know, takes a lot of unconscious decisions that you might have made and make some conscious. And that's incredibly valuable for learning, right? You know, 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, you know, when you start work and then it's six o'clock 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, like never stepping away from the work. And I also heard that from the developers too, that it was hard. I mean, 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 Hansen. 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 he 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. And 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 this 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 kind of like 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. And how I fixed that was I had a Pomodoro timer and I'll make sure to take, you know, dedicated breaks every hour or so. And then just being able to like separate home from work. I have a office and home and I don't let my home life come it come into the office to make sure you know I separate the two so when I'm outside I could be mommy or you know whoever I am when I'm not at work but then when I come inside the office it's you know it's go time and it's a lot easier to get into

the flow of working I would do like a quick status update every day. Like 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. There's no, I don't think there's any such thing as over communication when you're working remote. So yeah, just, you know, 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. And the head of engineering was remote and he was working in the woods south of Nashville. And 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 sort of 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 slash 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 back and we'll tackle the question, what kind of coder will you become? Thank you so much for joining us, Clive. Thanks, Saran. You've been listening to Command Line Heroes, an original podcast from Red Hat. I'm Saran Yadbarek. 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. Hi, I'm Jeff Ligon. I'm the Director of Engineering for Edge and Automotive at Red Hat. The number one hesitation that I think folks have about Edge is that they assume they're not ready for it. They think that it'll mean starting over from scratch or that every time their business needs to change,

there'll be re-engineering solutions and re-evaluating vendors. And look, edge is complex and it does mean a different approach, particularly for devices at the far edge. But with Red Hat, it doesn't mean starting over with new platforms. We've taken the same enterprise solutions that simplify and accelerate work across the hybrid cloud and optimize them for use at the edge. So you can manage your edge environments just like you do the others. Come find out how at redhat.com slash edge.