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

For greenfield applications, chose whatever the customer ask for on their Request For Proposals, or suggest modern solutions if they leave it open to proposal reply.

On existing solutions, deployed for several years on the field, actually measure what it brings in regarding business value. Either in terms of reducing project costs thus improving profit, or improving customer UI/UX thus improving the value the customers get out of the product, specially if it helps them to improve their profits.

What I am against is just adopting tech that doesn't improve anything, sometimes even causes products to be abandoned or removed from the market, just for the benefit of a few devs improving their CVs.

I have taken part in a couple of projects where it actually happened. Architects were busy chasing the new shinny instead of delivering what customers actually cared about. In the end the product was canned.

2. Pick a programming language and/or ecosystem and stick to it. That's not to say there isn't power in being a polyglot, but in order to get really good you need to pick one thing and practice it. It's that simple. That said, do not brand yourself as any one thing or be too specific. The key is to both specialize and generalize. You need to be malleable enough as things change, but at the same time not constantly chasing your tail with the latest thing. This fine balance comes with experience, as most new technologies and techniques you will find are the result of someone rediscovering something. I can't count the number of times I've seen something rebranded as new or revolutionary that was originally published as a paper in the 50's or 60's.

3. Own what you do. Don't wait for others to come to you with problems, think about ways in which you should be improving your software via instrumentation and closed loop controls. Try to understand the users of your software and what they really want and need. Sometimes little things and details that are seemingly unimportant are very important indeed. Software is a way for you to directly influence and collect information about the world, so you can be constantly testing your assumptions and refining your model.

4. Do personal projects. It's the only way to avoid burn-out and to keep yourself interested. And in many cases, personal projects can shine the light for you on where to go next or what to do next.

5. Get good at interviewing others on a team and make yourself part of the interview process. Real team building is a far more valuable skill in accomplishing your goals as an engineer than becoming a manager.

6. Stay close to the tech. At a certain point you may find yourself in a position where you aren't coding or creating every day. Avoid this at all costs. It doesn't matter if you have a team, or if you're in an architect role, or whatever, you should have the code checked out at all times on your computer, have it working, and be able to contribute at a moment's notice. If at any time any of this isn't true for you, stop what you're doing right now and make it true.

7. Don't be afraid to throw out huge legacy code bases and start over from scratch. Nature does this all the time; it's called trial by fire. The second time you do something is always easier than the first and you can really eliminate a lot of debt for you and your team.

8. The first time you do something, if its not messy and weird you aren't trying hard enough or pushing yourself hard enough. The code will be awful. Don't strive for perfection in the code the first time, if it sticks you and others will have plenty of time to refactor and make it better later. I've seen tons of "perfect", unused code that has never seen the light of day again and its really sad.

9. Work for a variety of companies, small and large, startups, mid-size, big tech, and do freelance at various parts of your career. Different size companies have different goals, needs and problems and it will help you understand what is applicable to a Google does not matter at all to a startup or mid-size company.

10. Work for companies that are actually doing something, preferably new work, and try to match that to your interests at the time. Avoid places and people that are toxic and do not have a deep love of technology and do not identify as "nerd"/"hacker"/"geek" etc (unless you yourself do not identify this way..)

I'd add one more - if you ever get a good client (freelancing, even when you are full time) keep them happy. A client who doesn't come up with billion changes, pays on time, doesn't micro manage etc is really worth working with, even if the work itself might not be super interesting.

- Don't get caught up in hype. Technologies go in and out of favor. Not long ago the idea of writing a application in JavaScript would have been laughed out of the room. Today the idea of building applications in Perl seems antiquated. The truth is it doesn't make a lot of difference which language you use, and no matter what you pick it will probably be less popular in 5-10 years if not virtually abandoned.

Experience certainly shines bright in architectural and design decisions.

I think the parent's point is that no one's code should be considered sacrosanct; all of us can make mistakes, and all of us, even the senior guys, will end up writing some ugly hacks just to get something out the door on time.

More junior programmers should not be afraid to make a pass at improving something, nor should they try to emulate their peers' styles or behaviors without thinking about and processing them, lest they internalize bad habits. If a junior dev notices an error, they should point it out, instead of assuming the senior developer's code is beyond reproach. They should understand that once they get added to the resident Wizard's project, they're still going to have to deal with the reality of a production application, which means shortcuts, impurities, bugs, and mistakes. The principle of Linus's Law depends on developers who are willing to call out mistakes and at least prompt a discussion about the tradeoffs.

This doesn't mean that senior developers won't be much better at writing maintainable code on a macro level. This is especially true because I've found it usually takes until upper-mid-level for developers to really get an appreciation for simplicity and avoidance of technical debt, and to register that you're actually better if you can do more with less. (n.b.: speeding up a computer program is just making it do less)