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.
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.
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".
- 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
The heart of the problem is that most companies have no real path that isn't into management.
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.
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.
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.
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.
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.
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.
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.