[mhfu]

Yep. I build glorified CRUD apps in NodeJS + React, my friend works on some embedded C++ stuff.

- My working hours are way more flexible. I pretty much only have to attend meetings which are rare, so I can basically work whenever I want during the day. That means that I can go to the dentist and stuff like that without taking the day off. She has pretty strict hours.

- I can work from anywhere, only requirement is decent internet connection. She has to go to the office because that's the only way she can actually test the code she writes for physical devices.

- My salary is basically double of what my friend makes.

She's currently learning JS so she can just move into web space. If someone can choose between easier job with much better salary, benefits and working conditions, they will do that without thinking, unless they reeeeeally like C++.

[colinjoy]

Probably less related to C++ as a language and more so an "embedded" issue or down to the specific industry that your friend is in.

E.g., there are hundreds of C++ devs at my company that have the same work from home options and flexible hours as their frontend peers. So these jobs exist.

[PartiallyTyped]

Agreed. My friend - a kernel dev - and I - a non-specialized SDE - have the same benefits and flexible hours.

[electrondood]

> glorified CRUD apps

Why is API design/backend engineering the only software discipline that gets maligned like this? These are bread-and-butter operations. I don't mean to attack you, just noting that I never hear anyone talk about mobile development in the same way, for example.

[WorldMaker]

A lot of CRUD app development feels like tedious, repetitive busy work. Data entry was a solved problem in COBOL if not earlier, it's not gotten any harder in the decades since, it's just gotten more tedious.

There are generic data entry tools that solve the entire class of problems in that space. In web tooling there are things like Django's Admin app. In "the ancient world" there is Excel for good and bad and ugly. But those aren't "branded" enough. Those aren't "experiences" that some UI designer has sweated and cried over until they were beautiful. Those "don't understand the domain" or "don't support our processes" or "don't know that we are a special snowflake with special snowflake data" hard enough.

So you just rebuild the same types of things over and over again every time the UI designers get bored or the company decides to use a slightly different version of the same data. Sometimes it can feel a bit Sisyphean.

[FredPret]

The same can be said for dentists or architects or chemical engineers or whatever. Teeth and houses and oil refineries are “solved” problems in that we know how to do it.

But each instance is a little different. Each customer wants their flavour of the problem solved.

Long story short: don’t get into a line of work if you don’t like churning out multiples of the same thing for years.

[WorldMaker]

> The same can be said for dentists or architects or chemical engineers or whatever.

- Dentists have dental hygienists that do the day-to-day grunt work so that dentists can focus on the real problems/exceptional cases (cavities, root canals, etc).

- Architects build the plans, but they leave it to construction workers to actually construct the project.

- Chemical engineers generally work with staffs of chemists and other roles that the take the engineered solution and apply it day-to-day.

Right now, software uses the same job titles "for everything". There's (perhaps intentionally) no differentiation between the people expected to solve the hard problems/engineer the tough solutions and the people hired to plug-and-chug their way through their 15th yet-another-CRUD-app that year. There are complaints in the surrounding threads even that some of the "drone work" pays better salaries and has better hours/corporate cultures than the harder stuff. It's an interesting "upside down" situation compared to even just the three fields specifically referenced here.

I went to an engineering school with the expectation that I would be doing software engineering not just in name but in role, but most of the jobs I've ever worked were paying me to do not that. I certainly know friends who are chemical engineers that also perform the role of chemists for their companies, but those are clearly distinct enough job descriptions with a big enough salary distance that those companies know that any hours my friends put in as chemists rather than their hired job is over-paying those hour rates by a considerable enough amount that they have reason to hire cheaper chemists. I have never seen a software job consider that they may be hugely over-paying a software engineer to do "software development grunt work". Without truly separate job titles and salary considerations that is forever going to be opaque to the accountants at companies.

Long story short: other professions clearly delineate between jobs that are (creative) problem solving and jobs that are more "grunt work" like Ikea-assembling CRUD apps. Why don't we?

[ZephyrBlu]

> Long story short: other professions clearly delineate between jobs that are (creative) problem solving and jobs that are more "grunt work" like Ikea-assembling CRUD apps. Why don't we?

Is that even possible? It's difficult to separate grunt work and problem solving, because you often need similar levels of context to solve both. They also tend to intertwine a lot.

[WorldMaker]

Of course it is possible. There's just currently more reasons for companies not to care and not to do it than to do it: Capital P Professions have education requirements and licensing/certification commitments. Capital P Professions have ethics bodies and mandate professional standards. Capital P Professions have professional societies that sometimes can organize industry wide negotiations (not quite to the same extent as Unions, but kin to it).

I don't think it is a technical problem keeping software from better sorting its various types of jobs by difficulty and types of problem solving. I think it's far more corporate politics and sociopolitics and a general lazy preference for the current status quo (because it works to company's favors in terms of job description opacity and keeping pay scales confused and under-valued and, uh, not having to worry about "quaint" "old timey" things like professional ethics investigations).

[klabb3]

I think there's truth to this but you're glossing over details that are critical. If the amount of variation between products were countable and predictable as you paint it, then you'd only need designers and a cms specialist who can configure the product. As a web shop, this is much cheaper to do. There are tons of website builders today which has saturated the "simple" market, but "intermediate" customers have small variations that still need custom integration work.

All in all, saying that dev work is repetetive is a hard sell, because if it was, you could just automate it. And we clearly haven't automated even the space of medium-complexity web apps yet.

[WorldMaker]

I pointed to two clear examples where we as an industry have automated it (Django's Admin app, Excel), and I could name tons more (Access, Power Automate, InfoPath, Power Apps, SharePoint Apps, SharePoint Lists, and those are just the Microsoft side of the list; you mention CMS specialists and we could list out of the box CMSes for days).

> still need custom integration work

Define "need" here. I already threw some shade at this by accusing many companies of thinking their every need is a special little snowflake that needs lots of custom tweaks and custom specifics. In my practical experience so much more of that is "want" rather than "need". They want to feel special. They want to feel like they have control. They don't want to pay for the cheap out of the box CMS because it might imply to their executives and shareholders that their entire business is cheap and easily automated.

Some of these CRUD apps are truly "John Hammond syndrome" apps: they want the illusion that no expense was spared. (And just like John Hammond sometimes confusing building out the gift shop and adding fancy food to the restaurant in the Visitor Center with spending enough on redundancy among the critical operations work and staff.)

[jonnycoder]

As someone who has done .NET, C++ embedded, Python and NodeJS, I have to say that picking up NodeJS and creating APIs at scale with full automated nightly test suites using docker and postman/newman was very easy to learn and very fun. Python is up there as well but I had to work on Django and not some of the more simpler api frameworks that looks nice.

[fiedzia]

> In web tooling there are things like Django's Admin app.

Which is great - for creating custom admin panels easily. You can't use it as "generic app" you just turn on and it works, so someone has to do it.

[mhfu]

It's not maligned. I've worked on some complex backends some time ago and I would never call those glorified CRUD apps. But my current project is basically Node backend with almost zero business logic. You hit GET endpoint, it returns someORMRepository.find('events').where({ category: 'FUN' }). That's it. React side displays a table with some basic sorting and filtering. Editing and creating and entry is just a basic form. I don't see how else could I call it, it's not that much different from CRUD demos you see in blog posts.

[Tomis02]

> Why is ... backend engineering the only software discipline that gets maligned like this?

Where do I even begin? The intrinsic difficulty of most backend problems is very low - read some customer data, save it to a database, call an external API, send data back to customer. The only effort you should have to put in is fighting boredom.

The web dev industry managed to overcomplicate this task to the point where even small startups targeting niche markets have architectures inviting race conditions over distributed systems with tens/hundreds/thousands of working parts.

It doesn't have to be like this. The problem is that your average web dev doesn't know how to scale down (optimize for space/memory/disk consumption), so instead they scale up (more computers). Scaling up isn't necessarily a problem if you know what you're doing, but I've seen a bunch of super-principal engineers regurgitating the popular scaling up buzzwords without actually understanding the tradeoffs. They choose a technology because Google is using it.

It's not fun to fix deep systemic problems in distributed systems when the system has already been running for a long time, and there's a large number of devs working on it. You can't just say "ok, everyone stop working, for a while, we'll take a couple of months to rewrite everything, the customer can wait".

What's worse it that this type of issues would've been obvious from the very beginning to anyone mildly curious to imagine what the future of such a system would look like.

Another type of common issue is slow queries, and the common "solution" results in eventual consistency.

I'll stop now.

> I never hear anyone talk about mobile development in the same way

Mobile development is just as bad, maybe worse. One overly complicated framework (Android), and another one that's fenced-off to non-Mac developers.

[epolanski]

> Why is API design/backend engineering the only software discipline that gets maligned like this?

It's web development in general.

[philote]

Why does that seem maligned to you? I don't see it as negative at all, just descriptive.

[colinmhayes]

backend web dev can feel tedious/monotonous imo.