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

Hi! I was late into the software game, or really I had a career reset. Breath a sigh of relief, your career is not over.

1. Age does not play a factor

2. Resume progression looks cool but practically means nothing. I have hired engineers that have been demoted (maybe adversity yields character.) I'm determining if you can pass my interview, not the last person's.

3. Software Engineers go in and out of relevancy all the time, the only difference is that you're noticing it during interviewing.

Now, as a drop out, I had to learn things on my own. I'll go over what I expect out of a Senior engineer. Keep in mind I work on a team where algorithms and data structures do matter, not all teams are like this. So, think about what you want your next team to be about.

1. Have knowledge of how algorithms work and what data structures work best with them. This is useful when dealing with tasks that must scale incredible loads.

2. Asymptotics. I generally only ask Big O questions, but know what the others are too. Big O is either memorization or a deep understanding, either is fine for Senior. You would need to be able to answer time and space complexity questions in my interview, in the form of, "walk me through the time complexity of what we just did." Sometimes I'll ask about space complexity but only if I see that you allocated memory for reasons I don't understand.

3. Abstract Systems Design is my love-child. Be inventive and take calculated risks. I don't expect you to be perfect, but I do expect a data-informed plan.

4. "Clean code" is a hyped term but it will communicate something about you. Use clearly defined interfaces and keep your concerns/domains separated in code. I'll explain a bit more below.

5. Learn to write tests with definitive outcomes. Usually when I'm helping a SWE with a problem and I'm short on time it's easier to crank out some tests that will keep them within my expectations rather than hold their hand the whole way through.

The whole "clean code" thing is iffy, imo. I learned to write good looking code by attaching linters, formatters, and static analysis tools to my IDE and learning through repetition. Designing good applications was harder, but it dawned on me when I had to write multi-threaded applications or applications that implement concurrency. You will start to naturally separate your code if you start doing this.

Learning asymptotics was iterative for me. Start on one of the Big O cheat sheet pages then Google each data structure/operation to understand why it works out the way it does.

There are lots of tutorials for learning to identify algorithms and data structures. This will be time consuming, but it can also yield benefits in your work depending on what you decide to do next.

I hope this helps!

It buys you nothing, and in the case of WWW, when you're grepping your code base to find everywhere you have "www.oldvendor.com", it fails.

Thanks for the clarification. I guess the tools you had available at that time would affect the severity of this. Nowadays, with the ability to refactor a macro name in a few seconds, I wouldn't necessarily agree that a developer that used a silly name would "never make it to a senior developer". Fuck, I'm "senior" and I definitely use worse variable names on a regular basis.

Yes. In fact this is an interesting topic in its own right - how do you approach management when you have found a problem. In my experience, there is a sort of scale here, along the lines of:

* do nothing and keep quiet (almost always the wrong thing)

* say "help"

* say "I've found this specific problem, but I don't know what to do"

* say "I've found this specific problem, here are some options for fixing it - what do you think?"

* say ""I've found this specific problem, doing X will fix it - what do you think?"

This will vary a lot in practice and depending on circumstances, but I think as people increase in experience and knowledge they tend to approach management with solutions rather than just problems.

I don't have a lot of specific advice for you. It sounds like maybe code isn't clicking as much as you think it should, and that's stressing you out in a negative way. You shouldn't be stressed out like that about your job if you can avoid it.

I had an engineer on my team that was struggling. For some projects that should take a single day to do, he would take almost two weeks. We started pairing him up with other engineers to teach him, and he was able to work with them effectively, but his solo productivity and his code quality on his own never really increased.

I considered putting him on a PIP and then letting him go, but while I was considering that, there was an incident, and the whole team jumped on a Zoom to handle the incident. Maybe it was because I was thinking of him specifically, but I could tell that he was thriving in this environment. He was identifying the bugs quickly, he was pinging the right people, he pulled up the right graphs and metrics immediately. It was honestly really impressive.

So I spoke with our head of Site Reliability and asked if he had an open role. He did. And he agreed that this guy was doing a good job and that he would take him on.

This engineer is now one of the most productive SREs in our organization. He writes a lot less code, but he's a lot more involved in adrenaline-pumping incidents. He's a great people person, so he knows everyone, and everyone knows him. When an incident pops up and people get paged, he communicates it clearly.

This is nothing less than a huge success story. I didn't lose anything by losing an underperforming engineer, but I gained a stellar SRE.

All of this is to say... maybe there are other roles in the company that would be a better fit for you. Maybe you would thrive in a DevOps role focusing less on code and more on infrastructure, or maybe in a SRE role that is about building redundancies and safety nets for the organization. Maybe you'd absolutely kill it as a PM. (Contrary to what you said, most PMs I know are not technical, so having any level of technical expertise is a huge plus. If you have lots of product ideas and like doing research, this might be a winner for you.)

If you trust your boss (and I hope you do), it would be worth talking to them and getting their perspective. Phrase it in a positive way, not in a self-deprecating way. Something along the lines of "I'm thinking about my long-term career, and I'm not sure I see myself as a Principal Engineer someday. What skill sets do you think I excel in? Do you think you can help me find opportunities to level up those skills and maybe find a role where I can utilize them the best?" Something like that.

Finally, I forget who said it, but someone said that you should work on improving your strengths, not your weaknesses. In other words, you don't see Michael Phelps running marathons or Usain Bolt swimming across the English Channel. Phelps swims and Bolt runs... because they're good at those things! And because they keep focusing on their strongest skill set, they get better and better. Just a thought.

Good luck!