Give Me a CRUD Slinger

I joined a small company that had built a CRUD app with 20 tables — basically a "notes" app — and was actively selling it to government agencies for insane money.

We had 3 (three) T-H-R-E-E user statuses: Anonymous, LoggedIn, PhoneConfirmed. A young talent before me saw a graph in this and wrote a 200+ line class implementing the Floyd-Warshall algorithm, bolted on a state machine, and — finding no more interesting challenges — aced an interview at Yandex and left.

I was hired as a senior, and I confess I didn't understand a damn thing. The algorithm worked perfectly for the first transition but glitched on the second. I glumly Googled the algorithm, deleted everything, and wrote: if(status==LoggedIn & phone!=null){status=PhoneConfirmed}.

One colleague looked at me with silent gratitude. But the boss was shocked and said my code was "not extensible" and "hardcoded," while that algorithm could traverse a thousand nodes in O(log N) time. When my probation ended, they fired me because my "technical level didn't meet their high standards." They did give me three months' salary though, and I'm grateful for that. They kept my code — they never managed to fix the other one.

That was the introduction.

The Push Notification Problem

Dear Yandex, Sber, and all the rest! I can solve problems fast and multiply output through simple solutions. I am the smartest programmer among all your employees! I am a Super-Ultra-Senior! Let me prove it.

Because only I can solve the problem you've been unable to fix for 10 years. When you get a push notification or SMS and your popup says:

"Your six-digit access code for our app: 123..."

...and then you have to tap somewhere and go somewhere and the app closed and where did it go and was that a push or an SMS or maybe it was Telegram?

Just change the push message to:

"Code: 123 456"

If not a single programmer at your company figured this out — but I did! You owe me five hundred bazillion for the consultation. If there's someone smarter than me there, explain to me why the hell you can't fix this godforsaken nonsense?

This Article Is For People With My Stack

I work with Spring/Java, frontend in React. REST, Kafka, microservices. There are thousands of us.

I know other programming domains exist that genuinely require algorithms, graphs, and heavy math. I've never encountered them in my work. This article is not about them.

Yes, I know that even in Java CRUD-slinging, you can easily introduce a touch of mathematical madness where a Nobel laureate in mathematics would struggle, and you'd need high-level seniors just to fetch a user by ID from the database. Whoever does that is a scourge unfit for programming — not a genius, unlike the example at the beginning.

If you need a shelf mounted, you'd probably lose your mind if the handyman spent a month building a levitating holder that doesn't actually work but emits radiation. Sure, he's very smart — smarter than me. But I'll mount your shelf in 10 minutes.

What follows is a set of simple rules. The rules are stupid simple. I don't understand why so few seniors are able to follow them.

Rule 1: Variable Naming

IDENTICAL!!!! Not different!!! Letter for letter! If in the database your user table has a field userName, then your User entity must have userName, and your UserDto must have the field userName.

What's so hard? Why does your entity say Person with a field login, while the DTO says Human with a field firstCred?

By analogy: UserController, UserService, UserRepo. I understand you have a rich vocabulary and suddenly decided you came up with a better name. But either rename everything, or stick with what you have.

It's especially infuriating when this passes through a chain of microservices where each microservice arbitrarily renames things.

Isn't Rule 1 easy to follow?

Rule 2: 20 Lines Per Method, 200 Lines Per Class

20 is less than 25. You're seniors — you can count to 20, right? And to 200, when you need to split a class in half. What's so hard?

And yes, tiny classes are unnecessary too. 100-200 lines is optimal.

Rule 3: Polymorphism

I love code like this:

class Animal {
    String type;
    voice() {
        if (type == "dog") -> "woof";
        else if (type == "cat") -> "meow";
        else -> "unknown";
    }
}

But then the corporate programmer shows up:

class Cat extends Animal implements Voiceable {
    @Override
    voice() { return "meow"; }
}

class Dog extends Animal implements Voiceable {
    @Override
    voice() { return "woof"; }
}

abstract class Animal implements Voiceable {
    String type;
}

interface Voiceable {
    voice();
}

Here's the thing: the first code is shorter and runs faster. And it's easier to read because it's all on one page, not scattered across 4 different classes. If you can do it with a switch statement, do it with a switch statement. Don't assault people's brains with your polymorphism!

Rule 4: Code Duplication

This is where it gets nuanced — not all seniors will understand. If you take a child and ask them to count the number of times the word "Voiceable" repeats, they'll say 4. If you take a senior, they'll say "polymorphism." A senior can crank out a dozen polymorphic classes that are 96% identical, differing by one line — and that's "correct" and "polymorphic," like the example above. But they'll have a meltdown if two adjacent methods share one identical line.

Code duplication improves readability and speed-reading. Extracting code from a method into a separate class or method forces you to navigate to other classes. Seniors can't grasp this delicate balance because seniors are very smart — they remember a lot, and if an ordinary mortal prefers a logical unit of code on one screen, a senior can correctly juggle two dozen classes at once, so their balance is heavily skewed toward overcomplication.

But even here there's a simple rule that even a senior can understand: after removing code duplication, the total line count should decrease, not increase!

If the line count decreased by less than three times, put it back! It's easier to read that way.

Rule 5: Loose Coupling

If an interface has only one implementation — get out of here with your coupling and other nonsense. Code should be concise. Remember the duplication rule.

Rule 6: One-to-One Database Relationships

NO! NO! NO! I won't even explain. Just NO! If you wanted to create a one-to-one relationship — go eat dirt. Did you enjoy it? Eat some more. Think about the connection between your love of dirt and your love of writing one-to-one relationships.

Rule 7: Unit Tests

There's a dumb interview question: what is legacy code? And one answer is: code not covered by tests. The worst garbage code I've ever seen was fully covered by unit tests. In fact, the worse the code, the more tests it has. Unit tests swarm to garbage code like flies.

When code starts turning into garbage, people start wrapping it in unit tests, as if that will stop it from being garbage. No — it'll just be garbage with unit tests.

Your code should be clear and understandable even to the most junior developer — that's the best defense against bugs. If it's not — that's your fault!

By the way, legacy is when the time required for improvements approaches infinity.

And a philosophical question: if a developer couldn't write simple, clean code, are you really confident they can write good unit tests?

Rule 8: Consistency

Ideal consistency is when everything is described by a single rule.

Example: 11111111 — the rule is simple: "all ones." 123456789 — also clear: "sequential increase." 413912316 — this was written by a senior. After 4, on weekdays comes 1, the third digit is 3 (because it's the third, obviously), and the seventh equals the sum of the sixth and fifth (see documentation). But only if you're a Capricorn.

Seniors have excellent memories — they really do remember everything, and they think it's all simple and obvious. And they assume everyone else read it once and memorized it too. No.

Now about the consistency rules: UserController -> UserService -> UserRepo, UserHelper, UserConverter. All class names follow one pattern, and so on. A person should know which class to look for a bug in without a stack trace. All processes should flow through standard classes. Everything identical!

You must reduce any process to CRUD and stuff it into the standard class chain. READ, UPDATE, DELETE. You are obligated to decompose any business process into a series of logical CRUD operations, whether it's ordering a pizza or transferring money.

Conclusions

I've worked at many companies and they were all CRUD-slinging, but the higher the seniority level of the developers, the more complex and incomprehensible the code became. It becomes increasingly tangled, obscure, and convoluted.

Then you come to another company. There sits a mid-level developer. Their code runs faster. It's easy to read and easy to modify. And it's vastly more functional.

The mid-level developer modestly stares at the wall: "I'm not great with generics. I wanted to set up microservices but it's kind of complicated. I only have two juniors. We don't write tests — no time." You open the repo: clean code. Pure pleasure.

Every senior thinks they're a genius, so the program is built by these self-proclaimed brilliant craftsmen. Every CRUD I've seen was done differently and with varying levels of unnecessary complexity.

Strength lies in standardization and simplicity of solutions. When industry moved from individual craftsmen to assembly lines, it stopped requiring high qualifications from every worker. A real senior turns their code into an assembly line where a dozen juniors can quickly and easily build new functionality — often through straightforward copy-paste.

1. A senior is someone who interfaces with the business. Often a major headache for users is solved very simply — like the push notification example.
2. Any application can be reduced to primitive CRUD — or to mathematical madness. See the Floyd-Warshall example.
3. A senior's job is to build an assembly line for juniors. If you need three seniors to fix a mapper, then it wasn't built by a real senior.

Cheers to everyone, and happy holidays!