Software Producers

When we see the speed at which LLMs can code, it’s understandable to have doubts about the future of software developers (devs going forward, to save some keystrokes). After all, machines can write code much faster than humans, and devs are “people who write code”, “code monkeys”… “people who turn coffee into code”. But writing code is not the dev’s main job, just as writing legal documents is not the lawyer’s main job.

The software developer’s job is to increase the company’s value by building digital systems that solve problems, either for the company (internal) or its clients (external). This usually means increasing company’s profit, but it may take some time for profit to catch up to value. Of course, the way to achieve this is usually to create, read, update, and delete code, but this isn’t the end goal. Users have problems, and developers have to find ways to solve these problems: get information out of the database, create the user interface, or make a video game. This is the key point of the discipline of software engineering, but the forest of system design is often hidden by the giant sequoia tree of coding.

Writing code is the best way we have found to build digital systems, and that’s unfortunate. Code needs specialized knowledge, it’s next to impossible to represent graphically (which would be great, since our visual cortex is amazing), and it can quickly become too complex for a single person to understand at once. It may look like devs write code all day because that’s a hard and singular thing they do, but that’s not the most important part of their job. Code has no value if it does not solve a real problem.

It’s usually preferable not to write code at all when there are viable alternatives. For example, when off-the-shelf software is already available, and it solves the problem well enough. Or when we can find higher-level frameworks, like no-code tools. But, mind you, they have to actually solve the problem. These tools may lack the flexibility to tackle complex requirements.

The key value* of devs is that they produce software, not as in “writing” software, but as in “producing music”. That is, that they make decisions that help guide the system to reach the right goals.

A music producer, or record producer, assists an artist with their recording project, bringing their vision to fruition and guiding their sound along the way. Being a music producer is in many ways a strange job. What a producer creates can’t be seen. What a producer creates is not even an object. If you zoom all the way out, what a music producer does for a living is this: Vibrate air molecules in such a way that when the air molecules bump up against a human life form, that life form feels something.

Berklee Website

Similarities with software development are plenty. Both music producers and devs create something that can’t be seen and generates something of value. If you think music is art and software is business, think again. Music is often times just business, and software can be hugely artistic, such as in video games. Mirroring Berklee, we could say that devs command the computer using logical rules so that when a human life form interacts with the interface they can solve a particular problem. Coding is just means to an end.

Other terms, like “developer”, “engineer” or “programmer”, put the focus on the technical side (writing code). But a producer focuses on the outcome, the product or system being built, and the value it generates. Making specific decisions about how a digital system should work (requirements, behaviors, constraints, specification) is the hardest part of the dev’s job, not writing code, and it has a huge human component.

By embracing the mindset of the software producer, a system designer tasked with solving problems through software, a few things come to light. For example, that devs are responsible for the quality of the final product. Quality being not only what the user sees but the overall system behavior because software, unlike music, has a lot of invisible functionality.

Interviewer: Do you play instruments?

Rick Rubin: Barely.

I: Do you know how to work a soundboard?

RR: No. I have no technical ability. And I know nothing about music. [smiles]

I: You must know something.

RR: Well, I know what I like and what I don't like. And I am decisive about what I like and what I don't like.

I: So what are you being paid for?

RR: The confidence that I have in my taste and my ability to express what I feel has proven helpful for artists.

Rick Rubin on the Creative Act — 60 Minutes

I don’t see the mindset shift from “coders” to “software producers” happening anytime soon. Going from “I write code to implement functionality requested by product” to “I am in charge of managing a digital system to increase business value” means stepping out of your comfort zone (AKA “the IDE”) to the messy real world of people, but this is the only way to make sure that your work matters.

Consequences of the producer mindset

Concrete examples

1. You work on a web application that integrates an external API. They ask you to update the API to the newest version, but you realize that some features will stop working if you do. Coder: you update the API version, tell someone in product that some features will stop working, and ask her if she needs anything else. Producer: you take ownership and device a replacement plan to keep the features working. If a feature will be too time-consuming to implement, you explain this to product and propose alternatives. You also research alternative APIs.

2. They ask you to build a feature because one of the company’s big clients requested it. Coder: you go ahead and do it. Producer: you dig deeper. What problem is the client trying to solve? Do other users have the same problem? Should we make something specifically for them and use feature flags? How will the complexity of this new feature impact the overall system?

3. They ask you to move a system to a particular technology because the old one is slow. Coder: sure. “This will look nice on my resume.” Producer: you ask clarifying questions. Why do we think this technology is slow? How are we measuring speed? If this technology is indeed slower, are there any trade-offs that still make it worth it? Have we had any actual complaints about the product’s speed? Have there been other consequences, like a large server bill? What are the performance bottlenecks in our system?

More general

1. “Working software is the primary measure of progress.” Not amount of features, not beautiful code or elegant abstractions, but working software solving real problems. A feature not coded means progress if users didn’t need it in the first place. Number of lines of code means nothing as a progress metric.
2. The focus shifts from algorithms and programming language trivia to architecture (high-level system design) and business logic, because that’s more important to understand if we want to increase value.
3. Recruiting and career development turns from focusing on the technical experience tuples to identifying and training great system designers.
4. Devs increase the codebase-to-value alignment, meaning that the software becomes more in line with the goal. This should always be the case, but it often isn’t. Just look at how many tech companies build apps and features that users hate, or how many times a manager makes decisions based on what technology stack is fashionable at the time.
5. Code is seen as a liability, not an asset, and that’s a good thing. The goal is to solve a real problem, with or without code, and every line of code written is a line of code to be maintained, so you try to write as little code as possible. Also, you know that is hard to reason about code, so you write simpler code and check it extensively for bugs. By trying to avoid code as much as possible, you end up with a better codebase.
6. Devs talk to users and see the impact of their work. They get more motivated and, thanks to the first-hand information they get, they can make better decisions on how to increase business value through software. By removing middle layers, devs can think of solutions hard to see for non-technical people. Getting a good sense of the user problems also informs the system evolution and helps devs prepare for upcoming features with a more flexible system design. A better picture of the system leads to a better model (software).
7. Devs start sitting at the big-boys table. They become more in tune with the company and the users, and have something meaningful to say when asked for input. Tech stops being a silo or a “support function” and starts helping the company move forward.

A producer’s job

Software is too important to leave it in the hands of people who don’t understand how computers work. Devs cannot just take requirements and code them, they must think at the system, company, and society level. It’s sad when a song has bad production quality and does not sound right, but bad software can cause catastrophic (no hyperbole) consequences.

The agile manifesto states “Customer collaboration over contract negotiation”. The key to making valuable software is to get deep understanding of the user needs and focus on solving their problems. To do that, we need to stop thinking in terms of code and start thinking in terms of the products we build, that is, becoming software producers.

---

Notes and Links

* Pun intended.

• Don’t call yourself a programmer is more about personal marketing and market politics, while Software Producers is about mindset. I think that “software engineer” is a pretty good name and “software developer” is OK.
• Agile Manifesto
• No Silver Bullet