Most developers believe they are being paid to write code.
After all, most days, that is what they do. They show up in the morning, check code out of the repository, modify it, add to it, and then check it back in at the end of the day and go home; many to write more code. On the surface, the idea that developers get paid to write code makes sense. After all, isn’t that the final product? Isn’t code what we release into production and ship to our customers?
We would argue that no, code is only one small part of the process and, in fact, it isn’t even the final product.
Glenn Vanderburg did an amazing presentation called Real Software Engineering at the Scotland Ruby conference where he redefined how to understand software engineering and its various parts. A lot of the thoughts in this article come from that presentation.
First, let’s look at bridge engineers.
They build bridges, right?
…but do they?
In fact, bridges are built by contractors, welders, metal workers, concrete workers, and so on. Most civil or structural engineers will never lift a shovel or pour concrete, or do anything constructive to help with building the physical, concrete bridge.
What engineers do is figure out how to get vehicles and people from one place to another. There is a gully or a river in the way and people need to get across it. Engineers work to understand and solve the problem. They determine if a bridge is needed, and if so, what kind to use. They determine the structural and aesthetic requirements and then model and test various solutions. Engineers are paid to understand everything that will make a bridge successful.
In order to get to this level of understanding, engineers use various tools. Experience from other bridges plays a huge role, but so do mathematical models and computer simulations. Basically, they run constrained experiments to understand the conditions under which the bridge will live. They use lots of little failing experiments to test different variations and to ensure that the passing experiments pass for the right reasons.
The most dangerous thing that any engineer, scientist, or software developer can encounter is to have all the experiments pass; this means that nothing has been learnt. You have no idea if you are right or just lucky, because you can’t compare your success to any failures.
So how does this relate to software development?
The first, and most obvious correlation is that software developers are paid to think and to understand. A professional developer’s job is to understand the problems that their customers are facing.
That’s it. End of story. Bottom line: They are paid to think, to run experiments, and to understand.
So what is code?
Good question. Code is the language in which developers do their thinking. The same way an engineer will use MATLAB to run simulations, developers use a programming language (Ruby, JavaScript, etc.) plus a test framework. If you don’t use a discipline like TDD, then you are not learning, you are merely guessing.
But isn’t code what we give our customers? Not really. The same way that an engineer’s blueprints, simulations, and mathematical models all need to be translated and interpreted before they go to the construction team, code needs to be translated and, sometimes constructed, before it will run on a computer.
Code is for humans to read. It needs to be interpreted, compiled, or both before a computer can understand it. Code is just a way of modelling our understanding of a problem and its possible solutions.
The realization that a developer’s job is to think and understand, is very liberating.
It removes the pressure of trying to get things right the first time all the time and it removes the pressure that productivity needs to be measured in lines of code. It can also remove the need to try and implement every solution as a software application.
These parallels don’t just end with thinking.
They continue with the idea of running little experiments in order to understand. Some of those experiments will succeed and some of them will fail. If everything succeeds, you aren’t really learning anything, you are just iterating on things you already know, working on something very small and unimportant, or being very lucky.
Failure is more important to software development than succeeding because failure is what drives innovation.
Failure is critical.
It is in failure where the best ideas come from and where the best solutions are discovered. As such, development teams need time to think and the ability to fail quickly, to fail safely and to recover quickly. Quickly coding or prototyping ideas, fast running tests, short iterations and constant customer feedback all help to provide this infrastructure.
At the end of the day, the value that developers bring to development teams and to business is not the code that they write, but their ability to understand and to think. Code is just the language that developers use to work out that understanding and make new discoveries. People don’t hire mathematicians because of the equations they write, they are hired for their ability to use those equations to discover new things about the world around them.
Software development is about thinking, solving problems, running experiments, failing, and, in the end, succeeding based on an even greater understanding of the original problem.
So, go, try new things, fail quickly and try even newer things.
Give yourself permission to look beyond the code, worry less about the tools, and have fun solving wicked problems.
Enjoyed this read? Click the♡ ! Want to learn about how we breakdown engineering and product culture at Nulogy? Follow us.
This article was written by Nulogy alumnus, Chris Johnston.
