If you only read one thingWhy I stopped using AI code editors (14 minute read) Interesting but irrelevant. Relevant to you as an engineering manager to understand the mindset of senior developers and their resistance to AI. In the end, another senior developer who will be overtaken by juniors using AI. A physics professor once told me, new ideas do not get accepted because professors change their minds, but because they die of old age (Also read Kuhns “The Structure of Scientific Revolutions” - we’re in a revolution). One interesting insight: “Not only did it take out the fun for me” separates the creators from the coders, those that love to create and code is a tool, and those that love to code and do not care about what they create. “I keep AI fully separate from my code editor” famous last words. https://lucianonooijen.com/blog/why-i-stopped-using-ai-code-editors
Stories I’ve enjoyed this weekSenior Developer Skills in the AI Age: Leveraging Experience for Better Results (19 minute read) Key to using a tool: 1. Determine if the tool works 2. Know if you use the tool the right way. If you can’t do 1 and 2, your tool selection and usage is random. Especially 1 is something not a lot of engineers can do for their tools. AI is a little bit different, because we can see the generated code. Here seniors benefit from their experience. That said, stubborn senior developers will be overtaken by eager juniors - who will never become senior coders, but senior AI-users. Article goes beyond that and explains things I have been thinking about for a while too, like “Well-structured Requirements” help with AI, indeed this might be the time after four decades we think about proper requirements. But go read the article. In defense of ruthless managers (4 minute read) The article has some flaws in its logic, for starters it attributes the good things of empathic managers to ruthless managers, but not the other way around. But there are also some good points in it, like “Second, empathetic managers are often in conflict with their own bosses, leaving them with little political capital.” Best career advice: Solve the problems of your boss, not your problems. Gain political capital then use it. But not by being ruthless, but by delivering. More interesting musings in the article, although most of them are wrong, as the article attributes positive things to the “ruthless” manager when it’s not clear why. An empathetic manager can’t break bad news to their team. But is that empathetic? Or are they just shying away from confrontation? Are they empathetic or do they just want to be liked? https://www.seangoedecke.com/ruthless-managers/ Elevate Your Engineering Culture: The Power of Documenting Architecture Decisions (8 minute read) ADRs are the most underrated. To me the core benefit: They explain and document the why of architecture decisions. And what alternatives have been discarded and do not need to be discussed over and over again. Also “A Single Source of Truth” and “Better Onboarding and Cross-Team Collaboration”. Article gets you started, if you haven’t done so yet, start on Monday. https://newsletter.modern-engineering-leader.com/p/elevate-your-engineering-culture “Echo Mapping is a reflective exercise that helps uncover the motivations and experiences that shape your career decisions.” Too many managers don’t know where they want to go. Also: One of the most difficult discussions with direct reports in 1:1s was where they want to go and why. It’s often hard to find out what you really want. https://medium.com/@MarlonSchultz/echo-mapping-fcd13d658d46 I’m not bored of it, it is the most exciting time since 1991 when I discovered the internet. I was bored for twenty years. https://paulrobertlloyd.com/2025/087/a1/bored/ Gates first code (9 minute read) What the world does not understand: Gates -> Engineer, Bezos -> Engineer, Jobs -> Engineer, Zuckerberg -> Engineer, Musk -> Engineer, Brin -> Engineer, Page -> Engineer, Packard -> Engineer, Hewlett -> Engineer. So they can’t replicate. https://www.gatesnotes.com/meet-bill/source-code/reader/microsoft-original-source-code The Reality of Working in Tech: We’re Not Hired to Write Code (7 minute read) Well, first developers are hired to write code. Second, if the only .NET developer leaves, and websites are going down, fire the responsible manager. Which reminds me, a company I worked for fired the only Ruby developer. Ruby was running essential image optimize scripts. They broke, and we (two engineering managers) sat there and wondered about the code and fixed the scripts. Wasn’t my team or the other manager’s team. Of course the responsible manager was not fired. Key point in the article: “My work was tossed away without a second thought. If they had hired me to write code, or if my old friend was hired to maintain what was exotic code, then why was it so easy to discard it?” They pay you to write code, but they don’t value the code. https://idiallo.com/blog/code-for-hire NVIDIA GeForce RTX 5090 & 5080 AI Review (18 minute read) Sadly there is not enough discussion on local-AI hardware. And very few reviews. I wonder, AMD 395+ Max/128gh, RTX5090, NVIDIA DGX Station, Apple Mac Mini - or with enough money a Mac Studio. Or an older EPYC? No help in sight. But local-AI will be a thing - for $$$ (Claude Code is embarrassingly expensive) and better results. https://www.pugetsystems.com/labs/articles/nvidia-geforce-rtx-5090-amp-5080-ai-review/ All Estimations Are Wrong, But None Are Useful (6 minute read) What a lovely title, “All Estimations Are Wrong, But None Are Useful”. I never liked estimations, beyond Small/Ok/(Too)Large to decide IF something is worth doing, they are not helpful and waste a lot of time, energy and good will. Oh and I was very good at estimating. The biggest problem: People confuse estimating with measuring. Go to your boss and say: “Estimate the length of this table” - then measure it. See? Estimates are not measurements. And one can become better and better (when estimating the same thing over and over, but we rarely build the same thing over and over again) at estimating, but you will always be wrong estimating the length of a table. The biggest business reason not to use estimations: You can’t change your mind after an estimation has been done, even if you have great new ideas and insights. Article has many more reasons. That said, if you are forced to do estimations and don’t want to leave: 1. Spend several hours on understanding what needs to be changed in the code = effort 2. Multiply effort with a load factor, depending on your company and culture (meetings, holidays etc.) e.g. 1.2 = duration 3. Multiply duration with a risk factor, e.g. 1.5 (illness, incidents) and that’s your estimation. (Everyone confuses duration and effort!) - WHATEVER YOU DO DO NOT USE SCRUM ESTIMATIONS (it’s better to resign though). https://newsletter.techworld-with-milan.com/p/all-estimations-are-wrong-but-none The Outlook for Programmers (10 minute read) Bad. Nothing new. Funny quote though, "[..] some hiring professionals see it as killing jobs, others say it is creating new roles [..]". So, hiring professionals say there will always be people to hire and don’t think jobs will go down and be replaced by AI, that doesn’t need to be hired. What everyone thought over the last 5000 years about their disappearing jobs, and was wrong of course. https://cacm.acm.org/news/the-outlook-for-programmers/ Join the CTO newsletter! | |
