Programming

The problem is that DevOps is not really a title or a role, its a mindset. It can be summarized as "You build it, you run it" and is supposed to solve the age old problem that arises from the disconnect of developers and sysadmins, where developers just hand over code to the admins without ever having given much thought about how to run it reliably (aka. "You go figure that out, not my problem.") and the admins being super protective of their painstakingly curated servers and databases that of course you as a developer obviously cannot have any access to whatsoever and of course your app has to work with the 10year old java version that ships with RHEL. The consequence was basically a lot of grief on all sides and huge waste of productivity.

The idea of DevOps is that these two responsibilities merge into on. That means that the team responsible for building the software also needs to take care of how to test it, how to build it, how to deploy it, how to monitor it, how to scale it, how to debug it, etc. This is now mainly incorporated into the software developer / "full stack" role.

The confusing part is, when you look at job postings, the DevOps engineer is often described as "working closely with" or "supporting / assisting" the development team. This goes pretty much against the principle of having the development team having responsibility for their own work. Instead, it's often just a re-branding of the old role with the title du jour. It also often details the pecking order, namely devops being support for developers.

Given that, if a company offers a DevOps position, you should spend some time finding out what that actually means for you, your work and your career. More often than not, it may put you in a box that only comes with restrictions for not obvious benefit.

Senior and Principal don't necessarily have to be managerial. They are often used for individual contributors as well and are just a way to denote you have more experience and expertise in your field.

Although your current role wouldn’t seem very senior at a large organizational, “senior“ is a relative term and at this company it seems like you are the engineer with ownership responsibilities over the end-to-end software development of a production system. So it might still be reasonable to use a senior title if there are other benefits

That’s right. I know I was thrown off by large projects earlier in my career. The more you learn the stronger you get at understanding and packaging/setting-aside larger and larger pieces of a project. Bigger projects stress this ability in new ways. I think I lost a job in 2016 because I couldn’t stretch my brain around something bigger, at a small business with maybe 14 devs.

This might be a bad way to communicate this, and I think I’m taking this in a weird direction, but: I’ll use the Mozilla project as an example of a large project, though I’ve never looked at its source.

Suppose you were in an interview, and due to the specifics you are expected to be fast and fluent with the same technologies used in the Mozilla project, though you’ve never looked at the source before. Given a machine with the source already checked out and open in an IDE, you have one hour to read through the source and familiarize yourself with it, so you can answer questions about how you would approach adding features or test coverage.

What I want to know is: how high does your heart rate go? Does it go up just a little, as expected for a high stakes situation? Or does it go up a lot, because you honestly have no idea how much another dev in your situation would be expected to accomplish, so you have no clue what “good enough” looks like?

This is a crappy example because no interviewer could ever actually use this metric. But I’d say if it goes up a lot, for the reason I gave, you might not be ready for senior. And by this metric, it might not ever be possible to grow to “senior” without working at a company with large multi-team projects. But I think that’s accurate.

(Edit: yes, sorry, Software Development Engineer. I think that’s a protected term in the US, in Texas and California at least, but anywhere else in the US you don’t need to pass an engineering board exam to use that title.)

Yeah, Senior Software Engineer is a good match then.

Works about right for the workload, responsibilities and the YOE.

The reason I asked about the impact/value is that it's a good way to argue your case. If you can quantify 'x' hours of manual effort (and the estimate should be an average person doing the work, not the best case), then you can start arguing using these numbers to show that you bring value to the org.

While it sounds like your supervisor seems to be pretty solid, it's possible you'll eventually sit down with someone esle who'll be deciding the final 'value' of your effort and would have a vested interest in paying as little as possible. For that conversation, whenever it may happen, you need to be fully prepared. That's going to involve hard number. Effort saved, value created, costs saved etc. It's difficult, but it's a useful dataset to have.

I've worked in smaller orgs like this in the past, and it's occasionally an uphill battle to get paid commiserate to the value you bring to the table. It's a good reminder for management that you're not easily replaceable and that they need to kep you interested enough that you don't wander off.