14 things you need to be a successful software developer - Number 5 - Software development is not about coding
This is the first in the second act of the trio of sections this series has, and it focuses on what it is like to be a software developer. When I first wrote this, I did it for a university talk and thought the advice on what it really is like to be a software developer might help the students understand what they would find and get successful faster. Since I have been consulting and speaking to many people, I have realized that there are developers at every level who do not know these things—and some, especially very talented and senior, feel they are there to sit alone and churn out "perfect code"... and they are wrong.
If I were to distil what software development is about to a word, it is tradeoffs. We are always making tradeoffs, and in terms of what those trade-offs are, it is just three things: Capacity, Time, and Features. Very simply, if you want to change one, you need to change at least one more of them—and sometimes two others. I have always liked visualizing this as a semi-rigid triangle, with each side representing one of these.
Time
The time aspect is probably the easiest to think about: it is how long it will take. This can be viewed as the whole project, but also down to individual tasks.
Capacity
This used to be called People and Resources, but we should always remember that people are not resources. When we think of this as People or Resources, we miss the nuance of this. When working with this triangle and talking about the costs of a project, capacity often aligns nicely with people—so if you want to lower the costs, this is an obvious one. That means you would need to increase time (i.e., how long it will take) or decrease features.
Capacity, though, is not just about costs. For example, if you have a single developer, you might feel you can increase capacity... but it can be changed. Are you context-switching a lot? That has an impact on capacity. Are they doing a lot of maintenance work? Again, it impacts capacity. Even the modern view that Scrum has failed is, in part, a realization that the cost of Scrum is directly on the capacity side, without a greater or equal impact on the time side. Even how psychologically safe your environment is impacts this, because a higher-stress environment lowers the capacity for your people to deliver.
Features
Finally, there are features—not only what the software does but how it does it. Do we build a feature in a way that meets the needs now or also those we foresee coming in a few months? Those are effectively two different sizes of the same thing; i.e., features is not one-to-one with the stories or epics in your backlog. Features also incorporate quality, observability, and non-functional requirements (FYI, Donald Graham’s DevConf talk is a must-watch on non-functional requirements—so check out the DevConf YouTube for when it comes out).
A feature you create with shitty code versus great code has different sizes here.
Tradeoffs
Now that we have the triangle and understand the tradeoff, it comes back to our initial rule: our job is not about coding. Yes, the triangle has aspects of coding, but our goal is to ship a solution. To do that successfully, we must identify what will impact the trade-offs and find solutions to that. If you can do that, you will be a far more successful developer—and, importantly, the code you do write will be code that matters, not just electrons sitting idle on a disk.
What can you control about this?
- Avoid the "it's not my job" view. The goal is shipping software that is used. That is a team sport, and if you can help achieve it by doing something outside your comfort zone, it is worth doing.
- Finally, while remembering the triangle, also remember Hofstadter’s Law: It always takes longer than you expect, even when you take Hofstadter’s Law into account.