OOP and Databases don’t mix well.
When you force them to mix, you get a lipstick.
Also know as ORMs.
Posts by Hussein Nasser
Announcing my new book, Root Cause, Stories from two decades of backend engineering bugs
paperback
amzn.to/4cKfZhe
ebook
amzn.to/4cfQjJj
Trying to explain a brilliant data structure (such as bloom filter) often falls flat and unappreciated. This is because the context and pain and the need behind it is often omitted or sometimes not even known. Instead a contrived reasoning is provided leaving people more puzzled.
I wrote a new book that has been in the works for years. It is called Root Cause, and it is for those who enjoy the art of backend engineering.
amzn.to/4cKfZhe
It feels good to understand what goes on behind the scenes in the database.
It boils down to the fundamentals that I compiled in this course.
I get messages from people who passed interviews, got hired, promoted and improved their apps.
Grab your copy
databases.win
Confidence is the absence of doubt
If you ever used the /*+ APPEND */ Oracle hint to bulk insert rows into a table, you won’t be able to read the table in the same transaction. If you try you will get this error.
ORA-12838: cannot read/modify an object after modifying it in parallel.
To build performant backend applications, it is better to start from first principles.
Head to courses.husseinnasser.com for a coupon.
I recommend getting the OS course as it is the basis to unlocking all other courses.
They will know the exact workload X is perfect for, how to tune and configure it.
Be that engineer.
No mention of the drawbacks of X
This is not necessary a problem, a good engineer can actually take advantage of this.
The engineer who realizes this, learns the ins and outs of X including the pros and cons, will be paid 10 times to fix problems caused by X production.
Any software you build to solve a problem will have a limitation.
The danger is in not knowing what the limitations are before building it.
To make this concrete, if database X is advertised as a better alternative of database Y, vendors of X will praise the “good” of X, highlight the “bad” Y
Abstractions are most powerful when we understand what lies behind them.
Use them, but never let your guard down.
The same applies to frameworks, client libraries, APIs or even languages.
The best performance comes from fully understanding the intricacies and complexities of a system—
And tuning them to your specific use case.
Put that function in a library and ship it.
Now, only you know the true nature of the code.
The developers using it don’t.
Those devs build more software and libraries on top of it, creating further illusions of simplicity.
Eventually, abstractions leak this complexity to end users in unexpected ways:
Often in the form of performance issues, latency, or high CPU and memory usage.
Deep down, we know this.
Wrap a large block of code in a function call, and the client code appears simple.
But we know it’s not.
Code with fewer lines is not always simple code.
Fewer lines of code often indicate an abstraction.
Abstractions are not inherently simple; they create the illusion of simplicity.
They don’t remove complexity—they hide it.
This hidden complexity can cause engineers to lower their guard.
Imposter syndrome is like a self recursive function.
If you sit with a bug long enough, the root cause will reveal itself.
Don’t try to get “rid” of it, because that will create frustration and aversion.
Enjoy the exploration of the root cause removing yourself from blame and responsibility. When you do, you will feel yourself level up.
Will RAM become so expensive that we’ll be forced to actually write efficient software?
just like the early days of computing
Giving out 200 free coupons of my courses for Eid.
هنالك ألم كثير في العالم، أتمنى انه نحتفل في السنة القادمة في عالم بدون حروب...
courses.husseinnasser.com
NGINX course
NGINXEID2026
OS course
OSEID2026
Real time websockets
WSEID2026
Troubleshooting backend
PFEID2026
Database
DBEID2026
what happens if you lose power halfway through writing to the data files in the database?
I explore this on my substack
open.substack.com/pub/hnasr/p/...
This course is for intermediate students who are familiar with Node and want to understand how it works. While not required, I recommend taking the fundamentals of operating system course as a prerequisite of this course.
Grab it here, node.win
They love to understand what is running behind the engine.
They enjoy tearing apart 1 the line of code into its original 1000 lines.
They question why is the output of a Node program is unpredictable.
They want to know when does the Node process exit.
I spent a while working on a course to demystify NodeJS Internals and Architecture and distilled this knowledge in this comprehensive course.
I built this course is for engineers who can't stand working with the opaque.
My favorite thing about software engineering is making it transparent.
Node is one of the most popular runtimes used on backend engineering yet I feel it is the least understood. I surely ran into this way at times.
PostgreSQL Internal Architecture Explained youtu.be/Q56kljmIN14
How I design software open.substack.com/pub/hnasr/p/...
Fully understanding existing components and how they work is something we rarely do.
We throw our hands and blame the component, the tool, the framework, the language, the database but rarely we blame our lack of understanding.
asynchronous calls are a mirage.
There always something synchronous being blocked upstream.