Meet Leaf Nunes, Head of Release Engineering
·8 min read
Leaf Nunes is the head of release engineering at Signal Sciences. Release engineering has always been sort of a black box to me, so I wanted to ask him more about his job, and how he got here. Plus he’s an all-around awesome dude and a great part of the team.
Some people may not know what release engineering is exactly, so let’s start there. What is release engineering, and why do we care about it?
When I started in release engineering, it often meant getting software engineers to use revision control systems (other than directory copies on filesystems), and making binary artifact production from source code reliable and reproducible. At some level, that’s still release engineering’s heart. For me: can your organization produce the bits needed to serve your customers reliably?
From those first steps, decades ago, release engineering has come to encompass the intersection of development, testing, and deployment: development tools and environments, build and test automation (aka CI systems), and deployment and installation (from packaging/installers for client-side or consumer releases, to server/service deployments).
I’ve often felt that “developers” (i.e. everyone in engineering departments who are not in release engineering) have a love-hate relationship with their release engineering teams. Is that something you’ve experienced in your career?
The only other time I’ve worked with a release engineer, I had no idea what he did nor how it affected me. He was hired well into the lifecycle of the company, and by that point the process for releasing software had been pretty established. So I wasn’t quite sure how he helped.
At my previous job, we didn’t have a dedicated release engineer, which placed the onus of builds for our various mobile apps on the mobile developers themselves. That might have led to some chaos, but maybe I’ve selectively erased those memories. How did you get into this particular specialization?
To your previous experience: in an ideal world, release engineering is completely self-service. Engineers would manage their own tooling, build, packaging, and release mechanisms. There are tools (AWS codesuite, GitHub, and GitLab CI systems) that make this seem tantalizingly close to reality, but that set of tools is still really complicated to manage at an organizational level. If developers are more interested in solving business problems, it’s unreasonable to make each individual engineer come up with versioning and packaging schemes that don’t wildly vary from, or contradict, what their colleagues are doing.
I gravitated toward this specialization in my first few professional roles––I would start somewhere (billing at a startup’s IT department, if I recall correctly), and see that there was no revision control whatsoever, and be horrified.
My focus cemented when I was hired in 1998 to be the dedicated release engineer for mozilla.org, which involved build system maintenance, packaging, some porting work, and CD Distribution Mastering. I felt a strong resonance with the mission, and consistently providing an alternative to Internet Explorer felt like a worthy use of time.
(Also, for the youngsters, CD above refers to compact discs, not continuous deployment) :laughing:
You and Robert (another one of our ops engineers) worked at Pixar for a time, right? Without spilling too many beans, what was the goal of release engineering there? As a follow-up, what past experiences informed how you wanted to go about doing release engineering at a startup like Signal Sciences, where I presume you have more influence than at older, more established places?
That’s right; I worked at Pixar for 12 years and the goal of release engineering there was to keep film crews (artists, animators, programmers) creating with as little friction as possible. This meant trying to balance stable software releases (no production downtime for users!) with some… non-traditional release techniques to get features and fixes into releases as quickly as possible (don’t get in engineering’s way!).
My experiences there, and at early Mozilla, didn’t immediately translate well to a startup in 2017. I was originally hired as an operations engineer at Signal Sciences even though there was supposed to be focus on packaging and releases. I spent most of the first year or two learning and maintaining the existing systems and also learning Operations (Chef, ElasticSearch administration, AWS) which were all new to me. Since we’ve increased staffing for Operations, I’ve been able to assemble a release engineering team, and I’m trying to synthesize the things I learned before with the things I’ve learned here. The aim is to keep developer velocity high with as light a process touch as possible, while making sure we have guardrails in place for uptime purposes.
Let’s switch gears a bit and talk about your day to day. Like a lot of us at Signal Sciences (including me), you’re a remote engineer. How do you like working remotely? Is this your first remote gig?
I really like the flexibility that comes with being at home, but it did take a period of adjustment. I worked remotely from 2000 to 2004, and again since 2016. The first round, I didn’t have a good work-life separation. I was working in my living room without a separate office room, so it felt like I was always on the clock. I don’t necessarily think this made me more productive, but it did lead to burnout.
Working remotely at Signal Sciences has been much better for a few reasons:
- Signal Sciences embraces a hybrid remote culture with over 30% of us working fully remote.
- The teleconferencing software we use is much better and supported ubiquitously.
- People are good about using Slack even when sharing an office (so hallway conversations aren’t as big a missed channel of communication).
- I have better discipline. I either have a separate room or a coworking facility, and I always wear a shirt and tie when I’m on the clock.
Speaking of which, do you care to share some of your past lewks with the readers. And, not to sound creepy AT ALL… but what are you wearing today?
My mozilla.org-era fashion sense was heavily mozilla.org and netscape t-shirt themed, with shorts and sandals (or barefoot), naturally. My manager there introduced me to formal or “tie” Fridays, where we’d buck the trend of going even more relaxed on Fridays by dressing up a bit.
I also worked with her at Pixar, and being exposed to actual artists on a daily basis led me to a bit less conventional style with frequent appearances by kilt-based ensembles with awesome socks. This is today; purple is generally the only color that makes an appearance.
Nice! If I’ve had a bad night of sleep I usually dress up the next day–– the clothes make me more professional even if my body is rebelling against it. It’s one of my productivity hacks! I also work out of a WeWork, so at a minimum I have to dress so that I look like a functioning adult. Speaking of coworking spaces, you recently moved into an office in Portland. How’s that going?
It’s going fairly well! Signal Sciences is considering hiring more Portland folks, so we found a non-profit co-working space that has reasonable rates for a dedicated suite and very fast network. I spend more time commuting than I did when working from home, but there’s a much clearer demarcation between work and home. I also bike most of the time, so I’m getting a bit more exercise than before.
Signal Sciences even sent one of our excellent IT folks out to set up dedicated displays and video conferencing, which I usually leave running throughout the day for drop-ins and for my team who are also mostly remote. Now I just need officemates!
Does the mission of Signal Sciences personally resonate with you?
“Protecting the Web” definitely strikes a chord with the same strings that made me passionate about working at mozilla.org. I would like us to figure out a model that lets us help smaller and non-profit organizations as much as we’re able to help the larger enterprise customers we support now.
Amen to that. I can’t wait for us to be able to address smaller organizations. Awesome, I think that’s a wrap.
The end is the beginning is the end. Thanks, Andy!
