Maybe add to that: try to stay long enough in a role to really feel the consequences of your actions. Even better if you're on pager for a while too. I know it's not trendy to stay in a job for long these days, and conventional wisdom is it's not great for your salary either, but one thing it will do is allow you to understand whether decisions you made were actually good or not.

There are roles I've been in where it's only been years later that the true impact of decisions made was actually apparent. I'm glad I hung around long enough to experience that.

I've been called back to code long after I left an org, and have had to review my own code 10-12-15 years after the fact. Seeing both the positive and negative aspects of decisions having played out in the real world was something it's hard to get from reading, and I'd argue somewhat harder to get even if you stay inside the same org for that length of time. Staying on the inside, you'll rationalize a lot of the changes to the code, the team and org over time, and it may be harder to be more objective about the impact the code has had.

I was quite proud of some decisions, but realized the negative long term impact of others. Trying to share that experience and whatever 'wisdom' or 'lessons learned' with others has been its own challenge in some situations, because you can easily come across as "the old person" who doesn't "get it" wrt to current trends. Some issues are evergreen and fundamental, but it's difficult for less experienced people to understand why some of these things are really core. I'm not sure there's much substitute for experience in many cases.

I wholeheartedly agree with this advice and have for over a decade now. I think there’s something in the fact that you know you caused that that helps the lesson stick. Potentially you will understand the assumptions you had then vs now that allows you to clearly see the underlying lesson to take.

Skin in the game is important.

I have a terrible programmer friend.

He is better at creating actual products than most people I met because his livelihood is on the line: he makes money only from websites.

So he is not living in the abstract idea of best practices, he had to make it profitable for the last two decades, with little resources to go by on top of that.

And he does.

After 10 years, he is still asking me how to write git commands. And I'm still learning from him to shed a lot of BS from my practices.

Being directly chained to the financial outcome of your works will have you dropping Scrum for Scheme real quick...

I agree, form your opinions when you have enough information.

For example, if you can’t decide between two data structures or tech, pick one and add a comment:

// I’m not sure

I agree, and would say is equivalent to:

> - There is no substitute for doing. Less tutorials, more coding.

Yes true. Mostly just opining on the “list of everything you gotta’ know” is a bit TOO concrete IMO. (As opposed to too abstract)

I was quoting out of similar things years ago at the start of my career, “it should be done this way because X said it” didn’t help me at all.

It feels like insulation against being called too junior, since, you can just wholesale adopt someone else’s list of ideas and you’re good. But making mistakes because you’re new to the career is precisely what forms the base of those opinions in the first place.