FAO Programmers: The Importance of Fucking Around
One of my all-time favourite things to do is ride my snowboard. I'm not really into freestyle so much, but freeriding is something I can't get enough of. With friends, with my wife, or on my own, I love flying down a mountain, whether it's carving on piste, hitting kickers on the side or throwing up rooster tails in deep power off of it (not so much in Australia). When I started the sport around 20 years ago I took a bunch of lessons, then didn't for a while, and then once took a single private lesson on a trip in 2001.
Pretty sure I could do this all day, every day.
A Rule to Live By
The guy who was teaching me basically gave me a tour of the mountain, took me through some amazing powder, jumping streams (at least every one after the first one) and dodging rocks. He gave me a few pointers on my technique, but then told me something at the end of the lesson that I'll never forget, and it's something that I've applied to a lot more than snowboarding since:
"Your technique is pretty good, the best advice I can give you now is fuck around."
I really wish I could fully attribute this quote, because it has more to it than first impressions might offer. It certainly doesn't mean that you shouldn't bother learning the basics, and it doesn't mean that formal training should be skipped either.
If you want to make a career of being a software developer you should never stop learning; even without dedicating time to it. If you find yourself thinking you've not learned something new in the last month then that's probably a good indicator that you should be assessing your situation. The instructor who gave me this advice elaborated on it, explaining that he meant whenever I'm cruising down an easy run (and not in the way of other people), or waiting for someone on the flats, I should hop about. Try and jump and spin, have a crack at buttering (not sure anyone called it buttering back then), drag a hand through the snow. In essence, fuck around: don't just cruise and rest on your laurels, don't just take the easy option, do try things that you're not familiar with.
Learning While Programming
In my humble opinion you should always be making an effort to read and learn about techniques and technologies relevant to your field (and those that aren't!), but even if you don't you should be learning from your mistakes and past endeavours. I don't know if I've ever met a developer who hasn't expressed some level of disgust or horror when presented with some code they wrote the year before.
If you don't like learning new things, you will despise software engineering. It's all we do.
Many of us are employed in a position that's focused on a particular technology or speciality, and that could seem like it's a limitation on what you can justify learning, but you never know what ideas you make pick up from a seemingly unrelated technology or field that translate all-to-well to the tools of your trade. I've read a book or two on Object Oriented patterns for enterprise software development over the years, and I also read a book on OO patterns for games development: unsurprisingly the two are very similar but one is far more fun to learn from.
Hobby projects are a perfect vehicle for getting stuck into something different from your day-to-day. In a bit of a knee-jerk reaction to the untyped, dynamic world of JavaScript sending me chasing my tail for a few days at work, I spent a couple of weeks tinkering with Rust in my spare time. Rust is a truly fascinating language with some very impressive features at compile time that can save you from shooting yourself in the foot; I'd detail them here, but then I'd just be giving away spoilers.
Code for the sake of it. Write code that'll go nowhere. Write code because you want to. Fuck around. It's all good learning.