Working in software development, it’s easy to get caught up in thinking the code is everything, and everything must be in service to the code. After all, not only is the product or service we deliver code, but running on the cloud means your operations are now code, infrastructure is code..it seems like literally everything about software has been turned into “just code.” Software has eaten the world, after all, and yet, writing the code is still the least important part of the whole software development process. That doesn’t mean it’s unimportant, mind you – “least” is a relative term – but there’s so much more that goes into building and running a successful application or service than commands and semicolons.
Why is writing code so unimportant?
Put simply, that’s the part that almost anybody can do. By the time you reach the stage of “type commands into a development environment and compile them,” you’re at the part of the process that anybody, no matter how inexperienced, can actually do it. At this point some of you are likely wanting to point out that there’s more to writing software than just the actual typing of code – you have to understand the problem and design a solution that is reliable and efficient – which is true. But that also goes to my point – the design of the code is more important than actually writing the code. There are tons of developers out there who are quite competent at taking thorough instructions on how to implement a solution and going out and doing just what they’re told, but it should (hopefully) be pretty obvious that developers capable of figuring out how to solve problems are more useful than people who just know how to do follow instructions.
What does matter then?
Software is developed as part of a larger system. On 1 level, system here can refer to the overall architecture of the code and how it’s run – your infrastructure, how applications communicate to services, how services communicate to each other, even how applications and services are scoped. On another level, system refers to the overarching business software is intended to solve problems for. Whether you’re working on internal software or something customer-facing, code written for a business is ultimately there to help the business make money. Even if the software isn’t written for a business, that software still exists to help solve a problem to enable other people to do something they either couldn’t do, or do something they’re already doing better.
Beyond the technical architecture, there’s the overall business to consider. How does the company make money? What are its main expenses? How can the code you’re writing maximize the former and minimize the latter? If your code doesn’t do either, it’s useless. It doesn’t matter how technically sound, fast, efficient, or cutting-edge it is – if it doesn’t further the overall business of whatever organization you’re working for, it has no value.
Even outside a business context, software still needs to serve a bigger purpose. If a piece of software doesn’t make anything better, then why are you using it? And let’s be honest, how much longer are you actually going to be using it? Probably not very. Those decisions are pretty fundamental to the decision to write the software in the first place. They also go to the core functionality of any code you write.
All of these facets to software and what/how it’s built completely ignore customer feedback. That’s the ultimate driver in making business decisions, some of which can be furthered through software, which needs to be integrated into existing systems or built as a new system, which needs to be designed in terms of fulfilling functional requirements, and then finally coded. So by the time someone pulls up their IDE of choice, there’s maybe 1 set of relevant decisions to be made – how am I going to build this thing?
There’s a lot of other parts that aren’t directly in the software development chain that impact software success. Joel Spolsky referred to these parts as the “development abstraction layer.” They matter just as much, but aren’t encountered in the (theoretically) straight line from “person writing the code” to “person running the company.”
It’s not just the number of decisions – it’s the impact
It’s not just how many decisions you get to make when building software that makes code writing the least important part of coding. It’s also how important those decisions are to the success of the software. Sure, figuring out an efficient way of doing something that scales well can really help make a product work well, but as a developer you’re not making the decisions that impact whether people use your software at all. Spoiler alert – it doesn’t matter how efficient, scalable, or resilient your code is – if potential customers don’t think it solves a problem for it them then that code might as well not exist (trust me, I’ve written code that didn’t solve customer problems, it did nothing, despite the cool feature set we advertised in sales pitches). Conversely, at that same company, we had a bundle of little 1-off utilities that was priced at next to nothing and often discounted away to nearly free, but invariably 1 of the utilities in that suite had just the functionality that customer needed, and as a result it closed multi-million dollar deals.
By the time you get to writing code, you’re at the execution stage of product development. I’m not saying execution isn’t important, because slow, buggy code drives customers away. But you need to realize that you’re effectively preventing attrition. The real impact comes from people who are processing the problems your users are experiencing and trying to figure out what a solution looks like. Software developers aren’t really “changing the world” unless you’re sitting down people making product decisions working on what product should do. If you’re not doing that, it’s best to remember that “just because you’re necessary doesn’t mean you’re important.“