[runawaybottle]

So, you’ve over thought this a bit. There is a course in comp sci called ‘Software Engineering’, and it’s the place where stuff like UML diagrams and end-to-end testing get covered (differences between tests). The UI developer would need to test his/her stuff too, no? You can engineer a good codebase for anything, not just critical applications.

The thing you are describing is something different altogether, where the distinction is more about status (e.g I do more important work than you). Usually we handle this with appropriate compensation, but if you are looking for nominal respect, that’s a losing battle. I just saw some kid on LinkedIn, graduates a bootcamp with no job experience at all, changes his title to ‘aspiring developer and data analyst’. Title pimping is a lost cause, and the integrity required to derive status from it is infinitesimally small.

Tech in general has always had this problem, as we mostly got lumped into ‘aren’t you an IT guy?’ for years. It had very little status, and we sort of have the same problem all over again except it’s the barbarian horde of newcomers that give themselves titles that would takes years to sincerely attain. Three month bootcamp straight to a ‘full-stack’ developer, huh? This stuff hurts us in general, and we might as all go back to being called ‘IT people’.

I do agree that software is too big to have a blanket term like ‘Software laborer’. There are ‘ui laborers’, ‘options trading laborers’, ‘infrastructure laborers’, ‘backend laborers’, etc. I wouldn’t want to create classism amongst laborers (you know, real laborers vs not so real laborers), but rather have descriptive branches of our field properly described so we understand what part of this field you specialize in - no status involved. I guess the same way we know what a Podiatrist does exactly, compared to an Orthodontist. There is no Medical Professional or Seriously-Better-Medical Professional.

I wouldn’t put too much weight on the term, marketing values ‘full-stack’ ahead of anything else anyways, which flys in the face of specialization. Probably why such a topic even comes up, if we’re all meant to be generalist, what sets us apart?

[notyourNMI]

I understand where you're coming from. I might have come off as a little "this is better than that" unfortunately.

What I meant to express is how I personally see our types of work relating to non-software engineering professions. For many physical engineering disciplines there's some type of external regulatory body that you must measure up against for each project you complete, to have that project approved to be "launched". In the UI example: if there's no external body that has to sign off on your work, you can pretty much do whatever the heck you want to get that gorgeous interface in front of a user. The skill required to do so may well dwarf my own, with a million crazy frontend js libraries, web standards, and so forth to memorize and wrangle (not a UI guy, obviously). But in my own admittedly narrow definition, as the work can be done without being answerable to some external body that has to sign off on it, I couldn't call that engineering. Again, it doesn't mean the UI work isn't complex, requiring highly skilled individuals, etc. Of course even safety critical software engineers don't have a regular recertification required. Given that and other differences, even this application of the term falls short in comparison to other disciplines.

For the record, I'm still of the mind that "real" engineers are those individuals trained to create physical things built to withstand innumerable stresses, structural material complexities, manufacturing hurdles, and so forth without endangering lives or risking property damage. We software types have sort of usurped the term, for better or worse. It's here to stay, but some kind of indicated specialization known widely beyond our industry could help.

Regarding "full stack" though, there are areas of certain software-heavy industries where that term doesn't matter. Take an avionics "black box" for instance. It can be a strictly embedded device with no concept of a PC-type environment. They almost universally run some kind of RTOS or compartmentalized RTOS, and perform a short, known list of master tasks (10-20 for instance) that will never change. They talk with various hardware in the aircraft and through radios on the aircraft to a variety of ground stations, satellites, and other aircraft. The standards they adhere to (for the physical wiring from box to box, the protocols on those wires, the way the software is designed, etc.) can be 20-30 years old. Those standards can be updated sometimes never, sometimes 2 or 3 times over that span. There's no concept of constantly changing software libraries because it's so SO ridiculously expensive to go through a process called "certification" that reports on exact versions of software working on exact versions of hardware, and then you don't change a thing (not a single resistor, not a single bit) unless you have a very good reason to. Besides knowing your embedded software/hardware craft, the companies that build these boxes want engineers steeped in the guidance and rules of the appropriate regulating body (in this case, the FAA). There's a rep from your company (but representing the interests of the FAA) looking over your shoulder, so to speak, called a DER. That person's job is to put their ass on the line for your company, to the FAA, saying you did what you were supposed to. You have to highly specialize in order to do your part correctly so your DER can do their highly specialized part correctly, so the FAA can approve your company to sell said black box to aircraft manufacturers with an FAA seal of approval. It's a ridiculously intricate, expensive, and time-consuming process that helps to ensure air travel is generally extremely safe. The FDA is about 20 years behind the FAA in terms of dictating what and how, but similar concerns, processes, and regulatory hurdles apply. There's extreme rigor required in these fields, and extreme specialization, because if you screw up you can kill somebody (or lots of somebodies).

[akiselev]

As someone who's worked on consumer electronics (analog + high speed digital PCB design) and software ranging from (research) satellite firmware to an orchestrator for a robotic genetic diagnostics pipeline but now works mostly in frontend/"full stack" roles, I disagree with your characterization of engineering. At it's core, engineering is about wrangling constrained systems to impact the world around you and the people living in it. Corny as that statement is, ounce for ounce, software engineers' sweat go so much further in that regard, for better or worse. The impact is very diffused so its hard to measure and we don't get that new-factory-smell assembled prototype from the fab to hold in our hands, but software has transformed the world around us (in concert with the hardware that runs it, of course) at a staggering pace.

I will say that your description matches what I consider "real" vs "bullshit" engineering - akin to how people refer to "bullshit" jobs. Science is all about discovering the constraints of the physical world and before software, engineering was all about exploiting those constraints to do what we want. Software engineering, however, is unique because its constraints are, more often than not, of our own making. All that time and boilerplate spent managing memory and converting data between all these different formats and representations is our own damn fault, which certainly takes away some of the pride that a mechanical or electrical engineer gets when they trick nature for their own purposes. Software's closest cousin is probably systems engineering and we've massively failed in learning its lessons.

[runawaybottle]

I suppose before I give a thorough response, why compare the apple to the watermelon?

I personally have no clue who the engineers are on this earth that architect a fly-by-wire system. Actually, the complexity and critical nature of it is so beyond developing a UI, that anyone would know the difference.

Now read the last statement above again. Outside of tech, is it truly true that anyone would know the difference? Or are we just ‘IT guys’ to the rest of the world. To fight amongst ourselves over titles, when we ourselves appreciate the differences, can only happen if we are trying to attain external validation.

Case study: Developer A: I am a software engineer at Facebook

Developer B: I am a software engineer at Boeing

Developer A: Billions use my software

Developer B: People die when I make bugs

The problem is not that Developer A and B don’t understand or appreciate the difference. The problem is the rest of the world doesn’t, therefore the industry has zero status. I’m arguing we are manifesting a frustration internally amongst ourselves from the greater sin of lack of respect given to us from outside.

Which brings me to my final point. If there is internal resentment, that a Facebook engineer makes more than a Boeing engineer, then we failed as an industry in not compensating appropriately. If the manifestation is from unfairness, we should examine that. If the Surgeon gets paid less or the same as the Podiatrist, and is resentful and bitter, we need not turn a million stones to find the crux of the matter. And, suddenly, the surgeon yells ‘that foot doctor can’t hold a scalpel if their life depended on it’. Lamentations of a deeper problem amongst ourselves.

All emotions are valid here, as the injustice is consistent and real. For most part, I am trying to distill the dialectal argument into it’s rhetorical form.

[notyourNMI]

I see I must be coming off as more of a grump than I anticipated :) I don't personally harbor resentment over different applications of our industry, but in fact am steadily amazed (befuddled/astounded). The market is what it is, and we individuals are fairly carried along like so much flotsam on the waves.

I agree we're perhaps dickering over distinctions no one external cares about, akin to characters in "Let That Be Your Last Battlefield". Is our internal perspective as valueless as the mindset of those characters above, or is there use in hammering out a common understanding for the general public before it's handed to us?

That being asked, the distinctions may be moot. Most of us have probably 10-20 years of rapidly dwindling utility in our respective realms due to the swift boot that is ML/DL/etc. And your point will remain more poignant at that time: "will anyone outside of our field know or care about the difference?".