You Need To Try A New Technology This Weekend

Being friends with developers is interesting, particularly as I watch those developers mature in their careers. While many outwardly advocate for constant learning, in part because our industry is constantly evolving, I see many developers (some those very same people) resistant to trying new technologies. It's always important to keep up-to-date on whatever your primary skill-set is, after all, it's what keeps you employed, but being tied to what you know can be extremely hampering to professional growth.

I'm not yet sure why people become so religiously tied to their programming langues or patterns of choice. It's probably complicated, some of it is doing the things we know to get the job done. Other times it could be to validate the hundreds of hours we have spent to learn something new. Or, possibly because we are jaded and have "seen this happen before". The difficulty in only learning about the things in our immediate sphere of expertise is that everything starts to look like a nail, and we just happen to have a perfectly good hammer to deal with that pesky nail.

As a consultant I often get referred to as a generalist, and sometimes that word is said with derision. It's true that I span more domains than someone working on a product team, but like any technologist I have my strengths and weaknesses and I aim to put myself in a position where I can best utilise my strengths. One of the benefits of being a consultant, and quite frankly one of my strengths, is I have had to learn not to think of everything as a nail waiting for a hammer. I could judge a book by it's cover, or a framework by it's community, or I could jump in and see where it might be useful.

It doesn't take long before a developer can pick up a new language or framework to undertake basic problems. After all programming is as much about learning a language and it's tooling as it is about abstract problem solving. As a result it's not difficult (if you have the time) to spend a day or two mucking around with that "hot new framework™". Make their Hello World! app or their To-Do List. When you're done pick something a bit off-the-wall and see if it can be achieved in that new framework. If it can't that's fine you're starting to learn where you can and cannot recommend, or use, that solution.

Trying something new is also fantastic for breaking creative blockers. I recently tweeted about a game I have been working on (and may never finish). For the longest time is was unnamed, but recently it earned a working project title, Athena. It did so because by trying a new technology I learned some valuable lessons.

In the above tweet I mention that I had solved every technical challenge. While that is true, what I didn't mention, was that one of them had me stumped for a long time. The problem itself was fairly simple but I'd made a lot of products the same way and one thing I was struggling with in this game was framing the playing space so it fit and scaled well from mobile to desktop. From 9:19 aspect ratio to 21:9. I was using Unity (as I always do) and every time I ran into the same problems. In frustration I decided to try GameMaker Studio and completely remake my game from the ground up.

While my GameMaker version was not as nice the limitations of its tool-set meant I had to find creative solutions to problems I took for granted in Unity. One of those very problems was the same one I faced in scaling my content to fit all device sizes. With new tools (and a lack of familiarity with those tools) I had new perspective, and with new perspective came new ideas, and with new ideas came new answers. Ultimately some of those ideas did not translate well to GameMaker, but the underlying concepts very much could be applied back to my original Unity project. Further I'd been able to draw examples from similar solutions in my previous Unity projects, just used in very different domains. It truly was a case where I could not see the forest for the trees.

So I encourage you to go and try something new. Gain an understanding of a part of software development you may not have tried, or don't appreciate. It will help us all get along as developers, help us to pick the correct tool for the job and become better and more creative problem solvers.

Who knows, like me, you might even decide that sometimes JavaScript is the correct tool for the job!