When I was a few years into my career, I thought I had it figured out. You've got your front end the stuff users see. You've got your backend, the stuff that powers it. Learn both, maybe throw in a database or two, and you're a "full-stack developer." Job done, right?
Yeah. No.
Five-plus years in, I can tell you that framing is one of the most limiting ways to think about this craft. It's not wrong, exactly, it's just a tiny slice of what actually ships software that works, scales, and doesn't wake you up at 3am.
Here's what I observed over the years:
The stuff between frontend and backend
There's this whole invisible layer that most tutorials skip entirely: the network. CDNs, DNS, TLS handshakes, HTTP/2 multiplexing, edge caching, latency budgets this stuff isn't frontend and it isn't backend, but it's absolutely why your app feels fast or slow to a user in another country.
I spent years writing Performant React and optimized SQL queries, wondering why our app still felt sluggish for users in Southeast Asia. Turns out, the problem lived in neither of my two mental buckets. It is in the middle of these two areas.
Once you start thinking about the full path a request takes from a user's thumb tap to a server rack and back you see web development completely differently.
DevOps isn't a separate job. It's your job too.
We understand that this is the main focus of the DevOps team.
But here's the thing: every time you've pushed broken code to production, wondered why something works locally but not in staging, or shipped a feature that immediately fell over under real traffic, that's a DevOps problem that touched your code. You were always involved whether you knew or not.
Learning the fundamentals of deployment and environment management doesn't mean you need to become a DevOps professional. It's about not being helpless when things go sideways, and not accidentally creating problems for the people who are.
Understanding the deployment lifecycle made me a more thoughtful developer and improved my coding practices.
Security is a feature, not someone else's checklist
Early in my career, security felt like a compliance thing. A box to tick. Something which is reviewed by the security team before launch.
Then I accidentally introduced an open redirect. Then a teammate shipped an endpoint with a missing auth check. Neither of us were careless people, we just hadn't built the habit of thinking like an attacker while writing code.
Web security isn't a separate discipline you bolt on at the end. CORS, CSP headers, input validation, secrets management, dependency auditing, this is web development.It becomes part of your everyday workflow, showing up in code reviews, configuration management, and package installations.
The developers I've worked with who think about security while building, not after, are the ones I'd want on my team every time.
Observability: knowing what your app is actually doing
If a critical issue were happening quietly inside your live application today, would your team even be aware of it?
Not after customers start reporting problems. Not after an error-rate chart suddenly jumps. Would your team detect the issue before it becomes visible to everyone else?
Logging, metrics, tracing, alerting this is the difference between running an app and understanding an app. And it's genuinely underrated as a skill. I've seen senior developers who write beautiful code but have no idea how to diagnose a production incident because they've never invested in learning observability tooling.
Your application is a complete system, not just a codebase. Observability allows you to gain real-time insight into its health and performance.
The soft stuff is actually hard
Technical breadth matters. But honestly? The thing that separates good developers from great ones, the thing I wish I'd taken seriously sooner is communication.
Writing a clear ticket.The most valuable code reviews don't just point out issues, they guide developers toward better solutions. Helping a product manager understand technical considerations without talking down to them or removing important details. Pushing back on a deadline without burning a relationship.
None of that is the front end. None of that is the backend. All of it is web development.
So what does this mean practically?
You can benefit from understanding automation and deployment processes without becoming a DevOps specialist. But I'd encourage you especially if you're a few years in and feeling comfortable to deliberately poke at the things outside your two buckets.
When an application slows down, investigate the entire flow before assuming the issue is in your code. When deploying, understand what the pipeline is doing instead of simply trusting it. When creating new features, think about security and failure scenarios from the start.
Real growth happens when you understand how different parts of a system interact and influence one another. The most effective developers are curious about the layers, dependencies, and processes that exist beyond the code they write every day.
What appears simple on the surface often hides many layers, and discovering them is what makes the job exciting.
What's something outside "frontend/backend" that leveled you up? You can also share in the comment box, it would be a pleasure to know.
Top comments (0)