To avoid the "eternal novice" trap, learn computer science fundamentals. If you can, choose projects and jobs which don't force you to burn time learning superficial material which will become obsolete in a few years.
I agree with this post (except for swearing allegiance to any specific programming language): learning programming languages is a poor way to prioritize. Learning algorithms, or math, or operating systems, or compilers, is more effective — and will make it easier to pick up a new language when you need to.
That won't teach you how to build maintainable software in the long run though. It will give you a lot of groundwork, but one of the major issues I see in eternal novices is the fact that they never had to maintain software beyond 2-3 years. Maintaining software in the long run demands certain discipline so it doesn't bite you in the ass and many developers simply never had to deal with something like that. Even the ones styled with "senior" titles.
I'm just learning this now. I have built lots of stuff over the years but I have always had to balance my time between actually coding, managing the coders, and running the business side of things.
Now, over the last few years we have actually experienced a lot of growth and our code has started to require some scale and I have had time to focus a bit more on the code.
I feel like I have learned more in the last 2 years than the 20 before that.
I've had to focus so much more on actually architecting the system, thinking about how the data is stored in the DB, creating a smooth developer experience, creating maintainable code, and actually tracking and logging tons of detail about the app so we can find and diagnose bottlenecks before the become a problem.
So in my case, it hasn't been so much about having to maintain it for more than a few years (I have projects I have maintained for 10 years now), but the fact that this one is experiencing some real scale has really laid bare my bad (and good) decisions and forced me to learn about and start making better more informed decisions.
A lot of it is just encountering new challenges you haven't faced before.
Learning to scale an application was certainly one for me. Another was writing a webapp where accessing the primary datastore was a 50ms round trip. Another was writing warehouse software that had to interface with hardware. And another was building a somewhat complex multi-system application that ran an ecommerce business.
Most days, I feel like programming is more like bookkeeping than anything else. Especially in legacy code. Managing complexity and maintaining consistency get hard.
This. I'm an electrical engineer and took the time to learn many of the fundamentals in my particular corner of the field. I constantly recommend others to do the same as it means you can do any analysis or study far easier. It's not just learning existing engineering software packages either. Once you know a little programming, Excel, or SQL, you can even build your own tools from scratch when the vendor applications don't do what you need. I've often found that my company has done something one way for years that is inefficient, slow, and less accurate than a process I can setup in a day or two. This all comes from the fundamentals. Learning these fundamentals isn't easy though.
I agree with this post (except for swearing allegiance to any specific programming language): learning programming languages is a poor way to prioritize. Learning algorithms, or math, or operating systems, or compilers, is more effective — and will make it easier to pick up a new language when you need to.