
What I learned maintaining a Symfony backend
A client handed me a Symfony backend already built by another developer. Here's what I learned maintaining it for months.
Almost all my PHP comes from the WordPress world: hooks, functions.php, a fairly direct request-response logic. So when a client handed me maintenance of a Symfony backend written by another developer no longer on the project, the first few weeks were more about reading than writing.
The first thing that stands out coming from WordPress
In WordPress, almost anything can happen almost anywhere, for better and for worse. Not in Symfony: every piece has a role and a place it lives in — controllers, services, repositories — and the framework itself pushes you to respect that separation. At first it feels rigid. After a couple of months touching real business logic, I understood why: in a project that’s going to live for years and pass through several people’s hands, that rigidity is exactly what keeps the code from turning into a plate of spaghetti.
Doctrine, the big mental shift
Coming from writing raw SQL queries (or WordPress’s $wpdb) to working with Doctrine as an ORM took me longer than I expected. Not because of the syntax — that you learn fast — but because of trusting that the ORM would generate the correct query without me seeing it written out. The first time a listing took five seconds to load because of an N+1 problem Doctrine was generating without me noticing, I learned to check Symfony’s profiler before assuming anything was fast just because “it works.”
What I’m keeping
Symfony’s console commands are, without exaggeration, some of the best I’ve used in any framework. Being able to write my own command that integrates with the rest of the system (with its own arguments, its own automatic help, its own error handling) for repetitive maintenance tasks has saved me hours.
I don’t know if I’ll start a project from scratch in Symfony anytime soon — for what I usually build, it’s still a lot of framework for the size of the problem. But maintaining this backend has made me a better developer overall: thinking in layers, in separate responsibilities, in what happens when someone else takes over the project two years down the line. That part I carry over to any language.