What even is Staff Engineering? 3 Final Tools

This is part 3 of my series on Staff Engineering. Here's part one and here's part two if you haven't read and are interested in catching up.

Hello, and welcome back my series on Staff Engineering! Last time, we took a look at some of the tools that a Staff Engineer will be using in their day-to-day work. Today, we’re concluding our series with three more important tools in a Staff Engineer’s belt: keeping your devs happy, having a solid test suite, and the oft-maligned, never-exciting…..non-technical parts of the job.^[1] Here are links in case you haven’t yet read part 1 or part 2 and feel so inclined.

Happy Devs, Happy Webs^[2]

Your devs’ happiness with working in your codebase is a huge part of its success. I hit on this a bit in part two when I talked about the “Let’s-scrap-this-and-rewrite-it” itch that poorly-managed codebases tend to produce. I simply call it…The Itch, which sounds like a really bad C- or D-superhero movie made in the 40s.^[3] The worst news about The Itch? It’s contagious. The moment one of your devs starts wondering if scrapping everything and starting over will be easier than fixing what you currently have, your project is all-but doomed.

The Itch can seem inevitable to any seasoned Software Engineer. Every codebase is going to grow, in both complexity and size, as it gets older and has more features added. Is it possible to manage that growth without your project turning into an insane, spaghettified mess? The good news? Yes, it’s certainly possible! The bad news? It’s going to take constant work, attention, and concentration. You wouldn’t plant ivy in your backyard, ignore it for decades, and then act shocked when your entire backyard was nothing but ivy.^[4] The same goes for a codebase.

This actually goes hand-in-hand with managing your tech debt, which we spoke about in part 2. The most important thing to remember on this front is talking to your devs, aka the people who work in your codebase all day every day and know all of it’s biggest pain points. Whenever I’m Staff Engineering a project, I make it a point to give my dev team a way to make their gripes or concerns about the project known. Given that I’m pulled in every which direction as a part of my Staff role, I don’t get the same exposure to the little annoyances in our codebase at the same frequency as those closing tickets all day every day. Giving my dev team a clear-cut way to communicate those annoyances or frustrations to me is important so that I can keep that list in our tech debt backlog so they don’t fall through the cracks.

Testing Sweets^[5]

A good test suite is one of, if not the, most important parts of any technical project. A test suite can make or break your entire product, and I’ve seen examples of both in my career. But what makes a test suite a good one? I’ve boiled this down to a couple of statements that might sound outrageous to some people:

• If your build is red, you should be fairly confident that there’s an actual bug or issue that needs to be addressed after just the first run.
• If your build is green, should be confident that you can push to Prod right now and everything would be fine.

If either of those sound like a fantasy to you, then I have some bad news: your test suite isn’t doing its job. If things are bad enough, it’s most likely even working against you as your project’s own [insert arch-nemesis of your choice here]^[6].

There are a great many things that go into building a test suite that achieves those two bullet points; too many, in fact, for a blog series about Staff Engineering. Between that and the fact that this is one of the things I’m most passionate about as a Staff Engineer, I have quite a bit to say about it, so look for that as a future blog series! For now, let’s stick with a TLDR: if you can’t, with confidence, say that both of the above bullet points apply to your codebase, it needs work to get there!

Just Non-Technical Staff Engineer Things^[7]

Sardonic remarks aside, all Staff Engineer positions are going to come with responsibilities that do not involve working directly in the tech with your hands on a keyboard. And listen, I know; I get it. You went the Staff route vs the management route so you could avoid all of this, but it’s a reality of working with humans that you’re going to…you know, have to work with humans.

The main non-technical work that I’ve had to do in this position is more Staff Engineer nightmare fuel: ESTIMATES.^[8] Allow me to be the first and loudest to say it: I. HATE. ESTIMATES. It is literally^[9] impossible to estimate anything past the next week or two realistically or consistently. Humans are not capable of this at the best of times and literally^[10] every software engineering project ever is the farthest possible thing from “the best of times.” The amount of complexity and unknowns involved requires inhuman levels of brain power.

With all that said, however (and please don’t hurt me), I understand why they’re necessary. As I mentioned a few times in part 2, we live and work in the real world. And money runs the real world. Writing code is very expensive and The Business needs to have some idea when it’s going to get a return on its investment. Thus, estimates. Do your best to pad estimates and communicate to stakeholders that The Unknown can always rear its ugly head and make things take a lot longer than originally expected.

Another example of non-technical work that I’ve had to do is find ways to unblock my team. What happens if the API endpoint you were expecting suddenly isn’t available, but your front end team is still expected to deliver their work? Should you hardcode some one-off values using your contract with the API team or should you be building some way to quickly and easily mock any response from the API? Choices like this come down to the Staff Engineer using their experience and their knowledge of the project to be the one to make the final decision.

There are countless ways a Staff Engineer will be called upon to use their technical expertise to solve non-technical problems. At the end of the day, I like to keep this in mind. Even when I’m not doing hands-on-keyboard work, I’m still using my extensive knowledge of Software Engineering and the SDLC to set my project and my team up for success.

That’s It^[11]

So yea, that’s it. You have finished 3 whole blog posts on practical looks at Staff Engineering and a Staff Engineer’s daily responsibilities and toolsets. You now have everything you ever need to succeed at anything. You’re welcome! Oh and since you’re a Staff Engineer God now: I have a great app idea I wanna share with you…