Passionately Curious
One thing I love about San Francisco: this city is full of brilliant, creative people who are passionate about their work. To be fair, the same could be said of many places, but there just seems to be a preponderance of talented, creative individuals in the City by the Bay.
It’s also astonishing how many of them are willing to share what they know with no expectation of receiving anything in return. Matt Ranney, founder and former CTO of Voxer, dropped by Maker Square this week to offer his thoughts on everything from the future of Node.js to the evolving structure of technical interviews. For a group of budding software engineers, being able to pick Matt’s brain was a tremendous opportunity. He was generous with his time and insights, and in listening to him speak you couldn’t help but catch a bit of his excitement for the craft.
Matt shared his passion for building fast applications that push the limits of available technologies. But for him, speed isn’t just an end unto itself: its pursuit demands a better understanding of the underlying technologies, and that understanding can and should lead to better, more reliable applications. It struck me as a deceptively simple insight from an industry veteran, and a reminder of the important role curiosity plays in the development of great engineers.
It’s easy to become complacent when you first start working with libraries like jQuery or frameworks like Rails and Node. It’s tempting to adopt the “it just works” mentality when much of the heavy lifting has been handled for you. But solving the hard problems—and solving them well—demands more of us as developers. We need to be curious and skeptical, to really spend some time asking why things work the way they do, and perhaps ultimately questioning whether they need work that way at all.
It’s something I struggle with, if I’m being honest. Growing up, most of my focus was on getting the right answers in school. I was good at it, and it seemed like the path to success in life. It wasn’t until I was older that I realized my mistake: I had trained myself to think of answers as the endpoint. When I was in college, I was ok knowing strings are immutable in Java; it wasn’t until years later that I finally asked myself why they are immutable.
It’s tough to teach an old dog new tricks, and in a city and industry full of brilliant 20-something’s, I’m nothing if not an old dog. It isn’t easy breaking the habits that served me well for so many years, but Matt’s comments were a reminder and inspiration to be passionately curious and keep asking why.
