> Find people who inspire you, but don't idolize them.
Luckily this is rather easy in the JavaScript world, haha.
Many good devs have bad attitudes, which makes it a bit harder for junior devs to value their skills, but it prevents them from being idolized too much.
Also, I always think it's a good sign if devs I look up to said stuff I found bad, so I know I still see them as humans and not as infailable idols.
> Don't devalue your work
This is a hard one.
On the one hand, if you work with too much non-technical people, they tend to overvalue your work. I met rather much mediocre devs who got sold to me by managers as the best devs ever. They simply always "delivered", which some devs don't. But finishing your work is a minimum in my eyes and not the "best thing ever".
On the other hand, if you only work with highly skilled devs, you could start to think you can't do anything right. In the end you got skills worth mad money to non-technical people, but you think you wouldn't get a job ever again if you lose your current one.
> Don't feel pressured to work all the time.
This is hard, especially for us devs who think of programming as their hobby.
I started freelancing 2 years ago and got about 4 weeks holidays in this time. I worked on many weekends. Not because of "crunch time" but because I liked what I was doing, but I found out it really takes its toll :\
Now I try to do 3-6 month long projects and 1 month holiday after every project. Also, only weekend work on "crunch time".
> Ignore fluff.
This is really hard, because fluff is fun.
I started with JavaScript by reading "JavaScript: The Good Parts" and "Pro JavaScript Techniques" and I learned a lot of pit-falls before I went in my first big JavaScript project.
But I came at the price of fluff everywhere.
It gives me a nice feeling reading about other devs who just don't get async/await, observables or destructuring. Not because I think they are idiots, but because I think "This seems to be hard and I already know about it!"
But yes, I probably poured days into learning observables and probably can't use them in my next projects.
> Dig into past research.
This is a nice thing, because most people don't do this.
I got a big book on HCI research of the last 50 years or so and I always find nice solutions for my problems there. Since many of the web and mobile problems have already been solved with experiments on research devices that never went mainstream.
> Take on big projects. Get uncomfortable.
Also: Let your life depend on it ;)
If you need to pay the rent with a project, you're much more inclined to "really" finish the thing and "really" learn the hard parts you need to understand before you can implement the solutions, which you need to "ship".
(Okay, letting your life depend on it isn't that good of an idea, but if money is involved it's often easier for me to walk to the end. You always should have enough money backed up to survive a failed project or two, so you can also logically justify to leave your comfort zone)