Software engineer titles have almost lost all their meaning
trevorlasn.com
trevorlasn.com
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.
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.
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.
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.
Those guys had some ridiculous job titles.
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.
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 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.
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.
No one “is” an engineer. People use that title to communicate something, and the title may or may not accurately describe their skills or the work they do.
One thing the article makes clear: the title “engineer” doesn’t mean anything specific outside of the software business either. It comes from tradition and maybe laws and regulations.
People can use whatever title they want, makes no difference to me. I choose Programmer. I don’t give it much thought and don’t see any reason to come up with justifications either way. The work looks the same no matter what goes on the business card.
For the large majority of people working with software, choosing programmer, developer, engineer, architect, or code ninja amounts to a distinction without a difference.
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?
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.
Another similar topic could be architects vs software 'architects'.
I now just call myself a developer. But I also only program for fun these days.
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."
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.
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.
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.
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:
You can't take a title to a bank and cash it.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.
What I can offer regarding same is to try to separate a title assigned from the positioned earned. To wit, I can give myself the title of "2023 NBA MVP"[0], but that doesn't make me Nikola Jokic.
HTH
0 - https://en.wikipedia.org/wiki/NBA_Most_Valuable_Player_Award
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.
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.
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.
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.
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.)
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.
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.
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.
One of my cow-orkers had "Dread Pirate Roberts (retired)"
* 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.
Assistant (entry level)
Associate (3-5 yrs)
Research (7 or more yrs)
Senior (typically >10yrs)
We transitioned from Programmer to Software Engineer during my 1st 10 yrs. It was a sore point for other company employees because we had nearly as many electrical engineers as programmers. They weren't happy with us becoming "engineers".
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.
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.
https://www.thecrimson.com/article/2023/10/5/faculty-debate-...
https://www.reddit.com/r/stanford/comments/ja2u6m/how_is_the...
The standard pattern is to work 2 years as a junior developer, then jump ship for a senior job and double your salary.
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.
I worked with Principal Architects who couldn't code themselves out of a wet paper bag.
I had (at the time) 20 years of experience in the field. Said Principal had around 5-6. But they were from a country where titles are highly valued, so they used up the "promotion budget" - I didn't get a fancy title (and tbh didn't want one).
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.
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.
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.
I have had recruiters tell me to use more impressive titles too.
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.
Also, if you want to lose all your assets - only then lead with your wallet.
I was the first employee, and so, even though they hired a second, I argued I was "Senior".
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.
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.)
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?
I just experienced a wave of nostalgia.
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.)
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.
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.
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.
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...
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.
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.
> 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.
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.
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.
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.
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.
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?
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.
In a world where pay is tied to public-facing titles I can look around, recognize that I'm doing more and better work than people with a higher title than me, and push for a promotion.
In the world you describe (absent salary transparency), how do you know if you're getting underpaid relative to peers?
So you are ignorant to the reality that it is meaningful and has some value, that value is debatable and subjective, but it can and does have actual value. You're stuck on your own narrow minded meritocracy mindset, which is noble and pure, but also extremely naive to how the world actually works at large.
> Where I work, pay is based on skills, experience, quality and value of work produced.
Reducing to N=1 doesn't help your argument. Quite the opposite. I think we're all in agreement it would be convenient if titles and levels were normalized across the industry / globe but they never will be. I'm glad you found an employer that works for your preference. But if you ever search widely for another job, and want to optimize your earnings, a big title will come in handy and have value. You can stick to your guns, but you are experiencing an opportunity cost by being stubborn on this and not seeking bigger titles. You'll never know how much more you could have been paid had you came with a big title and made them think you were worth way more than they wanted to pay.
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.
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.
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.
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.
Would you get surgery from someone in a back alley? Is that credentialist crap?
Why do you need credentials to differentiate these two?
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.
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.
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].
a person who has earned one of the highest academic degrees
(such as a PhD) conferred by a university
a person skilled or specializing in healing arts
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...
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.