If you only read two thingsConverting Capital Into Software That Works (6 minute read) This article is 25 years old. Two things: First, I find it astonishing how fast we forget. Joel was once a thought leader on software development. Today he is forgotten. Fowler comes also to mind. Do other industries forget as fast? Second, and way more important, from the article: “But the real goal for software companies should be converting capital into software that works. If you understand this, it’s easier to make the right strategic decisions.” This becomes paramount with the rise of LLMs. “Imagine that the goal of your software company is not to solve some specific problem, but to be able to convert money to code through programmers.” Replace “programmers” with “LLMs” and you understand LLMs. https://www.joelonsoftware.com/2000/03/21/converting-capital-into-software-that-works/ My AI Skeptic Friends Are All Nuts (15 minute read) “LLMs only produce shitty code if you let them.” which brings me to my Theory of Control. Software development is and always was about control flow, not work flow. How do we need to control LLMs so we get what we want? Another unforeseen nugget in the article: “I work mostly in Go. I’m confident the designers of the Go programming language didn’t set out to produce the most LLM-legible language in the industry. They succeeded nonetheless. Go has just enough type safety, an extensive standard library, and a culture that prizes (often repetitive) idiom. LLMs kick ass generating it.” Something I wondered about too, are there languages better suited for LLMs? Do we need more static typing in a language? Less? Will people favor JavaScript because after generating code with an LLM, no need to wait for compilation? Or does compilation give more confidence in the code? What people are not talking about, is how LLMs will influence the choice of programming languages. Will we get a LLM-friendly language soon? What will it look like? Third nugget: “Developers all love to preen about code. They worry LLMs lower the “ceiling” for quality. Maybe. But they [LLMs] also raise the ‘floor’.” https://fly.io/blog/youre-all-nuts/
Stories I’ve enjoyed this weekFactors in Structuring a Product Organization (6 minute read) From the godfather of product management, Marty Cagan. How to set up a product organization.
All good and nice tips I think. But the two world hypothesis of product and engineering is wrong. https://www.svpg.com/factors-in-structuring-a-product-organization/ The last six months in LLMs, illustrated by pelicans on bicycles (10 minute read) Simon made LLMs draw a pelican on a bicycle for the last six months to see how LLMs progress. Some see the pelican in the end and say, “not a pelican at all!”. Some see the progress of the last six months and say “Amazing”. Which one are you? You know on what side of the fence I am. https://simonwillison.net/2025/Jun/6/six-months-in-llms/ It’s The End Of Observability As We Know It (And I Feel Fine) (10 minute read) Let the LLM find out why you have those spikes in latency. When talking about LLMs, I often hear “but security”, “but bugs”. From my experience, LLMs are great at finding and preventing bugs and their ability of preventing and fixing security issues is way above most developers. And it seems this goes for DevOps too. Auto-repairing is near. Do you need your DevOps team? https://www.honeycomb.io/blog/its-the-end-of-observability-as-we-know-it-and-i-feel-fine Get Stack - Technology Landscape Overview (5 minute read) Operations, problems popping up right and left. Here get the big picture of technology - detached from that one developer who tried to sell you on Elixir for the last months. JavaScript on top, as is Postgres, OpenAI, React, Tailwind, AWS, OpenTelemetry. No big surprises. Point that Elixir developer here the next time they start a discussion on when to use Elixir. (And don’t!) Software is About Promises (6 minute read) I found this article an interesting view on software development, a perspective I have not seen before. Software is about promises. “What are you promising your users? And how is this promise testable?” It seems close to the methodology of “Jobs to be done”. Then there is sadly a flood of product marketing disguised as information. Do people think this works? But the idea of Software is About Promises is still good. https://www.bramadams.dev/software-is-about-promises/ Website designs are getting too complicated (3 minute read) “The web exists to connect people and share information. Let’s not confuse it with an art gallery.” Exactly. Great I found this article with my reestablished interest in UIs - currently working on a tech independent description language for app UI called PromptUI. What do we need as a UI description to make an LLM generate the UI we want? Confusingly there are no great examples of UI description frameworks, huh! SwiftUI is nice, but too developer centric. So, PromptUI it is. https://www.tabulamag.com/ article upcoming. And “let’s not confuse it with an art gallery”. https://websmith.studio/blog/website-designs-are-getting-too-complicated/ Stuff I learned at Delivery Hero (6 minute read) From the experience of a product manager in a post-IPO company. “They need to specify detailed requirements for engineers while delivering a business impact pitch to the wide organization and C-levels.” The biggest mistake of product management and engineering since Scrum was invented: We don’t talk to each other and don’t have a common process, but product managers have their world, and engineering has a different world. Both invent their own practices and processes. It’s a wonder it even works. You need to talk to engineers about business impact. Or better, with developers about business impact. And engineers need to query about business impact themselves. The view that there are two worlds is profoundly wrong. Wrong! I know you can’t change this in your engineering silo, and the company doesn’t want to talk to you about the really important things, like business impact, they only want to talk to the VP of Product - don’t let that put you down, go out, talk about business impact. Tech is the business enabler. https://www.kirillso.com/posts/stuff-iearned-at-delivery-hero/ There should be no Computer Art (8 minute read) Astonishing article from 1971. “Questions like “is a computer creative” or “is a computer an artist” or the like should not be considered serious questions, period. [..] We should not be interested in producing some more nice and beautiful objects by computers.” and “As concrete projects to be investigated I propose: 1. The study of the alienation of the artist from his product which is caused by technology in general and by computers in particular” 1971. One year older than me. https://dam.org/museum/essays_ui/essays/there-should-be-no-computer-art/ Join the CTO newsletter! | |
