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

I'm going to come at this from a different angle than the (good) advice that others are offering.

You say you started a few months ago; I take it you started remote and you've been remote the whole time?

I started my current job in quarantine and I've dealt with a ton of impostor syndrome ever since (I'd never really had impostor syndrome before this). I'm constantly feeling like a disappointment, wondering if they still want me, trying desperately to come up with ways to prove my worth.

I think at least part of that feeling of inadequacy is based in the lack of day to day, nonverbal feedback and interaction with my coworkers and managers. I feel precarious because I have very little data to go off of one way or the other. We even do one-on-ones, but still. A conversation about my performance once a month doesn't replace daily body-language, off the cuff remarks, expressions on people's faces after I've made suggestions or completed tasks.

Anyway: I'm hoping my situation will get better once I'm back in an office. Maybe yours will too.

Best of luck.

I think I disagree strongly on the first point.

If SEVENTEEN is used instead of MENU_SCALING_FACTOR and ARBITRARY_OTHER_THING (two semantically different things both happening to be 17), no refactoring tool (that I’m aware of) is going to be able to tease apart just the former use and amend it to 23, leaving ARBITRARY_OTHER_THING as 17.

  const int declarationAdoptedYear = SEVENTEEN * HUNDRED + THIRTY_EIGHT * TWO;

Find a safe place to get high quality code reviews. I recommend high quality software projects like Rails or Postgres. The biggest aid to my creating better software is code reviews.

Also, put this[0] in your calendar and read through it once a month. Read through books on your stack, and choose a stack known for high quality.

I can't tell you the number of times I've worked with "senior" devs that weren't. The number one thing they had in common was hostility towards code reviews. Pay attention to the little details and start absorbing and following advice in code style guides. Take this[1] one, for example. Also, there are some rules of thumb worth following. I do my very best to avoid inheritance (outside of mocks / fakes for testing) and I move hard coded constants into config files with ENV overrides available. Avoid over-commenting and try to follow TDD if you can, since it makes your interfaces more from the point of view of the caller rather than the implementer.

It's hard to talk about these types of things over text, so if you want me to review some of your work feel free to reach out to me and I'll give you some more advice over a video call.

[0] https://en.wikipedia.org/wiki/Code_smell

[1] https://google.github.io/styleguide/pyguide.html

I don't know, but some of the people I consider to be really good software developers seem to reference "The Pragmatic Programmer" (perhaps even more than I realize do since I never read the book but have heard of "rubber duck debugging" & "DRY").

Generally, good software would have to be first defined and there's no universal definition. In most projects, I require it to have the following properties: * New developers find it easy to ramp up on * A handle on the defect rate (usually through adoption of best-practices like unit tests, fuzzers, automated tools, CI/CD, reproducible builds, etc). * "Fires" infrequently enough relative to team size that it's manageable to accomplish your business goals. * No "surprises" in adding new features/fix bugs where you didn't expect them. * Meets business requirements today & can meet them tomorrow.

However, in other cases, like prototyping, "good software" means, "explores the problem space as quickly & cheaply as possible without worrying about any of those other things". Some of those other things can be useful in accomplishing this, especially if you plan to pivot from prototyping to the above definition. If you don't use them effectively then throw away your prototype before productionizing & start from scratch.

Having been a programmer for forty years, I am senior in every sense of the word.

Also, I hate everything I have ever written. When I look at something I wrote three months ago, it is embarrassing.

Now, today's code, that's a different story. It is awesome.

And it will be until I turn my attention elsewhere. When I come back to it, it will also suck.

Which is to say, Of course you hate your previous work. You learned that hardcoded values are a bad thing. Probably you won't do that again.

But, you will do something new that is egregious. In forty years, this is the pattern. Every new thing I learn makes my previous code suck.

Embrace the suck. It is part of life. When you see something you did that sucks, don't do it anymore. Find some new suckage to write.

Don't worry about trying to become a good programmer because, you will only achieve that if you stop learning new things. That would be bad.