Many thousands of bytes have been wasted imploring programmers to think of their jobs in terms of the value they generate. It’s not about the code goes the common refrain: the customers don’t care. Instead of wasting time thinking, we’re told, we should be generating revenue for the shareholders and value for the customers.
I’ve been around the industry for almost fourteen years now. I’ve worked with startups small, growing, and large. I’ve worked with big enterprise businesses. The number one most valuable thing you bring to the table is your brain and your ability to think.
If someone tells you, a programmer, not to think: run!
It’s Not About Value Alone
Designing a solution to a problem requires context. If your problem is that you want to connect two cities separated by a river you’ll need to build a bridge. Your context is the river, the estimated traffic between the cities, how long the bridge needs to last, weather patterns in the area, and so on. An engineer designs a solution to the problem in the confines of the context.
In a similar fashion we need to design software within a context. When I’m working on designing a system that a business or people will depend on one of the first things I ask myself is, what is the worst thing that could happen when this fails? I keep a list of the answers and use them in the requirements gathering and specification phases of a project. You have to be able to think precisely in the domain of the problem and consider all of the variables within the context that the system will exist in. If the answer to the question is somwhere along the lines of, not much, then I know I don’t need to be so formal; a unit test suite will make a fine specification and using a dynamic language to get things done fast at the expense of occasional errors is tolerable. If one of the answers is, someone would lose money or someone could be put in harms way then I know I need to take the time to write formal specifications.
Tech Matters
Nobody cares what languages you use. In a way this is true: unless I’ve told them they have no idea if I’ve written the system using Lisp or Haskell. They don’t even know what those are most of the time. Most people don’t know what the fuel-injection timing is in their vehicle or what effect it has.
However it does matter to you and they are trusting you to make the right decisions. The choice matters because some requirements of the system are more easily managed with automated tools that check correctness for you rather than relying on you or your programmers to not make errors.
The computer language you use on the team can affect anything from developer productivity to system correctness. A language like Haskell puts training wheels on programming so that programmers cannnot, a priori, make certain classes of common mistakes. Lisp makes it trivial to extend the language into the problem domain so that you can solve the problem in a more direct fashion. The team needs to agree on the best choice of language for the problem domain.
The stakeholders care what technologies you’re using. They may not know what any of it is. They’re trusting you, the professional programmer, to make the appropriate choices on their behalf.
The customers care because they will value different properties of the solution for different reasons. They want to know their data is safe. They appreciate software that is fast to load and is responsive. They want accurate, consistent results. They don’t want it to crash or update right when they’re trying to get some work done.
Our choices as programmers affect all of these concerns. If you need to render a 3-D scene sixty times a second there’s almost certainly no way your system can wait for a garbage collection pause in the middle of rendering a frame. If your web service stores financial transaction data you will want to use a storage service that has ACID properties. The technological choices you make will matter to your users even if they don’t know what those choices are or why they matter.
Choices Do Not Exist In a Vaccuum
Software is not a highly regulated industry. And yet we often write software for industries that are: motor vehicle transportation, food and drug manufacturing, science and engineering, and so on. The common method we use to regulate software, in my limited experience, is for our customers to trust us to protect them. Some regulations might force us to adopt certain processes or take perscribed precautions. In the end it’s all about how much over the speed limit you’re comfortable with driving.
I personally don’t think that is good enough. We have proven ourselves willing and able to cheat the system in the name of profits: a software system that allowed engineers to fudge test results, an online tax reporting system that leaks user information, and so on. When we are not personally liable it’s our customers who pay the price.
The code you write matters. You may have some cynical opinions about its value. You may not care about the quality of it. Don’t let profit be one of of the reasons for the way you act. There is value in taking responsibility for your customers and their users seriously and doing your due diligence.