Recently I spoke to someone who wanted to know what they should call themselves seeing as they never learned software development, formally or otherwise, but that's not stopping them from releasing AI-powered Python projects in GitHub. I suggested Project Manager, but they took offense to that because (I think) they wanted to hear Software Engineer in order to apply to those jobs. My counter-argument was that, legal rules aside, a S.E. should be able to differentiate good code from bad, but my suggestion wasn't super well received.
The point being: I'm always amazed at the cross-purpose impulse of arguing "the title is not important" while, simultaneously, really wanting to use the title.
It depends on the way they use it. If you design an architecture and use an LLM to fill it in, I'd consider a more technical label. If you're just using what Claude made, and providing feedback, that's just how software was done 10 years ago except then they'd be talking to a guy instead. And it would be orders of magnitude more expensive.
From my perspective, Claude feels like 5 engineers in a box. you can make things that required small organizations to make.
I think the role is that of a producer - similar to a music producer in the 70s and 80s integrating new synth and recording technology into ambitious outcomes where the goal was defined but the shape and detail unpredictable.
AI is heavy machinery. In the construction industry you need special permits to operate such machinery, and everybody driving a car needs to have a driver's license.
So I wonder if users of "heavy AI" should also need to have a license.
Project Manager is a great fit. I also heard and liked Director, which brings in good analogies from filmmaking and implies nothing about technical ability either way. Could even be Software Director.
As an analyst who vibe codes a lot I think it is perfect, along with Product Manager. There is a lot more to these roles, but I think they're the closest.
If you look up the etymology of engineer, you'll find ancient roots (Latin, etc.) many hundreds of years old which are primarily about contriving/inventing/designing clever devices and occasionally about operation thereof. And you can find that a definition regarding train operators was added less than 200 years ago. The train thing is just an offshoot that is irrelevant to other types of engineering.
I would suggest "Anthropic client", because the relationship between them and Anthropic is similar to the relationship between a client and a contractor.
You ask the contractor for what you want, iterate a little, and take what they give you. Sometimes you may read the results.
"The title is not important" was a movement coming from the fact that same jobs at two companies could've had vastly different responsibilities, and vice versa. But that was rather an exception and outside that bubble, people have always paid great attention to titles.
Yours sincerely, Software Developer with 6 years of experience. Last week for the first time in my career I've actually merged application code. It was AI generated.
There's only one country to my knowledge that has historically allowed anyone to be called a software engineer without being an engineer . Now that the bar is dropping even lower, can we stop normalizing that? I never had the audacity to call my self a Software Engineer without an Engineering degree, just use any of the other dozens of words.
Comp Sci degree is somewhat of an exception, I get that
Scrum and Agile seem to be dying. I had a Product Owner and Scrum Master cert for years on my resume but i've dropped it from my current. Feels now like the ancient webmaster title of the mid 90s. Made for another timeline which is not more relevant.
DevOps is another sad story as it was a saner approach to get people skilled for both dev and ops but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
DevOps should be a guiding principle for the organization, not a dedicated role. Every developer (or at least: every team) should be able to
- speak to production users
- ship to production
- monitor and learn from production usage
You don't need "devopsy" skills to do that, rather organizational structures that allow for incremental change. FWIW, deployments could still be a 2005-like upload via FTP, and the benefits of DevOps could still be reaped.
We’re seeing the same thing with QA. I guess developers can QA their own deliverables.
Leaving out the key fact that the vast majority of developers have no interest in testing stuff. And thus you end up “testing in prod” like with Microsoft projects.
It’s not a coincidence Microsoft’s software quality has collapsed since they’ve eliminated dedicated QA/SDET roles.
Why does the ability to interact with users, being able to test code, profile/debug code, and actually manage your deployed software imply you're a master of none? Too many developers act like it's a good state of affairs that they just get locked in the basement to grind the code. And now that we have tools that can grind code for you, they're finding out why that wasn't a good state of affairs for them.
The answer is master all of them, not none of them.
Most people aren't particularly good beyond 1/3 of those domains. It's delusional to expect everyone to be Superman even though that idea is amazing in a vacuum.
A programmer has to be able to demonstrate that his program has the required properties. If this comes as an afterthought, it is all but certain that he won't be able to meet this obligation: only if he allows this obligation to influence his design, there is hope he can meet it. Pure a posteriori verification denies you that wholesome influence and is therefore putting the cart before the horse, but that is exactly what happens in the software houses where "programming" and "quality assurance" are done by different groups. [Needless to say, those houses deliver without warranty.]
While I agree with this, in a lot of software there's more to verify than just being correct. Unless there's a separate and rigid UI/UX spec then there's also matter of things being intuitive to use etc. which may vary from person to person and the one making the thing might not have the same sensibilities as the users.
Once you write software that is run in places other than your computer by people other than you, you have the right and the duty to speak to those people, to look into those places, and to push updates in small increments once you've learned something valuable from either of the two sources. "You" can be a small team of close collaborators, so not every developer has to speak to users, and not all developers need to push to prod or look into the Grafana every now or then. It's just that those responsibilities should not be gated into remote departments.
Infrastructure is still provided and maintained by Ops. That's exactly the point of my critique: giving Devs access and responsibilities is no excuse to dump the whole Ops department. Managers shouldn't give someone a DevOps-title and think they get 2 for 1.
Similarly, asking Devs to write and maintain proper test automation for their services is the bare minimum - scraping centralized QA is still a bad call, though. Somebody must build and run test infra, set and enforce standards, aggregate data, track regressions, keep the full picture etc. - but they shouldn't block incremental deployments for days.
> but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Titles like these always mean something different from company to company.
Even “product manager” has had different meanings at my different employers, some times with major consequences for people who got hired into those roles expecting to do one type of work and then being evaluated on different expectations.
For DevOps, there were a lot of unrealistic expectations from everyone who saw the word and assumed they knew what it meant. I saw a lot of engineering leaders come up with completely different expectations for DevOps roles, but when the chaos arrived most of them reduced the DevOps people into the responsible-for-everything people, which just burned people out.
I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
> I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
This depends on the org, but product managers I've worked with spend a lot of time speaking directly with users, particularly in B2B shops. Between speaking with customers and communicating product plans both upwards (to GMs/VPs/exec etc) and outwards (to your own team + external teams) you really shouldn't have a lot of time to build anything as a PM, even with AI.
Where "product manager" really started going off the rails was when enterprise agile achieved hockey stick level popularity as all of a sudden the "product owner" role wound up being in the "product manager" job family.
All of a sudden you had "product managers" inserted deep in the bowels of large systems, instead of focusing on big picture topics.
DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
Any developer who doesn't at least *understand* the ops side of the fence and has never spent time actually *doing* it, will make bad decisions along the way from an ops perspective. These are bad developers.
I see a stark difference between understanding how it works and doing it in a professional manner.
For instance I probably have a decent understanding of what our CS team deals with, the tools they use, the volume and overall content of the customer feedback and requests that are coming to us. But I don't sit at a CS desk every day for a few hours and process the tickets of the service I'm running.
You should at least be able to step in and do that job, however, if necessary. That's different than that being the most efficient use of your time, but it's something every good developer should be *capable* of doing.
Last team I was on was repsonsible for supporting and maintaining their product, with help from the SRE team. It means after-hours support for issues and (maybe) releases but I think this was the right way. You became the backstop and support resource for things like data center outages and DDOS attacks that were largely the responsiblity of the (much smaller than many places) SRE team. We also put devs very closely behind front-line customer facing staff where it made sense (ex: reporting & analytics - yes, platform - probably not). It made the devs better and they might try and deny it but I think most of them actually appreciated it. #YMMV
The issue I was facing in a previous life was the turnover. We had data scientists, DBA and many specialized roles stay pretty long, where devops moved away at about twice the rate, and work life balance was mentionned in many exit interviews.
I agree with you that it's extremely formative, and having devs involved basically from start to end of the service surface gives a lot of flexibility. The downside being that it requires a ton of different skills as well, and while people learn, many won't get comfortable with it even after months.
This makes it specially tough when people get called at 3 in the morning to deal with an emergency while they've already spent half the night sleep deprived from their kid puking all night. The worst part being that while people could understand wanting to skip turn one or two times, engineers with small kids will have enough going in their lives that most on-call instances land at a time they're busy dealing with more important matters.
> being in the war room when a data center goes under
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
Imagine managing a gitlab instances. You're doing it for years and have a stable environment. If one of the instance gets hammered by external traffic or one of your data center dies, will you call the gitlab devs to deal with it ?
Depending on the size of the deployment. (Not sure what you mean with "one of your data center" though) If it's just you, you deal with it. If you're running a bigger deployment, you likely have GitLab devs internally that will be reachable. Even bigger - you're likely to have access to upstream devs in the ultimate tier even with self hosting.
>DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
These are all good point, that I think aren't really related to having devs do operations.
Having engineers understand what makes a service resilient and easy to manage, as well as giving them incentives to produce high quality code doesn't require them to do SRE. In particular, being close enough to the SRE team, getting inputs when building the feature, detailed feedback and requests on live services, and the blame when shit hits the fan, are a more scalable way of doing it IMHO.
>Having engineers understand what makes a service resilient and easy to manage,
I don't believe engineers can understand this without experiencing it. A counter argument might be "football coaches don't need to have played", but the counter to that is "players need to have played". Why would being on call make you a better player? Personally, I think being the person watching the dashboards, in realtime, scraping the logs, in real time, watching how the contagion happens, in real time, gives insights that a next-day post mortem just doesn't. There are things I've learned only from hearing something on the conference call and then asking someone about it in chat. Watching a presentation on "Why 99% of people fell of our new bike" isn't nearly as useful as riding the fucking bike.
I've been on teams (briefly) where the ops team having an absolutely shit 48 hours was simply not on the dev teams radar, because they had more important things to worry about. That of course meant that when devs needed, e.g. a new host to try something, ops just dragged their feet, sometimes for months. Perhaps I've only seen dysfunctional companies in this regard. Or perhaps teams are made of humans, and splitting dev and ops is guaranteed to fail for any organization of more than 20 people? Like, sure, a startup of ten highly motivated people - maybe that works. Never done that myself: we've always run our own shit at the startups I've run/worked. Once that startup is 50 people, I think you're destined to fail with separate dev and ops.
Been paid for this over 40 years now. Done startups and FAANGs. But yes, the rewards better be fucking worth it, and the shifts better be reasonable.
So like, I'm not certain you're wrong. I don't think you can be wrong here. It's about what you're willing to do. Personally, I've done both ways, and if I started a company, I'd only hire people willing to support their shit with a pager. I'm not sure that matters for all businesses, but I'm not interested in starting, e.g. a mom-and-pop web hosting site for local businesses. If the service matters, devs are on call. So maybe I'm self selecting by the expected $ return.
> DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles. Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
That's an org issue. For a given service dozens of roles will be involved, if devs are needed to do every single of them to care and be invested, there is a problem.
> [...] Only your developers can answer this question, not the ops team.
Yes. Those are questions that need an answer before a service is released, and the ops team need the veto power + sufficient means to escalate recurring issues in ways that will hurt the dev teams enough to make them care.
Exactly. The field is already too complicated, you can learn a lot without learning literally everything.
Actually, no one learns literally everything. "DevOps" mean that developers should prioritize learning ops over learning deeper something else (because ultimately there are only 24 hours in a day). Which sounds crazy to me; it would be better if the team had experts on different things cooperating together, rather than everyone being mediocre at everything.
That said, companies love replaceable people, or at least they love to imagine that everyone is replaceable. So when everyone becomes DevSecOpsCloudAccountantJanitor, it feels like as long at they keep one such person in the company, they got everything covered.
I kindly disagree. In my experience, developers don't spend 24h a day learning new stuff. They spend their working hours mostly writing new code. Learning how to build and ship it correctly isn't a lot of effort, averaged over years of work.
My feeling is more that developers want to believe that they are the superstars, and they don't want to do the "lower job" that is devops. "I'm too good to learn how to not make a mess in the CMakeLists".
> DevSecOpsCloudAccountantJanitor
I think that "DevOps" has "dev" in it for a reason. It is very close to what the devs produce. I am not saying that developers should be sysadmins or accountants or janitors. Just that they should know how to build their shit.
> Learning how to build and ship it correctly isn't a lot of effort, averaged over years of work.
As someone who worked for years at a company that delivered tools in the devops space, I think you're overlooking the difference between someone who deploys apps to Kubernetes and someone who sets up and maintains kubernetes clusters on bare metal hardware that they procured.
The dev may understand a lot of things about kubernetes, but the devops person is doing a lot of things behind the scenes that the dev should never have to worry about.
As someone who has been in the "robot devops" space for like a decade now, I think with robot companies it becomes particularly acute because:
- Ops for cloud services and ops for deployed robots are very different beasts, so it's really two different teams that could both reasonably be "devops".
- Ops/tools for robot developers is different since you're often dealing with simulation environments (local, cloud) and also managing access to a more constrained pool of test hardware, all of which needs to be able to quickly recover and restore itself to factory state after developers or their code have done unspeakable things.
- Deployed units are often the worst of both worlds between multiple domains. You've got the big deployment assets of a data center but without the big data pipe; nothing is virtualized so you can't just throw away a node that goes bad; you're stuck supporting hardware snowflakes (here's a text file somewhere with the list of units that have bad CPU fans and need different frequency caps); it's like IOT but with the power and disk and observability requirements of a real server.
Plus there's the mess of "different audiences need different views of info about the robots in order to triage" and those lines are murky, and someone's always trying a new tool, and "ugh, the new thing is great for group A, but now I can't efficiently see Y, and the old tool was fine (for me)"
> IOT but with the power and disk and observability requirements of a real server
And the issue with the robot is usually none of the regular observability health metrics of a real server... but when it is... "where does that dashboard live again, and is it still working?"
It's sad that people still think DevOps was about teaching people "dev and ops skills". There isn't even such a thing as "ops skills". Ops stands for Operations - as in Operations Management, a job that has nothing to do with servers (it's a job focused on ensuring business continuity in any industry). The term "Operations" got associated with servers and server commands because the department that Systems Administrators worked in was called the "IT Operations" department, aka, ensuring the business continuity of the Information Technology department. All of this happened because the entire industry spontaneously became collectively ashamed of the term "Systems Administrator" and "sysadmin". But they still wanted a way to refer to "the server people" and "what server people do", so they started saying "ops".
The "Ops" in DevOps was intended to mean the department itself, not the tasks they performed. The idea that devs should be learning or doing Systems Administration is the same as a building architect learning/doing concrete pours. They should know about concrete and the pouring/curing process, but they don't (and shouldn't) be pouring and smoothing the concrete themselves.
All have been meaningless except for Cloud Infrastructure Engineer. The rest described a generalist who knows how to deal with ambiguity and (usually) has the trust with things like AWS root account credentials. Most organisations have no idea what real DevOps is. If they did, they wouldn’t hire for a “DevOps Engineer”
Most places mean someone who does development and operations. They see it as a term for someone who has responsibilities on both sides, not a specialty.
In my experience DevOps Engineer has been infrastructure + operations while having a good grasp on code but writing application code was almost never part of the role. Almost every position had a coding interview round though.
The chart has "Systems Engineer" and "Systems Programmer" and te text even calls out different meanings of "systems engineer", but it misses both the independent field of systems engineering, which is not a software job and all, and the title "systems software engineer", which are SW engineers that write "systems software" i.e. drivers, kernel, OS.
I enjoyed looking back at my 20 year career through roles. I've done a few of them crossing domains twice. The tree should be seen as a constant evolving graph. There will be a plethora of new roles in the coming years.
For those who think Software Engineering roles are extinguishing, they just need to realize roles will evolve into something new. My current role (SRE) was a nascent niche at the start of my career and I didn't even know about it for many years.
Co-founder of Levels.fyi here. We think about this problem space a lot in developing our own taxonomy: https://www.levels.fyi/t
One of the hardest things is that the same title (and level) can mean very different things across companies, industries and over time. When collecting pay information, we take great care to merge titles that mean the same thing while distinguishing those that don't. There's other edge cases like at some companies a title will be more specific (Security Engineer), while at others they'll retain the general title (Software Engineer) but specialize in the same thing (Security).
Claude has been really helpful in wrangling this all and expanding our taxonomy :)
I’ve always been “software engineer” or some variant thereof, but always with the implication that you pick up any tech stack and learn it well enough to be productive. Often it was not the new programming language(s) that were challenging, but some really difficult black box tool (API, platform, database, framework, etc.), and even MORE challenging, the unnecessarily complex development environment.
I've had the title on and off since 2018, I assume we are pretending with DevOps that pure operations / ops management doesn't exist 0:-)
More charitably though, I think they are not focusing on operations despite it being one of the categories - I don't see incident coordinator / manager, problem manager, etc either.
I guess telecom engineer has been kind of a grab-all title for all kinds of jobs that are telecoms related but not enterprise networking. I’m a telecom engineer (telecommunications eng. diploma and all that jazz) but I deal with such ancient (PDH & SONET, yay!) and arcane stuff that no current job title would work.
Funny how an almost 100 years old title is still relevant today.
It's fascinating seeing all these in one place with the relationships and over time. I'd love to see one with the less formal titles (I like to go by "developer" personally though it's not my job title), but it would be gigantic.
There is a different incantation: when viewing the main version on mobile you can zoom in by choosing a category (eg “development”). And you can zoom out by pressing “all”.
IME, you see changes in numbers over time but the titles data analyst, data engineer, analytics engineer, data scientist are all still around. data platform engineer or SWE data seems to be stable as a systems role but anecdotally there is less demand for data roles now due to AI (either believed capability or deferred hiring to understand near term needs).
This was interesting to look at. I know it's not supposed to be perfect but it certainly does make one think about the career routes available. What surprised me was how short the path was for security to getting into the C-Suite. Although I do feel like most people become security analysts, then ISOs. Also I didn't realize that tape librarians were still a thing.
I’ve not been in the industry that long, but feel it’s so awkward that devops is in the operations silo. What happened with Development & Operations? Every place I’m at, the devops team is a bottleneck and everyone kind of accepts it.
The switch to the terminology of "forward deployed engineer" to replace consultant has been overwhelming. Almost certainly driven by the bad connotations that the title consultant has. Makes me wonder how long it will take to burn through any positives associated with that title before they switch to something else.
I've also seen a huge number of data scientists rebrand as "AI engineers" so I agree with that title's placement in the chart but I think that ultimately that's the wrong place for it to live. I'm convinced that AI Engineer will be a specialization of backend engineering since the work to integrate agents into production systems will be backend work not model training or other data tasks.
Interesting how disciplines critical to good software like Product Design, Service Design, Interaction Design, Content Strategy etc are just… not represented.
Software is mostly human-defined. The complexity mostly comes from understanding the meaning of a large corpus of existing text, and then building your thing on top of existing human-created conventions. Therefore, I suggest we start calling ourselves Software Lawyers, Software Judges, and Software Legislators. This is a much more sensible set of titles than “software engineer” and “architect,” and it will probably cause less confusion and pointless bickering.
Software is just an extension of electrical engineering, only with the small technical difference that instead of building circuits that process signals, you write instructions for a pre-made Turing machine instead. FPGA engineers are clearly digital engineers, if they want they could write out their circuits with diagrams, though most use code, because it's more compact, easy to modify, and is easier to operationalize with version control and testing. The only thing different from software is the depth of our abstractions, and the scope of our problems.
A lot of said complexity is ultimately because we haven't embraced software as an engineering discipline but as rules lawyering. We've lost sight of actual engineering goals like cost and size, and ventured far into the world of marketing, rushing to implement every feature instead of building a sound system first, causing immeasurable economic harm in product defects, engineer burn-out, and missed opportunity.
I worked in SWE for 35 years and the only titles I was given were: junior, senior, staff, senior staff, principal, lead principal, and senior principal. All followed by “software engineer”. I guess I never worked at companies that used all these fancy names.
> When I’m asked what the difference is between a DevOps engineer, an SRE and a platform engineer, the honest answer is always a little history lesson. This is the shortest version of that lesson I’ve managed so far.
Unless you talk to a recruiter and they say something like your more of a SRE then a DevOps engineer and we really need a devops engineer. Insansity
I think there should be more domains included other than mobile/backend/frontend, there’s software engineers working on robotics/graphics/aviation but not necessarily embedded engineer
Recently I spoke to someone who wanted to know what they should call themselves seeing as they never learned software development, formally or otherwise, but that's not stopping them from releasing AI-powered Python projects in GitHub. I suggested Project Manager, but they took offense to that because (I think) they wanted to hear Software Engineer in order to apply to those jobs. My counter-argument was that, legal rules aside, a S.E. should be able to differentiate good code from bad, but my suggestion wasn't super well received.
The point being: I'm always amazed at the cross-purpose impulse of arguing "the title is not important" while, simultaneously, really wanting to use the title.
i think "User" ultimately.
It depends on the way they use it. If you design an architecture and use an LLM to fill it in, I'd consider a more technical label. If you're just using what Claude made, and providing feedback, that's just how software was done 10 years ago except then they'd be talking to a guy instead. And it would be orders of magnitude more expensive.
From my perspective, Claude feels like 5 engineers in a box. you can make things that required small organizations to make.
I think the role is that of a producer - similar to a music producer in the 70s and 80s integrating new synth and recording technology into ambitious outcomes where the goal was defined but the shape and detail unpredictable.
AI is heavy machinery. In the construction industry you need special permits to operate such machinery, and everybody driving a car needs to have a driver's license.
So I wonder if users of "heavy AI" should also need to have a license.
As a software engineer (CS degree and ~10 years of pre-AI experience), I'd feel uncomfortable saying I was a Project Manager
Who would want to?
I'd call them a Software Conductor.
Prompt Whisperer
Project Manager is a great fit. I also heard and liked Director, which brings in good analogies from filmmaking and implies nothing about technical ability either way. Could even be Software Director.
Software Director could be confused for Director of Software Development.
Director of Software Directing?
Prompt Editor (Senior)
LGTM-er (100% approval rate)
As an analyst who vibe codes a lot I think it is perfect, along with Product Manager. There is a lot more to these roles, but I think they're the closest.
You could have suggested “prompt engineer”. As in “engineering by prompting”. :)
Prompt engineering usually means engineering the prompts themselves, and implies in depth knowledge of what makes a good prompt.
A prompt engineer is one who gets to the standup on time.
If I asked Gemini to recommend a weight loss plan, does that make me a dietician?
You're jesting, but I've seen self-claimed "dietitians" with much less involvement than asking a bot.
Software engineers keep software on the tracks like train engineers keep the train on the tracks. Nobody thinks the train engineer built the train...
If you look up the etymology of engineer, you'll find ancient roots (Latin, etc.) many hundreds of years old which are primarily about contriving/inventing/designing clever devices and occasionally about operation thereof. And you can find that a definition regarding train operators was added less than 200 years ago. The train thing is just an offshoot that is irrelevant to other types of engineering.
We should train engineers regardless.
Do you think the "engineer" in software engineer is etymologically closer to train engineer than it is to electrical/mechanical/civil engineer?
I don't think so.
Isn't it maintenance, not engineering?
Member of Technical Staff, Applied AI
Project engineer..?
I would suggest "Anthropic client", because the relationship between them and Anthropic is similar to the relationship between a client and a contractor.
You ask the contractor for what you want, iterate a little, and take what they give you. Sometimes you may read the results.
"The title is not important" was a movement coming from the fact that same jobs at two companies could've had vastly different responsibilities, and vice versa. But that was rather an exception and outside that bubble, people have always paid great attention to titles.
Yours sincerely, Software Developer with 6 years of experience. Last week for the first time in my career I've actually merged application code. It was AI generated.
...what did you do the last 6 years?
Yeah, wait what?
I'm confused about the point he's making here with the 6 years thing.
There's only one country to my knowledge that has historically allowed anyone to be called a software engineer without being an engineer . Now that the bar is dropping even lower, can we stop normalizing that? I never had the audacity to call my self a Software Engineer without an Engineering degree, just use any of the other dozens of words.
Comp Sci degree is somewhat of an exception, I get that
Scrum and Agile seem to be dying. I had a Product Owner and Scrum Master cert for years on my resume but i've dropped it from my current. Feels now like the ancient webmaster title of the mid 90s. Made for another timeline which is not more relevant.
DevOps is another sad story as it was a saner approach to get people skilled for both dev and ops but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
DevOps should be a guiding principle for the organization, not a dedicated role. Every developer (or at least: every team) should be able to
- speak to production users
- ship to production
- monitor and learn from production usage
You don't need "devopsy" skills to do that, rather organizational structures that allow for incremental change. FWIW, deployments could still be a 2005-like upload via FTP, and the benefits of DevOps could still be reaped.
> DevOps should be a guiding principle for the organization, not a dedicated role
The way I've always phrased it is that if a company has "DevOps" teams or titles, they're not doing DevOps by definition
I call it the reverse devops principle. The more a company speaks of doing DevOps, the less they are actually doing it.
Was that not the OPs point too about it being a sad story and many Devs not being capable of learning to run software outside of an IDE?
So jack of all trades master of none?
We’re seeing the same thing with QA. I guess developers can QA their own deliverables.
Leaving out the key fact that the vast majority of developers have no interest in testing stuff. And thus you end up “testing in prod” like with Microsoft projects.
It’s not a coincidence Microsoft’s software quality has collapsed since they’ve eliminated dedicated QA/SDET roles.
> So jack of all trades master of none?
Why does the ability to interact with users, being able to test code, profile/debug code, and actually manage your deployed software imply you're a master of none? Too many developers act like it's a good state of affairs that they just get locked in the basement to grind the code. And now that we have tools that can grind code for you, they're finding out why that wasn't a good state of affairs for them.
The answer is master all of them, not none of them.
Most people aren't particularly good beyond 1/3 of those domains. It's delusional to expect everyone to be Superman even though that idea is amazing in a vacuum.
https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD130...
Dijkstra being able to witness software development today would be interesting to say the least.
While I agree with this, in a lot of software there's more to verify than just being correct. Unless there's a separate and rigid UI/UX spec then there's also matter of things being intuitive to use etc. which may vary from person to person and the one making the thing might not have the same sensibilities as the users.
> So jack of all trades master of none?
Once you write software that is run in places other than your computer by people other than you, you have the right and the duty to speak to those people, to look into those places, and to push updates in small increments once you've learned something valuable from either of the two sources. "You" can be a small team of close collaborators, so not every developer has to speak to users, and not all developers need to push to prod or look into the Grafana every now or then. It's just that those responsibilities should not be gated into remote departments.
Infrastructure is still provided and maintained by Ops. That's exactly the point of my critique: giving Devs access and responsibilities is no excuse to dump the whole Ops department. Managers shouldn't give someone a DevOps-title and think they get 2 for 1.
Similarly, asking Devs to write and maintain proper test automation for their services is the bare minimum - scraping centralized QA is still a bad call, though. Somebody must build and run test infra, set and enforce standards, aggregate data, track regressions, keep the full picture etc. - but they shouldn't block incremental deployments for days.
That’s why the developers have to be on pager duty sometimes for the code they write.
Nothing makes you take testing your code more seriously than having to respond to an outage caused by a bug code you wrote.
> but turns out people don't like learning new skills as much as they claim. So its meaning differed from org to org and even within the same company.
Titles like these always mean something different from company to company.
Even “product manager” has had different meanings at my different employers, some times with major consequences for people who got hired into those roles expecting to do one type of work and then being evaluated on different expectations.
For DevOps, there were a lot of unrealistic expectations from everyone who saw the word and assumed they knew what it meant. I saw a lot of engineering leaders come up with completely different expectations for DevOps roles, but when the chaos arrived most of them reduced the DevOps people into the responsible-for-everything people, which just burned people out.
I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
> I think pure Product Manager - idea person and feature gate - as a role has limited days left, but Technical Product Manager - often people with recent dev experience and strong tech chops who can build a lot with AI - might be the new role.
This depends on the org, but product managers I've worked with spend a lot of time speaking directly with users, particularly in B2B shops. Between speaking with customers and communicating product plans both upwards (to GMs/VPs/exec etc) and outwards (to your own team + external teams) you really shouldn't have a lot of time to build anything as a PM, even with AI.
Bingo
Where "product manager" really started going off the rails was when enterprise agile achieved hockey stick level popularity as all of a sudden the "product owner" role wound up being in the "product manager" job family.
All of a sudden you had "product managers" inserted deep in the bowels of large systems, instead of focusing on big picture topics.
There is also a lot of title inflation, especially at startups.
DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles.
Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
Very few people want that in their life, money be damned. Same way in an ideal world devs should also participate in customer support, but very few could really do it or handle that for years.
Any developer who doesn't at least *understand* the ops side of the fence and has never spent time actually *doing* it, will make bad decisions along the way from an ops perspective. These are bad developers.
I see a stark difference between understanding how it works and doing it in a professional manner.
For instance I probably have a decent understanding of what our CS team deals with, the tools they use, the volume and overall content of the customer feedback and requests that are coming to us. But I don't sit at a CS desk every day for a few hours and process the tickets of the service I'm running.
You should at least be able to step in and do that job, however, if necessary. That's different than that being the most efficient use of your time, but it's something every good developer should be *capable* of doing.
Last team I was on was repsonsible for supporting and maintaining their product, with help from the SRE team. It means after-hours support for issues and (maybe) releases but I think this was the right way. You became the backstop and support resource for things like data center outages and DDOS attacks that were largely the responsiblity of the (much smaller than many places) SRE team. We also put devs very closely behind front-line customer facing staff where it made sense (ex: reporting & analytics - yes, platform - probably not). It made the devs better and they might try and deny it but I think most of them actually appreciated it. #YMMV
> I think most of them actually appreciated it.
The issue I was facing in a previous life was the turnover. We had data scientists, DBA and many specialized roles stay pretty long, where devops moved away at about twice the rate, and work life balance was mentionned in many exit interviews.
I agree with you that it's extremely formative, and having devs involved basically from start to end of the service surface gives a lot of flexibility. The downside being that it requires a ton of different skills as well, and while people learn, many won't get comfortable with it even after months.
This makes it specially tough when people get called at 3 in the morning to deal with an emergency while they've already spent half the night sleep deprived from their kid puking all night. The worst part being that while people could understand wanting to skip turn one or two times, engineers with small kids will have enough going in their lives that most on-call instances land at a time they're busy dealing with more important matters.
> being in the war room when a data center goes under
When doesn't this involve devs? If you have ops separate and isolated from the development effort, a devs representation will have to get involved at some point.
Imagine managing a gitlab instances. You're doing it for years and have a stable environment. If one of the instance gets hammered by external traffic or one of your data center dies, will you call the gitlab devs to deal with it ?
Depending on the size of the deployment. (Not sure what you mean with "one of your data center" though) If it's just you, you deal with it. If you're running a bigger deployment, you likely have GitLab devs internally that will be reachable. Even bigger - you're likely to have access to upstream devs in the ultimate tier even with self hosting.
So... Yes, sometimes you will.
>DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions
That's why they have to be the same team. Your dev team needs to: 1. understand how to write code that can be debugged and recovered in a crisis, 2. learn to write code that doesn't cause the crisis in the first place, 3. have the motivation to do so because they will be the ones paged.
Anything else produces are far worse experience for everyone involved, especially customers.
The problem I've seen with DevOps is that some fief-builder sets up a "DevOps Organization", which is literally the opposite of what DevOps means.
These are all good point, that I think aren't really related to having devs do operations.
Having engineers understand what makes a service resilient and easy to manage, as well as giving them incentives to produce high quality code doesn't require them to do SRE. In particular, being close enough to the SRE team, getting inputs when building the feature, detailed feedback and requests on live services, and the blame when shit hits the fan, are a more scalable way of doing it IMHO.
>Having engineers understand what makes a service resilient and easy to manage,
I don't believe engineers can understand this without experiencing it. A counter argument might be "football coaches don't need to have played", but the counter to that is "players need to have played". Why would being on call make you a better player? Personally, I think being the person watching the dashboards, in realtime, scraping the logs, in real time, watching how the contagion happens, in real time, gives insights that a next-day post mortem just doesn't. There are things I've learned only from hearing something on the conference call and then asking someone about it in chat. Watching a presentation on "Why 99% of people fell of our new bike" isn't nearly as useful as riding the fucking bike.
I've been on teams (briefly) where the ops team having an absolutely shit 48 hours was simply not on the dev teams radar, because they had more important things to worry about. That of course meant that when devs needed, e.g. a new host to try something, ops just dragged their feet, sometimes for months. Perhaps I've only seen dysfunctional companies in this regard. Or perhaps teams are made of humans, and splitting dev and ops is guaranteed to fail for any organization of more than 20 people? Like, sure, a startup of ten highly motivated people - maybe that works. Never done that myself: we've always run our own shit at the startups I've run/worked. Once that startup is 50 people, I think you're destined to fail with separate dev and ops.
Been paid for this over 40 years now. Done startups and FAANGs. But yes, the rewards better be fucking worth it, and the shifts better be reasonable.
So like, I'm not certain you're wrong. I don't think you can be wrong here. It's about what you're willing to do. Personally, I've done both ways, and if I started a company, I'd only hire people willing to support their shit with a pager. I'm not sure that matters for all businesses, but I'm not interested in starting, e.g. a mom-and-pop web hosting site for local businesses. If the service matters, devs are on call. So maybe I'm self selecting by the expected $ return.
> DevOps'issue IMHO is developing software and dealing with the ops side are two fundamentally different propositions, and require two different life styles. Doing ops also means entering the on-call rotations, being in the war room when a data center goes under and being on the hook when a DDOS brings down the service.
That's exactly the issue that DevOps aims to solve, though. When you have developers who have no ownership or responsibility once the software is running on production, it becomes a "throw it over the fence" situation, and devs don't care about the operational side.
Logging? Who needs that, if there's a bug report I'll reproduce it on my local machine (and if I can't, CLOSE-WONTFIX!) Performance monitoring? That's an ops problem, tell 'em to buy better hardware. Application crashes? Works on my machine, probably a bug in the server config; ops problem. Tell them to set up a scheduled restart every hour.
You still need dedicated operations staff who deal with the overall system health and design, but yes, a developer needs to be involved when a DDOS brings down the service, because how should the system behave under heavy traffic? Can it serve up cached read-only pages? Did someone find a very CPU-intensive public endpoint that is being exploited and needs to be fixed? Only your developers can answer this question, not the ops team.
> devs don't care about the operational side.
That's an org issue. For a given service dozens of roles will be involved, if devs are needed to do every single of them to care and be invested, there is a problem.
> [...] Only your developers can answer this question, not the ops team.
Yes. Those are questions that need an answer before a service is released, and the ops team need the veto power + sufficient means to escalate recurring issues in ways that will hurt the dev teams enough to make them care.
Dozens of roles for one service???
Give developers on call rotations and watch their code quality sky rocket.
A dev can very much enjoy learning new skills without feeling any desire for the pressure and burden of having to deal with ops.
Ops is when what you made collides with reality. Replacing "ops" in your post with "reality" gave me a good chuckle.
Ops has heaps of accidental complexity that has little to do with the software that was made. That’s why many devs dislike ops work.
What makes you say it's accidental?
accidental complexity versus essential complexity.
Yep the distinction is well understood. I didn't do a great job making it clear.
I'm asking what op believes is accidental complexity. If it was reducible we would've surely done so by now?
Now I'm reading every comment here, substituting "Ops" with "Reality" and it's hilarious.
Exactly. The field is already too complicated, you can learn a lot without learning literally everything.
Actually, no one learns literally everything. "DevOps" mean that developers should prioritize learning ops over learning deeper something else (because ultimately there are only 24 hours in a day). Which sounds crazy to me; it would be better if the team had experts on different things cooperating together, rather than everyone being mediocre at everything.
That said, companies love replaceable people, or at least they love to imagine that everyone is replaceable. So when everyone becomes DevSecOpsCloudAccountantJanitor, it feels like as long at they keep one such person in the company, they got everything covered.
I kindly disagree. In my experience, developers don't spend 24h a day learning new stuff. They spend their working hours mostly writing new code. Learning how to build and ship it correctly isn't a lot of effort, averaged over years of work.
My feeling is more that developers want to believe that they are the superstars, and they don't want to do the "lower job" that is devops. "I'm too good to learn how to not make a mess in the CMakeLists".
> DevSecOpsCloudAccountantJanitor
I think that "DevOps" has "dev" in it for a reason. It is very close to what the devs produce. I am not saying that developers should be sysadmins or accountants or janitors. Just that they should know how to build their shit.
> Learning how to build and ship it correctly isn't a lot of effort, averaged over years of work.
As someone who worked for years at a company that delivered tools in the devops space, I think you're overlooking the difference between someone who deploys apps to Kubernetes and someone who sets up and maintains kubernetes clusters on bare metal hardware that they procured.
The dev may understand a lot of things about kubernetes, but the devops person is doing a lot of things behind the scenes that the dev should never have to worry about.
As someone who has been in the "robot devops" space for like a decade now, I think with robot companies it becomes particularly acute because:
- Ops for cloud services and ops for deployed robots are very different beasts, so it's really two different teams that could both reasonably be "devops".
- Ops/tools for robot developers is different since you're often dealing with simulation environments (local, cloud) and also managing access to a more constrained pool of test hardware, all of which needs to be able to quickly recover and restore itself to factory state after developers or their code have done unspeakable things.
- Deployed units are often the worst of both worlds between multiple domains. You've got the big deployment assets of a data center but without the big data pipe; nothing is virtualized so you can't just throw away a node that goes bad; you're stuck supporting hardware snowflakes (here's a text file somewhere with the list of units that have bad CPU fans and need different frequency caps); it's like IOT but with the power and disk and observability requirements of a real server.
Plus there's the mess of "different audiences need different views of info about the robots in order to triage" and those lines are murky, and someone's always trying a new tool, and "ugh, the new thing is great for group A, but now I can't efficiently see Y, and the old tool was fine (for me)"
> IOT but with the power and disk and observability requirements of a real server
And the issue with the robot is usually none of the regular observability health metrics of a real server... but when it is... "where does that dashboard live again, and is it still working?"
It's sad that people still think DevOps was about teaching people "dev and ops skills". There isn't even such a thing as "ops skills". Ops stands for Operations - as in Operations Management, a job that has nothing to do with servers (it's a job focused on ensuring business continuity in any industry). The term "Operations" got associated with servers and server commands because the department that Systems Administrators worked in was called the "IT Operations" department, aka, ensuring the business continuity of the Information Technology department. All of this happened because the entire industry spontaneously became collectively ashamed of the term "Systems Administrator" and "sysadmin". But they still wanted a way to refer to "the server people" and "what server people do", so they started saying "ops".
The "Ops" in DevOps was intended to mean the department itself, not the tasks they performed. The idea that devs should be learning or doing Systems Administration is the same as a building architect learning/doing concrete pours. They should know about concrete and the pouring/curing process, but they don't (and shouldn't) be pouring and smoothing the concrete themselves.
So far in my career:
- DevOps Engineer (Junior, Senior, Staff)
- Systems Development Engineer
- DevOps Team Manager
- Cloud Infrastructure Engineer
- Site Reliability Engineer (+Lead)
All have been meaningless except for Cloud Infrastructure Engineer. The rest described a generalist who knows how to deal with ambiguity and (usually) has the trust with things like AWS root account credentials. Most organisations have no idea what real DevOps is. If they did, they wouldn’t hire for a “DevOps Engineer”
DevOps requires tooling and infrastructure, and at a certain size, a dedicated DevOps Engineer optimizes that tooling. What's wrong with that?
Most places mean someone who does development and operations. They see it as a term for someone who has responsibilities on both sides, not a specialty.
In my experience DevOps Engineer has been infrastructure + operations while having a good grasp on code but writing application code was almost never part of the role. Almost every position had a coding interview round though.
The chart has "Systems Engineer" and "Systems Programmer" and te text even calls out different meanings of "systems engineer", but it misses both the independent field of systems engineering, which is not a software job and all, and the title "systems software engineer", which are SW engineers that write "systems software" i.e. drivers, kernel, OS.
I've always just called myself a "computer programmer." Never was much concerned with what HR called me.
I enjoyed looking back at my 20 year career through roles. I've done a few of them crossing domains twice. The tree should be seen as a constant evolving graph. There will be a plethora of new roles in the coming years.
For those who think Software Engineering roles are extinguishing, they just need to realize roles will evolve into something new. My current role (SRE) was a nascent niche at the start of my career and I didn't even know about it for many years.
Very few think that SWE roles will completely disappear. The main concern is that whatever it evolves into, the world will need far fewer.
Cool! Not mobile friendly though - can you make the diagram zoomable with touch screens?
Co-founder of Levels.fyi here. We think about this problem space a lot in developing our own taxonomy: https://www.levels.fyi/t
One of the hardest things is that the same title (and level) can mean very different things across companies, industries and over time. When collecting pay information, we take great care to merge titles that mean the same thing while distinguishing those that don't. There's other edge cases like at some companies a title will be more specific (Security Engineer), while at others they'll retain the general title (Software Engineer) but specialize in the same thing (Security).
Claude has been really helpful in wrangling this all and expanding our taxonomy :)
I’ve always been “software engineer” or some variant thereof, but always with the implication that you pick up any tech stack and learn it well enough to be productive. Often it was not the new programming language(s) that were challenging, but some really difficult black box tool (API, platform, database, framework, etc.), and even MORE challenging, the unnecessarily complex development environment.
I can't see Operations Manager listed, yet I've had that title for the last 15(?) years.
I've had the title on and off since 2018, I assume we are pretending with DevOps that pure operations / ops management doesn't exist 0:-)
More charitably though, I think they are not focusing on operations despite it being one of the categories - I don't see incident coordinator / manager, problem manager, etc either.
I guess telecom engineer has been kind of a grab-all title for all kinds of jobs that are telecoms related but not enterprise networking. I’m a telecom engineer (telecommunications eng. diploma and all that jazz) but I deal with such ancient (PDH & SONET, yay!) and arcane stuff that no current job title would work.
Funny how an almost 100 years old title is still relevant today.
It's fascinating seeing all these in one place with the relationships and over time. I'd love to see one with the less formal titles (I like to go by "developer" personally though it's not my job title), but it would be gigantic.
Before data scientist, there was data miner or data mining engineer.
Would be nice if I could actually see it. I cannot zoom in, zoom out or do anything with it.
It’s here: https://ianmiell.github.io/sw-job-title-family-tree/
That's probably the one they found not working if they are mobile (or, at least, that's where I got stuck).
The magic incantation I found was to use the PNG version https://ianmiell.github.io/sw-job-title-family-tree/job_titl... since tbat just lets the browser handle it without any "smarts".
The main version wouldn't let me zoom in, the libked version would only let me pan, and the svg version wouldn't let me zoom out.
There is a different incantation: when viewing the main version on mobile you can zoom in by choosing a category (eg “development”). And you can zoom out by pressing “all”.
There's a link to the SVG version of it that you can navigate using your browser's normal interface controls.
CTRL+scroll wheel to zoom
On mobile you can pinch zoom on the png file: https://ianmiell.github.io/sw-job-title-family-tree/job_titl...
agree, the ui to navigate this data is very uncomfortable, I guess we're gonna need a front-end developer here to fix it. :)
Where does “Member of Technical Staff” fit on this tree? At the bottom should all arrows just feed into “Member of Technical Staff”?
Surprised “Web Designer” didn’t make the cut. That is what we were often called between being a Webmaster and Web Developer.
I've been a Webmaster and a Web Developer but I never called myself a designer.
The chart skips design entirely. e.g. UX, web designers, etc. also Web designers normally went into front end development.
Webmaster too though, I always thought that it downplayed my skills but since Claude writes most of my code, maybe that's what I am now.
IME, you see changes in numbers over time but the titles data analyst, data engineer, analytics engineer, data scientist are all still around. data platform engineer or SWE data seems to be stable as a systems role but anecdotally there is less demand for data roles now due to AI (either believed capability or deferred hiring to understand near term needs).
This was interesting to look at. I know it's not supposed to be perfect but it certainly does make one think about the career routes available. What surprised me was how short the path was for security to getting into the C-Suite. Although I do feel like most people become security analysts, then ISOs. Also I didn't realize that tape librarians were still a thing.
I’ve not been in the industry that long, but feel it’s so awkward that devops is in the operations silo. What happened with Development & Operations? Every place I’m at, the devops team is a bottleneck and everyone kind of accepts it.
Read The Phoenix Project. It will give you a little insight into what the original intent was.
In my 20 years I've been the following (in order):
Where my Design Engineers/Design Technologists at?
UX, Flash developer, Animation, 3D animator, 3D modeller. So many roles under this.
As a kid I always wanted to be a SysOp. Not that I knew what it was, all I knew was it had to do with computers and sounded cool. That was enough.
The switch to the terminology of "forward deployed engineer" to replace consultant has been overwhelming. Almost certainly driven by the bad connotations that the title consultant has. Makes me wonder how long it will take to burn through any positives associated with that title before they switch to something else.
I've also seen a huge number of data scientists rebrand as "AI engineers" so I agree with that title's placement in the chart but I think that ultimately that's the wrong place for it to live. I'm convinced that AI Engineer will be a specialization of backend engineering since the work to integrate agents into production systems will be backend work not model training or other data tasks.
My first paid job, at 21, in 1999, was "Senior Network Operations Engineer".
I've never been able to take "senior" seriously since.
Where’s member of technical staff?
> In 1947 coding was the clerical bit, and the real work was in the planning.
A tale which of course, flatters the planners…
Heh heh. Meanwhile in 2026, the developers are doing the real work, including those heavily employing AI. Which flatters me :-)
Interesting how disciplines critical to good software like Product Design, Service Design, Interaction Design, Content Strategy etc are just… not represented.
Software is mostly human-defined. The complexity mostly comes from understanding the meaning of a large corpus of existing text, and then building your thing on top of existing human-created conventions. Therefore, I suggest we start calling ourselves Software Lawyers, Software Judges, and Software Legislators. This is a much more sensible set of titles than “software engineer” and “architect,” and it will probably cause less confusion and pointless bickering.
Software is just an extension of electrical engineering, only with the small technical difference that instead of building circuits that process signals, you write instructions for a pre-made Turing machine instead. FPGA engineers are clearly digital engineers, if they want they could write out their circuits with diagrams, though most use code, because it's more compact, easy to modify, and is easier to operationalize with version control and testing. The only thing different from software is the depth of our abstractions, and the scope of our problems.
A lot of said complexity is ultimately because we haven't embraced software as an engineering discipline but as rules lawyering. We've lost sight of actual engineering goals like cost and size, and ventured far into the world of marketing, rushing to implement every feature instead of building a sound system first, causing immeasurable economic harm in product defects, engineer burn-out, and missed opportunity.
Where is Prompt Engineer?
It wasn't a software role
These days I half-jokingly (it’s on my slack profile “position” field) refer to my self as a Serious Product Vibe’ineer.
Where does this fit in on the chart?
I worked in SWE for 35 years and the only titles I was given were: junior, senior, staff, senior staff, principal, lead principal, and senior principal. All followed by “software engineer”. I guess I never worked at companies that used all these fancy names.
No middle or intermediate?
Great project! I love that you can download the Graphviz source.
"Forward deployed engineer" sounds like it comes from people who spent too much time fantasizing about military crap.
> When I’m asked what the difference is between a DevOps engineer, an SRE and a platform engineer, the honest answer is always a little history lesson. This is the shortest version of that lesson I’ve managed so far.
Unless you talk to a recruiter and they say something like your more of a SRE then a DevOps engineer and we really need a devops engineer. Insansity
Jokes on you, I'm a Senior Systems Engineer.
Member of Technical Staff is missing
What's the source of this data?
I a/b test titles on my linkedin every other month to the trendiest of trendiest terms
sometimes I hypothesize terms and roles, like a astro physicist imagining celestial objects that cant be detected for another 100 years
and that works too sometimes, you have to assume there is a mismatch between what employers want and what talent does
my background remains the same just what I’ve been doing the last 2 years gets radically reimagined
Another path: “fullstack” -> “product engineer”
I think there should be more domains included other than mobile/backend/frontend, there’s software engineers working on robotics/graphics/aviation but not necessarily embedded engineer
Folks. Job titles don't mean anything. You know this.