What Is the Value of a Programmer?

We looked at what a programmer does based on the names we use. What happens if we turn the question around and ask a more direct question? As a programmer, most of us will get up every day and go into a job and get paid generally well for our time spent because we are expected to provide some value to a company. When we leave at the end of the day, what is it that we were there for in the first place? What is the value we contribute?

Is a programmer anyone who can rub two lines of code together? I've worked with great people from many fields who can do that.

I have met

• great mathematicians who can make algorithms fly

• designers steeped deeply in language and program structure

• process experts who can organize any effort.

• clever and inventive people who could Macgyver a system into doing anything with two lines of code, a regex and a cron job.

Unfortunately, I've also seen all those people fail, or worse, sink their teams in a software shop.

So what is the measure of success? Our value is in our delivered solutions. That's all. Everything else is a means to an end. When we can deliver valuable solutions without code, we'll be out of work.

Therefore, a programmer's value is their

1. ability

2. to deliver

3. software

Ok, that doesn't seem very profound at first glance, but let's dig into it a little more.

Ability

Ability simply means what we are able to do. We often are not trained with that goal, though. Go to college, take a class, pass the test. Get straight A's. Can you ship software? Maybe. Go to the conference and listen to the talk. Bring home the slides. Bring home a new skill? Unlikely. Go to an "intensive" and get a certificate. Are we more able? Hopefully, we are slightly more knowledgeable than we were, and knowledge is a necessary prerequisite to ability.

Unfortunately, I see a lot of programmers and educational approaches stop here. Knowing syntax is not codecraft. Listing agile ceremonies is not leadership. Acquiring knowledge is just the first step in building skills. Skills are things we can actually execute, on the job, to provide value. That requires context, mentoring and lots and lots and lots of practice.

Additionally, to apply those skills, we need to have good judgment as to what to do with those skills. Knowledge, skill, and judgment are what create ability.

To Deliver

Of course, I could have the ability to write a stunning academic work on the value of functional programming approaches, but that isn't the ability for which programmers are valued. We are valued for delivering. Not writing, or coding or building or analyzing, but getting software out the door so it can make a difference. To create any value, we have to ship.

However, we can still create little to no value shipping, because businesses need even more. They need us to ship efficiently. An art project that we spent 5 years on is valueless, because it will already have been left behind by changing circumstance, changing technology, and competitive markets. We are probably already out of business anyway. Efficiency makes responsible, ethical use of our resources especially time.

They need us to ship predictably. If no one cares about when we finish, then no one cares about what we are building. Our work impacts businesses in staffing, funding, infrastructure, marketing costs, and much more. Building software is expensive, but its downstream effects can often be even more so.

To be predictable, we also need to deliver sustainably. If we work in a way that causes us to slow down with every step, not only will our planning fail, but our value will soon be swamped by our costs. (See Robert Martin Clean Architecture Chapter 1 for a good discussion).

Software

Designs and schematics are worth almost nothing. Requirements, contracts, or even tests do not provide the core value to the business. We have to actually craft and ship usable, working software. However, I could deliver hello world in eight languages tomorrow, so we need more.

We need to deliver software with high value. That means we have to actually know what users and businesses get from our solutions, not just what solutions excite us as programmers.

We need to deliver software that is reliable. Unreliable software is worse than just a cost generator for services groups. That could be argued away at the balance sheet. It reduces willingness to seek new value, to accept new features, to apply it to new problems. It strangles the project and that is ignoring the crippling effect is has on the development team itself.

Lastly, we are looking for software that is inventive. Rarely are we called upon to do what has been already done. Building new software is expensive and economies of scale favor existing solutions. Delivering software is a creative act where we attempt to craft a better solution than existed before.

Here is this value proposition in a cute little chart.

You know what? It still does not seem super profound. It is not a new and different reality that is special to software. It is the reality of a job as a maker. However, it defines what our career is, what our advancement means, what our ethics need to be, and what training is effective. It is why, though imperfect as all metaphors are, the software craftsmanship model works well for programmers. We translate ideas into working reality with our own hands (so to speak) and ship them out the door.

It is an important reality that grounds how we do our work. It defines the shape of our growth in our career path. It anchors us as responsible professionals in the crazy demand of the current job market. It lays out the foundation for how we look at and assess ourselves and each other on the job. So, maybe it is profound after all.

Joe Gee is a master craftsman at the Rocky Mountain Programmers Guild where he mentors programmers and teams to grow their mastery, performance, and delivery. Learn how he can help you or your team at www.rmprogrammers.com.