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

Interesting! I switch very early in my career to working for product companies because I saw no other way to have a rewarding career as developer. So far it's worked out pretty well for me.

However, recently I read Developer Hegemony[0], which seems to describe a path for IT developers to also have rewarding careers.

My current thinking is that the Agile philosophy definitely contributes both to successful projects and to satisfying careers for IT developers (Agile came primarily from that world of software development) but only when developers and users are equal partners. That generally only happens when the developers are independent consultants who can speak the language of business.

[0]https://leanpub.com/developerhegemony

Find a place that will quiz you on real-world work instead of CS textbooks. There are a lot of them.

Companies who base their interviews on CS curricula generally just end up only hiring people who've graduated recently enough to remember it (i.e., their staff ends up being junior because they're selecting for something that's, ironically, an anti-indicator of experience more often than not).

Few things come to mind

1. To not worry about my code being judged too much. Everyone's code can be improved. The real art is to know the balance between good enough, and not contributing obvious technical debt.

2. Not being afraid to break things. (unit testing helps lower that fear, so is documentation, single responsibility principle, open closed principle etc)

3. Assume you will probably never have time to rewrite it.

4. Assume you will probably never have time to do a major refactoring on it either.

5. Boy scouts rule. Due to the above, just gradually make the code a little better everytime you touch it. You see something bad in the neighboring method? cleanup, even if you didn't write it, and make sure the unit test covers that (shows how unit tests are important. It's not just to test your code, it's to allow people to feel comfortable changing your code when you are not there)

6. Unit test (almost) everything on one hand, but feel ok to skip testing a function that does something so trivial that the test itself is just repeating the same logic. Also consider mutation testing over code coverage as a metric.

7. The obligatory - check your own code first before blaming others, Google everything, if something looks WTF, then you are either looking at the wrong server, have cache issues, wrong git branch etc... (9/10 of the times)

8. Use other people's code, avoid NIH syndrome, use open source (with the right attribution) and don't be afraid to try and contributing back to the community. Best code is code you never had to write.

Yeah, pay grade is really where it gets sticky. If you have basic skills you can find an entry level gig easily... as long as you're willing to take a market-level salary for that role. A lot of people who've spent years building a career in a dead-end sector will have salaries substantially higher than that, and that makes it difficult to jump.

These people should focus on improving their credit, cutting expenses, and building up savings so that they can take the salary hit that will get their careers on a better track for the ~20 years until they're eligible for retirement.

Alternatively, these people can go in through a social backdoor. Befriend a powerful person at a company you'd like to work at and demonstrate why he needs you. If he has authority to set salaries, he will likely do everything possible to accommodate your higher-than-market salary, even if he can't get you 100% of the way there.

But beware: overpaying an employee is the best way for a company to trap him/her. Do everything possible to not become dependent on a rate you can't easily command somewhere else.

Most important: don't try and be clever when solving a problem. Simple & readable code is typically better than clever-tricks or one-line unreadable-solutions.

Almost-as-important: stay curious.

Apart from that:

- experiment, make mistakes, screw-up, accidentally do rm -rf / etc etc. Just make sure you learn from them :-)

- look at how other people have solved similar problems, perhaps what your colleagues have done at your job rather than just random github stuff so that it has more context. See if they did anything that you didn't think of (... or not!)

- learn the basics of key data structures and how/why they work (graphs, trees, hashmaps etc). Learn why they are cool, what the benefits are and where they could be useful, but remember the most important point and try not to be too clever and force them in where a loop would do!

- try to keep your interests/skills/knowledge fairly broad. I've interviewed people who seemed really good, but turned out to really only know about one specific narrow field (e.g. they knew everything about ReactJS/Angular/VueJS (for example), but did not know even the basics of how HTTP works or how to do a SQL join) so I've had to reject them. As well as programming, learn a "enough to be dangerous" in unix CLI, networks, databases, web stuff, basic OS stuff, storage etc.

- similar to above, try and learn another programming language after you are competent in one. The learning experience and different perspective will make you a better programmer in both languages.

- finally in a slightly more negative vein, the company you work for might be nice and might be friendly, but the company will have zero loyalty to you if it comes to layoffs/re-orgs etc. Don't stick around at a company longer than you know you should just because you feel like you "owe it" to them.

Have fun and good luck!