Yet another career story

Just before I headed out on leave with my second, I was finding myself talking about my career journey rather frequently. So let's kick off the new year with just that.

The following is a modified, updated version of the career story I shared with fellow Slack employees as part of our career stories series.

In hindsight, looking at how everything’s played out, it should’ve been obvious I’d end up here, doing exactly what I’m doing. But in the moment, it didn’t seem that straightforward at all 😅

Before 👶🏻

I grew up in a house full of computers. 🖥️

My dad was among the first to graduate from a joint Computer Science/Electrical Engineering degree at Université Laval (in Québec City) in 1983. He taught programming at a local CÉGEP for nearly two decades and then moved us to New Hampshire when he took a job as an embedded programmer in 2000.

For as long as I can remember, I always had access to a computer and a high-speed internet connection. I grew up drawing in MS Paint on a Windows 95 desktop machine, playing Sim City 4 on an eMac, and AIMing on an iMac.

At no point did my dad insist I learn how to program, and considering his job never sounded particularly thrilling, I was fine with that. (Talking about the number of bytes he needed to shed in order to get his code to run on the thermostat hardware they had available was not my idea of fun dinner conversation.)

University 📚

Day one at McGill, I had a(n ambitious) plan. I’d study molecular biology, land a spot in a lab at the McGill Genome Centre, apply to graduate school, and one day develop gene therapies. No big deal.

Things didn’t go quite work out that way.

By mid-October, disillusioned by the amount of memorization involved in microbiology, and the highly competitive attitude of the many pre-med students in my midst, I had a new plan. I’d become a chemical engineer! I swapped out “Introductory Microbiology” and “Elements of Immunity” for the required coursework to transfer into the Faculty of Engineering.

Unfortunately, one of the engineering requirements was an entry-level programming class. I feared the worst: that I’d struggle through the assignments and barely make it out with a passing mark; that I’d dislike the class and disappoint my dad. While I wasn’t the quickest to grasp all the new concepts thrown at us (nor the best at debugging), neither fear came true. (Thankfully!) There was something about creating something from nothing, the exhilaration when everything compiled. The satisfaction of it all was terribly addictive!

Ultimately, I wasn’t offered a spot in the Faculty of Engineering. For the second time that year, I felt completely lost. I reluctantly declared a major in computer science instead. I had no idea what I was doing.

Before heading back to Montréal, my dad sat me down for a “pep” talk. He told me he’d seen the number of women enrolling in his classes dwindle as the prestige associated with programming grew. He’d witnessed first-hand the leg-up that most of his male students had had from tinkering with computers and calculators well before they landed on campus. He warned me that I’d face a very steep learning curve.

“Programming takes practice,” he told me, “you just have to put in the time. You might be a little late to the starting line, but you’ll catch up.”

Besides, the ability to quickly churn out code wouldn’t be crucial in more advanced courses like algorithm design and systems architecture. “But most importantly,” he said, “with your work ethic, you can conquer anything.”

“Until then,” he said, “call me with questions anytime.”

And I did, often. We spent hours on Skype (yes, Skype) debugging null pointer exceptions and segfaults. Were it not for our late-night question and answer sessions, I’m not sure I would have survived my first year.

I eventually fell in with some of those very nerdy early-to-program types, and they helped carry me through the rest of my degree. (I eventually ended up writing a compiler with two of them, and later marrying one of them.)

It took me two solid years, but I caught up to my classmates. When I started my fourth and final year, with a job offer in hand, I finally felt more at ease among my peers.

Internships

Schneider Electric 🔌

I have nepotism to thank for my first internship. I sent my resume around, attended job fairs, but no one gave me a second look. When my dad offered to have me interview for a role at his company, I had no other leads. I spent the summer between my second and third years building interactive displays for administrators looking to understand their buildings’ energy consumption. I picked up some JavaScript and a renewed sense of confidence.

Rent the Runway 💃🏻

With proven experience under my belt, more companies were willing to take a chance on me. In the fall of my third year, I interviewed with a handful of companies, including Rent the Runway, a popular eCommerce platform for designer rentals. The company was relatively well-established, with a modestly-sized engineering team. As someone who religiously watched Project Runway (and all of its spin-offs), it felt like the perfect fit. They flew me out to New York for an onsite interview, where I had the opportunity to meet their (Twitter famous) CTO, Camille Fournier. When the offer came in, I signed right away.

I kicked off the summer refactoring their main product view component to properly display the company’s new dynamic pricing model (similar to how airlines change their prices depending on demand, day of the week, etc.) I loved being able to hit save, refresh, and view my changes immediately.

My teammates were kind, supportive, and ambitious. They were eager to have me work on just about anything. I wanted to make the most of the opportunity (hopefully snagging a job offer), so I said yes to almost everything they sent my way.

When I independently noticed we were loading duplicate CSS rules across most of the website, I set out to fix it. I reworked our imports, figured out how to properly minify them, and with the help of some profiling tools, reduced the size of our CSS assets by over 90%. Little did I know, this was the start of my performance journey!

Given I didn’t have any plans during the second half of August, I negotiated a two-week extension to my internship. I took the train back to Montréal with a job offer in hand, albeit not the one I had hoped for.

Whereas my friends were getting return offers in the low six-digits at Microsoft, Google, and the like, RTR offered me 90,000$ with the opportunity to buy some options over time. My gut told me to negotiate, try to get just 5,000$ more, that’s it.

I brought it up to my dad, who I thought would give me the best advice. Ultimately, that proved unwise. He dissuaded me from negotiating. He told me it was a good offer, and I should be grateful for it. So I signed, and mostly forgot about it. (There’s something to be said here about an immigrant mentality, but I’ll leave that for another time.)

In hindsight, I wish I’d reached out to the friends I’d made during my internship who had experience negotiating to get their advice on whether I should’ve haggled.

A new grad at Rent the Runway 🎓

I returned to New York in late June 2015, a month post-graduation. Our CEO, Jenn Hyman, had recently hired a new head of marketing who sought to rebrand the entire platform in order to appeal to more prestigious brands. With most frontend engineers already knee-deep in other projects, I was tasked with leading the engineering effort, code named the “September Issue” (alluding to Vogue’s famous September issue, and the project rebrand launch date). I worked closely with our product designers to implement hundreds of tedious changes, all carefully hidden behind a handful of interdependent toggles.

In hindsight, I’m certain that leadership didn’t anticipate the rebrand to balloon like it did. Everywhere we looked, there was yet another edge case we needed to handle, another heading or button we’d missed. Our stylesheets and components were a jumbled mess, and the rebrand further complicated it all. About two months later, our CTO announced her departure, and we revealed Rent the Runway’s new look.

Our conversion rates took a nosedive. Leadership hadn’t considered that while the rebrand would make the website appear more upscale, thus attracting more eminent designers, it would equally alienate our target demographic (soccer moms, bachelorettes, wedding attendees, sorority sisters). In the frenzy that followed, we decided to spin up a customer growth & acquisition team, where I landed.

The next few months were spent rolling out small, highly-instrumented experiments to figure out how we could boost our numbers. I worked closely with our analytics lead and product manager, eventually getting comfortable enough with Tableau and our tagging system to do my own analysis.

With every sprint, I grew increasingly frustrated with the amount of duct-taping we’d been doing. Very little of what we were building was done in a sustainable way. I tried my best to advocate for changes I thought would make everyone’s lives easier: refactoring our custom content management system to allow our marketing teams to publish new homepage content without our oversight, codifying a hierarchy to the half dozen banners adorning the navigation bar, consolidating our JavaScript dependencies. (It’s worth noting that I caused a fair number of outages and incidents with many of these changes: most notably, preventing customers from booking most formalwear for close to 24hrs, likely costing us close to 1M. Fortunately, the vast majority of those customers came back the next day.)

Thankfully, our PM was willing to give me the wiggle room necessary to implement these changes, even if it meant pushing back an experiment or two by a few weeks. She wasn’t intimidated by our president who’d been put in charge of engineering while we searched for a new CTO. Coming from a content background at AOL, and with limited software experience, she didn’t have much patience for the kind of maintenance work that was required to keep our systems healthy. Above all, she prioritized conversions and cost savings. She (and our CEO) didn’t think it was a priority to address our persistent performance problems. At the time, the homepage was taking nearly 10 seconds to load for the average user, but this didn’t matter because according to them, we had “no competition”.

Regardless, I found ways to try to address the lag. I was motivated, eager to learn, and hopeful my hard work would pay off. I’d regularly put in an extra 10-15 hours a week, chipping away, sending code reviews to members of our frontend infrastructure team, who in turn sent me blog posts and books to read, including Lara Hogan’s Designing for Performance.

Pay Discrepancy 💰

February rolled around and the enthusiasm and optimism I’d managed to hang onto completely slipped away:

• Thanks to an H1B application posted by our photocopier, I eventually found out I was the least paid engineer at the company.

• I was passed up for a promotion my manager had told me was “in the bag”, didn’t get a raise, and granted only half my bonus. His “hands were tied”, he said.

• To top it off, in the span of an afternoon, half my team was fired or laid off out of the blue.

I decided it was time to start looking for a new job. At the time, my boyfriend (now husband) was living in Seattle, working for Microsoft. Long distance was getting old fast. We figured we should give the whole “Silicon Valley” thing a try, so we both started applying to roles in the Bay Area.

I wanted to move into a backend role at a company where the leadership team was highly technical and software was the product. Unfortunately, most recruiters didn’t give my resume a second look: I only had about a year of frontend experience, all of it at a small fashion startup.

After dozens of form letter rejections (and failed interviews), I pivoted and began applying to frontend roles. I didn’t strike gold there, either. Three days after submitting my resume for a frontend role at Slack, I got the standard “thanks, but no thanks” email.

In a moment of desperation, I reached out to Camille for advice. She responded to my ramblings with two words: “intros incoming". Five emails followed, including one with Julia Grace, who headed Slack’s infrastructure team at the time. Julia was fabulous, apologized for the rejection, and set me up with a recruiter phone screen. A few weeks later, I flew out to San Francisco to interview at Slack, Quip (later acquired by Salesforce), and Twitter in the span of two very busy days.

I landed an offer with both Twitter, and Slack. I signed with Slack.

Slack 💬

Software Engineer II; October 2016 – January 2018

I started at Slack the first week of October. We were Slack’s biggest incoming class to date with about 20 of us gathering for onboarding that Monday morning.

I landed on the Enterprise pillar, focusing on Slack’s Grid offering.

My onboarding buddy, Moishe, was hard at work addressing performance problems for IBM (our largest beta customer) ahead of GA in January. He tossed me a few perf-related JIRA tickets to juggle alongside my feature work to help me get better acquainted with the broad service area covered by Enterprise. I’d never written a single line of PHP or SQL before, and often found myself wondering whether I’d bitten off more than I could chew in deciding to move into a backend role.

Fortunately, no one seemed to notice that I had no idea what I was doing. In fact, I’d feigned enough confidence that when we spun up a team focused entirely on handling enterprise-related performance problems, I made the cut. We had no shortage of problems to solve: everything was on fire.

The database shard housing the majority of IBM’s data was constantly on the verge of toppling over. For weeks, we did our best to simply survive to see another day. Each of us took turns coming into the office at 6 a.m. Pacific to be at the ready in case things went south when the bulk of IBM users logged in at 9 a.m. Eastern. I was only six months into my tenure at Slack, and just barely two years out of school, and yet, engineering leadership trusted me to keep Slack up for our biggest customer.

I masked my fear behind an eagerness to learn. If I could effectively debug and mitigate issues under pressure, then I’d no longer dread when my name popped up next on the PagerDuty schedule. When 💩 hit the fan, I’d sit in channel and watch as some of our most tenured engineers sent links to logs and graphs back and forth, helping out wherever I could.

I consistently volunteered to take on high-risk, high-reward projects where I felt wildly out of my comfort zone. I caused many incidents, many of which were preventable had I slowed down, been more meticulous, and tested more thoroughly.

One such project involved consolidating our data model around channel memberships. At the time, a user’s channel memberships in public, private, and DM channels was stored on distinct tables. JOINs across these tables were expensive, and visibly slowing down our response times. I set out to consolidate all membership data into a single table. (You can find more details about this endeavor in Chapter 11 of my book, Refactoring at Scale.)

Outside of work, a friend encouraged me to start attending Write/Speak/Code meetups. She’d recently given a talk at Grace Hopper, and I’d reached out expressing an interest in doing the same one day. With support from the Write/Speak/Code community, I submitted my first talk abstracts. I landed a keynote spot with PHP World in Washington, D.C., and spoke at WebExpo in Prague.

tl;dr Most of my time was spent doing things I found to be absolutely terrifying. I pushed myself out of my comfort zone constantly in order to learn and build valuable experience as fast as possible. I figured that if I was going to have imposter syndrome, I might as well have it for a reason.

Sr. Software Engineer; February 2018 – January 2019

The culmination of everything I’d worked on led to my first promotion in February 2018.

Elsewhere in the organization, plans were brewing to spin up a team to:

• steward core business “objects” like teams, users, and channels,

• introduce better code quality standards across the backend codebase, and

• generally increase its maintainability and operability.

Having recently refactored our channel membership data model, I began looking for opportunities to continue the consolidation effort, and this new team seemed like the right place to do it. With that, I became a founding members of the “Backend Foundation” team, alongside a handful of very tenured, very senior folks.

I kept chipping away at the channel consolidation effort (see above, and Chapter 11 of Refactoring at Scale), eventually bringing DMs into the fold so that only a single table was responsible for storing channel information, and likewise for channel memberships. It wasn’t “sexy” feature work, but I loved it. I’d gone deep, becoming the de-facto expert on our channel data model, a concept core to the Slack product; but I’d also gone wide, familiarizing myself with a huge breadth of the codebase in the process.

By the time I flipped the final few toggles, I’d migrated millions of channels, and in the space of just two years, gone from someone who’d never written a single line of SQL, to someone people sought out to help write their queries. Something that had once seemed impossible was somehow now second nature to me.

I had a new story to tell. I wanted more opportunities to speak at more prominent conferences, so I applied to speak at O’Reilly’s Velocity Conference in New York, and Lead Dev in Austin, TX. I landed both.

I’m particularly proud of my Lead Dev presentation. The content of the talk really exemplifies how I was able to make it to Staff.

tl;dr The senior to staff transition for me was all about coming into my own, honing the skills that I’d developed over the last few years, and capitalizing on the relationships that I’d built. I continued to work on teams where I was the most junior engineer, working alongside folks who oftentimes were 10 or more years my senior.

I was more comfortable navigating a wide range of engineering problems because of my breadth of experience chasing down performance regressions across the codebase, and consolidating our channel membership data model, something that was at the core of the product.

It was only once I landed the Staff title that I was able to start letting go of the imposter syndrome that’d plagued me for the last four years. I was good at my job, and my peers knew it.

---

Staff Software Engineer; February 2019 – July 2021

After spending the last two and a half years sprinting, I felt as though I could finally slow down a bit, like I’d arrived at a stable destination.

Refactoring at Scale 📕

In May 2019, I got an email from a book editor at O’Reilly who’d watched a replay of my talk at Velocity a few months prior. He wanted to know if I was interested in scheduling a call with him to discuss whether it was possible to develop my content into a book: an actual O’Reilly animal book. I had to reread the email a few times to make sure it was real.

Not only did I grow up surrounded by computers; I grew up surrounded by O’Reilly animal books. As a kid, I was always disappointed when I flipped them open and found page after page of code snippets and nothing at all about the animal on the cover. Now, as an adult with my own growing collection, I’d very privately hoped to have the opportunity to write one myself one day. I hadn’t breathed a word of that aspiration to anyone, and now somehow the universe had sent an editor my way.

I scheduled the call, fully expecting him to lose interest once he’d seen me on the other side of the screen. After all, what editor in their right mind would sign a book contract with a 26-year-old, just barely 4 years out of university.

“Your talk really resonated with folks. I’d love to read a proposal. I’ll send you the format. Just get it to me by the end of the month,” he said.

I wrote the book proposal. It was a small enough commitment. Then, I thought, they’ll finally realize I have no idea what I’m doing and they’d drop it.

Within a few days of submitting my proposal, I came face-to-face with an O’Reilly contract. The imposter syndrome came flooding back in full force. I very, very nearly didn’t sign it.

Fortunately, my husband said, “you’re not not writing the book. I’m not letting you say no.”

From September 2019 through July 2020, I spent most of my evenings and weekends writing in my living room. It was a drag, and the feedback on the first few chapters was brutal, but my editor was sharp, and he helped me discover my writing voice, and kept me track. Once COVID hit, writing had become part of my routine, and it was made all the easier by the fact that I was no longer missing out on anything: everyone else was sitting at home, so might as well sit at home and write.

My book went to final publication at the end of the summer, just as my husband and I were gearing up to leave San Francisco and move back east.

Performance Infrastructure 🚀

Work-wise, by the time the book contract landed, I was getting burnt out. I was struggling to find the energy to contribute to design discussions; every time I looked at a new chunk of code, I couldn’t help but think of the insurmountable pile of tech debt we’d accrued. It was in character for me to be critical, but always with a dose of optimism. It wasn’t like me to be chronically pessimistic.

Thankfully, my manager was happy to listen and help me figure out what I wanted to do next. We talked in length about performance, scaling Slack, empowering product engineers to understand the impact of their changes, and the work I’d left behind when I’d put the final touches on the channel consolidation project. She turned to me and said, “what you’ve described sounds to me like the mandate for an entirely new team.” So I wrote a sort of manifesto, and together we turned it into a team proposal.

Somehow, we got the ok to spin it up. At first, it was just me. I had complete autonomy to decide what to work on.

I kicked things off by planning Perfapalooza, a monthly learning session for backend engineers to learn how to debug performance problems.

When we were all sent home due to the COVID outbreak, I spent some time investigating a mysterious increase in 500s across our APIs, returning to my incident debugging roots from my early days on the Enterprise pillar. It was deliciously familiar and the impact was tangible. I could feel my optimism returning.

The team got its second engineer early May, and together we drafted a plan for supporting 1M concurrent Slack users in a single Slack instance by mid-2021. Unfortunately, everything got thrown out the window when just two weeks later, “Huge Corp”, who’d recently signed a sizable contract, decided to accelerate their launch from 18 months down to just 10 weeks.

We had 50 days to figure out how to verify whether Slack would be able to handle 500,000 concurrent users, fix the inevitable problems we’d encounter at that scale, and bolster our systems accordingly.

I drew on all of my experiences handling performance problems in my 4+ years at Slack to figure out how to most effectively use our limited resources (existing tooling, processes, guardrails, available engineering time, etc.) to solve the “Huge Corp” problem. It wasn’t going to be easy, but we were going to try our hardest to make it work.

By the time the early August deadline rolled around, engineering teams across the organization had run dozens of load tests, uncovering and rectifying significant bugs. We’d successfully managed to simulate 500,000 users in a single enterprise thanks to Koi Pond, our new load testing tool.

By the end of 2020, we’d successfully run a large-scale load test with 1M simulated users. We continued to build out Koi Pond capabilities, spinning up larger and larger load tests, culminating in 2M users in April 2021.

Somewhere in there, I decided to try my hand at thawing a code “slush” we’d instituted on the infrastructure side of the engineering organization. Turns out, helping sister teams regain trust in their ability to ship code and return to pre-“slush” velocity was the missing piece to further bolster a case for engineering-wide impact at the Senior Staff level.

tl;dr I was in the right place at the right time. When I pitched my manager on what later became the Performance Infrastructure team, I wanted to improve engineers’ ability to debug performance problems and build a flexible, cheap load testing solution that would enable us to conveniently test our systems at scale in a repeatable manner. I wanted us to start being proactive rather than reactive.

I had no idea “Huge Corp” was going to move up their launch date so dramatically, radically precipitating our own timelines, but spinning up the Performance Infrastructure team proved to be quite the prescient move.

Sr. Staff Software Engineer; July 2021 – July 2024

When my manager and I began working on my promotion packet for Sr. Staff, I honestly didn’t think I’d get it. Most engineers I knew who’d gone to committee for Sr. Staff had been deferred the first time; it was pretty standard.

I was both surprised and relieved when the promotion was approved. Our team had just hired two new engineers (both internal transfers), and I was just a few months away from going on parental leave. I was deliberately off-loading everything to everyone on the team, making sure they’d be able to confidently steer the ship while I was out.

While I wasn’t doing the kind of high-impact work that typically sparkles on promotion packets, growing the team and fostering an environment where all of us women (yes, all women! on an infrastructure team!) could thrive was, to me, some of the most important work I accomplished while at Slack.

I spent most of my time immediately following my promotion in July writing documentation. My son was born in mid-October, and I banished all thoughts of work for six months.

When I came back in early May 2022, half of the team had left the company. I was a little lost. For a few weeks, I toyed with the idea of going back to product development, but a close friend advised against it. “Don’t make any important decisions in your first six months back,” she said. “Six months is no time at all. Give yourself the space to get reacquainted with who you are at work. Then, and only then, should you consider making changes.”

With that, I maintained the status quo until my son’s first birthday.

I ultimately decided to stay on the Performance Infrastructure team. The work was fun, and my teammates (and manager) were stellar. We built new tools, and kept improving on existing ones. We began more deliberately partnering with product development teams every quarter, working with them to ensure their new features would scale to Slack’s current and future users.

I continued speaking at conferences, as well as sitting and moderating panels, particularly those organized by LeadDev. In 2023, I spoke at both StaffPlus New York and London.

By February 2024, we’d done it: we’d reached the end of the years-long roadmap I’d drafted when I originally founded the Backend Performance Infrastructure team in March 2020.

By May, I was starting to look for a new opportunity. There’s a lot more detail about what went into that decision here.

In the midst of my job search, the folks at Lead Dev reached back out, this time to invite me to co-host the upcoming StaffPlus New York conference. I was absolutely thrilled. Co-hosting alongside Tanya Reilly was a dream come true.

Principal Engineer, GitHub

Last August, I started my new job at GitHub. Turns out, that friend who’d encouraged me to start speaking at conferences is my new manager.

I cannot emphasize enough the importance of building and maintaining a strong network. I likewise cannot emphasize enough the luck and privilege that has come with joining Slack at an early stage. I chose the right horse to bet on, and many of the folks that I’ve had the pleasure of working with over the years have gone on to be successful at other exciting companies! When I decided to look for a new role, I had a large pool of folks I could lean on for referrals.

To date, the principal role is intimidating (but really engaging)! Coming in at such a high altitude means I have to deliberately find ways to dive down to understand what’s going on at ground level. Folks give extra weight to the observations I make because of my title, so I find myself hedging left and right, trying to be as mindful of my audience as possible.

Thankfully, my peers have been wildly welcoming, and have actively asked for my opinion on just about everything. To date, they’re exactly the kind of folks I was eager to work with.

My first two months were a bit of a make-your-own-adventure exploration of GitHub from an organizational and technological perspective. I met with tons of engineers and product managers. I tried to map out the life of a git push through the whole system. I attended a bunch of incident review presentations, read a ton of documentation, critiqued a handful of design proposals, tried my hand at some Ruby, and sprinkled in a bit of my observations, experience, and opinions where they seemed helpful.

And then, on November 3rd, I had my second baby, putting my onboarding journey on hold for six months. (Which is quite a luxury in the United States, and one I’m very grateful for.) I’m certain that when I get back in early May, many, many things will have changed, and who knows how much I’ll even remember. Whatever happens, I know I’ll be happy to rediscover the problems and teammates I (temporarily) left behind.