In a recent blog by Jon Evans, he explored the topic of developers overwhelming themselves with the plethora of technologies, the constant need and desire to learn more, and the difficulty facing developers just needing to pick a tool, language, library and/or framework and move forward with development of their next great idea or customer project. He referred to this stress as Developaralysis.
This particular blog struck a cord with me because it's 110% true. The amount of new tools/package managers/languages/frameworks (I will refer to all of these as noise) is constant and consuming. Set aside knowing enough about them to make educated decisions on their applicability, just knowing their existence is a challenge in itself. But where there is challenge, there is opportunity as long as you maintain a sane perspective. And it's there where I wanted to provide some ways I handle the fun and anxiety of keeping interest in learning, instead of being overwhelmed, with the latest and greatest, new and shiny.
When it comes to new noise, I rely a lot on my professional relationships and interactions to provide valuable exposure. This helps reinforce and foster engagement in my 'local' community of developers. Experiences of others with technologies provides great perspective on the latest new and shiny. They can learn from you, and your side projects, and you can learn from them. It's a win-win. Although it can feel adversarial when it comes down to developers against developers, great developers learn from each other and this is simply an extension on that premise. Hear about a new technology and wonder what it's really all about? Ask around. Maybe your coworker wanted to learn it too. The two of you take 10 minutes, check Google, and then end up putting together a quick prototype. Or maybe you both learn it's not ready for primetime and add it to the list of 'check out later'.
Goals and personal satisfaction
But what about those times where you heard about language X and you wanted to give it a shot? How do you turn the task of learning into something enjoyable? Okay, I'm not saying that learning, itself, isn't enjoyable. But what I am saying is, as with most anyone, regardless of the task, chore, etc.., ending up with something tangible at the end of a learning process really completes the job. If I walked away from playing with hand tools with a brand new bookshelf, I'd feel a lot better about the experience than having walked away with a thought of "I really should make a bookshelf someday". So how do you come up with something worthy of a build? Ask your family, friends, or just think of something you did recently and thought "I could make a tool like that". It may end up being another git repo in the projects folder that you never touch again, or it may end up being something useful. The key is a goal. Not just installation, hello world and that's it. If you can't find inspiration, don't get too worked up. If I can't figure out something to make that might actually be useful, it typically means it's time to step back and take a breather.
Minimize pressure to maximize enjoyment
With so many languages out there, and perhaps your own limited toolbox, you might be tempted to use a new customer project as an opportunity to learn a new language. On the job training in a new language, for example, seems like a fantastic idea. You get the satisfaction of learning a new language while doing the job for which you were hired. However, for the job you were hired, I'm guessing there was an explicit expectation of performance. If you are going to market with a new application, there are so many implications to deal with, learning a new language isn't necessarily the best additional risk to take. Sure, if the customer for which you are building the application has given the green light, you might want to take the risk. But even then, it's going to take after hours continued learning to help ensure you learn everything required for you to do the job right. It is absolutely possible to take this route, assuming your customer is on board, and you can be successful. However, if you are not successful, it can be both harmful to your career and your overall motivation and enjoyment of learning. The career implications are very important, but in their own way, the implications on learning are almost just as important. You don't want lose your edge, your motivation, and your drive to learn and share.
Jon asks, do we choose what we know to get the job done or fight the learning curve to address our concerns of inferiority and/or obsolescence? I think the choice comes down to preservation of the inherit enjoyment of learning. Mixing the completion of the job, with the learning and maintenance of your skills aren't always best served together. But it takes motivation. It takes setting aside time to try. To bang the keys. To figure things out. Balance your sanity with your drive. If you can, learn and experiment on your own terms. Don't let the pressure of a job, project, technology or anything else cloud the experience of learning. It's about your growth and culminating your growth will provide dividends further than the technology you decide to pick up on the side.
We all have our strategies for keeping engaged, learning and exploring, breaking and fixing and breaking again. But don't lose focus on your enjoyment. It's the enjoyment and overcoming challenge that keeps you banging your head against the wall when you can get some dependencies built, or can't find the correct version or some other random problem that hasn't received an answer on stackoverflow.