The value of a software engineer

A quick note about keeping us accountable to users.

As a software developer I take a great deal of time to try and further develop my skills and understanding of computers, software, the architecture thereof running software in production and measuring the success thereof.

It is thus a little preturbing that in my more recent reflection I’ve come to consider these skills and and of themselves — well, they’re not worth very much. That’s somewhat frustrating as such skills can be heavily rewarded within our monoculture of our software development peers, and are often inroads to furthering our prestige and careers. However, though were are tempted we cannot forget the fundamental nature of what we do:

We serve users.

Those members of our broader communities; the parents, children, white and blue collar workers, the richer and poorer members, those who are local to the area and those who have immigrated— those complex entities known as “people”.

It is given this that I think it’s worth re-evaluating how we approach our own self assessment of our equity with a view to improve some of the skills that are perhaps less emphasized within our profession:

Understanding each other

All computer problems are, fundamentally, human problems. Perhaps uniquely so as software developers we sit atop an entire stack of our forebearer’s ideas about not only software, but about life, the nature of relationships between teams, the relationship to the user and how we should talk to each other.

Taking the time to understand not only the code that is written, but the people who wrote that code and their ideas, as well as those people who are attempting to teach us their own systems to encode into our software, those who will use the software and those who will try and take what we have built and explain it to potential new users so that they can also benefit from what we’ve build, hopefully departing with some cash to show their appreciation.

The skill that I would prize above all others is that which embraces the complexity of our lives and the lives of others, and seeks to find a harmony between us such that we can build a thing thing that is truly a useful contribution to our community — rather than what amounts to a technical work of art.

Understanding the market

Market (noun):
a regular gathering of people for the purchase and sale of provisions, livestock, and other commodities.

Our markets are a complex entity involving the calculation of “value” given the social, cultural and financial context in which a given user is operating.

Understanding some of these complexities can help us as software developers create products that deliver the appropriate value to the users that we’re building for. If we’re able to examine what’s happening in the existing market, and spot ways that we’re perhaps able to help users in our uniquely efficient way we’re able to create a product that has the chance to be much more successful.

Further, if we understand the market we’re able to position our product in such a way that users are able to reason about what it can do for them and in their lives.

This gives what we give life with our actual development the much greater chance of commercial success, giving us a better chance to further improve the service or develop new ways in which we can improve the lives of our users.

Mapping domain specific expertise into software

The value of software is not in its inherent nature to do a thing repeatedly, but that this thing does something of value to us. We use software for a purpose; to derive a value from it.

Human endeavours are invariably complex endeavours; especially now that the encoding of simpler processes such as sending a letter or writing up some literature for expression into the world have been well solved by services such as Gmail or Medium. The problems that remain to solve are far more complex, though the payoff to solve such problems is still enormous.

Unfortunately, though I like to try we as developers cannot seek to understand the entire world. There are those who spend that time that we spend furthering our own engineering capacities furthering their own knowledge in their discipline; in accounting, medicine, coaching, construction, marketing, logistics or any of the other complex processes that make up this social fabric of the world.

However, the success or failure of the software we build is how the software is able to deliver value that complements or replaces those domain experts — how well we’re able to map their understanding into software.

We thus need to spend some of our time learning our area of software development, and learning how the experts whose knowledge we’re trying to encode into software approach a given set of problems. We further need to reason about how we can represent this approach in software, and talk further to those experts so we explain the limitations of machines and how to overcome them.

The skills required to ship code

It is here that I would place the skills that I have previously spent so much time refining; the engineering aspect of our discipline.

As software developers we need to be able to take the abstract representations of things that we understand and build both their logical representations and user interfaces such that users can either learn or map their own representations of that same abstract entity onto the interface.

To do that requires an extraordinary discipline, coordination with other developers, stakeholders and the users. One must make changes with a consistency I have never seen in other disciplines, matching, adjusting or working with the logical representations of our forebearer’s mental models.

It is perhaps most important to emphasize here that a developers work is only “done” when it is shipped and in front of users. Between conception and delivery (indeed, until after the software has been measured in production and it is verified working as intended) software changes are almost entirely hypothetical.

The skills required to run code reliably

Lastly, while it’s a simple conceptual model that we simply build and ship our software it is not quite how software pans out once it gets in front of users.

Users are wildly unpredictable, sometimes actively hostile entities. When developing software (particularly web software) one must both build and launch the software, and then actively manage it as users start using it, probing it and generally introducing it into their lives. These users combine enmasse to produce interactions that we never imagined and we need to ensure that our software still works as quickly and reliably as we predicted that it would, even though the requirements are not quite what we imagined.

We further must be aware that not all of our users will be friendly, and there will be users who will actively seek to find logical faults with our software and exploit them for their own gain.

In Conclusion

The building of software is, unsurprisingly, the vast majority of a software developers requirements. However, the building of software does not happen in a vacuum and the complexities of life, of people and their cultures and of the complexity of the problems we’re trying to solve all go into determining whether our built product will be successful. We as engineers need to reach beyond the borders of simply committing code to try and understand the context in which we operate and hold ourselves accountable to ensuring that our users are actually deriving the value from our software that we imagine they should.