a developer's job isn't to write code

Okay, yes it is, but not directly.

If there's one thing I've learned from my time as the lead developer of a new software product, it's that companies are there to do one thing: make money. They get this money from other people giving it to them, because what the company provides is valuable to them. If the company cannot provide something valuable to someone, they will not get more money.

A developer's job is help deliver this value, and to deliver it fast enough that the company will still be solvent by the time people start handing over money.

At an early-stage company, there's so much empty canvas to fill with code. This part of the canvas could use this cool mapping library that uses WebGL to render, instead of the one we use now which slows down with each new DOM element! Here is a tool we can use to design components in isolation, allowing us to have our own design language and establish the Company Name brand! And over here, we can begin implementing this high-performance tool in Rust instead of C++!

The first question any developer should ask themselves before proposing a change is: does this bring measurable value to the company?

The value can be short-term: product features can capture an untapped segment of the market, leading to more money coming in. The value can be an investment: devops features can make it so that the next feature can be delivered sooner. Much of the time, developers want to focus on the second: tackling tech debt, refactoring some component, reducing incident reports. But none of those matter if there aren't features that are going to customers, who give the company money.

If the feature doesn't provide outsized value, it is not worth it. It is a vanity project.

With that said, engineers should not bend to every whim of the sales and product teams. But engineers are beholden to them, and they are beholden to engineers. With few exceptions, they are locked in a battle between "value now" and "value later". And yet, one cannot exist without the other. Without a product and features, the infrastructure of a program will not sell. And without developers to build the product, there is nothing to sell.

If you are an engineer, communicate how and why your interesting software proposal is valuable. If you can't convince management that it is valuable, one of the two things is true:

1. Your proposal is not as valuable as other things that could be worked on now.
2. Your product and/or company will fail. If your proposal is truly valuable, and is being ignored by management, the product will collapse because of devops rot (feature regression, bugs) or another company will find that valuable niche, and eat your lunch.

Try to understand 1 as deeply as you can. Get into the shoes of stakeholders and think of the product from their perspective. Ask for their perspective. If you don't can't get a valuable conclusion, then you are in position 2. Start looking for a new job, or keep your head down and collect a paycheck while you can. I can't blame anyone who is just there for the paycheck. We shouldn't live to work, after all.

Developers have a set of skills that make them most effective writing code. But writing code is a means to an end, and that end is delivering value.