Skip to content
Artwork for Software Madhouse
Software Madhouse · Tuesday · 34 min

Darren vs Programmers vs Developers vs Software Engineers

Robert’s line from last time did not land: developers use code to solve business problems, and software engineers use code to create them. So Matt and Robert brought Darren Shepherd in to argue it. Darren created Rancher and k3s, and he is now chief architect at Obot. Matt restates the roles from episode 3 and drops computer scientist. A programmer writes the code someone else specified. A developer owns the lifecycle. A software engineer is supposed to own requirements, design, and reliability. The Bureau of Labor Statistics has programmer employment on a long decline, with hiring mostly replacements. It groups developers and engineers together and calls that work growing. Darren does not fit the list. He calls himself a bad programmer and an agent of chaos. He cares about the system, how the pieces fit, and the compromise in an architecture. He does not care about the process, and he does not want a perfect design. Robert treats architect as a level inside any of those jobs. Darren pushes back: some engineers optimize a widget and ignore the business problem, which is how engineers end up creating business problems. Matt splits the work another way: people who go deep on one component, people who go wide on the user problem, and people who see a problem and run off to invent something. WordPress and Longhorn come up as cases where the useful question is what you are optimizing for, not whether the code is pretty. Then AI. Darren does not accept the claim that training on open source destroys it. Rancher sold support and never licensed the software, and he still treats the value as the relationship, not the repo. He wants open source projects to hand the toil to AI, and he thinks code quality goes up once the process is less immature than the last year. Remix 3, which just shipped a stable release and left React, is his example of work a model will not originate: a new idea about simpler JavaScript, not another React app. Robert hates drive-by pull requests and still uses AI for syntax he does not want to keep in his head. Matt compares the model to the crew that lays pipe and cable after the house is designed, and notes that some contributors liked that work. Senior engineers can guide a model because they already know how the system is put together. People in their twenties are being told to start with the model. Darren’s advice is to copy the seniors who are actually doing the work, and to ignore the posts that claim one prompt built the app. A Rust-to-Bun port, he says, was hours of skilled guidance, not a sentence. Links Episode 3: https://softwaremadhouse.com/episodes/episode-3/ Obot: https://obot.ai Remix: https://remix.run k3s: https://k3s.io Longhorn: https://longhorn.io Watch this episode on YouTube: https://www.youtube.com/watch?v=U6xkSQUhQds

0:00-34:53

transcript

No transcript — this publisher did not publish one.

show notes

Robert’s line from last time did not land: developers use code to solve business problems, and software engineers use code to create them. So Matt and Robert brought Darren Shepherd in to argue it.

Darren created Rancher and k3s, and he is now chief architect at Obot. Matt restates the roles from episode 3 and drops computer scientist. A programmer writes the code someone else specified. A developer owns the lifecycle. A software engineer is supposed to own requirements, design, and reliability. The Bureau of Labor Statistics has programmer employment on a long decline, with hiring mostly replacements. It groups developers and engineers together and calls that work growing.

Darren does not fit the list. He calls himself a bad programmer and an agent of chaos. He cares about the system, how the pieces fit, and the compromise in an architecture. He does not care about the process, and he does not want a perfect design. Robert treats architect as a level inside any of those jobs. Darren pushes back: some engineers optimize a widget and ignore the business problem, which is how engineers end up creating business problems. Matt splits the work another way: people who go deep on one component, people who go wide on the user problem, and people who see a problem and run off to invent something. WordPress and Longhorn come up as cases where the useful question is what you are optimizing for, not whether the code is pretty.

Then AI. Darren does not accept the claim that training on open source destroys it. Rancher sold support and never licensed the software, and he still treats the value as the relationship, not the repo. He wants open source projects to hand the toil to AI, and he thinks code quality goes up once the process is less immature than the last year. Remix 3, which just shipped a stable release and left React, is his example of work a model will not originate: a new idea about simpler JavaScript, not another React app. Robert hates drive-by pull requests and still uses AI for syntax he does not want to keep in his head. Matt compares the model to the crew that lays pipe and cable after the house is designed, and notes that some contributors liked that work.

Senior engineers can guide a model because they already know how the system is put together. People in their twenties are being told to start with the model. Darren’s advice is to copy the seniors who are actually doing the work, and to ignore the posts that claim one prompt built the app. A Rust-to-Bun port, he says, was hours of skilled guidance, not a sentence.

Links

Watch this episode on YouTube: https://www.youtube.com/watch?v=U6xkSQUhQds

links6