I'm good at debugging and improving systems

There is absolutely a need for people who love debugging, fixing, and refactoring. Many devs dislike such things, and many managers struggle to find someone who wants to just maintain existing code vs. create new and shiny projects.

I'd recommend that you seek work in larger companies - they will have better odds of needing a full-time "maintenance" coder vs. smaller companies, startups, or consulting firms.

Don't fret, building stuff from scratch is hard: you have a thousand different decisions to make about the code and even just 1 wrong decision can make a codebase a clusterfuck.

But being good at debugging is a good base to learn how to build systems from. You'll see what naming conventions work well or invite confusion, what folder structure and project organization is less confusing, what design patterns lead to the trickiest bugs, etc.

Just keep at it.

There is _absolutely_ a future for you in Software Engineering, you just need to find the right fit or the right pair.

For instance, my skills and strengths are in some sense the inverse of yours. :) I enjoy building things, I dare say I'm quite good at it, and I get no reward out of work when I'm not building things. I do most things from "first principles", and am the sort who learns a language from the specification and takes months if not years before I can create.

I've had the privilege in the past of being paired with engineers with a completely complementary set of skills. People who can parachute into a new codebase, in a _language they don't even know_ and hack stuff together in a week or two. People who can treat a codebase like a black or grey box and still deliver value.

Every single time (okay, all of "twice" ;)) I've been matched up with someone like that, our combined output working together is beyond what either of us could accomplish alone.

If you have experience doing "Brendan Gregg style" performance engineering (if you know perf like the back of your hand, for example) I'd love to chat more....

One, very few real-world projects are totally "greenfield" -- as in, you get to (or in your case, have to) design things from scratch, without legacy code or peer projects/APIs to support. Most of the time you're inheriting someone else's code anyway, so refactoring & optimizing it IS the job, with small improvements along the way.

Two, I think it's totally normal for the first draft of software (or anything, really) to be just barely good enough. Whether you iterate and optimize it or someone else does, the idea is that it can get better over time. Maybe write it, rewrite it, optimize it, test it, further refactor it in a series of commits until you feel it's polished enough to actually PR? It doesn't have to all happen in one single pass. This is the sort of thing you'll probably just naturally get better at over the years, as long learn more and more patterns and algorithms and best practices that you can re-use in subsequent projects.

Three... do you LIKE optimizing existing stuff more than writing new code? If so, you can specifically look for projects (big corps maintaining legacy systems) or positions (test engineers, devops, DB admin, performance engineer, etc.) that focus on that IF that is your preference. But if you LIKE writing new code and just don't think you're that good at it yet, well, just keep doing it and you'll get better! It's a practice like any other.

FWIW, I've always considered myself a mediocre, self-taught dev who's never learned many of the best practices of computer science. I would never call myself an "engineer" because it's way too fancy a title. Still, it's been easier for me to find jobs in this field than any other that I've been in. There's way more demand than supply, for now, so even mediocre devs can build careers for themselves, and in so doing, learn from others along the way (sorry, coworkers, and thanks for the coaching!) Maybe just don't expect to join the FAANGs from the get-go, but get more experience in smaller businesses and tech-adjacent enterprises first?

Actually most software engineering jobs are about improving and maintaining existing, sometimes old, systems

If you feel not recognized, or too much pressure, maybe you just need to change company

I am exactly the same, I even took notes on that for my next interview

I am very good at debugging, improving systems. And helping people even though sometimes that does get me recognition. Maybe I don't fit, or maybe I should be promoted as manager, or team lead

When creating something new I just get too much indecision. Although I find out if I pair programming with a junior developer actually I think it I am OK

My whole career has been built around what you say you’re good at and I love it. I see debugging and optimising as puzzles. I started in test automation and performance engineering and went through sre and now platform engineering

Perhaps you can consider being a System Analyst or work at a company with legacy software to maintain- insurance companies and banks still use COBOL for example.

Learn how to build.

It is a skill that requires accepting that design is for users.

Hence it is often a bit boring technically, and requires real discipline. The discipline to focus on who you are building for and why it is being built.

Even worse most making results poor results. And so requires the additional discipline of accepting that most of what you will make will be shitty.

The bright side is occasionally something might be good.

Good luck.

Reminds me of this youtube video: https://www.youtube.com/watch?v=vVlEVRKv4is

Worry less on what you can´t control and focus more on what what you can do.

Cliche yet true.

Hopes that helps you out. Feel free to contact me. Ron.

You might enjoy the SRE path, or other closely-associated roles. Being naturally apt at debugging / optimising systems is a huge asset for us, and you might find a lot of satisfaction that way.

I'm bad at everything and still have a job. Being good at something give you a step up.

TLDR Build more, you’ll learn from it. Consider what you call suboptimal as POCs. Start over with a better architecture in mind then refactor and revise, apply your optimizing skills and you’ll end up with better projects.