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