What I’ve found to be important, though, is not getting stuck in what has been or is currently your wheelhouse. Without a doubt, the thing that’s helped me to progress most over the years is unbiased exploration. Taking a look at things not because someone said I should, but rather, because they look interesting or have a quality I can best define as articulate.
What I mean by that is that I look for things that have a clear definition of purpose. Not only is it clear why they exist, but it’s also clear how I can put them to use. In addition, I look for things that have a sense of completeness and lack any obvious cognitive dissonance. For example, if I’m going to learn a new language/framework, what do I need to know to do my day to day work?
Is the tooling built-in, or am I at the mercy of third-party developers? What is the overall quality of the training materials available? Do they get me excited about learning this thing, or are they mostly marketing fluff and/or bullshit (more common than you’d think)? These aren’t hard-and-fast tests, but they’re the best way to codify my personal intuition. If I look at something and there are no obvious flags, I press forward.
At the moment, the Go programming language has caught my attention. Not because it’s being hyped by anyone and not because I need to know it. Really, I just want to see what it feels like to sit behind the steering wheel of it. In the back of my mind, too, I’m asking “how approachable is this for a beginner (our core customer)?” In short: I’m playing.
This sort of thing can easily be bastardized under the banner of “not doing real work.” Sure, I’m not checking anything off my lists this morning as I watch a few videos and set up my environment for working with Go. But what I am doing is building—as a friend and fellow programmer explains it—the mental pathways necessary to “see” solutions in the future.
All of the things that I get paid to do/teach now were all predicated on similar moments. Sitting down with a cup of coffee and going full-blast nerd on some Getting Started tutorials. Without doing this, it’s impossible to see that thing later that makes you say “I should double-down on this.” You have to play. You have to experiment. You can certainly take someone’s opinion of what you should be working on at face value, but at that point, you’re not really thinking for yourself—and I’d argue, not really learning anything.
Just some food for thought. I can’t say whether this Go stuff will go anywhere, but the only way to know is to explore.