Communication: It’s an Engineering Skill
“I don’t like asking the engineers to do things.”
This admission came from Tim, one of the curriculum developers here at Codecademy. We were standing in our office kitchen, chatting after lunch. He explained that it was hard for him to approach the engineering team when he needed a new feature or a bug fix because he didn’t want to give us more work to do.
“Please ask us to do things,” responded Jon, another engineer on my team. Jon reassured Tim that we would be happy to take on his requests. Still, it had become clear that there was a major communication gap between our teams.
As with any job, effective communication and collaboration are essential to engineering. Often, what’s blocking our work isn’t a technical problem, but rather a lapse in communication. Unfortunately, not everyone seems to recognize this.
At the beginning of August, I started my first full-time job as a software engineer at Codecademy, and in that same week, former Google engineer James Damore published his now-infamous memo, “Google’s Ideological Echo Chamber.”
In the ten-page document, Damore attributes the gender gap in the tech industry, at least in part, to fundamental biological differences between men and women. He claims that women are “more cooperative” and “show a higher interest in people,” and thus that they naturally struggle in engineering roles, which tend to be more competitive and idea-driven.
What struck me about this memo was not just the blatant sexism of Damore’s claims, but also his fundamental misunderstanding of engineering as a field. In his manifesto, he paints a picture of engineering as a solitary, competitive activity. He says, “… there may be limits to how people-oriented certain roles at Google can be,” as if Google engineers sit alone in caves all day, churning out thousands of lines of code without any human interaction. Any engineer with job experience would tell you that this vision of engineering is, at best, misguided, and at worst, just plain wrong.
From sharing information across teams to letting users know about a new feature release, there are infinite ways in which communication affects our everyday work. The most obvious example is, of course, our interactions with our coworkers. Companies such as Codecademy require a wide variety of people to work together in order to accomplish a common goal.
Sometimes, as was the case with Tim, this requires structured channels of communication between different teams. After our conversation with Tim, Jon brought his concerns to our product manager, Andrés. In the next few days, Andrés created a structured process for submitting issues and bug reports to the engineering team. The existence of this process encourages curriculum developers to communicate their needs to engineers while allowing us to systematically integrate the extra work into our schedules.
On a broader scale, it’s often important to develop a shared vocabulary. As my coworker Alex pointed out: “Term definition is a constant communication problem. Ask everyone at a twenty-person startup what a word means, and you might get twenty completely different answers.” Here at Codecademy, we have company-wide jargon that allows us to share ideas quickly and effectively; for example, when we say the word “course,” we’re talking about a series of lessons, projects, and quizzes on our site. This prevents a lot of miscommunication that would otherwise impede our work.
Sometimes, of course, miscommunications between coworkers do occur. In those cases, it’s important to resolve conflicts through honest discussion. I spoke to one of our engineers, Eric, about what he does when there’s a gap in communication between himself and a coworker:
Giving and receiving feedback is a foundational part of the culture at Codecademy; it’s one of our cultural values. If an uncomfortable interaction arises at work, I’ll sit down with my coworker and discuss the experience and ways we can improve our communication in the future. Making a comfortable communication space with my teammates is important to me, and improving my ability to give and receive feedback at Codecademy has been refreshing.
Upon examining our behavior, it becomes clear that we are enriched, both as individuals and as an entire company, by our ability to communicate — to care about other people. After all, didn’t many of us become engineers to improve the world through technology?
Ultimately, we don’t need to make engineering more “people-oriented” — it is, and always has been, a field entirely driven by people. Instead, we need to recognize this fact and celebrate the engineers who use a wide variety of skills to succeed at their jobs.
I’ll leave you with this photo of two of our engineers, Eric and Rebecca, fixing a bug together (and clearly having a great time). I’m so happy to work on a product that changes people’s lives, in a collaborative environment with intelligent, driven coworkers who actually enjoy working together. If somebody thinks that people-oriented engineers are worse at their jobs, then they clearly don’t know what they’re missing.
Interested in working for Codecademy? Check out our jobs page!
