A software engineer's candid post on Hacker News is resonating with developers who find themselves drawn to maintenance and support rather than greenfield building. The anonymous poster, who holds a BS/MS in computer science and has nine years of industry experience, laid out a career trajectory that many will recognize: starting as a backend developer, moving into product ownership, and now confronting the realization that their strengths lie in a direction the industry rarely celebrates.
The product owner trap
The poster spent four and a half years as a backend developer before transitioning to a product owner role, motivated by a straightforward self-assessment: they weren't strong at implementation or system design. They wanted to work with technology from a higher vantage point, letting more skilled developers handle the build work. The move made sense on paper.
Eight months into a new company, the arrangement fell apart. The organization expected the poster to make technical design decisions, but the development team lacked the experience to backstop those choices. The result was a project the poster felt unable to deliver on, combined with daily exposure to work they knew they weren't equipped to do. The role that was supposed to let them leverage their strengths instead forced them into the exact kind of creative, constructive work they had deliberately stepped away from.
What actually brings satisfaction
The poster's list of enjoyable work reads like a job description the industry doesn't post very often. Second and third tier ticket management, digging through logs to reconstruct what happened, recreating problems in test environments with API clients. Customer support, walking someone through an installation, investigating why something isn't working. Serving as the bridge between business stakeholders and engineering teams, understanding both sides well enough to translate between them. Testing software before it goes live.
None of these activities involve building new systems from scratch. They involve understanding existing systems deeply enough to diagnose, support, and improve them. The poster describes this as "supporting existing software" versus "building new software," and identifies it as where their aptitude and interest actually align.
An uncomfortable truth about engineering culture
Software engineering culture valorizes creation. The architect who designs the system. The engineer who ships the new feature. The startup founder who builds the product. The career ladder reflects this: the highest individual contributor roles and management tracks both assume a trajectory that starts with building and scales toward designing larger things to build.
The poster's experience exposes a gap in this model. Plenty of people are good at working with software without being particularly good at creating it. They understand how systems work, can reason about failure modes, communicate effectively across technical and business boundaries, and derive satisfaction from keeping things running rather than making new things exist. The industry has roles for these people, but they are often lower paid, less prestigious, and harder to find at senior levels.
The poster is explicit about this tradeoff: they are willing to accept a lower salary for work that doesn't make them sick. That they frame it this way, acknowledging that their current role is causing severe anxiety, underscores how mismatched engineering work can become genuinely harmful when sustained over months.
Career tracks worth exploring
The poster's skill set maps to several established career paths that often go under-discussed in developer communities. Site reliability engineering and platform operations roles emphasize exactly the kind of diagnostic, troubleshooting work the poster enjoys. DevRel and solutions engineering combine technical understanding with customer-facing support. QA engineering and developer experience roles center on testing and improving existing systems rather than building new ones. Technical program management leverages the business-to-engineering translation ability.
The harder question is whether these roles exist at the seniority and compensation level the poster's nine years of experience warrant. Many organizations cap the IC track for operations and support roles well below what architects and staff engineers earn. Finding roles that value deep institutional knowledge of existing systems, rather than always privileging the ability to design new ones, requires looking at companies that have mature, complex products worth maintaining.
The broader pattern
This post connects to a recurring conversation in developer communities about the mismatch between what the industry rewards and what many practitioners actually enjoy doing. The poster is not unusual. They are just unusually honest about it, and specific enough about what they like that others can recognize themselves in the description.
The anxiety component is worth noting. The poster isn't looking for a lateral move to slightly different building work. They are looking for a fundamental shift in what their daily work involves, because the alternative is continuing to deteriorate. That level of clarity about what isn't working, combined with equally specific knowledge of what does, is actually a strong starting position for a career change, even if the destination doesn't fit neatly into standard engineering career progression models.