Ask HN: I've realized I'm a bad software engineer and I'm over 30, what's next?

I've always maintained that you really learn how to write code for a particular problem when you've done it three times. The first is usually to get working code, the second is to redesign it to improve some aspect (adding features, improving performance, code maintainability, etc.), and the third is when you really get it "right". Using this approach, it takes time and deliberate practice (borrowing the term from Geoff Colvin's "Talent is Overrated").

From my point of view, the core question that you're asking is "How do I get deliberate practice with coding?" There is no easy answer for this, but here are some ways to break things down so that you can come up with a plan for yourself.

1) "Clean Code"

This was brought up in another comment, but the book does an excellent job of covering many of the techniques for keeping a code base in good shape over time.

What can be trickier is 1) there are a lot of techniques, and 2) you may have a hard time taking the techniques from the book and applying them to your situation. While the examples in the book are universal, I think it's easy to get lost applying the technique to a more complex problem.

2) Applying One Technique to a Known Situation

Either start with a smaller piece of code or a medium piece of code that you know really well. Ideally, use some advanced piece of source code control that allows multiple branches. Then, start doing the practices from "Clean Code" one a time with a goal in mind, such as eliminated duplicated code, limiting scope, making functions more configurable via parameters, etc.

The real trick? Just do one of these improvement areas at a time. Do it a few times in different parts of the code. Eventually, the patterns start to emerge as to why it improves and where else it can be applied.

3) Recognizing Patterns

You may or may not have read articles/books about API design, coding style guidelines, etc. While many of those rules may seem arbitrary, as you get more practice, you'll start to see why such guidelines exist.

There will be similar patterns for how your code refactoring can improve modularity, debuggability, development time, testing, error handling, etc. Each code change may not improve all those things simultaneously, but you'll eventually start making improvements that cover more than one area of improvement.

4) Improving Your Learning Acceleration

There's a point you'll reach where you can keep refactoring, but you may not learn much more. At that point, try adding a feature. It can be a minor feature or a major one, but you'll start to see where the new feature forces your code to be refactored again. You can write a bunch of code or you can go through the "what do I need to change in the existing code base to add feature X?" as a mental exercise. In either case, you'll start to see what prior decisions may not have worked since they only considered one aspect of code improvement instead of three or four.

5) Putting All of the Above into Context

Another aspect of being a "Senior" engineer means that you recognize the problems really being solved by your software and what value it has. As you get more senior, you can answer all sorts of questions such as:

- How does the customer use this software? What pieces do they pay for? What features save them the most time/money/suffering? - What should the next features be? - What parts can be improved? Speed? Usability? Data Input? Connectivity/compatibility with other software? - What sort of documentation does the user need? - Is this software getting dated? What parts need replacing? Does there need to be a new solution (rewrite vs. continued refactoring)?

Not all of the above questions are applicable (e.g. tools used inside a company vs. a tool customers buy and use on their own computers), but being able to put the software usage into context (sort of the PM area you were talking about) and breaking down the technical context (the "senior" engineer role) are both useful skills.

You may need to go back and forth a bit between coding and reading books like "Clean Code" before the lessons really get internalized. Using the above guidelines and knowing what sort of learning process works best for yourself, hopefully you can start taking steps to improving in ways that help your career.

I read a few years back (long since forgotten where) in an advice thread to new people that you want to be careful that as you spend more time in your career you want ensure your experience levels up too. And there is a difference between 2 years of experience versus 1 year of experience 2 times.

There is already a lot of great advice in other replies. What many of them are getting at is being honest with ourselves what our actual level of experience is, and shaping the environment to best help level up the skills we need to improve. It sounds like you have already done one very difficult thing - moving to a position that forces you to improve and see clearly where to make changes.

    True = 1
    False = 0

You pointed out specific issues with your work, so you can go about improving on those thing.

Keep your chin up.