The culture of the software development world has sometimes valued technical know-how above all else. Developers may see cultivating the “soft” skills of social interaction, teamwork, and communication as a distraction from the work of writing beautiful code. In reality, we need these skills in order to do our jobs properly.

Naturally, developers do have to master specific tools and coding techniques. (And we can still celebrate and take pride in our technical mastery!) More than ever, though, we can’t work in isolation – from our own team members, or from our clients and their users. We’ve learned that we work more effectively and build better products when acting as a cohesive team than we could ever hope to do as a collection of individuals.

Software is everywhere.

The range of problems that we solve with software and the range of people who use technology every day have both grown enormously over my lifetime. The way we build software today reflects that change and growth. We now build not just specialized business applications meant to be operated by a few professionals, but a huge array of software products used by everyone.

This evolution demands that we move beyond thinking of building software that is simply functional, to creating products that are a joy to use. We can’t count on highly trained professional operators to power through a less-than-ideal user experience; we need to build software that is easy for everyone to use – intuitive, appealing, even fun. To do that requires developing a deeply personal relationship with our users.

Start with “why.”*

We have to understand not just what task a user wants to complete, but how they would prefer to do it and even why they’re doing it in the first place. Developing that knowledge takes real empathy, inquisitiveness, and clear communication when working with clients and users.

Building that rapport gives us the insight we need to anticipate and accommodate users’ needs and preferences. When we understand why a client asks for a particular feature, or why their users need to perform a particular task, we grasp the client’s desired outcome more deeply. This positions us to confidently deliver solutions that meet those needs. Without that level of understanding, we risk developing software that is hard to use or doesn’t deliver the outcome users expect, even if it meets a narrowly defined set of technical specifications.

Some technical challenges aren’t as challenging as they once were; others are more complex than ever.

Widely available libraries and platforms have steadily reduced the need to reinvent the wheel in the world of software. Nobody has to write a modal dialog box from scratch anymore! This, coupled with the increasing use of automation to manage and deploy code, highlights the need to sharpen our higher-level architecture, decision-making, and problem-solving skills – areas that involve working closely with team members and clients.

Today, a developer’s greatest contribution comes not from producing small, perfectly defined units of code, but from seeing the larger picture and knowing how to fit smaller pieces together into a well-functioning whole.

At the same time, the range of concerns we face in developing software products has only grown broader. Not only are more people using software for more purposes than ever, but they use software in more contexts than ever too – crucially, on a huge range of devices with varying physical characteristics and resource limitations. It’s no longer practical for a single developer to pursue mastery across every aspect of developing a large application. Instead, we need to work smoothly as a team leveraging our complementary skills.

We’re all responsible for a higher level of quality.

As developers, we rely on project management specialists to maintain the roadmap for our projects. We can’t just accept technical instructions without participating in the broader context and vision for the product, however. Such an approach will lead to misapplied effort, missed opportunities, and waste. Developers should be prepared to tactfully point out potential pitfalls, humbly advise when we see a more efficient or elegant way to accomplish project goals, constructively share knowledge with each other, and confidently suggest entirely new features that will result in a better product, based on our familiarity with the tools and resources available.

Developers should be prepared to tactfully point out potential pitfalls, humbly advise when we see a more efficient or elegant way to accomplish project goals, constructively share knowledge with each other, and confidently suggest entirely new features that will result in a better product, based on our familiarity with the tools and resources available.

Tying it all together is our job.

Today, a developer’s greatest contribution comes not from producing small, perfectly defined units of code, but from seeing the larger picture and knowing how to fit smaller pieces together into a well-functioning whole. These are inherently social, people-focused concerns. We need to be able to work with our team members, clients, and end users to understand root concerns, describe a solution that works for everyone, and coordinate with each other to deliver a coherent, elegant product.

All this means that the old stereotype of the developer as a clever misfit can finally be retired for good. It was never really accurate, and certainly not constructive. Now more than ever, good developers understand both the practical value of interpersonal skills and the deeper satisfaction to be enjoyed from our work when we forge real connections with the people who use the software we build.

* Start with Why: How Great Leaders Inspire Everyone to Take Action, by Simon Sinek. The Penguin Group, New York, New York. 2009.