The way to actually get better (at anything) is to create a feedback loop and focus on the bits and pieces which matter.
Ask a professional musician how they got better, and you won't hear them say "by playing the piano for 16 hours a day, every day". They'll say by doing focused practicing. And that can be done in anywhere between 2 and 6 hours a day.
Even at your day job...
You want to be a truly useful software developer? Expand your knowledge beyond software development by doing more than developing software.
> Ask a professional musician how they got better, and [...] they'll say by doing focused practicing.
How does focused practicing look for programmer?
http://artists.pixelovely.com/focused-practice-an-exercise-f...
Step 1: Identify what you’d like to be better at, and be specific.
Step 2: Try to break this goal down into smaller goals. List them. Notice if one might interfere with the other goals if it isn’t tamed first. Choose the most foundational goal.
Step 3: Commit to practicing that aspect of drawing 100 times. Each practice should take a minimum of 5 minutes.
This is for drawing but it looks like it could be adopted for programming.
EDIT: googling some more brings up this article https://sites.google.com/site/steveyegge2/practicing-program...
EDIT2: even more googling finds more concrete focused practicing http://web.archive.org/web/20060316094755/http://blogs.pragp...
I think getting better at programming has more to do with learning patterns, thinking carefully, and hard-won experience.
Feedback does not need to be external; it can be driven by the requirements you set forth for yourself. "I want to learn to build in low memory environments," leads to "This backend must never use more than 1MB of memory." "I want to figure out how to optimize programs," leads to "This backend must respond to every request in under 50ms." "I want to know everything about my current programming language," leads to "Obfuscate Hello World!"
Create a feedback loop and write simple programs, each time with different criteria. "I can only use functions," or "This must be as fast as possible," or "this must be as slow as possible (without using sleeps)"... the possibilities are many, and the time required is small for each exercise.
They make for great 20^H^H1% projects or "I need to step away from my current program" tasks.
there's a difference between just writing lots of code and understanding what your doing. I like the approach of writing katas every day until you've really internalized the technique you're working on.
If you wanted to be a great musician, athlete, or whatever, you would practice when you're NOT performing. It's a combination of developing the muscle memory, experimenting with new ideas, learning from other people, teaching others, and replacing bad habits with good ones.
There's no way to do that other than just doing it.
If your priorities are elsewhere, no problem but realize that little differences (salary, skills, exposure) compound over time.
If your employer is willing to subsidize your learning, count yourself extremely lucky. Most companies don't have the luxury to do that. They're pressed for time, so instead of having you learn the right way to do something, you tend to get pushed towards quick implementations that 'will do' for now. Even companies with the best intentions face this problem because their clients will set some arbitrary deadline that they have to stick to
When you're on your own time, you can relax and explore the subject matter in depth. It's this process of exploration that will make you better.
Just remember that it's a selfish world out there. Nobody cares if you're getting better as a programmer. If you want to get better, you have to invest in yourself.
My observations say the correlation is pretty much the other way around: You work more hours because you can't get the stuff done during your allotted time. You're not learning new stuff, you're doing the same you've been doing the previous 8 hours of that: Struggle.
Of course there is brilliant people that just enjoy their work and stay longer every day; but staying longer is not the reason why they're brilliant. Being brilliant, specially on a trade that has a strong creative component, it's not something you can always train. Or at least not by repeating the same tasks over and over.
I see your point and I agree that side projects could help increasing your skills and/or knowledge. However, I'm not sure they're an effective way of doing that or if we [tend to use mostly the skills we have / tend to learn skills that are so different than our daily jobs that can't be applied or aren't useful for professional development]
I'm sure most people here can attest to the anecdotal proof of having a difficult problem and leaving it. Then it suddenly coming to you some point later during non work. This also applies to developing skills. Not just problem solving.
To be a great software developer you need to work on pet projects for yourself and for others. Some people do the 9-to-5 and that's fine. But those are going to be your median developers. Not your great developers.
Nothing wrong with that.
Great software developers are great because they sharpen that edge for fun. They straight up love writing code.
When you work on pet projects you research new tools, new ways of doing things, and broaden your horizons. You open source stuff, forcing you to write clean code with proper documentation.
That _directly_ influences how you write code for your job. That knowledge applies in strange and unexpected ways. In my experience you end up using a lot of the new stuff you pulled in through your escapades.
You want to be a great software developer? Write open source code. Read open source code.