Why I Build Frameworks Before Using Them
Before using Spring Boot, I built a servlet framework. Before using Hibernate, I built an ORM. This is why I think every engineer should build the tools they rely on, at least once.
The Problem with Abstractions
Every framework you use is hiding something. Spring Boot hides classpath scanning, bean lifecycle, and the dispatcher servlet. Hibernate hides JDBC, connection pooling, and SQL generation. React hides the reconciler, the virtual DOM diffing algorithm, and the fiber scheduler.
Most engineers use these tools without ever looking underneath. They reach for them the moment a problem appears, lean on the documentation for configuration, and accept the magic without question.
This is fine. It works. You can ship products this way.
But something is missing.
What You Miss When You Skip the Internals
When something breaks in a Spring application, most engineers read stack traces and Google error messages. They’re debugging the abstraction rather than the underlying system.
When I built WEBRock, my own Servlet-based web framework, I had to solve the exact problems Spring solves:
- How does the router know which method to call for
/api/users? - How do you inject a
UserServiceinto aUserControllerwithout passing it manually? - How do you scan the entire classpath to find annotated classes at startup?
Answering those questions yourself, in code, changes how you see Spring forever. You stop being surprised by its behavior. You start predicting it.
The Method: Build First, Use Second
My personal rule is simple: before adopting any significant framework or library, spend a week building a miniature version of it yourself.
Not a production-grade version. Not even a complete version. Just enough to understand the core mechanism.
For an ORM, that means:
- A
@Tableannotation that maps a class to a table name - A
@Columnannotation that maps a field to a column - A
save()method that uses Reflection to generate anINSERTSQL statement
It takes a day. But after that day, you will never be confused about what Hibernate is doing when it says session.save(entity).
The Unexpected Benefits
The payoff extends beyond debugging. When you understand how a framework works internally, you make better architectural decisions:
- You know why Hibernate’s
LazyInitializationExceptionhappens (the session is closed when you access the proxy) - You know why Spring’s
@Transactionaldoesn’t work on private methods (it uses proxy-based AOP) - You know why React’s
useStatesetter doesn’t give you the latest value inside a closure (stale closure over the initial render’s state)
These are not obscure trivia. These are the bugs that cost hours of debugging in production systems.
Start Small
You don’t need to build Hibernate. You need to build enough of Hibernate to understand the contract.
Pick one tool you use every day. Spend a weekend building a 200-line version of it. The insights will compound across everything else you build.
That’s the mindset. Build it first. Then use it well.