The scourge of job title inflation
economist.com
economist.com
I asked a higher up why this was the case, and the response was simply that people quit if they aren't promoted quick enough. Titles are free, and smaller companies have zero problems handing them out like candy to keep people happy.
If you're getting promoted and being assigned greater responsibility, than your compensation should increase accordingly.
But you do appreciate the bragging rights of the title, and so that is all you get.
E.g., senior means I'm officially leet. Not that I have responsibilities.
Not to me. A "title promotion" without a pay rise would be demotivating, and lead me to wonder what I had to do to get a pay rise - like, leave, maybe.
Most people don't index their raises to inflation, a few years of 2% raises against 0% inflation looks pretty good, and they have a nice new title along with the raise. Never mind their real income is now less than it was a last year, they got a title and a raise.
I can't figure out how to get inflation through to whoever decides what raises should be - at any company I've ever been at. I would encourage everyone reading this to head into wage review discussions with the current yearly inflation number and make sure you boss knows it. Most companies seem to get slightly negative raises (measured against inflation), and then every 5-10 years a 10% across the board raise to bring everyone back in line with inflation.
The heart of the problem is that most companies have no real path that isn't into management.
- Everyone-in-a-startup is a side-effect of incredible automation where every competent engineer can leverage dozens of automations, CI/CD, automatic accounting and SAAS products. It’s a real capacity of coordinating.
- Titles will readjust. Titles will mean nothing. They should mean nothing. We’ve already given up reading the degree/diploma of programmers, skills matter more. Software development is so erratic and devspeed is so much due to individual talent that single founders with 50 employees can sell themselves to Facebook for 18 billions. When we can get predictable results out of software engineering, we’ll discuss how to position each one in a hierarchy.
Ultimately I prefer working with people that have experience in both.
Engineers who've only worked in smaller companies tend to be harder to work *with*, on a social inter-colleague level.
Engineers who've only worked in larger companies tend to be less capable when left to their own devices, they need more help if there is less demarcation. Engineers who've worked in smaller teams tend to pick up the slack proactively, from larger teams retro-actively.
At least that's been my experience both from within as well as without. (Currently working for a small company that has large corporate clients, have worked for small and corporations before that)
I definitely skew that way - anything in particular I might want to watch out for, that would play out as "hard to work with" in a big company setting?
- Inability to play politics for longer than 2hrs, let alone months,
- Self-selection, skilled people go to startups, and people who can maintain interest despite tons of paperwork to fill in, go to large companies (sometimes they’re as skilled, but it’s not the most important, 80% as skilled and able to run through processes is better).
Our company has grades instead: J0, J1, P1, S2 etc. So if someone is a junior, they can be "promoted" 2 times (J0 => J1 => J2) before becoming a "pro" (P1), and 2 more times before becoming a senior (P1 => P2 => S1). The official titles are still just "junior engineer", "senior engineer" etc.
As a consequence, since in other companies they often promote just "junior => senior", when we hire someone who was previously a "senior", they are often assigned a junior grade (for example, J2) which often demotivates people
I've also seen issues when UK colleagues who are senior enough to manage teams who manage teams, but are still below the "Director" role, then have to manage an entire team of "Directors" and "VPs" in NA who are the bottom rung and manage nobody. It seems like the job titles in NA can be totally meaningless? I suppose if you are used to how it works, it works fine, but if you are from a region with more conservative (and accurate?) titles it causes friction due to an imbalance in perceived power dynamic.
I've even seen an org chart in a NA firm that has 3 CTOs stretching down the same reporting line, which just seems pointless.
Never seen that; in fact I've never seen a contractor with a job title. I would be predisposed to think less of a contractor with a grandiose title.
A software engineer applies engineering principles when designing and/or implementing programs.
A computer scientist uses scientific methods and rigor when solving problems relating to computing.
If I would to meet somebody who claims to apply engineering principles or, worse, scientific method, I will make sure to be on top of their PRs at all times.
For example, if you are changing labels or adding buttons to a web app according to detailed instructions from a manager, then I would call that "programming".
If you are implementing an OAuth flow, or designing an API for some service, and doing so according to the current state of the art, you are "engineering".
If you develop a novel algorithm to solve a specific class of problems, you are "computer sciencing".
Obviously, there is some overlap between the tasks, and people will switch between the different parts depending on the stage of the project, but I don't think the titles can be chosen randomly.
As far as I can see there is no ethical accountability for the programmers at big tech companies. People are happy to pocket the crazy salaries and claim their managers or execs should be blamed for the damaging outcomes of their work.
I doubt it'll ever get adopted in the software industry, because we have many competent people doing good work without a software engineering degree, and degrees of low enough quality employers do whiteboard coding tests at interview, so there's not really a notion of a 'properly qualified' programmer.
Instead you’d claim that the key distinction is that engineering requires a legal/moral duty to accountability.
Is that a general consensus here?
Sure it helps to have established bodies to hold engineers accountable and report violations to, but I certainly don't think the ethics training is a significant factor. There's no shortage of degreed engineers signing off on things far more ethically questionable than most of what big tech is doing.
This also sounds pretty optimistic as a generalisation: > people refuse to sign off on work they don't understand or aren't confident in
At least in France, the biggest difference between an engineering degree and someone who learned by themselves are going to be:
* the engineer should have more general knowledge about databases, algorithms etc.. and generally how things work. Someone who didn't get that training might not have as deep an understanding in those fundamental concepts (that gap is sometime very very visible when working together). That's the most important part in the day-to-day.
* the engineer will have at least a decent English level. Not an issue in English-speaking country obviously, but that's actually the number 1 reason some students don't get their degree in schools I know.
* the engineer should be able to present well his ideas, and generally be at least good in communication. There is formal training to speak in public. If you are shy by nature, this may not come easy without formal training.
That's about it. There is no special skill that someone determined cannot acquire by themselves with freely available training and experience, but when you are a teenager with little self-motivation, it helps to get all this drilled into you. On the other hand, I wouldn't hire most people coming out of my own school, so take it with a grain of salt.
As for who I'd want to hire? Probably just the programmers who can do it correctly faster than most. Whether they're writing Python or hacking spreadsheets, they are programming a computer, and therefore, they are a programmer.
At the same time, I remember last year someone interviewed a bunch of non-software engineers who later got into software [1]. A good number of these folks actually do feel like software is still engineering.
[1] https://www.hillelwayne.com/post/are-we-really-engineers/
They rarely have reviews, don't have tests, rarely do something equivalent to pair programming etc.
The flip side is that traditional engineering is generally easier to reason about and with a lot of experience you can tell if something is wrong. Doesn't apply so much in software.
E: no testing might be an overstatement, but I think it's closer to no tests than an abundance of tests. Engineers tend to not get their hands dirty, which basically leaves computer simulations.
You can tick all the boxes and still do a shit job that either doesn't meet requirements or fails. It happens more often than you might think.
I've been working on airliner design and have ordered, specified, and reviewed a fair number of mechanical tests. Yet I've never actually built and ran the test rig myself, it's a full time job for specialists.
Difference is with software engineering, you seldom find yourself in court if you decide to skip the unit tests or code review...
Even if you're a chartered/accredited/licensed you personally may not have to. It could be someone else in the company, which shifts the liability.
For a given product, we had a custom PCB with FPGAs and the circuit board guys needed to follow a tons of design rules, then ran a ton of signal integrity and electronic interference simulations etc.
I was in the team who wrote the algorithms and 'software' for FPGA, we worked out the best approach using math on pen and paper, wrote a working prototype in MATLAB, designed the digital logic, implemented a high level but bit-accurate C++ model, and only then started on the HDL implentation, which we verified against the C++ one.
If you ever looked at how MATLAB, the HDL compiler, and the formal verification tool are implemented, even "mechanic" seems like way too much fancy title. The very old phrase "if architects designed buildings like developers built software, the first woodpecker would have caused the downfall of western civilization" comes to mind.
I am a software consultant who has worked in CAD software, which gives me quite some insight in this topic (software developers vs non-software engineers). Ironically, most of the time what's causing the problem is non-software engineers working on these tools, since engineers don't effectively translate their methodology into software (they don't see it as necessary, they don't understand the sources of complexity, they don't have training, etc.) , resulting in a very cowboy attitude to software development.
The amount of review and testing that goes into a single design industrial design is massive by comparison, since you cannot fix a 400 million dollar assembly as easily as code.
In the physical sciences, 'bug's often mean you will injure or kill an employee. The standards are extremely high.
In my time as an electrical engineer, there were many cases where I would book a flight to visit another company/site or consult with an academic/consultants. Also I would fly people in regularly to look at our plant. I never needed approval to bring in external reviewers and pay out billable hours. That sort of practice is unthinkable in software engineering.
For example, another commenter mentioned aviation. I would fully expect that industry to be more rigorous with both their software and physical engineering.
> since you cannot fix a 400 million dollar assembly as easily as code
Have you never seen these projects go wrong? I find that people often imply that things don't break and projects don't fail in traditional engineering when that actually seems to happen more often than most people would think.
For example, a ~$30M council parking building project in my city had to be demolished midway through the project because they messed up the design and it was structurally unsound.
And Berlin is (I'm told by everyone here) much more English language than anywhere else in Germany.
For conservative big names engineering like Bosch, Simenns or traditional mittlestand companies that mostly operate with German customers, yes they still use it. Xing is full of German only job ads.
But for software only companies operating international looking to attract foreign talent off LinkeIn, no, it's all English.
If your university offers computer science as a bachelor of engineering, it actually does grant you the title.
I believe around 2005 most german universities switched to granting masters and bachelors, usually „of Science“ for technical subjects. The title is in english, also in german language context.
That's not correct. E.g., consider the relevant section in the Bavarian engineering law[1] (using Google Translate):
> The job title engineer alone or in a word combination may use,
> (1) Anyone who has successfully completed an undergraduate degree at a state or state-recognized German university
> a) in a technical-scientific subject,
> b) which has a standard period of study of at least six full-time semesters and with which at least 180 points can be acquired using the ECTS system and
> c) in which the areas of mathematics, computer science, natural sciences and technology predominate; this requirement does not apply to people who have completed an undergraduate degree in industrial engineering and only use the professional title in the word combination industrial engineer
Further, my diploma for a Bachelor's in Computer Science from TUM contains the passage:
> The graduate is entitled to employ the designation Engineer alone or as part of a compound word.
[1] https://www.gesetze-bayern.de/Content/Document/BayIngG2016-2
Although I've heard Professional Engineers Ontario made enough noise awhile back and big tech companies had to rename their local job descriptions to "developer"
https://careers.google.com/jobs/results/?location=Waterloo,%... (only "developer")
https://careers.google.com/jobs/results/?location=New%20York... (only "engineer")
I believe it's more likely for a professional engineer to be liable, but surely in projects of any reasonably large scale there would be several layers of engineering management and oversight such that the engineer working on a part of the puzzle wouldn't be liable for a greater architectural flaw...?
For example, the Boeing 737 MAX had a high level fatal flaw that existed because of a mismatched collection of arguably correct or valid hardware and software systems. The engineers who designed the more forward set engines probably did their jobs correctly, and the software "engineers" who built the pitch up correction software presumably didn't write bugs. However, the combination of the two were primary factors in the fatal accidents.
I have seen situations where the text had to be changed to keep the software legally culpable.
In those cases negligence will lead to prosecution.
I think that's a bit harder to replace than it is to clean a dirty toilet. Presumably the professional engineers can clean their own toilet if absolutely necessary.
Engineering was a thing before software.
The group that wants to protect or maintain ownership of the word "engineer" is dependent upon the people whom it objects to also using that title.
The core concepts which make engineering engineering? Yeah.
>The group that wants to protect or maintain ownership of the word "engineer" is dependent upon the people whom it objects to also using that title.
They are as dependent on software as any other institution, on a day-to-day basis, which have transitioned to computerized automation over the last ~60 years. Software aids efficiency.
The argument that engineers are incapable of designing and constructing sound solutions without software is unsound.
Name one modern feat of engineering which could be done without the aid of software.
Commercial airliner? Nope. Modern skyscraper? Nope. Modern CPU? Nope.
Modern bridge? Maybe; but without structural analysis and stress simulations, it's going to use more material and be rated lower.
I'm done arguiung. It's clear that there's always some meritless retort waiting.
The key is that if it requires some sort of certification, as Canada claims it does, then it should be a modifier/adjective on the title like "certified janitor" or "licensed engineer".
Just claiming an existing single common noun as an exclusive term belonging to your organization is clearly an untenable position. If you have to keep reminding everyone that they're infringing on your trademark all the time by using a common word, you've already lost.
A long time ago in Paris the street sweepers were euphemistically called "surface engineering technicians" (paraphrasing from the French "technicien de surface", but I think this is close enough)...
If they use the term "engineer" in the work description, they won't be able to sponsor visas for candidate without an engineering degree.
Engineer ("ingénieur") is both a diploma, a status, and a title.
The diploma is regulated by a committee that endorses curriculum for colleges so that they can deliver an engineering degree. It indeed requires some specific training, and not all schools have the endorsement. There _is_ a difference between "I have an MSc in X" and "I am an engineer in X". I think this is what you are referring to.
The status can be earned by having the diploma or getting a recognition of skill by experience. It's usually useless in private companies, but opens the door to better social security in public and institutional services.
The title (as in job title) is unregulated and can be given to anyone.
from wikipedia In 2019, President Emmanuel Macron announced he would propose to abolish and replace the ENA. Macron is an ENA graduate himself, but the tight network of ENA graduates influencing the French civil service has been decried by populist protests such as the yellow vests movement as an elite governing class out of touch with the lower social classes. In April 2021, Macron confirmed the closure of the school, calling the closure "the most important reform of the senior public service" since the school's creation in 1945. In January 2022, it has been replaced by the Institut national du service public (INSP).
In the same way business schools are really networks or clubs (there is little learning taking place at BS..), ENA is a club for the highest-ranking civil servants in the country (i.e. no learning happens at ENA/INSP, merely co-opting into the club of those who then should serve the country but instead gut the state for the benefit of their class).
It requires specific licensure and years of training directly under an existing "Professional engineer".
That's like saying an electrical engineer is just a fancy name for a PCB designer. A mechanical engineer is just a fancy name for someone that uses solid works. An optics engineer is just a fancy name for someone who plays with light simulators.
You can't just trivialize what people are doing and then call it not engineering.
The problem with the programming profession is that it's possible to get away with not applying good engineering principles. It's only in domains like the nuclear industry, or the military (fighter planes etc.) where we can really imagine the consequences of buggy software.
Software Engineer is a title that reminds of how we should be approaching the programming problem.
Aka the most junior of juniors? Let's not pretend that will actually produce a working code meeting any real requirements.
I can see though how this would be an issue - in my experience there is a significant difference in quality between developers who just learned how to program on their own, and the developers who hold that engineering degree.
From what I've seen around me, the ones holding the engineering titles simply are more methodical in how they search for a pattern or key to how something works. They will have a better vocabulary to explain themselves too.
But maybe they aren't as good in thinking outside the box?
Kind of like how someone who has completed a formal philosophical education will usually be better figuring out the ins and outs of a particular text but not necessarily will have what it takes to come up with their own? Not sure - I'm a humanities kind of guy who works with engineers.
I've seen a lot of self-taught developers or bootcamp grads switch industry or try to move to "tech-adjacent" roles. Making it as an individual contributor is, in my experience, pretty rare.
- Sales Support Analyst
- Sales Support Specialist
- Senior Support Analyst
- Software Engineer
- Senior Developer
I have nothing against the professionalisation of programming; it would be a good thing. But the fact remains that the great majority of programmers are not engineers. We are tradesmen, a bit like plumbers or domestic electricians. There's nothing to be ashamed of in being a skilled tradesman; for a good part of my career, a plumber earned more than I did.
Same. Today, when someone asks what my job is, I say: 'I program internet shopping sites.' It's so simple that even grandmas understand it.
It requires some pretty heavy testing, a few years of apprenticeship, project reviews by mentors, recommendation letters, and a few other hoops.
Software is so much more broad than the physical sciences that I cannot imagine a way to generalize a pathway for software engineers.
We do exist.
To me the term "Engineer" means that someone holds an Engineering degree. And that degree allows me to make certain assumptions about what the Engineer knows.
For instance, I expect anyone holding such a degree (wherever they studied) and claiming to be a software engineer to have:
- A solid background in mathematics, at least applied. - A solid background in Computer Science (algorithm, data-structures, discreet math) - A solid background in Applied Computer Science (networking, operating system, build system, electronics, databases). I expect them to have built a few non-trivial projects. - A knowledge of project management (what's a Gant chart, waterfall, agile methodologies) and economics (able to read financial statements and understand basic accounting and corporate structure) not CFA level of course. - Communication abilities (I expect them to have written papers and technical reports as part of their degree).
Two out of these five elements are domain-specific; the rest is universal across engineering disciplines.
Note that you don't need an engineering degree to know all that; John Carmack would tick all these boxes. But he's an exception.
Some people with 1-2 years of experience really are significantly qualitatively different than others with that few years of experience. Some people with 5 years really are able to run teams and build large systems independently. It shouldn't be about the years alone.
Edit to add: Also, after 4 years intense studying it could be said that every software engineer with a Bachelors degree has already passed through the apprentice phase, their first 1, 2, or 3 years might legitimately be their journeyman phase, and so after a couple of years they might legitimately be "senior" in the sense of being an independent expert practitioner. Remember that we're talking about a person who has now spent 5-7 years of their life developing these skills, and possibly more before they attended university.
(And it then makes sense that the next step up would either be Staff or Architect as their skills grow to handle more complex organizational matters or even more complex software systems respectively.)
Now obviously that is NOT true of a large number of people who don't apply themselves in school or in their jobs, and so just sit in their chairs watching the clock until they have enough years of experience to be "senior", but a person who applies themselves can achieve a level of capability in a couple years that the person who does not apply themselves might never achieve in their entire career.
My last boss used to appoint "apprentices". They would stay as apprentices for all of 6 months (I think they got a tax-break for having apprentices). Traditionally, an apprentice in a trade would be indentured for several years, studying/serving under a master.
After completing his apprenticeship, the new tradesman would be kicked out, and barred from working in the same city as his master; he was expected to travel around and broaden his experience. That might last a decade. He'd then have to convince his trade guild that he now qualified as a master, often by presenting an exceptional piece of work (a "masterpiece").
It's often said that it takes a decade to learn anything really well. I think that applies equally to programming. So the "journeyman" stage fits in with that, as a way of designating someone's skill level. But the "apprentices" I worked with were doing exactly the same work as everyone else; we were all fungible programmers. In 45 years in the industry, I worked with approximately two people I'd designate as "master".
It’s in everyone’s best interest except for the industry as a whole. It’s why a “distinguished fellow” has to do the same inane leetcode grind as a fresh grad or someone with no degree who really likes computers.
When you get a loan (ie for a normal house) a vice president is probably required to sign off on it. Thus banks have vice presidents at most/all branch locations. Their pay, responsibility, and influence is pretty small in the company, but they are a vice president because that title is legally required to make the routine decisions they make every day.
The top salesmen in most companies also get a vice president title because customers fell important customers if a vice president is assigned to talk to them. Of course a vice president is allowed to make some decisions so they should (but may not) avoid promising things as it could be legally binding.
I think it's pretty safe to say that software architect would have been included in that carve-out if it was written today, and the ARB says: "We take a common sense approach to the use of ‘architect’ that isn’t connected to building and design, for example with ‘software architect’ or ‘systems architect’ which are increasingly used by the computer and IT industry." https://arb.org.uk/architect-information/what-we-do-to-regul...
Since the only way it is regulated is by the ARB bringing action against a person, their decision to ignore software architects is pretty final.
Literally started as Support Manager which basically meant that the tech support phone was on my desk in a four-person company. The three other people were the CEO, Software Development Manager and Hardware Development Manager.
Next, I became a Senior Software Developer, because a customer contract required seniors assigned to a project.
Now I'm a Software Specialist which basically means bottom of the bin in the title hierarchy here.
My experience is that those same people quit once they are promoted. They are playing a game of ladders. It might be your corporate ladder they are trying to climb but most likely it is someone else's. They want that Senior Engineering title so that they can hop to the next organization without putting in the work to achieve that title at that company. And, it works. Some of my former coworkers have been hired for jobs far above their skillsets and it's on those hiring companies for not being able to assess competence. I have had employees from my company with only four years of experience leave for a VPE title. I wouldn't trust them as an engineering manager or senior engineer reviewing code let alone a VPE but companies are desperate and they were charismatic enough to BS their way through interviews. I always smile when that happens because I know which company will likely go out of business since they can't assess skillsets without titles. These companies are willing to pay way more money for far less talent and well that's the stupidity tax these companies get to pay.
If recruiters are going to farm talent from smaller companies, as they do, I will ensure from here on out that externally all of my duds have Senior, Principle, or Distinguished engineering titles. I will hand them a grenade with the pin removed... Electrons to bits they hire them without evaluating skills or experience. ;) I'll give my exceptional talent titles like Level 1-M.U. (Level 1 being our highest most prestigious rank, the title being master of the universe, or whatever.)
This is the game companies they have created since they can't assess competence and corporate recruiters only know how to search LinkedIn for titles. They made that bed, now they can sleep in it :)
Jokes aside, I was only burnt a few times by employees wanting titles in order to jump ship quickly. I now recognize my coworkers with accolades, great pay, flexibility, and treating them like the intelligent adults that they are. Collaborating with them. Being transparent. If they still want to quit because I won't give them a title too soon and their ego simply cannot get past that, it's just not a great fit and I don't want to keep them from fulfilling the needs of their ego at their next job. That being said, the right people get the right titles at the right time, and in between then, there are a lot of ways I promote people culturally without giving them a title too soon.
Most people just want meaningful work, paid well, and only after those two have been addressed, then do they want recognition. Don't get me wrong, they want recognition too but a lot of poorly managed companies don't understand what meaningful work and paying employees well means so they hand out titles as quickly as they can. Heck, they don't understand what recognition is either if the best they can do is hand out a title.
PS; I am definitely not saying that is what is happening at your company or with your higher ups. I am just over here hyperbolically weaving fantastical yarns of fanciful prose to amuse and illuminate at 0530AM MST.
Up until recently everyone at Netflix was a Senior Software Engineer if they were an individual contributor. This worked great within Netflix, as you just did what you needed to do and everyone respected that you were doing the right thing. But it was troublesome if you ever wanted to leave Netflix, because you may have been doing what Principle Engineers do at other companies, but when you apply there they tell you "Well you were a Senior Engineer so the best we can do is Staff Engineer". Until it became well known what Netflix was doing, it was hard to get even an equivalent set of duties elsewhere.
That seems like a larger issue...
Even staff-level pay should've been a big step down unless you were going to Apple or Google or something...
The move beyond senior becomes almost entirely political. You have to play the game or you’ll be stuck there forever (or until interviewing into a higher role elsewhere). It’s all about doing the right things for the right people at the right time, with your name prominently attached.
The other thing is it is really hard to define "scope". With titles and hierarchies sadly all the scope below is attributes to you (and this reflects in the pay). You also hear a lot of making "impact". But seriously shipping a line of code (amidst 10s of millions) to a phone os update used by a billion users isn't that exciting to me. I care more about the % of attributable impact.
Meanwhile, when companies are hiring, they tend to ignore your previous titles and focus on evaluating things objectively. They're aware of title ambiguities because it's a charade they all play. They want to see your actual skillset, look at what you did in your previous role and assess that. During salary and role negotiations, they can use titles against you if they find your previous title wasn't inflated, even if they know you're actually more qualified than the title projects. It can be a way to rationalize lower pay bands or roles at another business. So companies tend to project value in titles when they give them away yet value them as worthless when it matters to them, meanwhile leverage titles any way they can to their advantage. It's an intangible commodity for manipulation.
Titles are a made up thing. We assign an english word to label an employee, then make value judgements about it.
Is title inflation really a thing? OK then, how was the value of a title set in the first place? Is there some natural phenomena to measure what an 'executive' should be?
My management has basically just shrugged, "it's the market right now" without considering any long-term ramifications. I'd almost be fine with it if the rising tide lifted all boats, but it seems to be highly particular to the incoming <5 years of experience people.
Before too long, I'm going to end up working for people who know almost nothing, and don't even have the experience to know it. That'll be the moment I retire.
Requiring 15-20 years of experience?
Just... no.
Software engineers are so well paid that many of them retire from the job market permanently after 15-20 years. You might as well ask people to be 65 years old until they can occupy the position.
20 years is 25% of a lifespan, and 33% of an adult lifespan.
Why isn't 10 years good enough? Unless it's an executive position for people who are at the end of their careers. You can become a Brigadier General in 20 years in the military, which would be broadly equivalent to a SVP.
It is completely juxtaposed with the reality of most senior managers, who are identified by companies in their early 20s. Companies tend to promote high velocity career climbers and want to promote them young in order to get plenty of years of service from them.
I started programming when I was 8, and have been a contributor to many software projects from age 11 onwards, with a lot of those contributions still publicly visible on my GitHub profile. Straight out of college, sure I have "~1 year of experience" (that is, if you even count my internships) but I've been programming for more than half my life. If you sum my ad hoc experience contributing to FOSS projects, doing one-off contract work, personal projects, and just tinkering over 15 years I might very well be as good as someone with "15-20 years of broad industry experience", but it doesn't show on my resume as an easily quantified number. I've definitely come across and worked with these kinds of tenured, experienced workers who went into software development not as a hobby or interest but as a mere career and ended up falling behind in their later years due to a lack of drive.
This kind of thing is rare in most professions, so people aren't used to it (and I'm not saying that it's 100% what's happening in your anecdote), but I believe it is becoming increasingly common in software development.
- junior, fresh out of school and is basically expected to do whatever task they are told to
- mid, a few years in and can define their own work within a project
- senior (many stop here), can manage their own projects, but limited influence outside the team. Expected to mentor juniors and work with partners
- staff, a lot less coding, lots of digital ink spilled recently on what staff engineers do :) basically influence the entire team and help set technical direction
- principal, basically a mega staff engineer, influences a larger organization. Called in to solve the hairiest problems.
- senior principal, can bend spacetime at will
I've been to Wal-Mart or Target or any number of places, where I have read a sign or overheard a prerecorded announcement referring to the workers as "team members", "associates", "specialists", "customer advocates", and so on. The illusion dissipates instantaneously. I immediately see it as pretentious, and the reflex is to cringe. I suspect that most employees roll their eyes at it too.
I don't believe that the executives who came up with these fancy names are fooled by them either --- and that's part of the problem, it's condescending. The executive thinks, "I see right through these words, into the real thing, but my employees and customers are stupider than me, and I believe these names can sway their thinking."
Another problem is that it is just like inflation, in that it doesn't stop spiraling upward. I believe that the word "employee" was once a fancy replacement for something plainer, like "worker". But H.R. told me, when I was making an app for them, that it's a dirty word: We don't "employ" people. That makes it sound like we are using them. (Well, you are, but they know you are, and after all you are paying them. It was all agreed upon at the outset. Also it's not so bad. Everyone wants, in the end, to be "useful".) But no, now they are called "associates". It won't end. There is even a chance that it will go in circles. I would not be surprised if some years later, a new executive arrives, says "associate" is too loose: "They aren't merely associated with us in some tangential way. We need them and employ them for our success. Let us call them 'employees'."
That being said I think most people still probably prefer this to the alternative. Being called a "associate" instead of "cashier" is still slightly more respectable to tell your friends/families. It also probably stresses to employees that their job is to represent the entire store - not just do a a task without regard for the customer experience.
Not if they have any sense and see it as a pathetic and condescending brainwashing technique it is...
I dont mind being called a gym "member" or hotel "guest" instead of "customer" or whatever. Its polite and fine.
Yes, those "old style genuine seniors" in the industry have had their titles inflated up the waxoo.
I don't think they're that unhappy about the change.
It's likely I'll end up with the title of Senior with ~3 YOE at a big tech co. I think it's extremely dumb and feel like Senior and sometimes Staff titles are often undeserved, but it feels like if you don't play along you're just falling behind.
"Communications director" is something you have to fucking decipher with a code you get on the back of your Froot Loops box, because it means one thing at one company and something radically different at another. Just to give an example. Reading somebody's resume can be hell.
I do agree that keeping preventing Canadian developers from calling themselves engineers is a joke (let’s see them try and stop me)
Whereas in software, you don't really know how much authority a "senior architect" or "engineering fellow" or "principal staff developer" really has...
My favourite 'Director' I've encountered so far was an Associate Director who was a fresh graduate doing LinkedIn outreach for an SME.
You can do the same. Take your side project, call it a company, and now you are CEO of that company. You don't even need to incorporate the company or give info about it (you are in "stealth mode").
To boil down my job title would reduce me to a computer programmer. I'm fine with that and it's what I tell to people I meet. In the industry though, it's another story, because we have to play the game in order to succeed. The result of this is that everyone on my team is a senior software person, while I reside in North America, and them, all overseas. You can imagine the pay-gap.
So where does this put me as the more experienced person on the team, getting paid double the salary of those who share the same job title? As the organization expands and goes through its cost cutting phases, I imagine that spot is directly in the sights of, well a coat saving opportunity. Am I paranoid? Maybe.
What’s perverse is that while having an inflated title may be a benefit with regards to external lateral employment, it’s a huge detriment to internal advancement as employees with inflated titles aren’t qualified for roles their title might imply, but aren’t considered for what could actually be career advancing roles as they’re considered too “senior” on a title basis
Instead, all of the startup execs had VP titles. When we got acquired by a large corporation, many of them went down to Senior Manager titles, a few being able to get Director titles. I suppose a cynic might argue this is actually about the ego of the startup CEO, but after seeing it in action I believe it was good advice and have used it in my own startup.
The problem with the "1 year of experience n times" career trajectory is it pays incredibly well.
And it's extraordinarily fulfilling to tackle a new project and a new tech stack every 18 months.
Everyone keeps saying establishing yourself is worthwhile... the money and the exciting projects say otherwise. I'm not sure how to feel.
I guess, what I'm saying, is just be careful not to get stuck in an ADHD local maximum where you're getting a dopamine hit for jumping to the next new thing. Sometimes taking the time to become a real expert in something can pay off on a longer time scale.
*I'm not saying that it's bad to have 1 year of experience n times, you're probably pretty good at getting up to speed - you have n years of experience of learning new things, and that is also valuable in many contexts. I'm just saying that it can be a local maximum.
> I'm not saying that it's bad to have 1 year of experience n times, you're probably pretty good at getting up to speed - you have n years of experience of learning new things, and that is also valuable in many contexts. I'm just saying that it can be a local maximum.
That's a really great way to phrase it, thank you.
It's definitely like that now I think about it... although I do see many engineers get caught working in bad environments because they choose too early.
That's not what I mean by 1 year of experience 10 times. That's 1 year of experience with specific technologies, which nobody except recruiters and HR people looking to mindless fill out a job description care about.
By 1 year of experience 10 times, I mean working in the same ecosystem, doing coding but never really going beyond that. It seems like there's always someone in every position I've had. They have a long resume, but look at their code or their overall development practices and you'd think it came from a junior coder new to the industry.
Establishing yourself through learning a new tech stack every so often is fine – as long as you demonstrate that your skills as a developer have grown. Going from not owning any specific area of the code, helping in other people’s areas, fixing bugs, making small modifications, and implementing very small features to owning an entire product, in all aspects of the development process, providing technical direction to others, doing design and making architectural-level decisions is establishing yourself.
I've just found the idea of "1 year of experience repeated 10 times" at a dissonance with an industry very much oriented around staffing individual projects.
I agree, as long as you're building those skills of ownership, that's progression. I've just had many say you need to stay at a place 5 years to do that, which is crazy to me.
So if you asked me, I’d probably say “I’m one of our leads”, because the company has several teams which serve different functions. But I am the singular tech lead of my team.
Had no idea that a team would have multiple leads, wouldn’t have even crossed my mind to disambiguate that for you, and I’m guessing that same confusion has happened with others
But this falls down when I, with over 20 years of actual work experience, am a "Senior Server Engineer" and I talk with a "Principal Server Engineer" from India who has problems logging in to AWS and checking CloudWatch logs.
Titles shouldn't be a reward used instead of pay rises or just for being in the company long enough. You shouldn't become Principal Software Architect just by being in the same job for a decade.
Source in German: https://www.tagesschau.de/wirtschaft/wirecard-prozess-vertei...
One wag said he wanted the title CFO. We said that would be OK but he'd have to actually do the job, including taking on the liability. He decided to pick something else.
The main purpose for titles was so that when you talked to someone outside the company they'd know who they were talking to "Oh, a VP. This person can sign my contract" or "Oh, a VP. THis is a waste of time; I need to talk to a developer"
===
OTOH I have worked in an industry where titles are super important: pharma. That's because you can get a job on a drug program that's already been under way for a few years, work on it for several years, and then move on with it still not approced. The NDAs are actually observed in that industry so you can't talk about your work. So the fact that you had a continuous rise to senior associate director showed that you had been at least valued by your employer.
If you write source code your title is obviously supposed to be Sorcerer, why is there even a question here.
that's the real scourge right there.
> "Baristas at Starbucks are called “partners”...to create a sense of shared endeavour and to disguise the cold reality of corporate hierarchies. "
https://www.goodreads.com/book/show/30209127-the-stupidity-p...
On one hand it rubbed me the wrong way personally, but that's not a big deal and something I could get over, but on the other hand I was regularly having to explain to team members in other regions why promotions in Mumbai were happening so much faster than everywhere else. It was a people and perception problem, but still had people who couldn't let it go.
In the 21st century, the term “engineer” has lost that meaning and it is now used mostly to identify programming professionals of various skill levels.
Receptionist may or may not be strictly necessary for any particular building, of course, but it's indisputable that a building receptionist is a real job. Eg a large office or residential building where you have a large number of people coming and going throughout the day. Part security guard, part front office mail clerk, part janitor, part concierge. More than enough random little tasks that are difficult enough to automate in the edge cases.
The article also mentions "Sanitation technicians", which are about as far from a bullshit job as you can get... someone has to clean the shit.
This is absolutely true. If someone is advertising for a VP of software engineering but asking for a skill set that matches mine, I conclude that they don’t know what they’re doing.
- New grad, takes more than give
- Individual contributor
- Team technical lead
I really liked it as it was clear what the roles where and how to move up. We kept running into problems with people wanting smaller career milestones. Unsure if it was due to smaller milestones from college, gamification, or what.
Since that company switched titles to match industry and at each job since, job titles have been a mystery to me.
Maybe I need to ask my boss for a "title raise" ;)
About the only thing that does not happen is a significant pay increase, but the titles with promotion keep getting more grandiose, pay, maybe a 0.5% increase if any.
https://www.economist.com/leaders/2012/04/07/the-perils-of-p... https://archive.ph/mrEtL
- LinkedIn: Blockchain Evangelist, Serial Entrepreneur, AI in Web3 Enthusiast, ex-IoT Devices Department Manager
- Reality: unemployed, failed in 5 businesses, but bought some Philips Hue lightbulbs
yes, i was a stock-boy. i suppose i was part of the problem from an early age.
on topic - my only real complaints about title inflation are 2 fold: first, interview screens; second, annimosity generated within departments between engineers holding the perception they "are better" than x yet x has a "higher" title. both are frustrating situations
I still remember a team member some years who was promoted to "Principal SW Eng" - when titles were still a little bit of "something". And then he added: yeah, but no raise. And we both laughed, because clearly it was ridiculous what they had done to keep him.
Garbage man, a janitor and you my dear
A real union flight attendant, my oh my
You ain't nothin' but a waitress in the sky"
Waitress in the Sky, by The Replacements.
I know a "Microsoft Certified Systems Engineer" is a thing that exists, but it seems to me rather a contradiction in terms, suggestive as it is of an engineer who is expected or even required to make mistakes.
Many construction workers and electricians do.
I don't know if that's a good proxy for engineering.
https://www.nspe.org/resources/issues-and-advocacy/latest-ne...
You are correct that the ruling partially constrains itself to traffic lights, but that is because that's all Jarlstrom asked for, and this was a preliminary injunction, it didn't even go to trial!
That said, the ruling also makes clear that the Oregon engineering title laws (as opposed to engineering practice laws) "violate the first amendment on their face". And if those statutes are unconstitutional, there's no law for Jarlstrom to violate. And as such, it states " Plaintiff Järlström may describe himself publicly and privately using the word “engineer." And that Oregon cannot enforce any of the professional engineering registration act against him for doing so.
And Oregon is one of only a few states with such a law, so in most of the US there isn't even a law to strike down, it's just clearly legal.
You could design, manufacture, and ship thousands of gadgets which turn out to be scarp, because someone forgot to place a pull-up resistor for the reset pin leaving the devices unable to boot up (definitely not a real example :) )
You can make costly mistakes with software too, but in old engineering it's the norm not the exception.
Or maybe I have a rosy view of what "actual" engineers do.
Sofware Engineers (and their recent extensions, Sight Reliability Engineers, Data Engineers), etc... have been a pretty common concept for 20+ years.
Is that title inflation for optometrist?
It's also basically a joke title anyway, but it's nice to at least have it in my work history. I write JavaScript, hoorah I'm an engineer.
Socially I find it a bit embarrassing, so I say I'm a programmer or a software developer.
> The application of mathematics and the physical sciences to the needs of humanity and the development of technology
The Wikipedia article for Engineer[2] further drives it home:
> The work of engineers forms the link between scientific discoveries and their subsequent applications to human and business needs and quality of life.
And that's what I do: I take the field I studied (Computer Science) and I apply the knowledge and discoveries of that field¹ towards the needs of humanity, i.e., I engineer. (Typically, and it is somewhat expected, I engineer software. Not always, ofc.)
People get hung up on that "PE" is a specific term of art in some jurisdictions and some fields, with a correspondingly more narrow definition.
[1]: https://en.wiktionary.org/wiki/engineering
[2]: https://en.wikipedia.org/wiki/Engineer
¹or, well, some of us do. The profession these days seems to have a real problem with knowledge.
I have often thought that making software has at least as much in common with cooking or sewing as it does with engineering or architecture, as in "software architect" or "software engineer"- yet there are no software chefs or software tailors.
Perhaps executives are uncomfortable knowing less about a fundamental aspect of their business than a chef or a tailor but if an engineer or architect knows something they don't, well, those are demanding disciplines that the executive can be forgiven not having mastered. Likewise there are no attire engineers or food architects because we might be more reluctant to have our waistline measured by an engineer or to tell an architect in fine detail how our meal should be prepared.
It also occurs to me that both architecture and engineering are traditionally male-dominated fields. On the other hand, "computing" was originally considered woman's work[0]. Whatever title I propose is ultimately moot if the people hiring would rather call their employees software architect, software engineer, software lumberjack, etc. However, since you asked me, I think "codewright" has a ring to it.[1]
[0] https://en.wikipedia.org/wiki/Computer_(occupation)#Wartime_...
Actually.... Chef is a configuration management tool that uses system configuration "recipes". [1] [2]
There are tailored systems in software. We call those bespoke systems. [3]
Bespoke software – sometimes called custom software or tailored
software – is a software solution created for a specific user.
Much like a bespoke suit, these software solutions are made and
tailored entirely to your exact specifications.
> However, since you asked me, I think "codewright" has a ring to it.CodeWright is a Windows Programmers Editing System for software developers originally marketed by Premia Corp. [4] Though, enough time has passed that you should be able to safely reuse that title!
[2] https://en.wikipedia.org/wiki/Progress_Chef
Here's mine: Executive Professor
In America, it appears to mean "is paid to teach"
"Dean" might work. Dean of cleaning. Dean of Catering.
Technically though, one is not a professor until reaching the rank of “full professor”, which typically happens no younger than 40, after being promoted from “assistant professor” to “associate professor” (and then coming up for full several years later).
Assistant professors will say “I am a professor” when asked what they do for a living. But when being introduced at academic conferences they would normally be referred to as “an assistant/associate professor at university X”.
Some of this is inside baseball among academics, but the first paragraph applies pretty widely.
Emeritus and Adjunct are a bit like "executive producer" in "State and Maine" grace-titles handed out to keep people happy. Emeritus get use of a room and access to the coffee machine.
Is emeritus and adjunct the same thing in those countries? In the US, the former is a semi-retired (tenured) professor, and the latter is not on the tenure track at all.
Well, you see, words "lecturer" and "reader" both have the same meaning, but the former is a fancy French/Latin word and the latter is a boorish English one, so I'd imagine the difference between the academic titles would be about of the same level.
I think it depends. We used professor when I was in high school (3.5 years ago).
However, there are nuances. The term "catedrático" is used for senior profesors/profesores at a university: https://spanish.stackexchange.com/questions/21816/what-is-th...
I would be glad to hear more from native Spanish speakers or other foreign language speakers who use similar terms (e.g. French speakers, who also use the word "professeur" with a similar usage).
titles are free
(and they are much cheaper than a pay-rise :))
"Greetings Engineer II"