On Quiet Developers
Redefining Community Engagement in Software Development
As a UI engineer, I’m as passionate about diversity and accessibility in the tech industry as I am about JavaScript. I look forward to work daily, adore my team at MongoDB, and taking on a challenging new task to roll out to our Cloud platform makes me really excited (like, unable to sleep excited). In everything I do, my main goal is always to improve myself while supporting others, and yet, whenever I’ve interviewed or interacted with other developers outside of my company, my credibility has been questioned because of my lack of community presence. Yet, I’m part of communities—just not ones that are immediately visible.
I’m not disengaged from what is going on in JavaScript; I’m what I call a quiet developer, and we’re challenging the standard definition of community engagement in engineering. Even more than the concept of a cultural fit, community engagement seems to be an omnipresent force in the homogeneity of the tech industry. Like anything promoting homogenous hiring and advancement in tech, it stands in diametric opposition to diversity initiatives empowering minorities and oppressed groups, and ultimately serves as a proxy for discriminatory hiring practices.
Who Are Quiet Developers?
I’ll admit that what people have pointed out is true. I have very few visible GitHub contributions. The only pull requests to public repositories I’ve made were because of arcane knowledge of Sumatran airports. I’m more prone to writing about identity politics than technology, and my bookshelves at home are more full of books on gender and Southeast Asian music than books on programming.
The only tech conferences I’ve attended have been with colleagues during work hours. At home I code less than 8 hours a week, and almost exclusively for contracted, close-source projects. I haven’t given talks. If I did, I’m confident they’d involve diversity and accessibility, not which APIs have moved from callbacks to promises (lookin’ at you, Notifications API), or how we still need to be careful in what polyfills we use at home in our favorite transpilers, be they ES6, ES7, or beyond.
Back in 2012, Scott Hanselman wrote in defense of a similar group of what he called dark matter developers. I don’t think that term is quite right for this situation though — he speaks of engineers focusing on existing technologies that can’t utilize the latest updates in languages and frameworks. In comparison, many developers are interested in staying abreast in our field and work with the most up-to-date tools and frameworks available to us. We’re not so much dark matter developers as what I call quiet developers; our work is less public, and we are largely uninterested in selling ourselves. But being quiet doesn’t mean being voiceless, ignorant, or self-conscious, and that misconception is a major mistake in how the software development industry functions.
There are tons of reasons why a quiet developer may not contribute to open source, attend meet-ups and conferences, or have an active internet brand. Many of us aren’t the target demographic of tech hiring—that is, we’re not straight, white, cisgender, affluent men in their early 20s. Using this as criteria for hiring is often a powerful tool for silent discrimination, whether intentional or compounded by implicit bias. For example, a quiet developer checking out at 6pm everyday is unlikely to be disengaged, and might instead:
- be a (potentially single) parent that prioritizes time with their children, or have dependents like aging parents, close friends, or partners to help care for
- have a non-visible disability, like anxiety, depression, carpal tunnel syndrome, Crohn’s Disease, HIV, a sleep disorder, fibromyalgia, or simply be undiagnosed and working to prevent flare-ups of what they experience
- commute a great distance to work, whether out of personal preference, to allow their children to attend a certain school district, to support nearby family members, or out of financial need
- face or have faced day-to-day discrimination and harassment that leads them to avoid criticism by effectively anonymous people
- work additional positions or part-time/contracted work, often compounded by disparate pay discrepancies impacting minorities
Regardless of circumstance, people are never obligated to structure their entire lives around their employers. People can simply have other lives outside of work. Quiet developers do not need to justify their relative silence.
Nor is there ever a reason to demand such justification from a candidate or employee—in fact, it is often illegal to require an employee to disclose some related circumstances, or to allow these circumstances (or the suspicion thereof) to influence hiring. For example, it is illegal to ask a candidate if they are married, if they have children, if they have outstanding debt, to require age disclosure (or ask questions like how long you’ve been in a field), or to disclose disabilities or information related to them (like sobriety, health, etc).
However, it’s perfectly legal to use community engagement and involvement as an excuse to not screen a candidate, or turn them away for a job — candidates who the interviewer may suspect to be married, have children, be over 30, or have physical or mental disabilities. Using engagement as a prerequisite in recruiting is just as common; a technical recruiter can easily be instructed to prioritize based off GitHub activity without knowledge of the projects or closely examining their work, ultimately empowering a candidate pool that maintains a status quo.
I can attest to this personally. I don’t program a great deal outside of work on purpose, and I’m open about these:
- Repetitive Stress Injuries and Insomnia often limit what I can do in a day, especially at night
- Negative and abusive experiences in OSS communities have made me hesitant to make contributions to organizations I do not know personally
- Pair/group programming is frequently more enjoyable for me than programming alone
- I don’t want other areas of my life to atrophy, like performing Javanese court music, composing, baking, or doing Iyengar yoga
Yet in interviews, managers have point-blank questioned this lack of community engagement as a character flaw, putting me on the spot and expecting me to defend myself. Some have tried to use this initially as intimidation, in an attempt to find only the “serious candidates”. Others mentioned these in response to my “unreasonable” interests in diversity/inclusion, with quotes like “I don’t know where you are finding queer developers, but frankly I don’t believe they exist” (I relayed this to a network of some 1600 queer developers that night). Employees of companies and contributors to major projects have dismissed my calls for eliminating gender-bias from their documentation simply because I don’t have enough open source contributions, even though my commentary was provided through GitHub on their open source projects. The same suggestions from regular contributors were celebrated and quickly merged in.
Embracing the Quiet
How then, do we proceed? Are there silver bullets to eliminating this bias? I have a few suggestions below, but first I need to state something so important that I’m going to use those gigantic quotes in Medium:
It is not the responsibility of quiet developers to fix hiring, just as it is not the responsibility of oppressed minorities to eliminate structural violence.
There is no difference in requiring an engineer to have a developed, public community presence outside of work, and requiring an engineer to spend the same amount of time out of work trying to instruct and educate others. Yet, quiet developers are not immune to the same biases, and it is our responsibility to question how we contribute to these oppressive strategies. In doing this, we must also avoid “bootstrap” rhetoric by which we credit ourselves and our luck to innate skill, and in doing so dismiss our peers in the same situations we were in moments earlier.
For everyone else, however, it is essential that these discussions be made, and made publicly, loudly, and frequently. Have conversations with hiring managers, colleagues, recruiters, and talent acquisition agents. Reframe your recruiting and hiring practices.
When doing this, it’s not enough to view community engagement as only a plus, rather than a negative trait for other candidates. This inherently benefits those with a visible presence in a way that quiet developers cannot benefit—this is effectively still positive and negative feedback. However, we don’t need to ignore community engagement; this, like many questions, can be viewed instead as a medium for asking a candidate about something they’re proficient in, and in turn reflecting on relevant topics like technical knowledge and, often more importantly, empathy.
Implicit bias training is another important (and in my mind, mandatory) first step. Identifying automatic associations we have with people and behaviors is incredibly important — this solves nothing, but gives the very basic first tools for dismantling where these biases reside in our processes.
Next, we must examine the desirable features of an ideal candidate, like activity in open source communities, and break them into what we actually are looking for in terms that aren’t as engineer-specific (for example, “empathetic towards colleagues” and “capable of giving supportive but precise criticism”). By using these abstract ideals instead of arbitrary checklists, we can discourage pro/con lists that justify initial impressions, and instead focus on learning about candidates.
Finally, it’s integral to remember that this isn’t just hiring. This extends into performance reviews and management, career progression, organizing training programs, defining regrettable attrition, running exit interviews, and many more facets of business. And if this sounds a lot like the same well-worn and repeated tips for diversity and inclusion 101, a secret: that’s because they are.
Empowering the Quiet
In the months since joining MongoDB I’ve attended conferences and worked with Mongo’s open source projects. I’ve watched and discussed countless talks, argued about upcoming technologies, helped read and revise blog entries from other engineers, and submitted a proposal for an upcoming talk on diversity and inclusion.
This wasn’t because I was required to, but because I was empowered to. My day job provided options to explore this as part of my daily responsibilities. The danger of emphasizing community engagement comes in it as a requirement, be it in hiring or evaluating job performance. Rather than requiring participation, we can focus on making engagement in projects we care about accessible and identify harmful behaviors in these communities that need to be addressed.
For example, rather than explicitly requiring a quiet developer to attend a conference, we can demand that the conference in question include a code of conduct that emphasizes the safety and well-being of all attendees, regardless of race, gender, age, sexuality, disability, or other characteristics. The conference must have resources available for all who wish to attend, especially those who the code of conduct most protects. While I write as an individual and not as an employee of MongoDB, I am proud of how we’ve taken this as a priority of our own. Our amazing events team drafted such a code of conduct and worked to create an exclusive safe-space in MongoDB World events for women and transgender developers to speak, decompress, and attend parts of the conference on their own terms together. We all can take this a step further, and request these spaces in other large conferences and push for this to be the norm, rather than laudable.
We can also give power to quiet developers that might be out-voiced by louder contributors or project owners by creating open source organizations on GitHub within our own companies, and we can encourage the abstraction and publication of OSS modules to these organizations. This allows quiet developers to keep their existing workflows and seek PR feedback and approval from colleagues they trust, rather than contributors they have never met.
We can highlight quiet developers’ achievements and accomplishments, insisting that they be correctly credited or cited for work that might otherwise be attributed to more visible colleagues. This begins the slow process of returning the credibility and validity stolen from minorities and oppressed groups of employees back to those individuals, and making it clear that it is not acceptable to attribute to the most visible, privileged members of a team by default.
We can allow quiet developers to help drive education initiatives. Taking a page from dark matter developers, we can prioritize learning about topics that interest or intimidate us, rather than simply what is the newest or most advanced topic. By shifting emphasis toward promoting constant growth, we can empower others and dismantle arguments as to which emerging technology is better. These arguments are seldom useful in these spaces—they often boil down to insider language used to affirm one another’s membership in a community, rather than promoting understanding.
Whose Community? Whose Engagement?
As we work toward redefining engagement in engineering, we’ve begun dismantling the concept of “community engagement” as a specific, positive attribute and breaking it into component characteristics: empathy, communication skills, passion, and other monikers for skills that frequently transcend technical experience.
Just as there isn’t a monolithic concept of engagement, there is no simple global community. Instead, there exist a great multiplicity of communities, some independent, many overlapping and intersecting, and each offering unique contributions. When we limit our sights to a specific community (like contributors to a popular platform), we often narrow our focus to specific communities we are part of, or seek to be a part of. Even when we focus on groups we aren’t a member of, it’s tempting to focus only on the output that most benefits us directly.
Both in and outside of work, this attitude becomes alienating and toxic. Instead of seeing a candidate or colleague as inferior for not contributing to a chosen community, we should see them for what they are: an individual with a distinct background living amongst the invisible borders of identities and groups. Those groups are innumerable and represent a spectrum of experiences: they might include a group of volunteers working without pay with after school programs, the family of a single mom, a table of queer elders playing cribbage, and many worlds beyond our own. It should never be a red flag when we cannot identify someone’s community, nor someone’s engagement in these communities. Rather than labeling others as outsiders, we should view ourselves as outsiders. In doing so, we learn to respect and admire others, and further empower people to define their own contributions rather than us defining their contributions on their behalf.
As for me, I’m thankful, lucky, and privileged to work on a team where questioning these assumptions is a day-to-day activity, and where we constantly seek to redefine what it means to hire in technology. When I think back to the interviews where a lead broke from their routine to mention that I was “not part of the [open source] community”, I invariably remember the same internal response I stifled each time: “…but you’re not part of my community!” Only through dismantling and carefully examining our assumptions can we begin to see quiet developers for who they are: real people with real passions, and anything but silent.
