If you only read one thingOur efforts, in part, define us (6 minute read) āItās not my wish that people canāt have access to a more effortless way to write code, but I feel a strange sadness that there is less left to the act of the craft.ā - a must-read reflective developerās viewpoint. AI is about identity and loss. https://weakty.com/posts/efforts/
Stories Iāve enjoyed this week10 essential books for modern technology leaders (6 minute read) Canāt go wrong with these books, though my list is different. Reply to know what I think which books are essential. I love that āRefactoringā is included, every developer does it, no developer knows what it is. I feel sorry for that book. https://www.hyperact.co.uk/blog/10-essential-books-for-modern-tech-leaders The Software Essays that Shaped Me (18 minute read) Very good read, not much to say, except, Joel Spolsky is listed twice, such a development hero, forgotten today. https://refactoringenglish.com/blog/software-essays-that-shaped-me/ Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code (2 minute read) āTeams that care about quality will take the time to review and understand (and more often than not, rework) LLM-generated code before it makes it into the repoā Teams that care about quality will find ways to define quality and care about it, without looking at the code. None of those teams looked at the binary code generated by compilers or JITs. This is a wrong understanding of quality. Good teams who do not follow cargo cults will find out what quality means in the age of AI and make sure it is there. "āDoom loopsā, when we go round and round in circles trying to get an LLM, or a bunch of different LLMs, to fix a problem that it just doesnāt seem to be able to, are an everyday experience using this technology." This happens to me and I tell the AI to stop, e.g. it might create a Python script to do something, on a Golang app, and it tries to fix the Python code without success. I tell it that the Python script is not the goal, making the Golang code work is. More often though, I see people go into doom loops because they iterate on the prompt. Donāt iterate on the prompt, iterate on the plan (Claude Code) or the spec. Then again, the blog is called āCodemanshipās Blogā. In this new age, what it makes clear, what it divides developers openly, into creators and coders. Both have been there for the last decades, but you couldnāt distinguish between them - they looked the same. Creators want to create, coders want to code. To AI or not to AI (7 minute read) a.) Great that people experiment instead of hype b.) Great that they are sharing results c.) They seem to have made every mistake you can make. Read the article and figure out which ones (some answers in this newsletter, some more in āI no longer look at source codeā) https://antropia.studio/blog/to-ai-or-not-to-ai/ cleaning house in nx monorepo, how i removed 120 unused deps safely (3 minute read) This uses a tool called knip to remove deps from a project. Though I today use AI for this, I think removing and checking dependencies is a necessary housekeeping task not enough teams implement. Start! https://johnjames.blog/posts/cleaning-house-in-nx-monorepo-how-i-removed-120-unused-deps-safely What is āgood tasteā in software engineering? (10 minute read) āTechnical taste is different from technical skill.ā and āYou can be technically strong but have bad taste, or technically weak with good taste.ā What a beginning to an article. Donāt care if I agree or not, this beginning makes me read it. I mostly disagree with the rest of the article, of course - the filter and map stuff - but I do think there is such a thing as technical taste. To me code looks good if it is in itself consistent. But I like Riesling SpƤtlese, and you donāt, so I think you have a different taste. Itās not important that tastes are different, but that we acknowledge the existence of it. And I might not have any taste at all. https://www.seangoedecke.com/taste/ Distracting software engineers is more harmful than managers think (9 minute read) Havenāt read this through before, āmanagers assume engineers can now be productive in smaller time chunksā in the age of AI. I feel like managing Claude Code in two terminals is more deep work for me, I need to be even more concentrated and in the flow than before. Itās difficult at that breakneck speed to stay in control. A manager might think it is ok to disturb me now, the opposite is true. As others wrote, they need to concentrate so much, they no longer can listen to music when ācodingā. Perhaps this is the nature of the beast, or we have not yet adapted. But it does take much more willpower to stay in the flow, because compiling. The AI coding trap (9 minute read) āsince LLMs canāt yet hold the full context of an application in memory at once, human review, testing, and integration needs will remain.ā As I recently wrote in a piece, why I no longer look at source code, this says more about your code than about AI. Layers in particular are difficult for AIs to manage. Tightly integrated microservices are difficult for AIs to manage for the same reasons. Vertically distinct modules, loosely coupled, make it easier for AIs to understand their application at hand inside a context window. We see another problem in the article, "[..] agents can be incredibly fast at producing working code for problems that would challenge some mid-level engineers, though they cannot yet match the expertise of senior engineers" - the definition of the senior by coding experience. If, as CTO, you follow this - developer perspective - model of seniority, you will fail. Seniority for the majority of engineers is about understanding business, taking ownership, feeling responsible and guiding others, not about coding expertise. https://chrisloy.dev/post/2025/09/28/the-ai-coding-trap āWith WFH we canāt innovateā is what they say. Iād say, if you canāt innovate with WFH, you canāt innovate at all. Reminds me of Steve Jobs working in his garage. More on what I agree with in the article, Iām totally an office guy, but this is just me. I would not want to force my working style on everyone else. And if I canāt get WFH work, I would consider myself a bad manager. The article contains this nugget, I havenāt thought about before āThe fact is, if your company has a mental health or environmental policy and you mandate RTO, you are simply liars.ā https://wordsrightman.beehiiv.com/p/rto-wtaf Friction is necessary for Growth (3 minute read) āThe title of this article says it all.ā https://jameelur.com/blog/overcoming-friction-leads-to-growth Companies are Lying About AI Layoffs (5 minute read) "āMy company replaced half my department with H1Bs or simply moved it to an offshore center in India, and then on the next earnings call announced that they had replaced all those jobs with AIā" Is this what is going on? Do managers do this because it shows they are moving to AI but canāt? Fake it until you make it? Or something they wanted to do and AI is the scapegoat? What is going on? https://huijzer.xyz/posts/111/companies-are-lying-about-ai-layoffs What is Stephan doing?Working on talks for code.talks in Hamburg, on my vision of AI on one hand and = perhaps - my theory of control. Also thinking about a podcast which might be called āWhy Iām differentā (working title) interviewing CTOs on how they are different, their role, their company, their team, their customers, their stack, they themselves. Events for Engineering ManagersJoin the CTO newsletter! | |
