On being a ‹insert favorite technology here› “guy”
When I was in graduate school, my thesis advisor, Simon Penny, once told me a story about an encounter he had with a locksmith during the renovation of one of the buildings on our side of campus:
A man was sent to fix a problem with one of our doors. When I encountered him he was enlarging a hole in the door with a grinder so the lock would latch. I looked at the door and noted that that door was not latching because the screws holding the hinges to the door-frame had corroded and the door had dropped. I pointed this out to him, and suggested that he replace the screws in the hinges instead. He looked at me with incomprehension and said, “Look, I’m a lock guy. I’m not a door guy.”
Throughout my career, I have often encountered “lock guys.” I still do. Typically, these are eager engineers early in their career who latch onto a specific technology and weave it into the core of their identity. These are the people who eat, breathe, and sleep a very specific framework, tech stack, or programming language. In the world of web development (and I’ll be using the non-gendered “folks” in lieu of “guys”), we have “React folks”, “Vue folks,” “CSS folks.” On mobile we have “Swift folks” and “Android folks.” Many years ago—when I was early in my career and didn’t know any better—I considered myself a “Flash guy.”
There are plenty of advantages to this kind of strong affinity and specialization early in your career, and I don’t fault anyone for doing this. The world of software is huge. When you’re new on the scene you need focus and guardrails to avoid becoming absolutely overwhelmed by sheer enormity of it all. And when a specific technology is hot, this type of specialization and self-identification could provide you with a distinct advantage in finding jobs, gaining visibility within a community of peers, and solving the set of problems for which that technology is particularly well-suited. But it also saddles you with a distinct disadvantage: when you identify so strongly with one particular technology or one tech stack you inherently limit your ability to frame technical problems from alternative angles. You risk becoming fixated on problem solving instead of problem framing.
The difference between problem solving and problem framing is one of intellectual curiosity and attitude. Problem framing often requires a willingness and ability to transcend disciplinary boundaries, to grapple with things that are incongruous or incompatible or simply outside your skillset. A problem cannot be solved—or at least solved well—if it has not first been fully understood, examined, and framed well. And this means developing skill in asking questions. But it’s hard to be curious and ask good questions when you automatically self-identify as “lock folk,” approaching every possible problem as a lock-shaped problem.
So, what to do?
Lose the label and become T-shaped. Stay curious. Keep learning. Go deep in a specific technology or framework or programming language, but develop breadth in adjacent technologies that will help inform your work and develop new perspectives. If you love React, make sure you also understand how to build things “on the metal,” outside the limitations of SPAs by using multiple pages and forms with straight up HTML and CSS. Try other frameworks or develop understanding of server-side technologies. If you love iOS development, try building something on Android in Kotlin, or dabble in making a few web apps. These experiences help you avoid the trap of trying to solve every problem from the same frame of reference every time. You’ll be better off for it. After all, you don’t want to be the one sweating it out with an angle grinder on a perfectly good lock, when all that would have been required is a screwdriver and a handful of screws.