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! | |
