This is going to be a quick post.

One very scary aspect of development choices I came to recognize recently is making easy things easier.

This is such a confusing statement to say, but let me elaborate.

Take, for example, ORMs like Prisma. Writing basic SELECT ... statements are pretty easy in SQL. But an ORM makes it even easier for you, so much in fact, that many people just ditch learning SQL completely and use only the API of Prisma.

But a problem will inevitably rise: once you ran out of easy things, easy queries, for instance, you will have a new problem.

Making "easy" "very easy" means that the gap between "easy" and "hard" just got larger.

I see people doing many requests to a remote database, because they haven't learned how to do proper joins, or miss understanding LEFT JOINs. Or they could be using a totally average SQL utility function, meaning that the data does not need to leave the database to be processed, but they don't even think it is available, so they do it in the javascript layer instead.

The trap is that the simplest solutions scale rather bad.

Scheduling 5 customer support agents in a spreadsheet is very simple. What can go wrong? Now you have 200 agents and people are not scheduled or unpaid because of copy-paste errors of a nightmarish monster sheet. (Seen it with my own eyes.)

Doing ineffective queries and skipping learning SQL work when you have a tight budget on engineering talent and only a 1000 records, but ultimately slows down everything (from response time to engineering efforts) when you have millions of them.

Not bothering with proper CSS and using a framework instead work until you have to rebrand thousand locally styled components. Dark mode...? Don't even bother, as the same colors are copy-pasted into them.

Unless you fully understand what corners you have cut by certain simplifications, you can quickly navigate yourself into traps that take serious efforts to overcome.

By the time a spreadsheet already manages the work of 200 people, it already has so many features and so many edge-cases that even understanding the scale of the replacement project would take months. There's no magic way replacing it. There's no product out there, that exactly does what it's in your local grown spreadsheet. I speak from experience.

Is there any way to avoid these traps?

Yes. I would say, first and foremost, never drink the Kool-Aid. ORMs are great but introduce early raw queries so the team gets familiar with SQL gradually.

Be on the lookout for company management spreadsheets (either used by HR, recruitment, support, sales, etc.) and spend time and energy aside to put them on a proper trajectory.

And sometimes invest instead in learning a technology rather than hide it: for example slonik encourages you to write normal SQL queries by making SQL templating easier and safer. In turn, your IDE would be able to understand those queries and give you support based on the database schemas you actually have.

It pays off also to learn modern CSS architecture like EveryLayout before using a framework that hides (and then gives you back almost word-by-word) display: flex behind classes.

Make sure you have a plan how to transition gradually from your simplification, or skipped engineering time (in case of internal tools written and managed by spreadsheet enthusiasts)!

Thanks for reading this article!