One of the most important roles that titles play in the tech industry (at least the US-centric tech industry) is to help evaluate compensation.
Companies subscribe to reports which provide "salary band" compensation data across the industry. When it's time to consider raises, management with access to those reports can then see if their pay is more-or-less in line with other similar companies.
This means titles like "Senior Engineer", "Staff Engineer" etc do actually have very meaningful purposes - they can be used to attempt to map together different levels at different companies in order to determine if you are being under- or over-paid for the role you are in.
If you've never held a management position that includes decisions around compensation increases you are likely unaware of quite how much thought and effort goes into this process.
Don't get me wrong: it sucks, and it's still mainly a bunch of tea-leaf reading (with serious real-world consequences for employees) - but it's important to understand this any time you're wondering why titles work the way they do.
> One of the most important roles that titles play in the tech industry (at least the US-centric tech industry) is to help evaluate compensation.
I think there are some hints left by management and HR. We often hear excuses around appraisal like:
"we want to give you a hike, but your current job title doesn't allow us to pay beyond xyz and we don't have budget for a promotion".
I guess there's an element of truth in it sometimes (often these are excuses) because your title may limit your hike but it doesn't stop your manager from assigning and expecting you to take on work above your pay grade.
Yeah I've heard that exact phrase. I was told I was already at the top of the band for my title (Senior Engineer haha) and not eligible for the annual salary increase. Then six months later laid off.
> If you've never held a management position that includes decisions around compensation increases
In large organisations, yes.
In smaller organisations and startups, the "salary bands" are less fixed and there's more freedom to just pay people what you think they're worth. Consequently the title means less and in a lot of cases a small business really doesn't care what its staff call themselves. Titles can get inflated easily here too [0].
[0] Anecdote: a friend of mine attended a bootcamp, got a job with a small (<20 headcount) business, got up to Senior Developer title within 2 years because the business didn't care. Then transferred to a large org at a suitable Senior pay scale.
One way to get out of this is to have a title wildly out of range relative to your compensation.
If you're title is "engineer" and you're overseeing a technical team and participate in the architectural decision for your company, anyone dealing with your salary (including when moving jobs) will need to actually look at your job instead of just the title.
In the same vein I had a coworker request "staff” as title and we were small enough that it didn't matter.
Worth mentioning that staying in line with other companies is critical for company sponsored immigration in the US. If an individual is paid too differently from their title at other companies, their visa might be denied for being unfair to citizens looking for similar positions. It could be similarly unfair if they're paid differently from citizens with the same title within your company. Hence everyone at your company needs salaries that align with industry titles, or you risk not being able to get visas for international employees.
This is exactly it. This is why often people will have titles change along with increases in compensation even though there may not be any change whatsoever in job description or responsibilities.
I don't think this article describes a new thing. I got my first real job as a Programmer/Analyst (that was the entry-level title) back in 1979, at Nike. In less than two years I got promoted to Senior Programmer/Analyst. I clearly didn't count as "senior" in the industry at large, but within the logistics/inventory group at Nike I had significant seniority. Like at a lot of companies titles corresponded to pay ranges, so a raise came with a new title.
Back then Nike laid out their business cards vertically. When I got my new cards the title read "Senior Prog/Anal," a title I still cherish. My manager noticed and had the cards reprinted with the title on two lines.
I got a Senior title at my next job, and by 23 I got named Manager and reported to the CTO at a mid-size logistics company. All of the programmers there got Senior in their title. I have worked with people all through my career who had inflated and meaningless titles.
At some point in my career I realized titles don't communicate anything meaningful. I started using Programmer. Even now with 40+ years experience I use Programmer if I have to give a title. That at least describes what I do most of the time.
I have never willingly called myself an "engineer," though I have worked at places that called all of their programmers "engineers." That seems like stolen valor to me, I didn't get an engineering degree and I don't think of programming as an engineering discipline.
Every company has its own hierarchy of titles, but those don't correspond to other companies. I got asked in an interview once why I hadn't made it to senior after so many years in the business, I just laughed and said I made senior at 21 after two years working, and didn't think titles said much -- my actual experience speaks for itself.
I doubt this was ever a thing at all. I think the author falls to the common nostalgia trap of an imagined "perfect" past that has degraded somehow. It's a trap all human beings easily fall into, so I wouldn't blame him, but I fail to remember any such period from my career or older historical accounts that titles were reliably and consistently meaningful across the industry.
The moment you've got more than a handful of companies doing software, each company will do its own thing with the titles it gives — and there are few incentives (if any) to heavily gatekeep titles with a complex and hard-to-implement certification process. And if a company does end up implementing some sort of certification anyway, it would be specific for that particular company and not something that's relevant for the entire industry.
I would even argue that's not just the case for software, but for any industry that is not regulated by the state or by a mandatory certifying body such as law, accounting and medicine — and even in those industries, the standardized certificates you get are generally limited to a fairly entry level.
The only imagined past where career progression was strongly regulated that I can think of is European Professional guilds in the late Middle Ages through the Early Modern period, where you'd often apprentice for 7 years or so before attaining the title of Journeyman, and then you would have to wait anything between 10 to 20 years to never (the most common result) before you obtain the necessary funds and approval to become a master and practice on your own. I'm not sure there is any point going back to THAT system.
The guild system lives on in a way in the skilled trades. An electrician or plumber goes through specific career stages. My son apprenticed learning how to make beer. It also lives on in the military. I think programming would benefit from an apprenticeship stage -- I had great mentors assigned to me early in my career but that seems to have gone away.
The meritocratic nature of programming attracted me to it (as a young nerd with an incomplete degree in military history). If you could do the work you got paid and promoted, and companies would put in the effort to train and mentor juniors back in the day (or maybe I got lucky and feel nostalgic for an imaginary past). I saw the credential craze come and then mostly fade away (I got Oracle, Novell, and DEC certifications). Now I see companies insisting on CS degrees.
My early programming heroes didn't seem to use titles -- Dennis Ritchie, Ken Thompson, Brian Kernighan. I suppose Bell Labs gave them titles but when I read their papers they just used their names. Rob Pike calls himself a programmer -- when he presented Go at OSCON a long time ago he introduced himself as a "programmer at Google." Maybe a humblebrag, but if you can walk the walk you don't need to show off with a fancy title. I think we shouldn't get hung up on titles, or use them to gatekeep or judge.
Yup. I worked 3 years and 10 months (yes I just checked) before I was first hired as a "Senior Software Engineer", by a very normal desktop publishing development company, in 2007. Not via LinkedIn, nobody I knew was on it back then.
I wasn't expected to be some "visionary architect" (lol), just competent enough to get the job done without hand holding. Which (spoiler alert!) I was able to do, had a good run at that company and then for the next 17 odd years I've stayed a "senior engineer" at many other companies.
When I've been in hiring we've always based seniority on how we evaluated their skills and experience, not how long they've worked in the job.
In Australia the term "engineer" wasn't really used for software until relatively recently. I've been in tech for almost 30 years and have been a sys admin, network admin, db admin, developer, manager, product lead, consultant etc. I have experience in many languages, platforms and technologies and have worn many hats.
I now just call myself a developer. But I also only program for fun these days.
> That seems like stolen valor to me, I didn't get an engineering degree and I don't think of programming as an engineering discipline.
I don't think of software as solely an engineering discipline either, but domains within it are certainly "engineering"-ish. I work all day with "proper" engineers doing an essentially similar job. If we call it something else, that implies the terms aren't identical. If they're not identical, what semantic differences are being conveyed, since both sets of titles refer to jobs sharing the same ultimate responsibilities for the results? When does this become a stolen valor situation?
Engineers get degrees in engineering, have to pass tests to work in their field, and get required ongoing education to stay current. Not every engineer but in general the title "engineer" connotes a minimum amount of education, credentials, exams, etc. that don't exist in the programming world.
I think of engineering disciplines as fields that have documented knowledge and processes that lead to predictable and repeatable results. In my experience programming defies accurate (or even useful) prediction, and we fail to replicate success reliably. I agree that programming has some engineering-ish aspects, some things we understand better than others, but we mostly fall down as a field producing predictable software.
I think those "failures" come from the nature of programming as an idiosyncratic craft, a field too big with too many specializations to master in a lifetime, and a constantly-changing landscape of hardware, languages, tools, frameworks, and so on. And programmers very often work with vague, incomplete, and shifting requirements -- something engineers have better processes for. A bridge or a building or a road gets planned out to a level of detail that similarly large software projects do not.
If a programmer wants to call themselves an engineer, I don't mind, and I understand how that means something different than electrical engineer or civil engineer. I have always found "programmer" sufficient to describe what I do.
I’ve always thought that “senior” has evolved to be a relatively, well, junior title because you don’t want to give it to anyone potentially perceived as old, which could be legally problematic or just awkward.
I think people understand that "senior" can have different meanings depending on the context. As an actual senior (over 60 years old) I don't take offense -- give me the senior discount! As part of a job title "Senior" doesn't mean anything, and probably never did, but it certainly never referred to age.
It seems the author has given their own meaning to Senior Engineer as a sort of weird gatekeeping, "you aren't a REAL senior engineer unless you're done X, Y, and Z"
My counterargument is that the very few job titles in Software Engineering was a bug, not a feature, and forced good engineers into management, as it was the only way to climb the career ladder.
By now creating more defined rungs on the latter, software engineers are able to climb a more reasonable career ladder with more than "junior engineer" and "forged in the crucible."
The author isn't wrong that "Senior" is probably a bit of an inflation for what it means in the industry - competent enough to work on medium to large projects with little oversight - but Staff, Senior Staff and Principal titles all exist to fill the gap the author is talking about, as does architect, although I don't see that one as often. It's definitely confusing if you aren't intimately familiar with the industry though.
For what it's worth, I can't think of any notable company where senior is anywhere close to the terminal level for a software engineer.
Over here it's mostly just the tech companies that do Staff+ titling.
The oher big organizations, home-grown agencies and similar, usually go from junior and medior to senior. Juniors aren't hired, because "what we do is too complex for them".
After senior you sometimes have an architect role, and sometimes even a senior architect, but that's about it for ICs. Architects are generally not expected to code, or even know how to code. It's more about landscapes of applications.
In practice, senior engineer is a terminal level, though I don't think these companies ever really made a considered choice regarding terminal levels. Up or out would run into problems with employment law very quickly after two years, so it's not a policy that will work well here.
People looking for raises can get them. There's a band for salaries and people can get a few percent raise for performance. Always too little of course. In general, once you reach the end of senior you can eiter do lead or management functions, or do the architect thing, or leave to be a rent-a-dev. Though employment law has recently made that last one harder, due to union pressure.
They never had any meaning to begin with. Outside of ostensibly knowing how to program, the title carried with it no firmly held, measured, or maintained any baseline expertise of any kind. It's always been a hodgepodge of ad hoc criteria on a job by job and hype cycle by hype cycle basis.
I've experienced this and I think it's due to skills matrix bingo. You're a junior engineer and to become a senior engineer all you need to do is make a line in the skills matrix. Write a test! Be nice to someone in a code review! Boom! BINGO! Senior engineer.
Of course it's good to know what you need to do to become a Senior. It used to be more wooly but at the same time even the best thought-out skills matrices don't capture what a Senior engineer really is.
Getting promotion used to be hard. Google engineers used to stay in E5 for many years and getting to E6 was considered a great achievement and many considered it impossible. Similarly, getting to L6 was a big deal, and getting to L7 was considered exceptional. As far as I know, it was Meta who broke this tradition. If an engineer had a large enough impact, the engineer would be promoted. So, it was not uncommon to see a engineer in Meta get promoted every year or two. Nowadays, it has become a norm for engineers to expect to get promoted every two years.
> Remember when being a “Senior Software Engineer” actually meant something? I do, and I can’t help but feel nostalgic for that clarity.
I am one and I do. Thankfully, the post provides a reasonable definition thusly:
> A true senior engineer is a battle-tested problem solver. They’ve faced and conquered complex technical challenges across multiple projects, dealing with more than just tricky bugs. These are the architects who’ve untangled system-wide issues that require deep understanding and creative solutions. They’re the ones who can navigate and refactor sprawling legacy codebases with confidence, understanding the delicate balance between maintaining existing systems and building new ones.
As the author explains above, being a senior engineer does not require a specific title. It is a mindset, an understanding reached not by years but by enlightenment.
A CIO to which I once reported shared with me a perspective that remains with me to this day:
> As the author explains above, being a senior engineer does not require a specific title. It is a mindset, an understanding reached not by years but by enlightenment.
And who is capable of recognizing enlightenment in a land where the blind lead the blind? This is an industry where novices who have been programming for 16 weeks sum total are elevated to the level of "senior engineer" for political reasons or for compensation and then, on the basis of this titling, are put on hiring committees and then considered qualified enough to judge the merits of another - who may have been a total weeb shut-in and already put in 30000 hours of obsessive programming but doesn't conform to the whitewashed, diluted, Big Bang Theory-esque cultural notions of what a geek is supposed to look like because they don't abide by Caucasian heteronormative standards of how geeks are supposed to take 30 second reels or themselves writing JavaScript in VSCode.
"Remember when being a “Senior Software Engineer” actually meant something? "
As a counterpoint I would argue it has never meant anything specific.
The term "engineer" is not at all well defined in software industry. Many other industries whose professionals use the title "engineer" fit a very specific box that is sometimes strictly controlled by law (depending on country).
If the title "engineer" is not well defined it's not very surprising any subsequent steps are less so.
Of course we hear opinions "as an engineer you should this and that" which how I also describe my role and responsibilities in discussions with non-technical stakeholders.
But it's not a specific title as humanity at large understands specific titles. See for example the strict demands on structural engineers. Or lawyers. Or doctors. Software industry has discussed should there be a fixed definition of an engineer and has not come up with one yet. Individual organizations have attempted to create more formal ladder systems of course but those are then particular only to the organization using them.
Job titles exist in the context of the business and don't mean a lot outside that context, and putting stock into it is not worthwhile.
I have worked at businesses where "senior engineer" was equivalent to a "staff engineer" and we had no juniors, so "engineer" was equivalent to being an senior anywhere else. I've also worked places where "VP of engineering" was basically a PM. Title inflation is a thing and big tech has kind of figured it out, somewhat with their own internal rankings that match salary bands and responsibilities.
What I've also seen is demand on HR or executives to reclassify roles as "senior" or "staff" from unknown companies because employees felt just being called "engineer" was harming their resumes and future prospects because it didn't reflect their work.
Point being, we put too much stock in these things. Ask people what they've done or what their role is and weight it accordingly. If you don't have enough knowledge about the hierarchy of roles in a business than you can't use the title as an indicator into what their role is, you actually have to talk to them about it.
I believe at one point, you could make it to Senior at Google and then never move up i.e it was considered ok to stay there. Staff/Senior Staff were somewhat rare, Principal was insane and anything beyond that meant you were special to the company. I've never worked at G so if someone is better aware of the history they can correct me .
Here in India, titles are so inflated it's not even funny. Anyone with 5+ years of experience is considered "Senior". After Senior, you go to "Tech Lead" meaning you're aiming for Manager, or directly to "Principal Engineer". To further differentiate, I believe some places have Principal Engineer 2 and beyond. Because India does leetcode on steroids, achieving these levels is mostly about grinding leetcode and having the adequate years of experience for the position.
I guess this is what happens in most industries. A hierarchy is set by management and people jump through hoops and make sure they're "on track" in their career.
The concept you are describing at Google is the "terminal level" for Software Engineers.
At Google, the vast majority of new college hires would begin as Software Engineers at Tech Level 3 (L3), where Tech Level 5 is "Senior Software Engineer." Level 6 is "Staff."
The terminal Level concept was one where all Software Engineers are expected to perform in an upward trajectory toward the standards of the next Tech Level, until reaching Tech Level 5. I.e. Software Engineers are expected to be promotable up to Level 5, and after reaching L5, there is no longer an "up or out" expectation. L5 SWEs are not expected to become Staff Engineers.
Today, the Terminal Level for Google SWEs is now Level 4.
The median Google SWE historically was around L4, and your average Google SWE would be a seasoned L4, potentially ready for a promotion to L5 in the next few promotion cycles.
The idea of a "principal" Software engineer is Level equivalent to a Director (Level 8) of which despite there being many at Google/Alphabet, as a percentage of the total population it is quite small.
This is similar to what we had, a few years before Google, at a serious software engineering company.
Technician I, Technician II, Engineer I, Engineer II, Sr. Engineer.
If you made it to Sr. Engineer, that was as high as most anyone could go. People at that point were focused on the work, not on ladder-climbing, AFAIK.
Though there were maybe a couple people who I knew were Principal Engineers. One was brought into the advanced R&D group at that level, as a rare domain expert and methodology expert, and would be key to whether the complex next-gen flagship product did what customers needed. (Incidentally, that person was also literally a Navy SEAL, which is another label obtained only rarely.)
Engineering titles have always had limited external meaning, but it's not an issue that needs to be "solved".
At a tech company I worked at, we started with no engineering titles (everyone was a SWE) but management eventually added them. My impression was this was due to (1) some candidate wanted a title in order to join the company and (2) executives wanted to quickly distinguish how respected + compensated someone was within the engineering org.
The reality is what one company/team values in terms of engineering skillset could completely differ from another. One company could be working the latest techniques in machine learning, while the other is working on web apps requiring database expertise.
Software engineering is far from a single linear skillset, so expecting titles to accurately reflect that doesn't make sense.
I'm coming up to my 40th anniversary in computing, started as a programmer on the original IBM PC.
There's no such thing as software "engineering" on the same basis as being a professionally licensed "engineer" in other disciplines. We don't have the history, we don't have the licensing infrastructure, we don't have the professional liabilities that require that licensing.
What's more, we don't have the industry history or the requirements "written in blood" that civil, mechanical, and other engineering disciplines have. We don't have the methodologies and analysis like structural engineering that can be evaluated and measured independently.
Programming is still an artisanal occupation, requiring an apprenticeship, "journeyman" and "master" type progression (apologies for the medieval type terminology).
Title inflation is all about compensation and comparison, nothing to do with experience and ability.
I've been through a handful of job changes in my career, and it seems that most of the time either my title goes up but my pay goes down, or vice versa:
* Software Engineer -> Founder: huge pay cut
* Founder -> Principal Engineer: Got a salary again
* Principal -> Advisory Engineer: 20% raise
* Advisory -> Senior: More than doubled my TC (but the job was stressful and the hours were terrible)
* Senior -> Staff: Cut my TC nearly in half (but much better WLB)
In general, I'll take the money over the title. But beyond a certain point, I'll take time with my family over the money.
As perhaps the penultimate example of the meaningless of (and idiosyncratic requirement of) titles, at one point in a BigCo job I had a business card printer in my office and would print cards with the title needed for a given meeting. I didn’t have an official title at all; just a “grade level” for establishing compensation.
Title inflation generally occurs when a profession becomes old, standardized, and uninteresting. See investment banking, etc, where the median title is a VP
Also sometimes a certain word just becomes more fashionable than those used previously, “analyst” is entirely generic title and gets used in every field and that previously had roles of clerk, associate, specialist, etc. which are mostly generic words themselves
> Companies that resist title inflation gain a significant competitive edge. By maintaining meaningful titles, they attract and retain top talent who value authentic growth over inflated roles. This leads to more accurate hiring, improved team dynamics, and enhanced productivity. Realistic titles also foster trust, both internally and with clients, positioning the company as a beacon of integrity in the industry. Ultimately, companies with well-defined, honest title structures build stronger, more capable teams and a reputation for excellence that sets them apart in the market.
This argument is more intuitive to me if I consider that these people who value authentic growth are looking for more than just a sensible title system.
So, nurture a variety of organizational qualities that appeal to people who want more than just a paycheck and job-hopping, and one of the many things you do in the process is to set a sensible title system.
These days I equate senior titles with more mid level. You've seen some shit but could use a bit more time in the oven so to speak. I see Staff Engineer and Engineering Lead used for what I would consider a senior role 7 or 8 years back. I fully expect those will become meaningless as well and we'll move on to something else.
In my first job there were two 'Senior Engineers' and a 'Chief Software Engineer' when I started.
None were over 25. This was over 20 years ago. FWIW one of them was, to this day, the best coder I've ever worked with. I think he's a diving instructor these days.
It's been largely meaningless for at least two decades.
I believe that Eng. Manager and HR are mostly at fault for it, confusing seniority and familiarity as creating and giving higher title to keep people without doing the requirement part of the job: accessing the title, drawing a ladder linked to a skills matrix.
I've been a Senior Software Developer or, if I had to be, Senior Software Engineer for a long time, but these days when a form asks for my title I put in either Senior Dogsbody or Executive Megafauna depending on my mood.
It has no meaning whatsoever, the payment stuff is just making sure management is able to control you. We have many companies renting out people here and you always get "seniors" who do not even qualify as juniors. Always in full suit to compensate for lack of any knowledge.
I always have doubt on this, who is developer and who is engineer?
I think,
Who are capable to using existing languages, frameworks are developers.
Engineers are the one who can design & create those frameworks, can understand algorithms and techniques / working principle. A engineer can reinvent the wheel (worst or better engineering from existing one makes good or bad engineer)
The term `Senior` always refer the working experience on the field more than 1 time. Not necessarily the years.
Programmer, developer, software engineer, etc. get used interchangeably, they don't indicate any real distinction except maybe within a single organization. Similarly "senior" doesn't mean anything other than "I got promoted."
In the last decade "architect" started to show up as a euphemism for what we used to call "analyst," someone who gathers, makes sense of, and translates business requirements into software development plans. But I have seen relatively junior programmers call themselves "architect," I suppose because it sounds cool. For me an architect designs buildings.
One of my friends decided to change his job title from "technical project manager" to "solutions architect" for the sole purpose of sales. He and the boss agreed that it sounded more impressive to the clients we were going after.
Exact same day-to-day work. Exact same responsibilities and pay. Everyone within the company agreed that it was a complete joke. And yet, we still did it.
You see that kind of thing a lot with contract programming firms -- they give all of their programmers fancy titles because it makes them look better to potential clients: "We only have senior software engineers available to work on your project, we don't hire junior people." In that environment the customer probably won't individually vet whomever gets put on their project.
I have had recruiters tell me to use more impressive titles too.
I worked with a very popular and senior journalist in India and after decades of experience he was, well, a Senior Journalist. I was, at about 3 years of experience then, a Senior Software Engineer. It felt so funny for me at that time.
I used to think that I wouldn't mind working a company where "everyone" was Member of Technical Staff (a la Bell Labs).
Then I noticed that the people who decided that everyone would have egalitarian titles... still had grandiose titles for themselves.
So, the next time I'm discussing what engineering title system a startup should have as it grows, I'm probably going to suggest something that the early hires will be happy to have on their LinkedIn, and I'd guess that will probably look fairly conventional.
(Also, Google could get away with downleveling people only because they paid a lot better, and everyone knew it. So, unless you're paying like Google, good luck telling hiring candidates that you think they were overrated in their most recent role, and you want to put them in their proper, lower place.)
Also consider that a lot of “senior” level problems have been automated away or even solved (js framework for everything) over the years. This has happened to a lot more than job titles, just look at the red-tape-yaml hell of devops. This will continue with the push of LLMss. Jobs have changed, somewhat for the worse. As the barrier for entry lowers, so does the expected responsibility.
If everyone wants to develop on the same damn stack because you’re too bored of teaching and training then don’t expect anything senior level to exist.
> Remember when being a “Senior Software Engineer” actually meant something?
Nope.
I'm only 35, but within my career I saw "developers" become "engineers" because that's what Facebook and Google were doing.
Titles never meant anything. Today, they're a class-like system for labeling pay in large organizations.
You can't address title inflation. Years ago, I interviewed at Subway for the position of "sandwich artist." I thought it was cute, but the person who interviewed me seemed to take the title quite seriously.
If you get hired as a Principal Wizard Non-Commissioned Bit Slayer, good for you. The title will be used to justify your pay to coworkers and future employers. Maybe you're a wizard bit slayer, and maybe you're not.
I find these articles go a bit too far in their rhetoric. This one alleges that the most important factor is that "senior engineers remain humble and curious".
Really? Is that what you're looking for in a job interview? You're going to knock back an otherwise exceptional candidate with twenty years of domain-specific experience for only having 50th percentile humbleness?
My take is that the difference between junior / mid / senior / principle / CTO is the following question:
At what scope are you taking responsibility?
A junior can take responsibility to take a completely described specification and turn it into code. Eg, "We need a button on the page which looks like this: (mockup). When clicked, it should do this."
A senior can take responsibility for broader / more ambiguous problems. For example: "We're getting sporadic reports from users that they can't fill in this web form. But we can't reproduce it - every time we ask them to show us, everything works." / "The website just feels slow". Or: "The web server crashed again last night! That's the third time this month. How do we make this problem go away?"
As you keep "going up", the solutions increasingly involve subtle judgement (of the team and the customers) and interacting with other people. "Hey Jenny - I've been looking into a reported bug. I talked to a couple of our users about it. Part of the problem is this particular UX flow. I think it needs another pass. How full is your plate?" / "Ideally we'd scale up the team. Our biggest bottleneck is frontend iOS development. Lets hire 2 more devs. I'll talk to a couple recruiters and get the process started."
With this sort of perspective in mind, it gets much easier to judge the seniority of someone. Forget their job title, past or present. The author is right: Thats more signal than noise these days. In an interview, ask them to tell the story of some problems they've faced in their last role. Press for details on how the issue was communicated to them, and what was difficult / rewarding. Juniors will talk about tickets they closed, or tell you a story about a failing test case they were assigned by their lead that they fixed. Seniors will talk about something ambiguous and long running, or how they speced out a problem. Or about a long running issue they found & fixed off their own initiative. CTO level people will talk about hiring, or one time they corrected something that was going wrong in the team's culture.
Its pretty clear. Was it a more ambiguous problem? Was the scope broad? Did they take the initiative themselves? Did solving it involve judgement in a broad range of areas (eg technical, social, UX, etc)? All of those things demonstrate that the person is acting at a more senior level.
I use the same approach when coaching people at work. Lots of people are capable of operating at a higher level, they just need the right set of challenges and often the right push to take initiative and start stretching themselves. (And plenty of people, sadly, are the opposite.)
We've had this discussion many times before and the consensus was always the same: that at small companies / startups they use titles as a way to make people accept low-ball offers. Where the titles there are mostly meaningless. But at larger companies the titles actually do have meaning because the denote responsibility and pay scale.
Eh whatever. I'm a senior engineer by actual job (solo dev everything for a large org), but have a mishmash of actual experience, so I just call myself a developer because it's accurate.
I never adopted "developer" as a title because people who organize construction projects use that title. I never use "engineer" because real engineers have engineering degrees and have to pass standardized tests. "Programmer" best describes what I do, usually I add system admin if I think that will come up.
Not knocking programmers who prefer "developer" or "engineer," makes no difference to me what title someone uses. Either they have the necessary skills and experience or they don't, and if they don't a fancy or inflated title won't help them.
They all just write code, imho - software guys are considered very low status and have no pull compared to other professions like doctor, lawyers - i never seen a woman being excited about a programmer haha.
There was never a time in human history when Senior Software Engineer had a consistent definition. It’s fine to write a nostalgia piece about your past experiences, but this blog post doesn’t go very far beyond that.
And from his bio: "I've been coding professionally since 2014", that wasn't that long ago, I started around the same time and senior was definitely just as meaningless.
Claiming that companies which resist title inflation has a competitive edge is like claiming schools which resist grade inflation have a competitive edge. Maybe if they are competing on who is the most irrelevant...
I can't help but notice the irony in pointing out that Software Engineering titles have lost their meaning without addressing the fact that it may be one of the largest misuses of the title "Engineer" (legally protected in many countries as requiring a professional engineering license by an accredited engineering body) that is in common use today.
If the author went a little bit deeper they might be able to make the same arguments about how the title "Engineer" has lost a lot of meaning in the public due to the cavalier attitude with which many organizations throw it around.
In the US there's no such protection and it's actually a good thing.
We have the formal designation of "professional engineer" (PE) but outside of civil and mechanical engineering (and some government work) it's not that meaningful. You have to complete a 4-year degree at an accredited institution, pass some licensing tests, and then apprentice under a licensed PE for four more years before you can earn a PE license.
In some states you can't legally call yourself an "engineer" without your PE license but I have never seen it enforced. I live in one such state, I'm not a PE, I call myself an engineer, I've worked with engineers for years, and even the entry level jobs in this state the title is "engineer." No one cares about it and not many people see it as worth much, unless they're doing engineering work for local governments in which case it's required.
Not surprisingly, it just makes that work more expensive for everyone involved.
Creating barriers to entry that benefit existing players in the market are not good if they don't add value. For certain projects where there is legal liability (like building a bridge, and some human needs to certify it's "good" and if they're wrong, people die), that makes sense. For everyone else it just adds overhead that doesn't need to be there.
And given that the US has led the world in engineering for the back half of the 20th century, the attitude that there must be some professional licensing body to tell us who is and is not an engineer is nothing if not smug and elitist. Some of the best software is built by people who would never have become PEs, and the entire establishment is contrary to innovation.
> like building a bridge, and some human needs to certify it's "good" and if they're wrong, people die
Even in things like civil engineering jobs, not all of the work is done by the PE, they just need to review it as if it was their own work. Some tech industries taking over critical parts of life could use oversight like that.
It is practically impossible to get a PE in the defense industry because of the apprenticeship/vouching requirements. If your employer has no PEs, you can't ever qualify for one.
That, but more to the point, the value of the term is based on the strong history of regulation and common use, which SWEs as an industry have taken advantage of and diminished.
Which, I get that not everyone agrees on licensing law and philosophy, but it should at least signify mastery of the topic via formal education or apprenticeship.
Most PEs have both of those, engineering degree and licensing internship.
How many SWEs have either? I honestly don't know.
If you don't have either, you are at best senior technician, which should be respectable enough, but for title inflation.
Mastery of what topic? What I consider important for my work in safety critical systems is probably very different from whatever you use in your presumably different field. Both of those are different again from e.g. GameDev, HPC, or operating systems and all of them encompass domain knowledge not adequately captured by existing degree programs. How would a useful certification be realized, as opposed to mere credentialism?
I strongly disagree that SWEs have "taken advantage of and diminished" anything. The practice of ignoring PE licensure extends well beyond software and was well established as nonsense before the dotcom boom.
> How many SWEs have either? I honestly don't know.
Almost all of them, in practice.
> If you don't have either, you are at best senior technician, which should be respectable enough, but for title inflation.
Engineering as a discipline is much older and nuanced than PE licensing bodies. If you are applying the science and practice of problem analysis and design synthesis you are an engineer.
The ones that matter, do this. In many states if you are building anything for a government or business where lives are at stake, a PE is involved and there's legal liability for the engineers that certify something.
But the whole PE thing is nonsense. We can get around this with malpractice policies/insurance and still have a qualified human certifying things, and reasonable bodies rejecting that certification if they don't feel the human that does it is up to snuff. The whole PE dance is just a dog and pony show.
Maybe we should be concerned about more than just direct loss of life? What about data leaks, for example? It might be nice if there were some risk that software engineers could lose their license over eg. plaintext passwords, or be protected by a governing body if they need to take a professional ethics stand against their employer.
>unless they're doing engineering work for local governments in which case it's required.
In those states, the local governments should be required to only use software from vendors where all the "software engineers" (i.e. every employee that uses that title) in that company actually have PE licenses, including Microsoft.
This is because the US does not require this, and the US arguably lead the charge in internet innovation, standards, and commercialization and continues to be the highest paying country for SWE roles. Thus, most discussion is US focused.
In other countries like Canada, the title is just s/Engineer/Developer.
To add, the author is talking about the levels no longer indicating experience due to level inflation. Not word semantics along the lines of “senior no longer means the oldest on their team”.
Titles don't intrinsically mean anything. They cost nothing to assign, and have no requirements.
So the only people complaining about titles being inflated are those to whom they have "meaning". And the only reason they're being inflated in the first place is because the same folk want "better sounding titles".
They're given out like candy to those who want candy.
They do mean something on your resume and as social capital. I wouldn’t sell short the actual intrinsic value of having a big title even if it’s fake you can sell it to the next employer. Even if they disagree with giving you the same title, you can use it to justify your comp expectations.
I'm sure there are people, and companies, impressed by fancy titles.
Personally, I go the other way. I don't have a fancy title, and I don't want a fancy title. I don't need a title to earn social credit or impress an interviewer. I have my achievements for that.
But of course, to those who are impressed by titles feel free to call yourself anything you like. There are no qualifications or skillsets required.
My gym instructor describes my pudgy, bald, middle-aged body as "stud".
I think I'm gonna update my resume, and linked-in profile to "Stud". I expect that will help in the next interview.
You’re disconnected from reality. You say titles cost nothing. You really don’t think it costs companies money to progress employees from engineer to senior to staff and so on?
You seem to agree title inflation is common and you say fancy titles are given out like candy. If everyone easily gets promotions, what does that say about someone who’s not given such easy candy?
If you work at a company that has a bunch of pay levels, and levels are tied to titles then sure I guess you see titles as "meaningful". (Personally I think the pay part us the meaningful part, but hey, whatever floats your boat.) I'm not sure your title has any meaning beyond your company though.
Where I work, pay is based on skills, experience, quality and value of work produced. I can call myself "programming super-god" if I like but that has no effect on my pay. Some companies just have pay levels and you're an L5 or whatever.
What would you consider a good set of formal qualifications?
Degrees that the people who wrote software you regard well probably didn't have, and people writing software you dislike do? Quickly outdated written tests? Years of experience when a common refrain is 1 year of experience x times?
I work with safety critical systems. I still haven't found a better way to evaluate people than having a conversation because none of the overt metrics have correlated well with my "won't get people killed" rating.
Good question. I think a big part of physical engineers' credential comes down to liability, which ultimately leads to civil engineering firms hiring contientious and responsible engineers. It's a internal feedback loop that the software industry tends to lack.
I'm not advocating for senseless beaurocratic hurdles, but you have to admit that standards for software have fallen as more people have entered the industry.
I don't agree that modern developers are less capable. If I had to choose between software developed to the best practices in 1995 and the same software developed to modern best practices, I'd pick the modern software in a heartbeat. What's changed is our relationship with software. Old school software did fewer, simpler things. The tools available limited what could even be realized and expectations for the end result were fundamentally different than we have today because they had to be.
I get it, this is hacker news after all, but it really could be worthwhile for the profession to differentiate between someone who picked up Python for a weekend project, and someone with 30 years experience with real-world systems.
Would you get surgery from someone in a back alley? Is that credentialist crap?
The first surgeon had no credentials and no “relevant experience.” And that surgeon probably didn’t do a great job at first.
This industry is still within memory of the first digital computers. Now we have lots of rote work, some interesting and novel areas, and a small sliver of wacky innovation. But I think many here cherish that self-image of the self-taught inventor… this is “hacker” news after all. I for one am not ready to give someone undue credibility because of a title or piece of paper.
Because unlike in most actual engineering disciplines software developers generally aren't held particularly liable for the failures that their bad engineering causes, whereas people who build faulty bridges or airplanes don't have that luxury.
Software has built a lot of modern toys but it still plays a relatively limited role in the world of atoms rather than bits, but I suspect the value of credentials is going to appreciate as that changes over the next few decades.
I don't think the irony is in regard to certification, but rather that any software engineer cannot implement any sufficiently complex system in any standard, methodical or predictable way.
Hillel Wayne's crossover project [0] is a great read for anyone interested in the question of whether we're really engineers. The tl;dr is that most engineers he interviewed who switch from a licensed engineering discipline to software totally consider software engineering to be just as much an engineering discipline as what they did before, and there are a lot of neat ideas he develops for ways we can learn from each other.
Another great resource I've found is Practical Engineering. Listening to his videos it's easy to see how much overlap there is between our ways of thinking and interacting with the world.
As for the legal side, as others have noted in most of the US "engineer" in the abstract isn't legally protected. So there's no legal problem with using the title, and engineers who've done both don't consider our practices to be somehow lesser.
If we go far back to Latin, the original meaning of "doctor" is, in fact, an education professional and has absolutely nothing to do with medicine. In classical Latin, "doctor" is a teacher or a trainer.
In Medieval Latin u
In (Middle) English, the earliest recorded use of "doctor" was for church fathers in 1303, but you'd find it widely used for teachers and any knowledgeable person - including medical doctors - as the 13th century goes on.
The codification of the Doctor of Medicine degree and license seems only started in the 18th century[1], but doctors of theology and law far predated that (somewhere in the 12th century I think). Even the PhD (i.e. doctor of philosophy) degree appears to predate the medical doctor degree by half a century.
Originally they were all academic titles: Doctor of Law, Theology, Medicine & Arts.
At some point an expectation developed that practitioners of medicine actually had some formal qualifications and eventually to most people Doctor became synonymous with Physician.
I blame this lack of meaning on the overpaid Memetics Engineers who have added the word to just about every possible discipline in a vain attempt to make those disciplines seem important and dignified.
One of the most important roles that titles play in the tech industry (at least the US-centric tech industry) is to help evaluate compensation.
Companies subscribe to reports which provide "salary band" compensation data across the industry. When it's time to consider raises, management with access to those reports can then see if their pay is more-or-less in line with other similar companies.
This means titles like "Senior Engineer", "Staff Engineer" etc do actually have very meaningful purposes - they can be used to attempt to map together different levels at different companies in order to determine if you are being under- or over-paid for the role you are in.
If you've never held a management position that includes decisions around compensation increases you are likely unaware of quite how much thought and effort goes into this process.
Don't get me wrong: it sucks, and it's still mainly a bunch of tea-leaf reading (with serious real-world consequences for employees) - but it's important to understand this any time you're wondering why titles work the way they do.
> One of the most important roles that titles play in the tech industry (at least the US-centric tech industry) is to help evaluate compensation.
I think there are some hints left by management and HR. We often hear excuses around appraisal like:
"we want to give you a hike, but your current job title doesn't allow us to pay beyond xyz and we don't have budget for a promotion".
I guess there's an element of truth in it sometimes (often these are excuses) because your title may limit your hike but it doesn't stop your manager from assigning and expecting you to take on work above your pay grade.
I would call out that BS excuse. They could pay you whatever they want for your title, the only thing stopping them is an arbitrary policy.
Yeah I've heard that exact phrase. I was told I was already at the top of the band for my title (Senior Engineer haha) and not eligible for the annual salary increase. Then six months later laid off.
> If you've never held a management position that includes decisions around compensation increases
In large organisations, yes.
In smaller organisations and startups, the "salary bands" are less fixed and there's more freedom to just pay people what you think they're worth. Consequently the title means less and in a lot of cases a small business really doesn't care what its staff call themselves. Titles can get inflated easily here too [0].
[0] Anecdote: a friend of mine attended a bootcamp, got a job with a small (<20 headcount) business, got up to Senior Developer title within 2 years because the business didn't care. Then transferred to a large org at a suitable Senior pay scale.
One way to get out of this is to have a title wildly out of range relative to your compensation.
If you're title is "engineer" and you're overseeing a technical team and participate in the architectural decision for your company, anyone dealing with your salary (including when moving jobs) will need to actually look at your job instead of just the title.
In the same vein I had a coworker request "staff” as title and we were small enough that it didn't matter.
Worth mentioning that staying in line with other companies is critical for company sponsored immigration in the US. If an individual is paid too differently from their title at other companies, their visa might be denied for being unfair to citizens looking for similar positions. It could be similarly unfair if they're paid differently from citizens with the same title within your company. Hence everyone at your company needs salaries that align with industry titles, or you risk not being able to get visas for international employees.
This is exactly it. This is why often people will have titles change along with increases in compensation even though there may not be any change whatsoever in job description or responsibilities.
I worked for a company where what you said was entirely true - for all offices except the one in Gurgaon.
Those guys had some ridiculous job titles.
I don't think this article describes a new thing. I got my first real job as a Programmer/Analyst (that was the entry-level title) back in 1979, at Nike. In less than two years I got promoted to Senior Programmer/Analyst. I clearly didn't count as "senior" in the industry at large, but within the logistics/inventory group at Nike I had significant seniority. Like at a lot of companies titles corresponded to pay ranges, so a raise came with a new title.
Back then Nike laid out their business cards vertically. When I got my new cards the title read "Senior Prog/Anal," a title I still cherish. My manager noticed and had the cards reprinted with the title on two lines.
I got a Senior title at my next job, and by 23 I got named Manager and reported to the CTO at a mid-size logistics company. All of the programmers there got Senior in their title. I have worked with people all through my career who had inflated and meaningless titles.
At some point in my career I realized titles don't communicate anything meaningful. I started using Programmer. Even now with 40+ years experience I use Programmer if I have to give a title. That at least describes what I do most of the time.
I have never willingly called myself an "engineer," though I have worked at places that called all of their programmers "engineers." That seems like stolen valor to me, I didn't get an engineering degree and I don't think of programming as an engineering discipline.
Every company has its own hierarchy of titles, but those don't correspond to other companies. I got asked in an interview once why I hadn't made it to senior after so many years in the business, I just laughed and said I made senior at 21 after two years working, and didn't think titles said much -- my actual experience speaks for itself.
I doubt this was ever a thing at all. I think the author falls to the common nostalgia trap of an imagined "perfect" past that has degraded somehow. It's a trap all human beings easily fall into, so I wouldn't blame him, but I fail to remember any such period from my career or older historical accounts that titles were reliably and consistently meaningful across the industry.
The moment you've got more than a handful of companies doing software, each company will do its own thing with the titles it gives — and there are few incentives (if any) to heavily gatekeep titles with a complex and hard-to-implement certification process. And if a company does end up implementing some sort of certification anyway, it would be specific for that particular company and not something that's relevant for the entire industry.
I would even argue that's not just the case for software, but for any industry that is not regulated by the state or by a mandatory certifying body such as law, accounting and medicine — and even in those industries, the standardized certificates you get are generally limited to a fairly entry level.
The only imagined past where career progression was strongly regulated that I can think of is European Professional guilds in the late Middle Ages through the Early Modern period, where you'd often apprentice for 7 years or so before attaining the title of Journeyman, and then you would have to wait anything between 10 to 20 years to never (the most common result) before you obtain the necessary funds and approval to become a master and practice on your own. I'm not sure there is any point going back to THAT system.
The guild system lives on in a way in the skilled trades. An electrician or plumber goes through specific career stages. My son apprenticed learning how to make beer. It also lives on in the military. I think programming would benefit from an apprenticeship stage -- I had great mentors assigned to me early in my career but that seems to have gone away.
The meritocratic nature of programming attracted me to it (as a young nerd with an incomplete degree in military history). If you could do the work you got paid and promoted, and companies would put in the effort to train and mentor juniors back in the day (or maybe I got lucky and feel nostalgic for an imaginary past). I saw the credential craze come and then mostly fade away (I got Oracle, Novell, and DEC certifications). Now I see companies insisting on CS degrees.
My early programming heroes didn't seem to use titles -- Dennis Ritchie, Ken Thompson, Brian Kernighan. I suppose Bell Labs gave them titles but when I read their papers they just used their names. Rob Pike calls himself a programmer -- when he presented Go at OSCON a long time ago he introduced himself as a "programmer at Google." Maybe a humblebrag, but if you can walk the walk you don't need to show off with a fancy title. I think we shouldn't get hung up on titles, or use them to gatekeep or judge.
Yup. I worked 3 years and 10 months (yes I just checked) before I was first hired as a "Senior Software Engineer", by a very normal desktop publishing development company, in 2007. Not via LinkedIn, nobody I knew was on it back then.
I wasn't expected to be some "visionary architect" (lol), just competent enough to get the job done without hand holding. Which (spoiler alert!) I was able to do, had a good run at that company and then for the next 17 odd years I've stayed a "senior engineer" at many other companies.
When I've been in hiring we've always based seniority on how we evaluated their skills and experience, not how long they've worked in the job.
In Australia the term "engineer" wasn't really used for software until relatively recently. I've been in tech for almost 30 years and have been a sys admin, network admin, db admin, developer, manager, product lead, consultant etc. I have experience in many languages, platforms and technologies and have worn many hats.
I now just call myself a developer. But I also only program for fun these days.
> That seems like stolen valor to me, I didn't get an engineering degree and I don't think of programming as an engineering discipline.
I don't think of software as solely an engineering discipline either, but domains within it are certainly "engineering"-ish. I work all day with "proper" engineers doing an essentially similar job. If we call it something else, that implies the terms aren't identical. If they're not identical, what semantic differences are being conveyed, since both sets of titles refer to jobs sharing the same ultimate responsibilities for the results? When does this become a stolen valor situation?
Engineers get degrees in engineering, have to pass tests to work in their field, and get required ongoing education to stay current. Not every engineer but in general the title "engineer" connotes a minimum amount of education, credentials, exams, etc. that don't exist in the programming world.
I think of engineering disciplines as fields that have documented knowledge and processes that lead to predictable and repeatable results. In my experience programming defies accurate (or even useful) prediction, and we fail to replicate success reliably. I agree that programming has some engineering-ish aspects, some things we understand better than others, but we mostly fall down as a field producing predictable software.
I think those "failures" come from the nature of programming as an idiosyncratic craft, a field too big with too many specializations to master in a lifetime, and a constantly-changing landscape of hardware, languages, tools, frameworks, and so on. And programmers very often work with vague, incomplete, and shifting requirements -- something engineers have better processes for. A bridge or a building or a road gets planned out to a level of detail that similarly large software projects do not.
If a programmer wants to call themselves an engineer, I don't mind, and I understand how that means something different than electrical engineer or civil engineer. I have always found "programmer" sufficient to describe what I do.
I’ve always thought that “senior” has evolved to be a relatively, well, junior title because you don’t want to give it to anyone potentially perceived as old, which could be legally problematic or just awkward.
I think people understand that "senior" can have different meanings depending on the context. As an actual senior (over 60 years old) I don't take offense -- give me the senior discount! As part of a job title "Senior" doesn't mean anything, and probably never did, but it certainly never referred to age.
It seems the author has given their own meaning to Senior Engineer as a sort of weird gatekeeping, "you aren't a REAL senior engineer unless you're done X, Y, and Z"
My counterargument is that the very few job titles in Software Engineering was a bug, not a feature, and forced good engineers into management, as it was the only way to climb the career ladder.
By now creating more defined rungs on the latter, software engineers are able to climb a more reasonable career ladder with more than "junior engineer" and "forged in the crucible."
There were 3 stages to this.
1. There is no IC progression, so engineers go into management for promotion.
2. There is IC progression, with roughly standardized expectations/naming at the various levels.
3. The standard levels were then exploited by companies to under-pay employees, by over-titling them (title in lieu of compensation).
This piece is about the final/current abuse of title stage.
The author isn't wrong that "Senior" is probably a bit of an inflation for what it means in the industry - competent enough to work on medium to large projects with little oversight - but Staff, Senior Staff and Principal titles all exist to fill the gap the author is talking about, as does architect, although I don't see that one as often. It's definitely confusing if you aren't intimately familiar with the industry though.
For what it's worth, I can't think of any notable company where senior is anywhere close to the terminal level for a software engineer.
Over here it's mostly just the tech companies that do Staff+ titling.
The oher big organizations, home-grown agencies and similar, usually go from junior and medior to senior. Juniors aren't hired, because "what we do is too complex for them".
After senior you sometimes have an architect role, and sometimes even a senior architect, but that's about it for ICs. Architects are generally not expected to code, or even know how to code. It's more about landscapes of applications.
In practice, senior engineer is a terminal level, though I don't think these companies ever really made a considered choice regarding terminal levels. Up or out would run into problems with employment law very quickly after two years, so it's not a policy that will work well here.
People looking for raises can get them. There's a band for salaries and people can get a few percent raise for performance. Always too little of course. In general, once you reach the end of senior you can eiter do lead or management functions, or do the architect thing, or leave to be a rent-a-dev. Though employment law has recently made that last one harder, due to union pressure.
They never had any meaning to begin with. Outside of ostensibly knowing how to program, the title carried with it no firmly held, measured, or maintained any baseline expertise of any kind. It's always been a hodgepodge of ad hoc criteria on a job by job and hype cycle by hype cycle basis.
I've experienced this and I think it's due to skills matrix bingo. You're a junior engineer and to become a senior engineer all you need to do is make a line in the skills matrix. Write a test! Be nice to someone in a code review! Boom! BINGO! Senior engineer.
Of course it's good to know what you need to do to become a Senior. It used to be more wooly but at the same time even the best thought-out skills matrices don't capture what a Senior engineer really is.
Getting promotion used to be hard. Google engineers used to stay in E5 for many years and getting to E6 was considered a great achievement and many considered it impossible. Similarly, getting to L6 was a big deal, and getting to L7 was considered exceptional. As far as I know, it was Meta who broke this tradition. If an engineer had a large enough impact, the engineer would be promoted. So, it was not uncommon to see a engineer in Meta get promoted every year or two. Nowadays, it has become a norm for engineers to expect to get promoted every two years.
> Remember when being a “Senior Software Engineer” actually meant something? I do, and I can’t help but feel nostalgic for that clarity.
I am one and I do. Thankfully, the post provides a reasonable definition thusly:
> A true senior engineer is a battle-tested problem solver. They’ve faced and conquered complex technical challenges across multiple projects, dealing with more than just tricky bugs. These are the architects who’ve untangled system-wide issues that require deep understanding and creative solutions. They’re the ones who can navigate and refactor sprawling legacy codebases with confidence, understanding the delicate balance between maintaining existing systems and building new ones.
As the author explains above, being a senior engineer does not require a specific title. It is a mindset, an understanding reached not by years but by enlightenment.
A CIO to which I once reported shared with me a perspective that remains with me to this day:
> As the author explains above, being a senior engineer does not require a specific title. It is a mindset, an understanding reached not by years but by enlightenment.
And who is capable of recognizing enlightenment in a land where the blind lead the blind? This is an industry where novices who have been programming for 16 weeks sum total are elevated to the level of "senior engineer" for political reasons or for compensation and then, on the basis of this titling, are put on hiring committees and then considered qualified enough to judge the merits of another - who may have been a total weeb shut-in and already put in 30000 hours of obsessive programming but doesn't conform to the whitewashed, diluted, Big Bang Theory-esque cultural notions of what a geek is supposed to look like because they don't abide by Caucasian heteronormative standards of how geeks are supposed to take 30 second reels or themselves writing JavaScript in VSCode.
"Remember when being a “Senior Software Engineer” actually meant something? "
As a counterpoint I would argue it has never meant anything specific.
The term "engineer" is not at all well defined in software industry. Many other industries whose professionals use the title "engineer" fit a very specific box that is sometimes strictly controlled by law (depending on country).
If the title "engineer" is not well defined it's not very surprising any subsequent steps are less so.
Of course we hear opinions "as an engineer you should this and that" which how I also describe my role and responsibilities in discussions with non-technical stakeholders.
But it's not a specific title as humanity at large understands specific titles. See for example the strict demands on structural engineers. Or lawyers. Or doctors. Software industry has discussed should there be a fixed definition of an engineer and has not come up with one yet. Individual organizations have attempted to create more formal ladder systems of course but those are then particular only to the organization using them.
Job titles exist in the context of the business and don't mean a lot outside that context, and putting stock into it is not worthwhile.
I have worked at businesses where "senior engineer" was equivalent to a "staff engineer" and we had no juniors, so "engineer" was equivalent to being an senior anywhere else. I've also worked places where "VP of engineering" was basically a PM. Title inflation is a thing and big tech has kind of figured it out, somewhat with their own internal rankings that match salary bands and responsibilities.
What I've also seen is demand on HR or executives to reclassify roles as "senior" or "staff" from unknown companies because employees felt just being called "engineer" was harming their resumes and future prospects because it didn't reflect their work.
Point being, we put too much stock in these things. Ask people what they've done or what their role is and weight it accordingly. If you don't have enough knowledge about the hierarchy of roles in a business than you can't use the title as an indicator into what their role is, you actually have to talk to them about it.
I believe at one point, you could make it to Senior at Google and then never move up i.e it was considered ok to stay there. Staff/Senior Staff were somewhat rare, Principal was insane and anything beyond that meant you were special to the company. I've never worked at G so if someone is better aware of the history they can correct me .
Here in India, titles are so inflated it's not even funny. Anyone with 5+ years of experience is considered "Senior". After Senior, you go to "Tech Lead" meaning you're aiming for Manager, or directly to "Principal Engineer". To further differentiate, I believe some places have Principal Engineer 2 and beyond. Because India does leetcode on steroids, achieving these levels is mostly about grinding leetcode and having the adequate years of experience for the position.
I guess this is what happens in most industries. A hierarchy is set by management and people jump through hoops and make sure they're "on track" in their career.
The concept you are describing at Google is the "terminal level" for Software Engineers.
At Google, the vast majority of new college hires would begin as Software Engineers at Tech Level 3 (L3), where Tech Level 5 is "Senior Software Engineer." Level 6 is "Staff."
The terminal Level concept was one where all Software Engineers are expected to perform in an upward trajectory toward the standards of the next Tech Level, until reaching Tech Level 5. I.e. Software Engineers are expected to be promotable up to Level 5, and after reaching L5, there is no longer an "up or out" expectation. L5 SWEs are not expected to become Staff Engineers.
Today, the Terminal Level for Google SWEs is now Level 4.
The median Google SWE historically was around L4, and your average Google SWE would be a seasoned L4, potentially ready for a promotion to L5 in the next few promotion cycles.
The idea of a "principal" Software engineer is Level equivalent to a Director (Level 8) of which despite there being many at Google/Alphabet, as a percentage of the total population it is quite small.
This is similar to what we had, a few years before Google, at a serious software engineering company.
Technician I, Technician II, Engineer I, Engineer II, Sr. Engineer.
If you made it to Sr. Engineer, that was as high as most anyone could go. People at that point were focused on the work, not on ladder-climbing, AFAIK.
Though there were maybe a couple people who I knew were Principal Engineers. One was brought into the advanced R&D group at that level, as a rare domain expert and methodology expert, and would be key to whether the complex next-gen flagship product did what customers needed. (Incidentally, that person was also literally a Navy SEAL, which is another label obtained only rarely.)
Engineering titles have always had limited external meaning, but it's not an issue that needs to be "solved".
At a tech company I worked at, we started with no engineering titles (everyone was a SWE) but management eventually added them. My impression was this was due to (1) some candidate wanted a title in order to join the company and (2) executives wanted to quickly distinguish how respected + compensated someone was within the engineering org.
The reality is what one company/team values in terms of engineering skillset could completely differ from another. One company could be working the latest techniques in machine learning, while the other is working on web apps requiring database expertise.
Software engineering is far from a single linear skillset, so expecting titles to accurately reflect that doesn't make sense.
I'm coming up to my 40th anniversary in computing, started as a programmer on the original IBM PC.
There's no such thing as software "engineering" on the same basis as being a professionally licensed "engineer" in other disciplines. We don't have the history, we don't have the licensing infrastructure, we don't have the professional liabilities that require that licensing.
What's more, we don't have the industry history or the requirements "written in blood" that civil, mechanical, and other engineering disciplines have. We don't have the methodologies and analysis like structural engineering that can be evaluated and measured independently.
Programming is still an artisanal occupation, requiring an apprenticeship, "journeyman" and "master" type progression (apologies for the medieval type terminology).
Title inflation is all about compensation and comparison, nothing to do with experience and ability.
At Apple, back in the 80s anyway, you could put anything you wanted on your business card except President or CEO.
One of my cow-orkers had "Dread Pirate Roberts (retired)"
I've been through a handful of job changes in my career, and it seems that most of the time either my title goes up but my pay goes down, or vice versa:
* Software Engineer -> Founder: huge pay cut
* Founder -> Principal Engineer: Got a salary again
* Principal -> Advisory Engineer: 20% raise
* Advisory -> Senior: More than doubled my TC (but the job was stressful and the hours were terrible)
* Senior -> Staff: Cut my TC nearly in half (but much better WLB)
In general, I'll take the money over the title. But beyond a certain point, I'll take time with my family over the money.
As perhaps the penultimate example of the meaningless of (and idiosyncratic requirement of) titles, at one point in a BigCo job I had a business card printer in my office and would print cards with the title needed for a given meeting. I didn’t have an official title at all; just a “grade level” for establishing compensation.
Title inflation generally occurs when a profession becomes old, standardized, and uninteresting. See investment banking, etc, where the median title is a VP
Our "Director of First Impressions" (receptionist) would like a word with you ;-)
Also sometimes a certain word just becomes more fashionable than those used previously, “analyst” is entirely generic title and gets used in every field and that previously had roles of clerk, associate, specialist, etc. which are mostly generic words themselves
> Companies that resist title inflation gain a significant competitive edge. By maintaining meaningful titles, they attract and retain top talent who value authentic growth over inflated roles. This leads to more accurate hiring, improved team dynamics, and enhanced productivity. Realistic titles also foster trust, both internally and with clients, positioning the company as a beacon of integrity in the industry. Ultimately, companies with well-defined, honest title structures build stronger, more capable teams and a reputation for excellence that sets them apart in the market.
This argument is more intuitive to me if I consider that these people who value authentic growth are looking for more than just a sensible title system.
So, nurture a variety of organizational qualities that appeal to people who want more than just a paycheck and job-hopping, and one of the many things you do in the process is to set a sensible title system.
These days I equate senior titles with more mid level. You've seen some shit but could use a bit more time in the oven so to speak. I see Staff Engineer and Engineering Lead used for what I would consider a senior role 7 or 8 years back. I fully expect those will become meaningless as well and we'll move on to something else.
In my first job there were two 'Senior Engineers' and a 'Chief Software Engineer' when I started.
None were over 25. This was over 20 years ago. FWIW one of them was, to this day, the best coder I've ever worked with. I think he's a diving instructor these days.
It's been largely meaningless for at least two decades.
I believe that Eng. Manager and HR are mostly at fault for it, confusing seniority and familiarity as creating and giving higher title to keep people without doing the requirement part of the job: accessing the title, drawing a ladder linked to a skills matrix.
I've been a Senior Software Developer or, if I had to be, Senior Software Engineer for a long time, but these days when a form asks for my title I put in either Senior Dogsbody or Executive Megafauna depending on my mood.
It has no meaning whatsoever, the payment stuff is just making sure management is able to control you. We have many companies renting out people here and you always get "seniors" who do not even qualify as juniors. Always in full suit to compensate for lack of any knowledge.
I always have doubt on this, who is developer and who is engineer?
I think,
Who are capable to using existing languages, frameworks are developers.
Engineers are the one who can design & create those frameworks, can understand algorithms and techniques / working principle. A engineer can reinvent the wheel (worst or better engineering from existing one makes good or bad engineer)
The term `Senior` always refer the working experience on the field more than 1 time. Not necessarily the years.
Programmer, developer, software engineer, etc. get used interchangeably, they don't indicate any real distinction except maybe within a single organization. Similarly "senior" doesn't mean anything other than "I got promoted."
In the last decade "architect" started to show up as a euphemism for what we used to call "analyst," someone who gathers, makes sense of, and translates business requirements into software development plans. But I have seen relatively junior programmers call themselves "architect," I suppose because it sounds cool. For me an architect designs buildings.
One of my friends decided to change his job title from "technical project manager" to "solutions architect" for the sole purpose of sales. He and the boss agreed that it sounded more impressive to the clients we were going after.
Exact same day-to-day work. Exact same responsibilities and pay. Everyone within the company agreed that it was a complete joke. And yet, we still did it.
You see that kind of thing a lot with contract programming firms -- they give all of their programmers fancy titles because it makes them look better to potential clients: "We only have senior software engineers available to work on your project, we don't hire junior people." In that environment the customer probably won't individually vet whomever gets put on their project.
I have had recruiters tell me to use more impressive titles too.
It was ever thus. "Do you remember when the word engineer meant something?"
I worked with a very popular and senior journalist in India and after decades of experience he was, well, a Senior Journalist. I was, at about 3 years of experience then, a Senior Software Engineer. It felt so funny for me at that time.
I used to think that I wouldn't mind working a company where "everyone" was Member of Technical Staff (a la Bell Labs).
Then I noticed that the people who decided that everyone would have egalitarian titles... still had grandiose titles for themselves.
So, the next time I'm discussing what engineering title system a startup should have as it grows, I'm probably going to suggest something that the early hires will be happy to have on their LinkedIn, and I'd guess that will probably look fairly conventional.
(Also, Google could get away with downleveling people only because they paid a lot better, and everyone knew it. So, unless you're paying like Google, good luck telling hiring candidates that you think they were overrated in their most recent role, and you want to put them in their proper, lower place.)
Completely agree. I've seen people with like 1 year experience being in "Manager" roles without any prior experience. Title inflation is real.
Also consider that a lot of “senior” level problems have been automated away or even solved (js framework for everything) over the years. This has happened to a lot more than job titles, just look at the red-tape-yaml hell of devops. This will continue with the push of LLMss. Jobs have changed, somewhat for the worse. As the barrier for entry lowers, so does the expected responsibility.
If everyone wants to develop on the same damn stack because you’re too bored of teaching and training then don’t expect anything senior level to exist.
Completely agree with this article. I essentially ignore titles at this point. Senior has no meaning for me anymore.
My title became what it is purely so employers could fit me into a comp band that was competitive.
At some places, the title used to simply be: "Member of Technical Staff"
dupe https://news.ycombinator.com/item?id=41897122#41898574
> Remember when being a “Senior Software Engineer” actually meant something?
Nope.
I'm only 35, but within my career I saw "developers" become "engineers" because that's what Facebook and Google were doing.
Titles never meant anything. Today, they're a class-like system for labeling pay in large organizations.
You can't address title inflation. Years ago, I interviewed at Subway for the position of "sandwich artist." I thought it was cute, but the person who interviewed me seemed to take the title quite seriously.
If you get hired as a Principal Wizard Non-Commissioned Bit Slayer, good for you. The title will be used to justify your pay to coworkers and future employers. Maybe you're a wizard bit slayer, and maybe you're not.
I find these articles go a bit too far in their rhetoric. This one alleges that the most important factor is that "senior engineers remain humble and curious".
Really? Is that what you're looking for in a job interview? You're going to knock back an otherwise exceptional candidate with twenty years of domain-specific experience for only having 50th percentile humbleness?
> Remember when being a “Senior Software Engineer” actually meant something?
No, I do not. I’ve been doing this for almost 20 years and “senior” was always a title earned in <5 years. It’s never been all that lofty.
My take is that the difference between junior / mid / senior / principle / CTO is the following question:
At what scope are you taking responsibility?
A junior can take responsibility to take a completely described specification and turn it into code. Eg, "We need a button on the page which looks like this: (mockup). When clicked, it should do this."
A senior can take responsibility for broader / more ambiguous problems. For example: "We're getting sporadic reports from users that they can't fill in this web form. But we can't reproduce it - every time we ask them to show us, everything works." / "The website just feels slow". Or: "The web server crashed again last night! That's the third time this month. How do we make this problem go away?"
As you keep "going up", the solutions increasingly involve subtle judgement (of the team and the customers) and interacting with other people. "Hey Jenny - I've been looking into a reported bug. I talked to a couple of our users about it. Part of the problem is this particular UX flow. I think it needs another pass. How full is your plate?" / "Ideally we'd scale up the team. Our biggest bottleneck is frontend iOS development. Lets hire 2 more devs. I'll talk to a couple recruiters and get the process started."
With this sort of perspective in mind, it gets much easier to judge the seniority of someone. Forget their job title, past or present. The author is right: Thats more signal than noise these days. In an interview, ask them to tell the story of some problems they've faced in their last role. Press for details on how the issue was communicated to them, and what was difficult / rewarding. Juniors will talk about tickets they closed, or tell you a story about a failing test case they were assigned by their lead that they fixed. Seniors will talk about something ambiguous and long running, or how they speced out a problem. Or about a long running issue they found & fixed off their own initiative. CTO level people will talk about hiring, or one time they corrected something that was going wrong in the team's culture.
Its pretty clear. Was it a more ambiguous problem? Was the scope broad? Did they take the initiative themselves? Did solving it involve judgement in a broad range of areas (eg technical, social, UX, etc)? All of those things demonstrate that the person is acting at a more senior level.
I use the same approach when coaching people at work. Lots of people are capable of operating at a higher level, they just need the right set of challenges and often the right push to take initiative and start stretching themselves. (And plenty of people, sadly, are the opposite.)
We've had this discussion many times before and the consensus was always the same: that at small companies / startups they use titles as a way to make people accept low-ball offers. Where the titles there are mostly meaningless. But at larger companies the titles actually do have meaning because the denote responsibility and pay scale.
I was "Senior Technician" at my salaried job. At 16.
I was the first employee, and so, even though they hired a second, I argued I was "Senior".
Eh whatever. I'm a senior engineer by actual job (solo dev everything for a large org), but have a mishmash of actual experience, so I just call myself a developer because it's accurate.
I never adopted "developer" as a title because people who organize construction projects use that title. I never use "engineer" because real engineers have engineering degrees and have to pass standardized tests. "Programmer" best describes what I do, usually I add system admin if I think that will come up.
Not knocking programmers who prefer "developer" or "engineer," makes no difference to me what title someone uses. Either they have the necessary skills and experience or they don't, and if they don't a fancy or inflated title won't help them.
A true senior engineer doesn't mess with scrolljacking scripts.
They all just write code, imho - software guys are considered very low status and have no pull compared to other professions like doctor, lawyers - i never seen a woman being excited about a programmer haha.
In the bay area it’s mildly different as its known that the wages are high
Wages do not matter anymore, i've seen guys making 300K+ a year struggling to get women interested in them.
Also, if you want to lose all your assets - only then lead with your wallet.
There was never a time in human history when Senior Software Engineer had a consistent definition. It’s fine to write a nostalgia piece about your past experiences, but this blog post doesn’t go very far beyond that.
And from his bio: "I've been coding professionally since 2014", that wasn't that long ago, I started around the same time and senior was definitely just as meaningless.
I've been coding since 1998. Wherever I've worked, 'senior' has always just meant 'doesn't need to be supervised'.
The standard pattern is to work 2 years as a junior developer, then jump ship for a senior job and double your salary.
I'm a BBCode engineer specialising in AI prompts.
BBCode?
https://en.m.wikipedia.org/wiki/BBCode
I just experienced a wave of nostalgia.
Claiming that companies which resist title inflation has a competitive edge is like claiming schools which resist grade inflation have a competitive edge. Maybe if they are competing on who is the most irrelevant...
https://www.thecrimson.com/article/2023/10/5/faculty-debate-...
https://www.reddit.com/r/stanford/comments/ja2u6m/how_is_the...
I can't help but notice the irony in pointing out that Software Engineering titles have lost their meaning without addressing the fact that it may be one of the largest misuses of the title "Engineer" (legally protected in many countries as requiring a professional engineering license by an accredited engineering body) that is in common use today.
If the author went a little bit deeper they might be able to make the same arguments about how the title "Engineer" has lost a lot of meaning in the public due to the cavalier attitude with which many organizations throw it around.
In the US there's no such protection and it's actually a good thing.
We have the formal designation of "professional engineer" (PE) but outside of civil and mechanical engineering (and some government work) it's not that meaningful. You have to complete a 4-year degree at an accredited institution, pass some licensing tests, and then apprentice under a licensed PE for four more years before you can earn a PE license.
In some states you can't legally call yourself an "engineer" without your PE license but I have never seen it enforced. I live in one such state, I'm not a PE, I call myself an engineer, I've worked with engineers for years, and even the entry level jobs in this state the title is "engineer." No one cares about it and not many people see it as worth much, unless they're doing engineering work for local governments in which case it's required.
Not surprisingly, it just makes that work more expensive for everyone involved.
Creating barriers to entry that benefit existing players in the market are not good if they don't add value. For certain projects where there is legal liability (like building a bridge, and some human needs to certify it's "good" and if they're wrong, people die), that makes sense. For everyone else it just adds overhead that doesn't need to be there.
And given that the US has led the world in engineering for the back half of the 20th century, the attitude that there must be some professional licensing body to tell us who is and is not an engineer is nothing if not smug and elitist. Some of the best software is built by people who would never have become PEs, and the entire establishment is contrary to innovation.
> In some states you can't legally call yourself an "engineer" without your PE license but I have never seen it enforced.
You may or may not be aware of this but Oregon at least tried to enforce this:
https://www.nspe.org/resources/issues-and-advocacy/latest-ne...
> like building a bridge, and some human needs to certify it's "good" and if they're wrong, people die
Even in things like civil engineering jobs, not all of the work is done by the PE, they just need to review it as if it was their own work. Some tech industries taking over critical parts of life could use oversight like that.
It is practically impossible to get a PE in the defense industry because of the apprenticeship/vouching requirements. If your employer has no PEs, you can't ever qualify for one.
That, but more to the point, the value of the term is based on the strong history of regulation and common use, which SWEs as an industry have taken advantage of and diminished.
Which, I get that not everyone agrees on licensing law and philosophy, but it should at least signify mastery of the topic via formal education or apprenticeship.
Most PEs have both of those, engineering degree and licensing internship.
How many SWEs have either? I honestly don't know.
If you don't have either, you are at best senior technician, which should be respectable enough, but for title inflation.
Mastery of what topic? What I consider important for my work in safety critical systems is probably very different from whatever you use in your presumably different field. Both of those are different again from e.g. GameDev, HPC, or operating systems and all of them encompass domain knowledge not adequately captured by existing degree programs. How would a useful certification be realized, as opposed to mere credentialism?
I strongly disagree that SWEs have "taken advantage of and diminished" anything. The practice of ignoring PE licensure extends well beyond software and was well established as nonsense before the dotcom boom.
> How many SWEs have either? I honestly don't know.
Almost all of them, in practice.
> If you don't have either, you are at best senior technician, which should be respectable enough, but for title inflation.
Engineering as a discipline is much older and nuanced than PE licensing bodies. If you are applying the science and practice of problem analysis and design synthesis you are an engineer.
The ones that matter, do this. In many states if you are building anything for a government or business where lives are at stake, a PE is involved and there's legal liability for the engineers that certify something.
But the whole PE thing is nonsense. We can get around this with malpractice policies/insurance and still have a qualified human certifying things, and reasonable bodies rejecting that certification if they don't feel the human that does it is up to snuff. The whole PE dance is just a dog and pony show.
Maybe we should be concerned about more than just direct loss of life? What about data leaks, for example? It might be nice if there were some risk that software engineers could lose their license over eg. plaintext passwords, or be protected by a governing body if they need to take a professional ethics stand against their employer.
>unless they're doing engineering work for local governments in which case it's required.
In those states, the local governments should be required to only use software from vendors where all the "software engineers" (i.e. every employee that uses that title) in that company actually have PE licenses, including Microsoft.
I fully agree but can't help but think about the SWEs writing code for Tesla et al
This is because the US does not require this, and the US arguably lead the charge in internet innovation, standards, and commercialization and continues to be the highest paying country for SWE roles. Thus, most discussion is US focused.
In other countries like Canada, the title is just s/Engineer/Developer.
To add, the author is talking about the levels no longer indicating experience due to level inflation. Not word semantics along the lines of “senior no longer means the oldest on their team”.
I agree, and I'll add more irony...
Titles don't intrinsically mean anything. They cost nothing to assign, and have no requirements.
So the only people complaining about titles being inflated are those to whom they have "meaning". And the only reason they're being inflated in the first place is because the same folk want "better sounding titles".
They're given out like candy to those who want candy.
They do mean something on your resume and as social capital. I wouldn’t sell short the actual intrinsic value of having a big title even if it’s fake you can sell it to the next employer. Even if they disagree with giving you the same title, you can use it to justify your comp expectations.
I'm sure there are people, and companies, impressed by fancy titles.
Personally, I go the other way. I don't have a fancy title, and I don't want a fancy title. I don't need a title to earn social credit or impress an interviewer. I have my achievements for that.
But of course, to those who are impressed by titles feel free to call yourself anything you like. There are no qualifications or skillsets required.
My gym instructor describes my pudgy, bald, middle-aged body as "stud". I think I'm gonna update my resume, and linked-in profile to "Stud". I expect that will help in the next interview.
You’re disconnected from reality. You say titles cost nothing. You really don’t think it costs companies money to progress employees from engineer to senior to staff and so on?
You seem to agree title inflation is common and you say fancy titles are given out like candy. If everyone easily gets promotions, what does that say about someone who’s not given such easy candy?
If you work at a company that has a bunch of pay levels, and levels are tied to titles then sure I guess you see titles as "meaningful". (Personally I think the pay part us the meaningful part, but hey, whatever floats your boat.) I'm not sure your title has any meaning beyond your company though.
Where I work, pay is based on skills, experience, quality and value of work produced. I can call myself "programming super-god" if I like but that has no effect on my pay. Some companies just have pay levels and you're an L5 or whatever.
I think, yes and no.
Yes, there is no formal standard or certification, and that opens the door for charlatans and sloppy crap.
No, designing and implementing software systems well requires planning, fail safes, redundancy and all kind of things "physical" engineers deal with.
It may be time to certify to differentiate between script kiddies and the folks managing the software systems that back our modern world.
What would you consider a good set of formal qualifications?
Degrees that the people who wrote software you regard well probably didn't have, and people writing software you dislike do? Quickly outdated written tests? Years of experience when a common refrain is 1 year of experience x times?
I work with safety critical systems. I still haven't found a better way to evaluate people than having a conversation because none of the overt metrics have correlated well with my "won't get people killed" rating.
Good question. I think a big part of physical engineers' credential comes down to liability, which ultimately leads to civil engineering firms hiring contientious and responsible engineers. It's a internal feedback loop that the software industry tends to lack.
I'm not advocating for senseless beaurocratic hurdles, but you have to admit that standards for software have fallen as more people have entered the industry.
I don't agree that modern developers are less capable. If I had to choose between software developed to the best practices in 1995 and the same software developed to modern best practices, I'd pick the modern software in a heartbeat. What's changed is our relationship with software. Old school software did fewer, simpler things. The tools available limited what could even be realized and expectations for the end result were fundamentally different than we have today because they had to be.
A lot of the software that built this modern world was created by people who would be disgusted by this credentialist crap.
I get it, this is hacker news after all, but it really could be worthwhile for the profession to differentiate between someone who picked up Python for a weekend project, and someone with 30 years experience with real-world systems.
Would you get surgery from someone in a back alley? Is that credentialist crap?
> differentiate between someone who picked up Python for a weekend project, and someone with 30 years experience with real-world systems
Why do you need credentials to differentiate these two?
The first surgeon had no credentials and no “relevant experience.” And that surgeon probably didn’t do a great job at first.
This industry is still within memory of the first digital computers. Now we have lots of rote work, some interesting and novel areas, and a small sliver of wacky innovation. But I think many here cherish that self-image of the self-taught inventor… this is “hacker” news after all. I for one am not ready to give someone undue credibility because of a title or piece of paper.
Because unlike in most actual engineering disciplines software developers generally aren't held particularly liable for the failures that their bad engineering causes, whereas people who build faulty bridges or airplanes don't have that luxury.
Software has built a lot of modern toys but it still plays a relatively limited role in the world of atoms rather than bits, but I suspect the value of credentials is going to appreciate as that changes over the next few decades.
I don't think the irony is in regard to certification, but rather that any software engineer cannot implement any sufficiently complex system in any standard, methodical or predictable way.
Hillel Wayne's crossover project [0] is a great read for anyone interested in the question of whether we're really engineers. The tl;dr is that most engineers he interviewed who switch from a licensed engineering discipline to software totally consider software engineering to be just as much an engineering discipline as what they did before, and there are a lot of neat ideas he develops for ways we can learn from each other.
Another great resource I've found is Practical Engineering. Listening to his videos it's easy to see how much overlap there is between our ways of thinking and interacting with the world.
As for the legal side, as others have noted in most of the US "engineer" in the abstract isn't legally protected. So there's no legal problem with using the title, and engineers who've done both don't consider our practices to be somehow lesser.
[0] https://www.hillelwayne.com/tags/crossover-project/
It's even worse. Civil engineers are allowed to create structures that have 0 engines in them! We should restrict the title to its original meaning.
another vague term is "doctor", as lawyers and education professionals share the same term with practitioners of medicine and so on.
> another vague term is "doctor" ...
The English definition of "doctor" is not a vague term. It has two common usages, both of which share the concept of one having an advanced degree[0].
0 - https://www.merriam-webster.com/dictionary/doctorIf we go far back to Latin, the original meaning of "doctor" is, in fact, an education professional and has absolutely nothing to do with medicine. In classical Latin, "doctor" is a teacher or a trainer. In Medieval Latin u
In (Middle) English, the earliest recorded use of "doctor" was for church fathers in 1303, but you'd find it widely used for teachers and any knowledgeable person - including medical doctors - as the 13th century goes on.
The codification of the Doctor of Medicine degree and license seems only started in the 18th century[1], but doctors of theology and law far predated that (somewhere in the 12th century I think). Even the PhD (i.e. doctor of philosophy) degree appears to predate the medical doctor degree by half a century.
[1]: https://www.gla.ac.uk/schools/medicine/mus/ourfacilities/his...
Originally they were all academic titles: Doctor of Law, Theology, Medicine & Arts.
At some point an expectation developed that practitioners of medicine actually had some formal qualifications and eventually to most people Doctor became synonymous with Physician.
I blame this lack of meaning on the overpaid Memetics Engineers who have added the word to just about every possible discipline in a vain attempt to make those disciplines seem important and dignified.
The bureaucracy of protecting titles or jobs with licensing is mostly unnecessary, often regulatory capture, and crippling to innovation.