this post was submitted on 29 Jul 2024
127 points (92.6% liked)

Programming

17022 readers
239 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] leisesprecher@feddit.org 17 points 1 month ago (1 children)

I've written it countless times before, but software engineering desperately needs to do some engineering.

What you're describing is absolutely true, but compare the way you're working with an actual engineer. No sane engineer would start investigating the production process of a steel beam just to build a regular old warehouse. The steel beam has certain characteristics and unless you have very good reasons, you don't need to question that.

We are software developers however need to know a lot of our steel beams and can't rely on many of them. That means even simple stuff takes forever and we tie ourselves to it way more than we should.

[–] masterspace@lemmy.ca 7 points 1 month ago* (last edited 1 month ago) (1 children)

Again, I used to work doing actual electrical engineering, working at an architecture firm designing bridges and buildings, and what you're describing as "actual engineering" is the whole reason I went into software.

Because if the actual engineering you're doing is just combining a lot of well defined parts to fit certain acceptance criteria, then you don't really need a person doing that, software can do it.

[–] leisesprecher@feddit.org 1 points 1 month ago (3 children)

But that's exactly what's holding us back.

Let's divide the problem sphere very broadly into business and technical. The business problem is "I want to store an order" the technical problem is "We need to connect to a database and map our data onto the table structure".

What we should be doing is solving the technical problem once, and then map thousands of business problems onto that. But instead, the same technical problems are solved again and again, even though there is a technical solution, because that solution is too leaky for us to rely on.

I don't want to write the 200th iteration of basically the simple problem again and again. I want to solve the actually hard problems. Yes, software can do the simple stuff, that's what's the entire point of our profession. Every developer should try to make themself obsolete.

I don't want to sound harsh, but your sentiment reminds me a lot of the "back when men were men and wrote their own mouse drivers" comments from ye olde time. But that's not what our job is about.

[–] masterspace@lemmy.ca 7 points 1 month ago* (last edited 1 month ago) (1 children)

Quite frankly I don't really know what you're complaining about. You're literally describing how we reuse standard database technologies like SQL, or standard patterns like REST, or standard application and data access frameworks, which we do literally all the time.

[–] leisesprecher@feddit.org 1 points 1 month ago (1 children)

Quite frankly, I think you don't understand what I mean.

Don't kid yourself, "patterns" are boiler-plates so common they have a name. Yes, SQL makes things much faster, but that's just the beginning. As soon as you venture out of the almost trivial cases, things get ugly fast. Think about something as simple as a form. That's a standard problem. But I can't just write down a "form-spec" and have a frontend and backend for that. No, I need a bunch of libraries that don't quite work together and need a lot of persuasion to work together.

Or think of Rest-APIs. How many times could you really just ingest a spec and have everything working as expected? That's very rare. Some libraries are plain weird, some don't support certain aspects of what you want, etc. etc. etc.

A simple CRUD app should not require a single line of code. Yet, 80% of us are essentially doing exactly that.

[–] masterspace@lemmy.ca 5 points 1 month ago* (last edited 1 month ago)

Think about something as simple as a form. That's a standard problem. But I can't just write down a "form-spec" and have a frontend and backend for that. No, I need a bunch of libraries that don't quite work together and need a lot of persuasion to work together.

You can just spin up a Next.js project complete with API calls and ready to go forms. Pick a full stack framework and go with it, there are several.

The larger reason that there is separation between front and back end though is that there is intentional decoupling between them because the backend might also be responding to requests from native applications, or other servers.

Hell, what you're describing with Gui based application builders also exist everywhere. That's basically airtable or salesforce or flutterflow, and guess what, those applications all kind of suck because a form is not as standard as you think. In a good application, there will always be customized design, flow and logic that happens to capture user input on the frontend, and on the backend there are a myriad of reasons to optimize different databases for different things. Look at the limitations you run into with Salesforce and Airtable databases because every database needs to have a whole plethora of features just to support the frontend Gui interface to manipulate them. I mean if you just want a flat form use Google forms, if business logic starts connecting some of the fields with complicated relationships and flows then suddenly things aren't so standard.

[–] Corbin@programming.dev 3 points 1 month ago

You're not crazy or harsh. This is a very real problem. I have been stuck doing business development at every company I've worked for. There's always some shitty load-bearing Django app whose schema determines what the business is capable of doing, and somebody's gotta maintain it. It's gotten to the point where I assume that any interesting things I do will be outside of work and not for pay.

[–] CodexArcanum@lemmy.world 0 points 1 month ago

This is still a business problem. The truth is, we solved basically all the technical problems that could be practically solved by the 2010s. We have all the technology, we know what people want and need. We could, and should, build a lifetime personal computer (phone form factor) for every person on Earth that provides for their communication needs, acts as a personal assistant and organizer, and more. And we've had those, dozens if times.

But how do you keep selling people stuff once you've met all their needs? You tear it all down and keep rebuilding and reselling it. You enshittify to squeeze money out, customers flee, so you encircle them with another capitalist enclosure and rebuild the same shit again. Repeat.

Software devs should basically all be making games and trying to teach AI to be smarter but instead we're replacing internet search (a problem we solved in the 90s!) with LLM enabled advertising engines that literally can't find info for you so they make it up. And we're iterating on the 10 thousandth version of an e-commerce site because all internet shopping is part of a giant global MLM now. Seriously, "drop shipping" is the latest iteration of the same old scam they used to run on diet pills and knives and magazine subscriptions.

But every college student with a fresh business degree can set up a Wix site to resell sunset lamps. It's uber for scams. The reseller takes on all the risk, sets up the e-commerce site with a builder, firehoses ads all over their social media, and does all the work. There are multiple industries now entirely supported on conning desperate people into being your salesforce, workforce, advertisers, and customers all at the same time.