I agree. I've been coding for decades,but it's a handful of years that made the vast majority of difference. That's not to say you don't learn some things every year, but the major progress is concentrated in a few years (and they aren't all at the start!)
As also someone who started coding at 13 and now mid-40s, mine too has been quantum evolution. Usually from needing a particular technology for a project and then learning it or just a didactic itch I scratched. Novel coding techniques distract you from solving the problem and exploring the novel for its own sake is a common pitfall in the programming world.
10 Solve problems with tools you know
20 Learn new tools
30 GOTO 10
I am glad I took some spare time to learn RoR coming from a .NET background. I had no problems to solve in RoR that I couldn't solve in .NET.
I just explored it and learned about different ways of doing things. I am sure it has made my .NET programming better too.
Also learning some RoR has got me also using Linux and Git. I learned a bit about Nginx etc. I went to some interesting RoR meetups. I gained a lot from it.
So I encourage programmers to learn other languages and techniques, for the sake of it!
--
10. Learn another programming language / framework tool
20. Have fun with it
30. Realize you can now solve problems you previously
couldn't
There is some confusion, you are agreeing with me.
I mean don't try solving novel problems in your day job with novel tools and techniques. Use known tools to solve problems. Lean new tools when not solving problems.
OK i misunderstood you, but I don't see how you can avoid learning new tools when solving problems.
You must often hit the point where you think "surely there is a better way to do this, lets research it" - then find new tools, spike them and then use them? No?
However what I think you are getting at maybe is people who think stuff like "Node.js - that sounds funky, oh.. Hadoop - thats hip at the moment how can we use that?" perhaps for fun, or to enhance their CV. That is dangerous. You end up with completely the wrong tool for the job!
Yes, that's what I mean. Software is all about building tools.
I mean like "I know, I'll do this client job in Lisp, I've never tried that" which is probably a bit of an extreme example but I have learned similar by experience :)
That's always been a big driver for my learning. If I could do the job with the tools I already know, my drive to learn new tools is somewhat diminished.
its hard if you don't have the context to know this though. you may never think what you are using is insufficient if you don't get out of your comfort zone.
True, if I'm never challenged in my work then I never find reason to get new tools. Hopefully we're working on things that do challenge us and do expose us to the weaknesses in our tools - and force us to say "There's got to be a better way, how does everyone else do this?"
I think my little bit of pseudo basic was to extreme. I meant there is a temptation when faced with a problem you know already how to solve to do it with novel tools on the client's time. Like "I should do this in Forth, how hard could it be"
yes, and no. i still think that without exploring you are not going to find things way out of your comfort zone. sometimes its not "weakness" in your tools that should inspire you. you can write perfectly great stuff with imperative languages, but at some point you may want to try a pure functional language to get a perspective shift. its more so to see if there may be a better way, or a different way to do things. i am very glad i took two courses in haskell, despite the fact that i don't ever use it for work, just because it has changed the way i think about certain things and given names to concepts i only had a vague notion of before.
10 Solve problems with tools you know
20 Learn new tools
30 GOTO 10
Sure, but since learning new tools more than superficially means solving problems with them, that is equivalent to:
10 Solve problems with tools you know
20 Solve problems with tools you don't yet know
30 GOTO 10
And learning new tools -- programming languages specifically here -- often involves learning new techniques, that while not necessarily as natural and popular with your current language, can be applied there, which its good to have in your pocket for when the techniques that are most popular/natural with your current languages aren't great for solving a problem you run into.
There are good reasons that the The Pragmatic Programmer includes the recommendation to learn a new language every year.
