Happy Wednesday!

Today's Issue: Driving impact as a designer or an engineer, code-splitting your webpack bundle for performance gains, and height in CSS.

---

If you've been working in tech for awhile, you probably know that "senior" is considered a career level, meaning it's completely valid to reach the senior level and then stay there for the rest of your career. For people who would like to extend beyond the senior level, there are a bunch of additional levels that are usually broadly referred to as "staff+". [1]

As I'm (slowly) inching towards staff-level, I'm discovering that it's less important to work hard and more important to do work that is high leverage. If you're anything like me, you're hearing the word "impact" a whole lot more now than you did a few years ago. (Also you're hearing it in your nightmares.)

A mid-level engineer is expected to execute a prioritized list of tasks that someone else compiled. A senior-level engineer often provides feedback on that list of tasks, and may suggest some tasks that would be valuable based on their deep knowledge of the codebase.

A staff engineer is responsible for defining what actually needs to be done, breaking those tasks down, and delegating them to others.

I've started asking myself questions like:

1. What differentiates me from the other people I work with?
2. What kind of projects do I specifically need to work on, and what kinds of projects would be a great fit for my peers who are a few years behind me?

I found this essay from Ben Kuhn particularly compelling as I try to determine how I can drive impact in my role: Impact, agency, and taste. I particularly loved this quote about determining what you're good at and how you can differentiate yourself:

I’ve noticed a lot of people underestimate their own taste, because they expect having good taste to feel like being very smart or competent or good at things. Unfortunately, I am here to tell you that, at least if you are similar to me, you will never feel smart, competent, or good at things; instead, you will just start feeling more and more like everyone else mysteriously sucks at them. For this reason, the prompt I suggest here is: what does it seem like everyone else is mysteriously bad at? That’s probably a sign that you have good taste there.

---

If you've recently joined a new team or you're pretty sure no one's inspected the bundle for a while, definitely consider taking a peek yourself.

I joined my new job about 6 months ago, so I was curious to see what was going on under the hood. I noticed some very large libraries (including zxcvbn which is a password strength estimator) being loaded into the vendor bundle on every single page of our app. Splitting it out into its own bundle that only gets loaded on pages which need it saved us around 0.6s per page load -- not bad.

If you're not sure what I'm talking about, read this blog post about how to code split your webpack bundles. It should get you started!

Around the Web

• Josh Comeau explained how heights work in CSS
• ByteDance shipped a new library development tool called rslib

---

[1]: There are some great books about being a staff engineer by the way, most notably Staff Engineer: Leadership beyond the management track and The Staff Engineer's Path.