I used to think becoming a better developer meant learning more technologies.
React.
Node.js.
PostgreSQL.
Docker.
Cloud.
TypeScript.
Another framework.
Another library.
Another tool.
Then I started building actual software.
And I realized something:
The hardest part isn’t writing the code.
It’s figuring out what the code should actually do.
⸻
Tutorials don’t prepare you for the messy part
A tutorial can show you how to build authentication.
Create a user.
Hash the password.
Create a session.
Set a cookie.
Return the user.
Done.
But a real application immediately asks you a completely different set of questions.
What account does this user belong to?
What if they belong to multiple accounts?
Can they access another company’s data?
What happens when their session expires?
What happens when the database is unavailable?
What happens when the same request is sent twice?
What should the API return when something goes wrong?
Suddenly, you’re no longer just writing code.
You’re designing a system.
⸻
Software development is mostly decisions
The more I build, the more I realize that development is basically a long chain of decisions.
Should this logic live in the frontend or backend?
Should this be a separate service?
Do I actually need another dependency?
Should I refactor this now or keep moving?
Should this data be stored permanently?
What happens if this component fails?
Will this decision still make sense six months from now?
There isn’t always a perfect answer.
Sometimes you’re simply choosing the trade-off you understand best.
And that’s a very different skill from knowing syntax.
⸻
A great stack doesn’t automatically create great software
You can have:
- Next.js
- React
- Node.js
- PostgreSQL
- Prisma
- Supabase
- Docker
- GitHub
- Vercel
…and still build a badly designed application.
The technology isn’t the architecture.
The technology isn’t the business logic.
The technology isn’t the security model.
The technology is a set of tools.
What matters is whether you understand how the pieces fit together.
⸻
Sometimes the bug isn’t in the code
This has probably been one of the most important lessons for me.
Something can be “broken” even when the individual pieces of code look perfectly reasonable.
Maybe the frontend expects one response while the API returns another.
Maybe authentication works locally but behaves differently in production.
Maybe the database schema technically works but doesn’t represent the actual business relationship.
Maybe the feature itself was poorly defined.
So debugging isn’t always:
“Find the broken line.”
Sometimes it’s:
“Find the broken assumption.”
And that requires understanding the system.
⸻
This is changing how I learn
I’m still learning technologies.
But I’m trying to learn them through problems, not just tutorials.
Instead of:
“How do I learn Prisma?”
I’m more interested in:
“How should my application model this relationship, and how can Prisma help me implement it?”
Instead of:
“How do I use authentication?”
I’d rather ask:
“How should identity and access work across this application?”
Instead of:
“How do I deploy Next.js?”
I’d ask:
“What does this application need in production that it doesn’t need locally?”
The technology becomes the tool.
The problem becomes the thing I’m actually trying to understand.
⸻
I don’t want to know 47 tools
I don’t want my definition of being a good developer to be:
“I know more frameworks than you.”
I’d rather become the person who can look at a complicated system and ask the right questions.
Where does this data come from?
Who is allowed to access it?
What happens when this service fails?
Where should this logic live?
What happens when the user does something unexpected?
How does this feature affect the rest of the system?
What will become painful six months from now?
Those questions interest me much more now.
⸻
The real milestone isn’t “I learned the framework”
For me, the bigger milestone is being able to take an idea and gradually turn it into a working system.
Idea → workflow → data → API → frontend → authentication → deployment → bugs → debugging → improvement.
Then do it again.
And again.
That’s where the learning starts becoming real.
Because eventually, you’re not just learning how to write code.
You’re learning how to think in systems.
And honestly, that’s the kind of engineer I’m trying to become.
Not someone who knows every tool.
Someone who understands enough to build, debug, and improve complicated things.
⸻
What has been the biggest difference between learning to code and actually building software for you?
Top comments (0)