Ask HN: For those programming 10+ years, what do you wish you knew 4 years in?

I sympathize. Early in my career I landed a job in a small software company. My skills improved greatly. Then I made the mistake of taking an IT job. That IT job rolled into another and another. While I stay near the technical top in my IT departments, I find it tough interviewing for software company jobs. The concerns of a software engineer in a software company are just so different from an IT developer’s.

I interview for backend engineer jobs. I notice a common theme in the interviews: efficiency. They are very concerned with transactional throughput. They optimize everything from the services layer to the database for trimming every microsecond. At a past interview, the people wanted me to talk about the efficiency and implementation of various data structures: nothing exotic, just garden variety queues, stacks, lists, and hashmaps. They quizzed me on threading issues. One guy got into various indexes in a relational database and then jumped into TCP vs. UDP questions. In my most recent interview, the guy started by asking me the difference between optimistic and pessimistic locking. In my IT job, I never deal with locking issues: they are all abstracted away. Two-thirds of the way through the interview, I remembered and circled back to the question. However, the damage was more than likely done. A person who deals with those issues daily would never forget. But, I know what to work on for the next interview.

I understand your predicament. It’s deadening on every level when you’re doing work beneath your capability and interest, but you don’t have the necessary knowledge to get through an interview for more interesting jobs. Hopefully, the observation I made above helps you to target particular areas to successfully navigate an interview.

Thanks -- haven't heard that term before. I'll check it out. I like the idea of early FI but I'd like more a cushion that I think some of the lean guys are going for.

> Everyone's code basically sucks, including yours.

Which is why I'd say, unit-test your code, or TDD, or something. When you look at that crap months later, your mental model of how it all works has completely eroded, and only the test suite is left to preserve your expectations as they existed back then, preventing you from wasting a lot of time stepping on your own toes while you re-grok the big picture, if you have to make a change.

> The boundary between a beginner and a coding rockstar really isn't very great unless you are getting into the realm of computer sciences, like machine learning.

I don't agree with this. I didn't spend 20 years learning nothing, as it were.

Learn how to evaluate trade-offs. Not everything is black and white. Given two alternatives, both of which have advantages and flaws, learn how to decide which one is better (and why).

Learn a sense of... I want to say "taste", but it's more concrete than that. Learn what the bad ideas are, and why they're bad. Learn a sense of "that doesn't feel right" that's technical, not just aesthetic.

Learn what it's like to maintain a two-decade-old code base of a million lines or more. See what the problems are. Think about what you're doing when writing new code that's going to create some of those problems.

Learn to document what you're doing to an appropriate level of detail. Take the time to do so.

By the sheer number of responses here, this is a testament to how personal each coder's experience is and how much they value it unto itself. Coders care about the work they do and especially in the beginning find their choices to equate to who they are, tending to find unwanted changes or revisions to their code by others' hands as annoying or encroaching upon their precious domain, at least for me.

To this day, I still get very annoyed when someone takes what I have done, completely reworks it or even throws it away, doing something else that IMO is more complex and difficult to work with. My values have shifted from doing the quick and custom style to moving more toward standards and TDD in a style that everyone can pickup easily and understand.

This has made my work so much more productive in getting to the final production quality by a factor of not less than 2. In my youth, I spent 99% of my time fixing code as it broke. Now, I unit test and in many cases, end-to-end test with TDD frameworks providing myself with a much higher probability of success when pushing to production.