Skip to content

On choosing my latest role

A week ago, I started as a Staff Software Engineer at Abstract.

This is my first time in a while going from one job to the next without a 🤷‍♀️ figuring it out type break in-between. Before HashiCorp, I was leaving my job because I was burnt out and my former company and I parted on friendly terms. And before that, I left a job without anything lined up (thinking I’d focus on consulting … and ended up joining IOpipe as their first engineer).

At HashiCorp, it was an opportunity arising and me realizing I didn’t want it that led to some reflection, MNAM-ing, and figuring out what I do want. Plus, I felt like I’d done what brought me onto my former team: help mature the Terraform Core codebase (and, additionally, 2 years is a kinda normal time for engineers to change roles). The current 0.15 major release is part of a pre-release for Terraform 1.0 later this year. These realizations led to the job hunt, and me accepting an offer to work at Abstract. I’m hoping my new role will fulfill a some key gaps in my preferences that weren’t being met.

Smaller, leaner, flexibility

When I started at HashiCorp, it was less than 500 engineers (I think it was the ~300 range, but I can’t confidently say). When I left, it was 1100+ … and still growing rapidly. That is an extremely tough growth area and things can be strangely chaotic, even though you have more people to help … theoretically. There’s so much to do!

When I joined, one of my reactions to HashiCorp was “This is a big company that doesn’t know it yet.” And now they’re becoming that big(ger) company but there’s a lot of rockiness in that in-between space as far as who should be doing what (“if no one is in charge of it, no one is in charge of it” as the adage might go).

On my job search, and speaking to a few critical mentors, and thinking on what I missed from previous roles, I thought about how smaller companies offered me more flexibility around working on various areas. I could pick something up and not be typecast forever – if I did some release engineering, I wouldn’t become “the person who does the release engineering related work” as what seemed to happen in a larger company.

Particularly in the last so many months, I felt like what I was learning in my job was becoming an expert on the particular code base I worked on, not necessarily growing as an engineer, and in some ways, some of my skills were decaying. At a smaller company, I’m hoping there’s more flexibility around chipping in on various systems, or at least having more bandwidth to understand them.

Learning with breadth

I went to HashiCorp to transition to working more in Go, and now I’ve got two years of Go experience … working on a codebase that is compiled into a binary. That is what I wanted, to be able to work in Go but not have an intensive on-call schedule, particularly in burnout-recovery mode. And that was really helpful!

But I started missing engaging with services on the web. I talked about company size first because it’s relevant that in a larger company, people need to “stay in their lane” (and I don’t think this is a bad thing – you can’t scale an organization if people are running around doing other people’s jobs).

What it meant though is in my (now previous) role I had little to nothing to do with anything running as a production service on the web. I’m hoping that will change some! Or at least, now that I’ve done Some Reflecting, I have a much clearer idea of what I want to be reading up on, some small projects to perhaps design for myself. I made a big dent in reading Distributed Systems in Go during my break between jobs.

Tighter feedback loops

My “dealmaker” in my job hunt was “I can see the impact of my work with every change I make, which motivates me to keep making things better”.

The impact of working on Terraform Core was huge. There are more than a few businesses and peripherals built on the body of that codebase, and even more if you expand that to include all the tooling generally in the Infrastructure-As-Code space inspired by Terraform.

Yet, Terraform is a binary that is a packaged release and, very reasonably, that means some longer deployment cycles than other kinds of software development. Work I did in May wouldn’t be generally available until August, and that was quick in this sphere, IMHO.

The distance between the design, implementation, and release didn’t work well for me. Maybe it will another time, but a tweak I’m making is trying to work on things where I can release more frequently or at least feel more tightly integrated into the feedback loop (such as having a QA team, which I’m looking forward to!).

Something new(ish) I’ll be trying is that I’m moving into working on software for a different audience – designers. I thought I’d be working on tools for developers by working on Terraform, but found that, in my opinion, it’s more of a tool for operators. This challenged me to think about where I draw motivation. Turns out (or my theory is) I’m motivated by being connected to the work that I do ending up in users’ hands and making their situations better. I’m hoping tighter feedback loops will serve this.

Baseline requirements

Finally, a few things were positive signals that I think worth mentioning: remote work and who I’m working with.

I’m switching from one fully-remote (pre-pandemic) company to another fully-remote (pre-pandemic) company. That’s a knob that even though some companies are going to thrash on the remote/not thing this year (or next?) that I will hope not to deal with.

And I strongly prioritized the people aspect of this job hunt. One friend said one of the coolest things about working in tech is “We can do work we love with people we really like” – that I have the privilege of being choosy about who I work with and what I work on, without compromising on working conditions (and changing jobs when those things aren’t met, or because I want a different challenge).

The friend who referred me to Abstract (although she didn’t know there was a referral bonus lol) told me a dreamy story about a situation where she’d given her professional opinion on a matter, and the person listening didn’t like it and tried to go over her head. The conclusion to that situation was my friend’s superiors having her back, deferring to her expertise, because it is her job. That’s what I’m hoping to have in this working situation, and I wish it didn’t seem so rare in tech.

Welcome swag (and cat!)

And here I took some photos of the welcome swag, and one of my cats got curious about it so she’s making an appearance too. Onward to new things!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.