The Orchestrator

Programmers have spent decades as intermediaries between an expert and an outcome, and at a financial news organization, a retail company, and a large educational institution I spent years in exactly that position. Someone understood the business, someone understood the customer, someone understood the operation, and I understood enough of the technology to turn a need into software and enough of the organization to keep that software working.

It was a valuable role and it still is, and it also created distance. The person who knew what the business needed could not always change the system, the person who could change the system did not always know what the business needed, and the programmer became the bridge — which sometimes became a tollbooth.

People talk about the death of the programmer as though it has already happened, or as though it would be automatically tragic if it did, and both versions are too simple. The death of the programmer is largely overstated, and there will be plenty of people writing code for a long time. What will change is that some programming work becomes easier to request directly, so a business owner can describe a change and have a system inspect the consequences, implement it, test it, and explain the result. That is not the end of technical work but an expansion of who gets to participate in it.

The risk is that we end up building systems that produce more software while fewer people understand how software is made or how to tell when it is wrong, which is why the earlier chapters insist so hard on training, review, failure modes, and technical judgment. Direct access to capability is only useful when people can see what the capability is doing. Loukides’ warning about generated code nobody can maintain is this risk at Pete’s scale.