When you first learn about software engineering, you think it’s all about building shiny new things. But what I wish someone told me sooner is that it’s usually the opposite: maybe 10% building, and 90% maintaining the thing you built incorrectly. Building is fun because it’s more asynchronous—you sync up for requirements, then you can go off and implement. But you also have to accept that what you build might not be used for a long time… or ever, and that’s still okay because you learned a ton. Most of the job, though, is maintaining: troubleshooting, being glorified technical support, and figuring out whether something is an outage, another team’s deploy, a known bug, or (my favorite) “actually that’s a feature.” I walk through what maintainer work looks like with a real deployment: pressing the button, watching dashboards, manually testing, monitoring support channels, and coordinating in synchronous meetings—especially when the product is high-visibility and you can’t fully rely on automation. I also show a gradual rollout where we shift traffic from service A to service B via dynamic config, separate from the code deploy. And yes, maintenance includes deleting code: I removed 2,217 lines of legacy paths to reduce confusion for new engineers and keep the codebase clean.