Software is about people and the jobs they need to do. It may look like it’s about things like algorithms, databases, and network protocols (which certainly are all relevant), but software developers' primary responsibility is making a system of people and their jobs more successful. Writing code may be the means, but code must be fit for use and actually be used to have any value.

Everyone sees the universal kinds of applications like spreadsheets, word processors, and web browsers. Look past that class of software and you’ll find the dark matter of the software industry: programs that automate business processes, proprietary tools used within the walls of a single company, portals made by one big company for another to use.

Chances are that if you are a software developer, you work on the dark matter and not the glamorous stuff. If you want to grow in your role, technical know-how isn’t enough; you need to understand the people and their jobs.

What job does your software do for its users? What service do they provide in your industry? How does your company fund itself by providing that service?

All enterprise software is built out of the fossilized strata of what was successful in the past. They are full of historical accident and complexity. You may have to follow the trail awhile from your applications the people at the other end, but people are certainly there.

I’m not trying to discourage you from working on your technical skills. Those skills very much matter. By all means, learn statically-typed functional programming, a new architectural style, and how your favorite database works in excruciating detail. It’s great fun and will give you greater leverage when you attack the right problem. Just mix in some learning about product management, user experience, and your industry. You’ll learn to see which problem is the right problem for the people your software serves.

No matter how hyped software may be, there’s nothing special about software developers. We are people working with other people to do a job that is useful to people. Even the recent rapid progress in machine learning won’t change that, at least until our artificial intelligences rebel and declare war.

Just as in other jobs, your career and skills grow making yourself more valuable. Taking responsibility for making the whole system work just a little better leads to more autonomy. You can use that autonomy to take greater responsibility and build a virtuous circle of improvement that yields growing skills and the capability to deploy them strategically.

Recommended Reading

Living With Complexity. Donald Norman.
Most people don’t relate to technology the way that software developers do. Don Norman will help you empathize with your users, appreciate the challenge of design, and help you think about how software works socially.

User Story Mapping. Jeff Patton.
User story mapping is software project planning method centered around a user’s journey doing a job. This is the best technique I know for planning end-to-end iterations that actually make sense to users.

Product Management in Practice. Matt LeMay.
Product management is inherently a discipline that bridges most of a company, so it’s no surprise that a product manager would produce one of the best guides to navigating ambiguity that I know.

The Phoenix Project. Kevin Behr, George Spafford, and Gene Kim.
A business novel that shows you an (admittedly idealized) path from organizational dysfunction to people working together with common goals.

Building Evolutionary Architectures. Neal Ford, Rebecca Parsons, Patrick Kua.
You don’t have to figure out everything up front when designing systems. Survey of architectural styles and guidelines for how to grow a system into fulfilling its purpose.

Release It! Michael Nygard.
Code has to run in production and survive real use to be valuable. If you aren’t already responsible for keeping your application operational under load, you are starving yourself of a valuable feedback signal for improvement.

Domain-Driven Design. Eric Evans.
The classic guide to learning how to translate the language of experts into how you build software. Of all the patterns books out there, Domain-Driven Design is the deepest and most valuable.

Working Effectively with Legacy Code. Michael Feathers.
Nothing alienates non-technical collaborators faster than saying “We can’t make forward progress on the product unless we rewrite everything from scratch!” It’s a common impulse and rarely true or productive. You cannot possibly have to deal with code that is scarier than the code samples Michael Feathers uses in this book. Seeing the patterns he uses to bring an unruly system under test will eradicate your fear of diving into a legacy mess.