As a group, developers have curated a deep-rooted, stymieing fear borne of our industry's highly competitive "culture of competency" and our laundry-list résumés: the fear of not understanding things.
Specifically, the fear of others knowing we don’t understand — and it’s holding us back.
Admitting that you don’t comprehend something and need to ask for an explanation seems to be, for many developers, a deeply uncomfortable experience. We’ve created this by expecting ourselves — collectively as developers — to grasp new concepts quickly, with minimal explanation, and off-hours practice if needed. We expect ourselves to have command over a wide array of technical skills (wider than most!), and failure to demonstrate this command with authority can place our jobs in jeopardy. The perpetuation of this expectation of mastery prevents devs from engaging at full capacity with non-dev teammates, and actually makes us worse at our jobs.
How We Silo Ourselves
This fear of appearing unknowledgeable, along with a prevailing cultural belief that others’ work is not our concern, prevents developers from stepping outside the quantifiable skillsets we hawk in our LinkedIn profile headlines. We encourage others to “Google it” when asked a question with an answer that seems obvious to us, and we shy away from asking questions that might expose a knowledge gap that can’t be filled by just quietly trawling StackOverflow. This, however, is not at all how most other professions work, neglects the learning styles of our teammates’ in those fields, and makes us unapproachable.
Tech experts often struggle to become leaders, as noted by Eastern Standard’s founding Technology Partner, Jim Keller. I believe that the issue goes deeper still: tech experts, particularly full-time developers, often struggle to be engaged — fully, productively engaged — at an organizational level due to our fear of vulnerability. This has wide-reaching implications for our work relationships, careers, and the success of the companies we work for.
The most important development decisions are made outside of code, in many cases by people who — at most — passed C++ in the hall once in high school (at companies with disengaged tech teams, at least). Most of us as developers have had at least one job where we felt management or other departments made decisions that were seemingly asinine and had direct, problematic implications for the development team. Of course, this stems primarily from a lack of developer engagement, not malice on the part of our coworkers, but in order for devs to be engaged in these discussions and decisions, we have to understand our teammates and the way they work.
What to Do About It
1. Ask the questions that feel dumb. Ask your designer why that button needs to be in that exact spot, completely out of flow from the rest of the DOM, and really listen — don’t talk over them or suggest things until they’re finished. Did the client insist, is there no other place for it? Is it to draw the eye through visual flow to another area?
Build your understanding of what constraints your teammates are working with, what their challenges are, and why they’ve made the decisions they have. This will inform suggestions you make to resolve the issue, and in turn makes you more approachable to your coworkers when similar questions arise.
2. Explain without ego. Owing to the bootstrappable nature of development, we’re used to figuring it out ourselves. In most other career paths, progression is collaborative and nebulous, and rests much less on correct/incorrect implementation, and much more on situational awareness and original thinking. This requires a different learning process, one which devs are less familiar with: talking it out.
3. Do as the Romans do. You might be the type of developer who goes home after a long day of coding and spins up a pet project to get a couple hours of development in. When was the last time you designed an icon set or created a sitemap for a friend’s project?
Put yourself in your coworkers’ shoes and practice doing what they do. Ask for their feedback on these projects, be vulnerable and inexperienced. Learn to speak their language through immersion, the way you would any other language. “You’ll learn things you never knew you never knew,” as Pocahontas sang, and you’ll gain an appreciation for what they do every day.
Why It Matters
Any organization that’s worth its salt knows that having a capable developer engaged early on a project, one who can spot pitfalls ahead of time and suggest solutions that consider the needs of all parties, is extremely valuable to project success. A key skill to succeeding here is to actually understand those other stakeholders’ needs, perspectives, and workflows, which can only be attained by stepping away from the IDE and doing less development, not more.
Developers can be blindered into seeing code as the solution to problems, but as the phrase goes, “the best code is no code at all.” Learning how to understand your teammates fosters collaboration where code isn’t the only answer, but merely one tool of many to reach a solution. Further, it makes us more well-rounded people, more adaptable to varied challenges, and better teammates who are engaged across our organizations to the benefit of everyone.