DEV Community: Mike Sandula

Climbing the software engineering ranks: Going from senior to staff

Mike Sandula — Fri, 19 Dec 2025 18:00:03 +0000

This is Part 2 of a two-part series.

My last post was about actionable steps mid-level software engineers can take to become senior software engineers. This time around, I’ll share some steps you can take to go from senior to staff.

I didn’t say it explicitly before, but I think being a senior engineer is about being a leader within the engineering organization; staff engineers, by contrast, bring that same focus and attention to all organizations throughout the company. They act as expert-level liaisons between engineering and design, product, and other teams. With that said…

Become a technical expert

The primary expectation of a staff-level engineer is deep technical proficiency. One of the steps I mentioned for becoming senior was to “share the knowledge”. That should continue to include small things—various learnings, brief posts about “why I’d like to make these changes”—but staff engineers also need to tackle issues of ever-increasing size and scope. Architectural changes, large refactors, introducing patterns or dependencies.

Your company may or may not have a formal culture around these things, but even if it’s not explicitly required, I strongly recommend writing things down and putting them out there.

Communication skills become increasingly important as you move up the engineering ladder, and writing is one of the main ways you’ll communicate. Writing helps you think through complex problems and serves as invaluable documentation. I once wrote up a spec on how we should reorganize the file and folder structure of our codebase. It explained the benefits of the proposed approach, why I chose one pattern over another, and the steps needed to get us from A to B. The team was able to review it, weigh in, and once I had buy-in, I completed the work through a few focused PRs.

Make yourself available

Mentorship is a key component of being senior/staff. It’s common for people to continue spinning their wheels rather than ask for help, but you can be proactive. When a team member says they’re blocked or struggling during standup, try asking, “Want to jump on a call after this meeting?”

One way to bring junior engineers into the fold is to involve them in areas where you’re the domain expert. Did you recently refactor your codebase’s state management and now a bug has popped up? Offer it up to another engineer and let them know you’d be happy to pair. As the more senior engineer, who’s most familiar with that bit of work, you could likely fix it faster on your own, but that doesn’t help your team grow.

As an aside, this approach avoids information silos. When only one person understands a critical piece of code, it becomes a black box, and that’s risky if that person moves to another project—or another company altogether.

Find ways to collaborate

Regardless of what department they’re listed under on the org chart, staff-level employees effectively belong to the whole company. They’re expert engineers/designers/project managers who can interface with other departments on behalf of their own.

Working on a design system—if you have one, or creating one if you don’t—is the ideal way to collaborate with designers. Think about your company’s product the same way your product team does by asking thoughtful questions during requirements gathering and refinement. When non-engineers think of “someone from engineering”, you want that someone to be you.

If you’re in the middle of your engineering journey and looking ahead, I hope these guides offer some practical steps you can take to level up your career.

Climbing the software engineering ranks: Going from mid to senior

Mike Sandula — Fri, 19 Dec 2025 17:58:02 +0000

This is Part 1 of a two-part series.

Going from a junior- to a mid-level software engineer has always been fairly straightforward: gain experience and competency by fulfilling your day-to-day tasks. You should be able to handle any engineering work you’re assigned. Your manager should be using words like “reliable” and “efficient” to describe you, meaning you deliver mostly bug-free work in a timely manner.

Once you reach mid-level, however, it becomes harder and harder to continue leveling up. Here are a few things you can do to help yourself stand out. Keep in mind it’s important to keep doing what you’re already doing, so these should be in addition to, not in place of, your existing responsibilities.

Find small things to fix/improve

Every software company has tech debt and bottlenecks that everyone knows and complains about, yet they persist simply due to inertia. Seek those things out, fix them, and your coworkers will thank you. Examples include fixing console warnings, stabilizing flaky tests, or improving the run time of your test suite. The kind of work that won’t get assigned in a ticket and so it slips between the cracks, but that can make real quality of life improvements for the engineering team.

You can gain plenty of knowledge and experience by doing the typical engineering work of features and bug fixes, but once you begin exploring the edges of your codebase and the systems that support it, you’ll naturally begin to operate at a more senior level.

Update your dependencies

At my current job, I started an initiative to track which dependencies were out of date and work toward reducing that number. Again, this is the kind of tech debt that’s easy to let slide, but it can have implications beyond the engineering team. Updated dependencies means you’re getting security fixes (your Dev Ops team will thank you) as well as new features you can take advantage of (looking at you, Product).

Once again, this also helps you personally as an engineer. When you encounter breaking changes while upgrading, it’ll force you to read through the docs and understand the changes. Maybe something you used to struggle with will suddenly click. Maybe you’ll realize you don’t even need that dependency (in my case, I found over two dozen dependencies that were no longer even being used). Or maybe you could become the person who’s trusted with deciding whether to use Package A or Package B.

Take ownership of something

Become the owner and/or domain expert of some facet of your codebase. Maybe your team lacks shared formatting and linting standards. Maybe you use GraphQL (or any other technology) but no one knows the best practices. Or maybe there’s some pattern or abstraction you can introduce to improve consistency and maintainability.

Once people see you as the go-to person for something, you start to become indispensable.

Share the knowledge

When you do any of the above things, it’s important to share what you’ve learned, whether through Slack updates, documentation, or both. Never in a braggy or show-off way, but for purposes of knowledge sharing—although, yes, doing this can go a long way toward demonstrating seniority. As an added bonus, explaining things always forces you to have a deeper understanding of those things.

And that gets at what being senior is all about. Over time, it becomes less about your ability to produce great code. That should be a given. Senior engineers are leaders, and that means leading by example and thinking beyond the normal day to day, focusing on the long-term health of their team.

Separating ourselves from the separation of concerns

Mike Sandula — Fri, 31 Jan 2025 13:51:15 +0000

I like to cook, but I always find the following type of instruction frustrating:

Once the onions have softened, add the cumin, oregano, and chili powder.

How much cumin, oregano, and chili powder? I have to flip back to the ingredients list to check. I’d much rather see:

Once the onions have softened, add the cumin (2 Tbsp.), oregano (1 Tbsp.), and chili powder (1/2 Tbsp.).

This would save me from bouncing between the ingredients and instructions, especially if I’m using my phone. Even with a physical cookbook, the constant context switching breaks my flow—a problem familiar to software engineers.

This is similar to another problem familiar to software engineers: the separation of concerns. The separation of concerns is a design principle that suggests keeping distinct aspects of a system separate for clarity, such as the Model-View Controller pattern where data (the model) is kept separate from the UI (the view), with a controller in the middle linking the two.

When React introduced JSX, there were concerns that this syntax violated this principle. In time, however, most came to see that JSX only violated a separation of technologies. I had a similar aversion to Tailwind the first time I used it—I still don’t love it—but I definitely don’t miss always needing a CSS file open in addition to its corresponding JSX/TSX file.

Makes you wonder whether there are any other "separations of concerns"—in coding, cooking, or anything else—that are false distinctions we’ve been clinging to.

Using pow() and sqrt() in CSS to make shapes with shapes

Mike Sandula — Thu, 12 Sep 2024 18:32:16 +0000

If you’ve been writing CSS for a while, there's a good chance you've used the calc() function before. One such use case would be when you want to make the width of an element be the width of the page minus some distance, e.g., width: calc(100vw - 16px);.

But did you know that CSS now has other math functions, such as pow() and sqrt()? These functions were introduced in December 2023 and have baseline compatibility. They work the same as JavaScript's Math.pow() and Math.sqrt() but without the Math prefix.

Let's see how we can make use of them.

Making shapes with shapes

In this CodePen, I have a circle, a triangle, and a square, each traveling a path in the shape of itself around its origin.

The circle and the square don’t require anything too fancy (I won't delve into it here, but you can check out the code for yourself) but the math is a bit more involved for the triangle. The animation needs to move among the three points of the triangle. In order to do this, we need the X, Y coordinates of each point, where the center is at (0, 0). These points are represented by the red dots in this image.

The X coordinates are pretty straightforward: The top dot is at 0, and the bottom two dots are each n / 2 away from 0, where n equals the length of each side. For example, if n is 16px, then their X coordinates would be -8px and 8px, respectively.

Figuring out the Y coordinates is where things get just a bit more complicated. We'll need to first figure out the height of the triangle.

To do that, we'll need the Pythagorean theorem which, as you may recall from geometry class, is A² + B² = C².

The C in this case is n since that's the longest side, and A is half the length of n, or n / 2. To get B, which represents the height, we need the square root of n² minus (n / 2)².

I'm using a CSS variable called --size to represent n. Note that I also have a variable called --size-with-unit. I have a slider that lets you adjust the size from 1rem to 5rem, with a default value of 3rem. I'm mostly using the --size-with-unit variable throughout my CSS, but these math functions require a plain numeric value. It was easier to have two separate variables rather than worry about adding or removing units in place.

We'll use the pow() function for squaring values (This function is actually an exponential function that takes in two numbers: a base number and its exponent. When squaring a number, the second parameter will always be 2.) and the sqrt() function for calculating the square root. We'll save our calculation to a --height variable, which looks like this:

.triangle {
  --height: calc(
    1rem * (sqrt(pow(var(--size), 2) - pow(calc(var(--size) / 2), 2)))
  );
}

Since we're traveling relative to our center origin, we'll go either half the distance of our height upwards or downwards. We'll save this to a variable called --midpoint, which is equal to calc(var(--height) / 2).

Now we have our X, Y coordinates:

(-(size / 2), -midpoint)
(0, midpoint)
(size / 2, -midpoint)

Put it all together, and now our triangle can, well, triangulate (while the circle circulates and the square ... does its thing)!

Conclusion

This was a contrived example, of course, but hopefully you can see the pow-er of these new CSS functions 😆. Good luck and happy coding!

Note: In case you're curious, I used Excalidraw to create the images in this post.

How to create typography tokens for a design system using Sass mixins

Mike Sandula — Wed, 04 Sep 2024 20:13:29 +0000

A lot of design systems start out with basic design tokens for things like colors and sizes, which can be easily translated into CSS variables (or Sass, or Less, etc.).

// tokens.scss
$primary-text-color: #aaa;
$secondary-text-color: #ccc;

$size-s: 8px;
$size-m: 16px;

// some-component.scss
.some-component {
    color: $primary-text-color;
    padding: $size-s $size-m;

    h4 {
        color: $secondary-text-color;
    }
}

The next logical addition to your collection of tokens is fonts. And while you can apply the above pattern to fonts, most designers I’ve ever encountered think about typography as a whole. The font and its weight influence its size and line-height — it’s all a package deal.

In other words, typography is treated as a class. This is a great use case for a Sass (or Less) mixin (unfortunately, there’s currently no equivalent in native CSS).

Here’s an example:

// tokens.scss
$font-sans-serif: Aria, Helvetica, sans-serif;

$size-s: 8px;
$size-m: 16px;
$size-l: 24px;
$size-xl: 48px;

@mixin heading-sans-serif-l {
    font-family: $font-sans-serif;
    font-size: $size-l;
    font-weight: 700;
    line-height: 1.3;
}

@mixin heading-sans-serif-xl {
    font-family: $font-sans-serif;
    font-size: $size-xl;
    font-weight: 700;
    line-height: 1.4;
}

// some-component.scss
@use "tokens";

.some-component {

    h2 {
        @include tokens.heading-sans-serif-xl;

        padding: $size-l $size-xl;  
    }

    h3 {
        @include tokens.heading-sans-serif-l;

        padding: $size-s $size-m;   
    }   
}

Every h2 and h3 within any component with the some-component class will get all of the styles defined within its included mixin — font-family, font-size, font-weight, line-height — and we’re free to extend it by adding in some padding (you import from an outside file by using @use). You could also overwrite any of the mixin values, if necessary (or if you want to make a designer’s eyes twitch).

This is the approach I took when building out a design system at Dictionary.com. It definitely helped streamline the redesign effort of our home (Thesaurus.com, too!) and browse pages (/browse/light is the quintessential example), which launched earlier this year.

Leverage mixins to create powerful building blocks within your design system.