Categories: interviews

Software Engineer Mike Conley on sharing “The Joy of Coding”

When Mike Conley joined the Mozilla team in 2011, he never imagined that he’d someday be livestreaming his work every week. But a few years ago, a challenge from CEO Mitchell Baker prompted him to do just that, and now “The Joy of Coding” is giving viewers around the world an inside look at what it’s really like to build Mozilla products — as Mike says, “warts and all.” Below, the principal software engineer explains his path to Mozilla and the reasons he stays, describes the stretch project that helped him build his career and shares the benefits of working in front of an audience.

What’s your background and what brought you to Mozilla?

I was big into theater in high school, but because that can be a hard way to make a living and I had decent math scores, my guidance counselor suggested I look into electrical and computer engineering. I turned out to be terrible at the electrical part, but pretty good at the computer part, so I ended up double majoring in computer science and theater at the University of Toronto. Every day I’d go from yoga to calculus or programming to voice class. It was actually really energizing.

When I graduated in 2008, the job market was pretty bad, so I decided to go to grad school and do software engineering research. I had a graduate supervisor who knew a lot of people in the industry, including at Mozilla, and I started working as a contractor on Thunderbird (Mozilla’s email client) after I finished my degree. Then when that contract was about to expire, they invited me to join full time. That was about 11 years ago, and I’ve been here ever since. I love the people, the work we do and the challenges. I get to solve puzzles for a living! And I get to wake up every morning and think about how to make the web a better place, rather than how to raise a stock price.

Tell us about the work you’ve done since joining the team.

I started out doing little bits of UI work — first on Thunderbird, and then on the Firefox team. I was polishing up the user interface, moving buttons around, writing patches to fix bugs. Then I was fortunate enough to be invited to work on some larger architectural projects, including one we codenamed Electrolysis. At first, I felt so outside of my comfort zone. I’d done a little bit of C++ programming previously and was interested in doing more, but this was definitely a stretch project — I had impostor syndrome and thought, “Am I the wrong person for this job? Maybe they made a mistake.” But I ended up staying with that project for three years, and I think it allowed me to level up and led to a lot of the work I’ve done since. It was a great team, and I got to learn from some really smart people I otherwise might not have met.

I also came away with a much better understanding of the Firefox codebase. Browsers these days are analogous to operating systems — they’re big and complicated. But it’s like a city. It’s not possible to know the whole thing, but you can get to know one block, or one neighborhood, or the transit system. And then over time, patterns emerge, and you start to see the bigger picture and understand how everything ties together.

Can you share more about the work you did on Electrolysis?

It was a big project — we had to essentially re-architect Firefox, and do it while people were using it without disrupting their experience. Our goal was to switch from a single-process browser, where all of your web content is running in the same program, to multiple processes. The simpler architecture had its advantages, but when everything runs inside the parent process, it’s more susceptible to abuse, and to performance issues — if a web page is running slow or crashes, for example, it will slow down or crash the whole browser rather than just one tab.

We had some of the infrastructure we needed already in place for plugins like Flash and Java, but we wanted all web content running separately from the browser UI. So it was like taking a Gordian knot and finding a way to slice it in half, which meant making some hard choices. XUL (user interface language) add-ons were one of those; we initially tried to make them work with the process separation model, but it was clumsy and glitchy. We had to make the call to deprecate them and create the web extension APIs, so we could ultimately ship a more secure, performant, stable browser.

We pulled it off, which was a big moment for us, and I personally learned so much from getting that broad view of the browser — when you cut a knot in half, you touch a lot of different pieces. Working on Electrolysis is what gave me the confidence to dive into an unfamiliar piece of code and say, “Well, I don’t know what this is, but I’ve figured things out before. I’ll talk to the right people and figure this out, too.”

You do a weekly livestream called “The Joy of Coding,” where viewers watch you work. How did that come about, and what kind of impact has it had?

The initial catalyst was a talk our CEO, Mitchell, gave at an All Hands meeting, where she challenged us to find ways to be radically open. Not long after that I was at home, watching TV, and the old Bob Ross show “The Joy of Painting” came on, which I’ve loved since I was a kid. Normally when you see a painting, you’re only seeing the end result. But on that show, you get to see the process. If he makes a mistake, he turns it into a tree. I wanted to do the same thing with software — share my screen and narrate as I worked. I wasn’t sure whether anyone would actually watch, but if nothing else I was curious about what it would be like to work that way — including not checking email or Twitter for an hour and a half!

I also wanted people to see what goes into something like Firefox, warts and all. I don’t go into a stream with a plan — there’s no code prewritten, and I might not even have a solution in mind. I just poke at something and see where I get. No, that didn’t work. Neither did that. But oh, this did.” Just like painting, that process is usually hidden, sometimes even from the other people working on a project. But if someone sees your struggle, not only can they learn from it, it also helps fight impostor syndrome. That’s actually turned out to be one of the main benefits of streaming, I think. It’s a way for me to show people that if I can figure things out, so can they. I’ve been doing this for more than a decade, and I still make mistakes every day. I’m not doing anything special. I’m just being persistent.

There are lots of other benefits, too. I have a Google form viewers can fill out to communicate with me, and I’ve learned a lot from them. They are also great at spotting typos in my code. And more than one of them has gotten involved with Mozilla. I just met someone at All Hands in Hawaii who stumbled on my streams when YouTube recommended it and started to contribute, and now she’s a contractor helping us migrate from Amazon Web Services to Google Cloud Platform.

What’s next — for you and your work and streaming, and for Mozilla?

I want to keep doing The Joy of Coding”; thinking out loud is such a useful tool for problem-solving. It forces you to confront your assumptions and helps you see the gaps and new ideas to try. And I think it’s always good to get comfortable with the vulnerability of making mistakes in front of people.

As far as work itself, I’m contributing to changes in the UI to support the upcoming Manifest v3 changes to WebExtensions in Firefox. We’re adding some new controls to our navigation bar to make it easier to control your WebExtensions and what web content they can access. There’ll be broader communication about this change as it becomes more ready, but in the meantime you can read this mailing list post about it by my colleague Will Durand. After that, I’m going to be looking at ways we can make it easier to migrate from other browsers to Firefox.

It’s worth noting that at Mozilla we punch above our weight — we’re up against giant companies like Microsoft, Google and Apple. That requires ways to compete asymmetrically. We figure out what our superpowers are and make them our advantage. We try to find the places where our competitors won’t go.

As far as what’s next for Mozilla, I’m not good at predicting the future. But the world does seem to be much more aware of privacy on the web than even just a few years ago. It’s not the Wild West anymore; it’s a big business, and every browser is trying to brand themself around the things we’ve been doing since the beginning. So I think we’ll see more investment in innovations to protect data and privacy, and more value placed on Mozilla’s areas of expertise. Making the web better is never easy, but if you read the Manifesto, that’s the job — it’s why we exist. We aren’t going to move the mountain overnight, but it can be done.