Not only do the CRUDs have value but they're good for your sanity. I knew a guy back in the dot-com era. Very skilled coder. Backbone of the company. He pulled off miracles. Fulfilled impossible deadlines. Then one day, out of the blue, he quit. Took a job at a non-technical corp. They put him in a cubicle where he wrote Visual Basic CRUDs on an 8-5 schedule. No weird deadlines, no sleeping under the desk. He called it his paid vacation.
> They put him in a cubicle where he wrote Visual Basic CRUDs on an 8-5 schedule. No weird deadlines, no sleeping under the desk. He called it his paid vacation.
That was all nice and good for a while, but the times are ending.
I suspect there will still be a human involved in the production of software, but it will be domain experts, not CRUd monkeys who picked up just enough domain knowledge to be dangerous.
The really valuable CRUD monkeys are already domain experts as well. The threatened ones are junior developers whose output is barely better than AI slop.
> The really valuable CRUD monkeys are already domain experts as well
Sure but that’s a minority I’d argue. There wouldn’t be such a volume of shitty business software otherwise.
I will be interested to see if there are any economic effects of ending one of the last well paid, low barrier to entry careers in which some level of meritocracy was permitted.
You can tell from my comment that I'm not AI. I've had a lifelong habit of using commas instead of dashes in situations where the dashes would have been more appropriate. AI would always go for the dash.
The grass is always greener on the other side - many low-level programmers feel like an imposter when it comes to high-level systems such as CRUD apps.
Can confirm, my buddy who is someone I respect immensely, is an embedded programmer.
He will talk about OS events, or any low level concept and it makes me feel like I don’t know anything, but he acts like I’m a genius if I talk about JavaScript Runtimes, browser engines, anything frontend.
It’s cool he teaches me new things, I teach him some
Some people are exceptional at solving difficult but hard to explain problems while other are great solving direct business problems. No need to feel ashamed for both it’s just different work
Most people know that there is a big difference between experience in something pretty easy vs mastery of something very difficult.
A rocket scientist acknowledges a concrete guy knows way more than he does about concrete, but also knows that doesn't make him a genius because it's easy enough to learn just being around it. Plus, the rocket scientist also knows that since he knows so little about concrete, he wouldn't even be able to judge if the guy is really a concrete genius or just saying things a real pro would label wrong.
Your example isn't that crazy, but still, you should realize your friend is just being nice.
I work on OS/embedded and my wife in server backend. I definitely feel like a simpleton when trying to understand all of the high level stuff she works on. It doesn't invalidate my own expertise. There is nothing wrong with acknowledging someone has skills that you don't have and likely would take a long time to pick up.
Yeah exactly. High-level people think the low-level stuff is magic, and us from the other side think the high-level stuff is magic (how can you handle all that complexity?...)
I felt this way moving from embedded into backend for the first time and having no idea where to start. Was incredibly daunting, but both domains become trivial over time.
Trivial under plan9/9front. Under Win32/POSIX, run way.
On bit shifts, pick any Forth programmer and shaders will be almost like a toy for them. They are used to implement double numbers (and maybe floats) themselves by hand by just reusing the only integer numbers they have and writting custom commands to output these pairs of integer as double numbers. They can probably implement multithreading processing by hand in Forth and also know the IEEE standards for floats better than C programmers over 20 years.
I know literal kernel developers who can handle drivers and race conditions any day of the week who can't wrap their mind around Outlook, let alone GUI updates.
Myself. Forth it's easy, 9front C it's manageable but POSIX it's hell and managing both Unix descendants are a piece of cake.
GUI interfaces for the enterprise came from Dante's hell themselves. I hate them, they are like the Madhouse from that Asterix movie making satire of the European bureucracy of the day. The often are oddly designed and they are not documented at all, you must guess the meaning by chance of with a senior tutoring you.
The same with anything corporate from Microsoft with AD roles/group policies and the like. Or anything coming from IBM.
lol you guys are being too nice. Building CRUD apps is just implementing business logic by gluing APIs together, there is nothing to understand except the business domain, which is only done through exposure, because business logic is random. And then the APIs which are all essentially a kludge because of the shifting business logic.
Understanding low level code puts you on entirely different level because you can reason about a problem using logic and how systems operate.
No disrespect to any crud devs here but from my personal experience they just know a particular implementation of their domain and rarely even consider how the code base even operates as a whole
> lol you guys are being too nice. Building CRUD apps is just implementing business logic by gluing APIs together, there is nothing to understand except the business domain, which is only done through exposure, because business logic is random.
It isn't "random", a as business process develop over time to various business/customer/regulatory needs. The business process evolves over time typically.
When you take a business process, you are often formalising it. The fact that you have no appreciation of this, tells me you don't really understand what you are talking about.
> Understanding low level code puts you on entirely different level because you can reason about a problem using logic and how systems operate.
You have to do this in high level languages as well. It isn't something that only low level devs do. In fact to be able to write any good code you need to understand the problem domain.
> No disrespect to any crud devs here but from my personal experience they just know a particular implementation of their domain and rarely even consider how the code base even operates as a whole
You are literally disrespecting them by saying this. It is also false, what you are describing is developers having deal with incomplete/poor specifications and poor documentation. BTW this is rampant through the industry. I wanted to do some stuff yesterday with Docker and Go, the documentation is non-existant.
I work on compilers, and have bounced several times off trying to write my own full stack crud app for a personal project (tried doing it in rails, phoenix and django at various times). I'm finally getting somewhere with claude's help, but it really is its own set of skills - easy to get started with but hard to do well.
You may be surprised by how much easier it is to dump the framework/stack and just write it from scratch. I say this because I too work on compilers and have a crud app as a personal project. The first versions were a nightmare in various frameworks and since I switched to a C++ backend / vanilla .js frontend it has been incredibly easy to write.
no database for this project - the data model has a simple text representation so it gets serialized out to a folder/file layout on disk that goes into version control. single self-contained binary: contains the web/websockets server, backend logic, parser/serialization. there is a separate component in python that sits behind an internal network connection to handle an execution sandbox.
You can probably learn to do these things too with enough determination, but don't sell yourself short. Some CRUD apps can get deceptively complicated. Businesses have a way of coming up with just the right requirements to completely invalidate your architecture if you don't know what you're doing.
As someone who works on systems at this level, believe me, it’s a learnable skill. And at least an intellectually valuable one I think too. Even if you never really need the knowledge for the things you do, there’s a nice feeling that comes from seeing something done at a high level and understanding how that makes its way down into the system and why those design choices were made.
If I were more money motivated I’d probably be building CRUD apps too. I just like weird puzzles XD.
Start working through the layers! It's incredibly rewarding to go from just typical day job stuff to understanding bits and pieces of esoteric low level implementation. One level at a time, it's not that bad, although it is hard and takes effort. I know next to nothing either, but having felt the same way a few years ago, these kind of posts now at least excite me instead of just intimidate.
I am a normal web dev / CRUD app coder. All of this isn't beyond your ability.
Every so often I hit a problem that requires me to go all the way down to the OS level and find out what is going wrong or into the core framework and you find out that most of the code is actually less complex, better documented and clearer than a lot of the garbage bespoke applications you have to deal with at the higher levels.
You’re still an engineer. Knowing the right places to click in an esoteric app is like knowing where to hit the boiler with a hammer to get it working again.
Why do people belittle CRUDs? Or even call them that? I have written quite a few applications, where there was a frotend which displayed things stored in a SQL db, with certain operations allowing you to modify said db, which I guess would fall into the CRUD variety, but the least of the complexity, and usefullness lay in that fact.
Plenty of business apps don't really ask for much more than that, and those are the CRUD apps. They're not particularly challenging to write, nor is it very interesting to do so.
I knew what an SRE was and found the article somewhat interesting with a slightly novel (throwaway), more realistic take, on the "why need Salesforce when you can vibe your own Salesforce convo."
But not defining what an SRE is feels like a glaring, almost suffocating, omission.
I'm a software engineer working to help people build products and deliver value to their customers.
I can help build: - web applications using modern principles with the latest technologies (Angular, React, TypeScript, Vue, TailwindCSS, HTMX); - services that monitor equipments using telecommunications protocols (SNMP, NETCONF, TR-069); - serverless programs on any business domain to help reduce costs and increase availability (AWS Lambda); - microservices that expose REST APIs for consumption using battle-tested frameworks (SpringBoot, Quarkus); - data processing applications and services that consumes streams of data using common parsing techniques (Rust with Nom); - small CLI apps to help automate common tasks (Rust); - integration of different services using distributed log (Kafka, AWS SNS), WebSocket (with NodeJS) or with simple HTTP requests; - proper documentation for common services using OpenAPI specification and/or frameworks such as Diátaxis (Swagger)
What I’ve built:
Recently developed a chatbot MVP for a small business (DJ & lighting rentals) — scraped/cleaned product data, embedded it with HuggingFace + Chroma, and served responses via FastAPI with a streaming API. Integrated React front-end for chat UI. Prior experience building automation/scraping tools and full-stack prototypes.
What I’m looking for: Full-stack or backend-leaning role (internship, entry-level, or startup contract) where I can ship fast, learn in the trenches, and contribute to real product outcomes. Interested in early-stage startups that value initiative and flexibility.
Email:
pfrase4@wgu dot edu
pfras@protonmail dot com
Why would you want to abstract away the underlying database?
Wouldn't it better to already use the target DB to cattch potential issues earlier? Also to avoid creating another layer of indirection, potentially complecting the codebase and reducing performance?
Primarily for libraries and deployment environments that aren't fully in your control which is still pretty common once you get to B2B interactions, SaaS is not something you can easily sell to certain environments. Depending on the assurance you need, you might even need to mock out the database entirely to test certain classes of database errors being recoverable or fail in a consistent state.
Even in SaaS systems, once you get large enough with a large enough test suite you'll be wanting to tier those tests starting with a lowest common denominator (sqlite) that doesn't incur network latency before getting into the serious integration tests.
I'm a software engineer working to help people build products and deliver value to their customers.
I can help build: - web applications using modern principles with the latest technologies (Angular, React, TypeScript, Vue, TailwindCSS, HTMX); - services that monitor equipments using telecommunications protocols (SNMP, NETCONF, TR-069); - serverless programs on any business domain to help reduce costs and increase availability (AWS Lambda); - microservices that expose REST APIs for consumption using battle-tested frameworks (SpringBoot, Quarkus); - data processing applications and services that consumes streams of data using common parsing techniques (Rust with Nom); - small CLI apps to help automate common tasks (Rust); - integration of different services using distributed log (Kafka, AWS SNS), WebSocket (with NodeJS) or with simple HTTP requests; - proper documentation for common services using OpenAPI specification and/or frameworks such as Diátaxis (Swagger)
I'm a software engineer working to help people build products and deliver value to their customers.
I can help build:
- web applications using modern principles with the latest technologies (Angular, React, TypeScript, Vue, TailwindCSS, HTMX); - services that monitor equipments using telecommunications protocols (SNMP, NETCONF, TR-069); - serverless programs on any business domain to help reduce costs and increase availability (AWS Lambda); - microservices that expose REST APIs for consumption using battle-tested frameworks (SpringBoot, Quarkus); - data processing applications and services that consumes streams of data using common parsing techniques (Rust with Nom); - small CLI apps to help automate common tasks (Rust); - integration of different services using distributed log (Kafka, AWS SNS), WebSocket (with NodeJS) or with simple HTTP requests; - proper documentation for common services using OpenAPI specification and/or frameworks such as Diátaxis (Swagger)
