Hacker News Reader

Comment by sfn42 | Hacker News Reader

I'm in that boat, everything is just a crud app. I've worked on some fairly complex apps but at their core they were crud apps and most of their complexity were caused by bad developers overcomplicating and fumbling things.

That's not to say something like Figma isn't on an entirely different level, but most apps aren't Figma and don't need to be. Most apps are simple crud apps and if they aren't it's usually because the devs are bad.

It's also worth noting that a crud app can be quite complex too. There can be a lot of complexity even if the core is simple.

I also think that those of us who can recognize simple apps for what they are and design them simply are also the people best equipped to tackle more complex apps. Those guys who can make a simple crud app into an incomprehensible buggy monster certainly can't be trusted with that kind of complexity.

View on HN

> Most apps are simple crud apps and if they aren't it's usually because the devs are bad.

I heard this a lot from candidates who had only worked on software that could be described as an app. They bounced from company to company adjusting a mobile app here, fitting into a React framework there, and changing some REST endpoints.

There is a large world of software out there and not all of it is user-facing apps.

I agree 100%. IMHO this is the software that is vibe-codeable, by the way.

>I heard this a lot from candidates who had only worked on software that could be described as an app.

Similar to that thinking, I made a previous comment how many developers in the "L.O.B. Line-Of-Business / CRUD" group are not familiar with "algorithms engineering" type of programming: https://news.ycombinator.com/item?id=12078147

Vibe coding is easiest for CRUD apps. However, it's useless for developing new scientific/engineering code for new system architectures that require combining algorithms & data structures in novel ways that Claude Code has no examples for.

I can attest to that. I was using Gemini to help with some spherical geometry that I just couldn't figure out myself. This was for an engineering system to define and avoid attitude deadzones for a system that can rotate arbitrarily.

About 75% of the time the code snippets it provided did what it said they did. But the other 25% was killer. Luckily I made a visualization system and was able to see when it made mistakes, but I think if I had tried to vibe code this months ago I'd still be trying.

(These were things like "how can I detect if an arbitrary small circle arc on a unit sphere intersects a circle of arbitrary size projected onto the surface of the unit sphere". With the right MATLAB setup this was easy to visualize and check; but I'm quite convinced it would have taken me a lot longer to understand the geometry and come up with the equations myself than it actually took me to complete the tool)

Aye.

One my standard coding tests for LLM is a spherical geometry problem, a near-triangle with all three corners being 90 degrees.

Until GPT-5, no model got it right, they only operated in the space of a euclidian projection; perhaps notably, while GPT-5 did get it right, it did so by writing and running a python script that imported a suitable library, not with its own world model.

is Claude Code actually useless or is is a prompt engineering/context issue?

Do you have any advice for entering group 2? I graduated university expecting to at least see jobs that needed those skills at least some of the time, but the hardest problem I've worked on was a variant of the knapsack problem and it happened in my first year out.

Take a look at the data storage industry, e.g. EBS and EFS teams at AWS, pure storage, net app, etc. The people there who work on the filesystems and block data path are doing legit applied computer science. I did it earlier in my career and it felt like being at Bell Labs in the 70s and 80s.

I haven't done anything with an UI for decade and a half. Backend integrations, data transformations, piping, transfer protocols and so on. Javascript hell avoided so far. No thank you

Just to interject one bit... I actually really like JS/TS for basic data transformations, piping and ETL type work in general. If you understand how type coercion works with JS it can be really powerful as a tool for these types of workloads.

Meanwhile, for actual low-level work data is bytes not Javascript objects in memory, and Javascript is a miserable tool for transforming/processing bytes.

Agree

I work on a vision based traffic monitoring system, and modelling the idea of traffic and events goes into so much complexity without a word of code written

These people are working on problems that have tutorials online and dont know that someone had to make all that

If you're going to deny people just because they haven't had a chance to work on more exciting stuff yet you will skip a lot of good candidates.

> It's also worth noting that a crud app can be quite complex too. There can be a lot of complexity even if the core is simple.

I suppose technically a database is just a CRUD app

Yeah, that's essentially what I mean when I say crud app. It's basically a web api written in something like C# or whatever you prefer, which receives HTTP requests and translates them into DB operations. CRUD and views basically.

For this type of development you want the DB to handle basically all the heavy lifting, the trick is to design the DB schema well and have the web API send the right SQL to get exactly the data you need for any given request and then your app will generally be nice and snappy. 90-99% of the logic is just SQL.

For the C# example you'd typically use Entity Framework so the entirety of the DB schema and the DB interaction etc is defined within the C# code.

I prefer to just use Dapper for most DB interactions with C#... EF (and ORM tooling in general) can come with a lot of gotchas that simply understanding the SQL you are generating can go a long way to avoid.

Dapper is nice, but what you don't get as far as I know is migrations. With EF the app just spins up the whole DB from scratch which is great for onboarding or when you just needed a new laptop etc. Also EF is fine as long as you know what you're doing, or at least pay attention to what you're doing.

I use grate for migrations. I prefer a more manual, hands on approach to that as well.

I think you're missing the point of the comment you've replied to. That comment is talking about implementing the DB. When you're implementing a DB, you can't just forward reads and writes to another DB. Someone has to actually implement that DB on top of a filesystem, raw disk, or similar storage.

With the post's logic if you work on DB you likely have an SQL engine that is a CRUD on top of storage engine. And storage engine is a CRUD on top of some disk storage, which is CRUD over syscalls on files. Think Mysql using MyRocks using RocksDB. And keep applying until there's no sense left.

If you are referring to my post, it's about web applications. I'm not in any way claiming that postgres is a crud app. I'm describing how to design a good web application that mostly revolves around a database. Which is what people mean when they say crud app. It's just any app that's mostly crud. Where the majority of the logic can be handled by the database like I described.

A lot of apps are just about putting data into a DB and then providing access to that data. Maybe using the data to draw some nice graphs and stuff. That's a crud app.

I was actually going for the opposite point - databases generally meet the definition of CRUD app. You create rows, read them, update them and delete them (literally SQL verbs INSERT, SELECT, UPDATE, DELETE). But they are highly complex pieces of software. People who program them are generally hard core.

I think databases are more of the development environment for such apps, rather than the apps themselves. C.f. how Electron apps are "just web pages shipped with their own browser", and yet a browser (and its JavaScript runtime) are significantly more complex than almost any app built in the manner of an Electron app.

> I'm in that boat, everything is just a crud app. I've worked on some fairly complex apps but at their core they were crud apps and most of their complexity were caused by bad developers overcomplicating and fumbling things.

Far too much of my recent work has been CRUD apps, several with wildly and needlessly overengineered plumbing.

But not all apps are CRUD. Simulations, games, and document editors where the sensible file format isn't a database, are also codebases I've worked on.

I think several of those codebases would also be vulnerable to vibe coding*; but this is where I'd focus my attention, as this kind of innovation seems to be the comparative advantage of humans over AI, and also is the space of innovative functions that can be patented.

* but not all; I'm currently converting an old C++ game to vanilla JS and the web, and I have to carefully vet everything the AI does because it tends to make un-performant choices.

Sometimes complexity exists because what you're doing is complex and their is a minimum to how simply it can be abstracted.

Yeah, but based on my own experience, most of the time complexity exists because devs suck. I know because I've simplified lots of code written by others, because rewriting it is simpler than maintaining their huge mess.

Or because they used the project as an excuse to learn a complicated but (in this case) unnecessary framework or technology stack as an resume enhancer.

Why wouldn't figma be considered a crud app? It’s still basically adding and updating things in a DB no? With some highly complex things like rendering, collab and stuff. (Fair question btw)

It's very, very far from a CRUD app or "just updating a DB". GUI-heavy apps are notoriously hard to get right. Any kind of "editable canvas" makes it 10x harder. Online collaboration is hard, so that's another 10x—there are known solutions, but it's an entire sidequest you have to pour a massive amount of effort into.

Custom text editing and rendering is really hard to do well.

Making everything smooth and performant to the point it's best-in-class while still adding new features is... remarkable.

(Speaking as someone who's writing a spreadsheet and slideshow editor myself...among other things)

It is a CRUD app, though, which is why that classification isn’t generally meaningful. CRUD basically just means the app has persistent storage.

"Having CRUD operations" and "Just a CRUD app" are very different things.

The custom text rendering bit alone should have been a good cue for this distinction.

That was the point. It is a CRUD app but it is not just a CRUD app.

When people say "a CRUD app" they mean "an app that is mostly just CRUD"

This might have been the response trcf22 needed.

But sure, I’m being too pedantic here I suppose.

I'm trying to imagine a scenario with a non-trivial app that is missing a create, read, update or delete operation. I'm coming up with so few examples that I have to imagine the colloquial use of CRUD app means just CRUD operations.

You should look into figma. Its one of the few marvels of software engineering made in recent times.

If you want to know how tough realtime editing is, try making a simple collaborative drawing tool or something. Or an online 2 player text adventure game

Theres a reason tutorials for those arent common

What makes Figma more complex?

Collaboration and the whole editor UI in general is a much more complex task than your average glorified PDF with some dynamically rendered data.

It's not the Pinnacle of complexity, just more complex than your average app.

I'd say the multi-user aspects and level of scale add quite a lot of complexity in to the mix.

Check out their old blog post on how they got real-time collaborative editing without conflicts to work: https://www.figma.com/blog/how-figmas-multiplayer-technology...

Reply on news.ycombinator.com