CRUD Was Never the Job (We Just Got Paid For It)

Every developer knows the ritual.

Ticket comes in. New entity. You need a table, a migration, a model, a couple of endpoints, validation, a list view, a detail view, a form, some error states, a test or two if you're feeling virtuous. You've done it a hundred times. You know exactly how long it takes. You could do it while mildly hungover, and some of us have.

And here's the thing nobody says out loud: it feels great.

It's satisfying in the way that assembling flat pack furniture is satisfying. There's a clear start, a clear end, and a moment where the thing exists and works and you made it. Four hours disappear. You look up and it's dark out and you've got a working CRUD screen and a sense that you are a productive person who did a productive thing.

I loved that part of the job. I'm not going to pretend otherwise.

But I want to make an argument that's been sitting with me for a while: that work was never actually the job. It was the toll we paid to get to the job. We just happened to build an entire industry around measuring the toll.

The tollbooth

Think about what a feature actually is. Somebody has a problem. You figure out what the problem really is, which is usually not the first thing they told you. You decide what to do about it. Then you build it, ship it, and find out whether you were right.

The building part is the middle. It's necessary, it takes skill, and for the last twenty years it also took most of the time. So we treated it as the whole thing.

We estimated it. We pointed it. We burned it down on charts. We ran ceremonies about it. We hired for it, interviewed for it, and promoted the people who were fastest at it. Entire methodologies exist to optimize the throughput of the middle bit.

Meanwhile the parts that determined whether the feature was worth building at all mostly happened in somebody's head, in a hallway, or not at all.

That's a strange way to run a business, and we got away with it because the toll was so expensive that it looked like the destination.

The tell

Here's how you know the toll was never the job: none of the things that actually made a feature good were ever on the board.

Deciding not to build something wasn't a story. Realizing on day two that the customer meant a different thing entirely wasn't a story. Noticing that three teams were solving the same problem in three ways wasn't a story. Knowing which of the four reasonable interpretations of a ticket was the right one, because you'd been on the support call, wasn't a story.

That work was invisible. It didn't move velocity. In a lot of places it looked like slacking off.

And yet ask anyone who's shipped software that mattered what made the difference, and they won't tell you about the migration script.

What changed

The toll got cheap. That's the whole story of the last eighteen months.

The four hour CRUD screen is now a forty minute CRUD screen, and honestly the forty minutes is mostly you reading what got generated and deciding whether you agree with it. The flat pack furniture assembles itself. You still have to know whether you wanted a bookshelf.

Which means everything I just described as invisible is now the visible part. It's not a bonus skill for senior people anymore. It's the work.

That's a hard transition, and I don't want to be glib about it, because it lands differently depending on where you sit. If most of your professional identity is built on being fast and accurate at the middle bit, this feels less like a productivity gain and more like someone moved the goalposts while you were mid run.

I get it. That's a real loss and it deserves more than a LinkedIn post about embracing change.

At Corfix, concretely

We build health and safety software for construction. A lot of what we ship, structurally, is forms. Inspections, incident reports, toolbox talks, sign offs. If you squint, an enormous amount of it is CRUD.

Here's what's never been CRUD: knowing that a form with eleven fields gets completed and a form with fourteen gets abandoned. Knowing which three of those fields the safety officer actually reads. Knowing that a supervisor will happily fill something out at 6:45am and will not touch it at 4:30pm, so where the reminder fires matters more than what it says.

None of that is in a ticket. You get it from being close to the people doing the work.

We could always build the form. We could build it in 2019 and we can build it faster now. What determined whether it worked was never the build. It was whether anyone on the team understood the guy holding the phone.

The uncomfortable follow up: for years, the number of people on my team who had that understanding was small, and that was fine, because everyone else was fully occupied paying the toll. That's no longer fine. It's now the constraint.

The craft didn't die, it moved

I wrote a post a while back about legacy code, and one line from it has aged better than I expected: the best engineers I've known were excellent because they could reason about messy systems.

Note what that isn't. It isn't "could type quickly." It's judgment, context, and the ability to hold a complicated thing in your head and know where the sharp edges are.

That skill is now worth more, not less. Somebody has to read what the machine produced and know it's wrong. Somebody has to know that this innocent looking change is going to melt down at 300 concurrent users on a Monday morning. Somebody has to understand why the system does the weird thing before deleting the weird thing.

The craft is intact. It just stopped being measured in lines.

What this looks like on Monday

Some things that are actually working for us, in rough order of how easy they are to start:

1. Say what problem you're solving before you open the editor

One sentence, in the ticket or in Slack. Not the solution. The problem, and who has it. It's a small thing and it catches a shocking number of wrong builds.

2. Get on a customer call

Any call. One a month. You will learn more in thirty minutes than in a quarter of reading requirements.

3. Treat "we shouldn't build this" as a deliverable

If someone spends a day and comes back with a well argued no, that was a great day. Say so publicly, or nobody will ever do it again.

4. Review the idea, not just the code

If the code is clean and the approach is wrong, the PR is wrong. That's a harder conversation and it's the one worth having.

5. Stop celebrating volume

If your team demo is a list of things shipped, you're still measuring the toll. Talk about what changed for a user instead.

None of this requires a reorg, a new framework, or permission from anyone. It requires deciding that the invisible part is the actual part, and then acting like it in the small moments where it's easier not to.

So

The CRUD was never the job. It was the price of admission, and we all got very good at paying it, and some of us built whole careers on being efficient at the tollbooth.

The gate's up now. Nobody's collecting.

That's either terrifying or the best thing that's happened to this profession in a decade, and I think which one it is depends entirely on whether you were ever curious about what was on the other side.