Ask HN: Senior developers, what would you tell a younger you?

I don't consider myself a senior developer, but this is what I'd tell my younger self:

- don't spend to much time on exploring tools, but whenever you notice you're repeating yourself often, make sure to do a quick search to see if there's a quicker way. There usually is, because others will repeat themselves in similar ways.

- make sure to find real projects (where you get paid or at least dinged for not delivering) that offer a degree of challenge/unfamiliarity. I've gone months with very little progress in my abilities, only to take on a project with an unfamiliar toolset or environment and learn a shit-ton of stuff that helped my long-term.

- find a mentor!

- look into this 'functional programming' thing, but don't become a convert. It's not the solution to everything.

- if the coding you do for work doesn't excite you, make sure to find some exciting side-project. Programming, at least for me, is so much fun. I've let work take the fun out more than once, to the point where I'm seriously considering finding some other line of work to make a living so I can code just for fun. 'Unfortunately' my front-end work is so lucrative that it's the best way to have as much free time as possible.

And the two biggest ones:

- "Bad programmers worry about the code. Good programmers worry about data structures and their relationships." and "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." I can't properly express how much this has improved my coding. I don't think it's a coincidence that React/Redux (often) put such an emphasis on one big state object to work with. If I start my work with thinking about the data structures and their relationship, the code becomes so much easier to write!

- Watch 'Simple Made Easy'.

I've had OOP driven into me since I started learning programming, what would you recommend instead?

* Some people will be hostile to you or your ideas. Maybe it will be personal, maybe not - but people can be ass-hats, so expect it. Don't waste a lot of energy on people who have no interest in exploring new ideas simply because they didn't come up with them.

* there's always something to learn. You know that, but you'll lose sight of it.

* look at the bigger picture, always

* don't be afraid to ask questions, as many as you need until you have the information you need.

* worry less about what you want, and more about doing the right thing for the customers you're building for. (In the end, there's a surprising amount of overlap...)

* 12 hour days might feel good, but they don't help in the longer term.

* you can't do it all yourself.

* you'll get paid more than you need to survive - so don't be an idiot with your money.

* talk to people. continue to talk to them after you are no longer required to interact with them regularly. Relationships are work, but they're important to your sanity and career.

* Those things you avoid because they're too hard? They're not really too hard, and that's not really what's stopping you. There's nothing wrong with failing.

* Those ideas you have? Do something with them. But one at a time, and make an active choice as to whether it's worth finishing.

* There will always be things that you want to do better. Don't let that stop you from shipping.

* Don't read comments. And for the love of FSM, don't reply to them.

* Crush your enemies, see them driven before you, and hear the lamentations of their women

There are so many things, of course. But here are two things I wish I'd understood better a long time ago:

* Think in the problem space / avoid thinking in implementation details. Structure your solution along lines that make sense in the problem space, name variables for that, etc.

* Do the simplest thing that solves the problem at hand, but no simpler. Small, simple implementations are easier to change when (not if, when) unanticipated changes come up. If you anticipate additional functionality, leave the door open to those changes rather than writing code for them now.