Long before I could call myself a professional developer, I had a chance to participate in the Microsoft Imagine Cup, a contest for university-based startups. Student teams—although full of energy and creativity— are typically short on resources, and ours was no different. So my two teammates and I did what we did best: We started coding.
What would be the best architecture for our project? Which framework would help us build quickly? Should we have used ORM? How should we solve real-time communication? What if the connectivity failed? Last but not least: Was it performant enough? The clock was ticking.
Then something weird happened. The contest organizers asked us for a slide deck summarizing what we were building, as well as for a short video clip in which we’d pitch our idea. We were shocked: Somehow a team of three full-stack web developers wasn’t equipped to solve the contest’s challenges.
What factors most influence software quality? Many think that it’s a team’s raw programming abilities. In theory, that might be true. In reality—knowing that we’re not working in a utopian environment of nonexistent deadlines, endless capacity, and zero distractions—the answer is much more complicated. Diverse skills are as key a component to strong teams as is programming talent.
Imagine a team responsible for a core part of a SaaS product. Due to the impact on the whole platform of the modules that they develop, they work under high pressure from stakeholders. Team members need to answer questions not about the framework or library they use, but about whether their work can be finished sooner, faster, or more cheaply. Though everyone on the team can be considered an expert in their domain, they’re asked to use skills beyond those directly related to their programming language of choice or to the tools they develop and maintain. They also must negotiate deadlines and project scope, as well as handle operational events like service outages, which require frequent, clear communication. If they work on common utilities, they must also ask for feedback, accept critique, and collaborate with others. It’s not only raw programming experience that determines performance in such conditions, but also so-called “soft” skills, as well as nonstandard ones, such as marketing, data analysis, or strong organizational abilities.
Famously, in his 2005 Stanford commencement speech, Steve Jobs related the story of how attending calligraphy class later helped him understand the importance of typography while building the first Macintosh. Other nonprogramming skills have similarly diverse applications in software development: Writing is key to good documentation, without which it’s impossible to maintain existing software or solicit OSS contributions. Marketing can help you build teams for an open-source project or startup that has yet to become a well-known brand. Organization-minded developers, who suffer from looking at complex codebases and over-engineered solutions, make it possible to update products with additional business cases without losing extendability and scalability.
Some may argue that using extra skills in your primary career path is easy if you’re a freelancer, or if you’re developing your own pet projects. (In those cases, the same person might be creating a piece of software, marketing it, and talking with users in different countries and time zones.) But regular employees who work within regular, well-defined roles at regular software companies can still use their nonprogramming skills in their daily work.
When talking to colleagues in similar roles, you likely share workplace frames of reference, a field-specific vocabulary, and patterns of collaboration. But when you work with other teams, things get more complex. Suddenly, you hear words that you’re unfamiliar with, you see people stressed out about things that you’ve never had to think about, and, from time to time, your coworkers laugh at a joke that you don’t get at all. For us engineers, these moments aren’t that rare.
It’s highly likely that, at some point in your career, you’ll have to talk to a designer, a product manager, a business analyst, a people manager, an account executive, a salesperson, a marketing manager, a customer representative, a support-team member, or a C-level executive. That’s at least ten types of specialists that your daily job may be connected to! The richer and more diverse an engineering team’s experiences and expertise are, the more comrades you’re able to get along with. And aren’t more creative and diverse work environments what we’re all striving for?
Unsatisfying. That’s how I’d describe my team’s first attempt to win Imagine Cup. Though we spent a lot of time coding to ensure that our app worked well—and landed in the top 30—we weren’t ready to do anything else, much less start a company. Our gut feeling was that we needed something more: a stronger, more diverse team. A year later, we had to reinvent ourselves, and so invited a mobile developer and a film student to join us.
Each team member offered completely different views on the product that we built, and, together, we managed to make it much more compelling. In addition to the central product—a service that lets people discover how crowded restaurants, pubs, and bars are in real time—we created a mobile app; a well-written landing page, which centered the product’s usefulness to people (instead of listing all the frameworks and libraries being used under the hood); and a promo video, which explained the different use cases for our product. Because we now had a connection to the film school, we were able to borrow equipment, record a few scenes using drones, mix in CGI, and even get help from experienced actors who had already spent time in front of the camera.
Our team drew upon our collective skills—software development, filmmaking, project management, and design—and made it to the top three, the first group from our university to do so.
The world that we live in is full of strictly defined career paths. Are you good at math? That’s great, you should focus on a degree in the sciences. Are you creative? Perfect, we have a vacancy in an advertising agency nearby. Do you want to mix these two? Why would you? Modern workplaces, where everyone celebrates specialization, have little place for polymaths.
Education, industry, and even job titles organize people into professional circles. Such groups can easily cope with the problems that they (and their leaders) expect, but they often fail in the face of the unexpected. Teams building software can’t afford to fall into this trap—not when they care about end users.
Since secondary school, I’d wanted to become a graphic designer. I spent long hours participating as an active member of online design communities; reading posts, articles, and books about good and bad design; and working on design projects to gain experience. Then real life happened. After my first design job turned out to be more repetitive than creative, I decided to pursue something that had always been in the background, helping me build my online identity as a designer. Computer science, here I come! After graduating university and working as a full-stack developer, I decided to specialize in frontend development—which blended my prior interest in design and my later journey into software development.
Connecting the dots from my past, I recognized that all those years dedicated to graphic design had paid off. Not only was I able to communicate better with the designers around me, but my suggestions regarding UI were also more accurate. I was aware of the most common constraints that both designers and developers operate within, and my familiarity in this area resulted in faster and more concise feedback loops. Bringing this broad skill set to my work now helps me build software that feels better for end users.
While my computer science education helped me lay the foundation that I needed to become a successful developer, I’ve had to look beyond strict computer science as I continue to build upon it. We are better engineers the more we know about the internals of the products we make (the language, the frameworks) and the more we understand about the externals of the world that we—and our products—live in. Those advantages compound in a team, especially in workplaces that actively seek out and support engineers with broad, varied skill sets, and especially in an industry where the only constant is change. After all, our software does diverse things. So should we.