My dearest gentlest reader,
I come bearing news of grandeur. I am officially the Vice President of DEFNA! I am grateful that I get to help shape some of the organisation's decisions alongside the board, and now I get to bear responsibility for them as well. I am excited and, at the same time, aware of the weight of responsibility, but I intend to make this one of my best rides ever. Pull up a chair and some popcorn, because it’s going to be one beautiful ride.
In other news, Symptoms of Bad Software Design argues that poorly designed software often manifests in four key warning signs:
Rigidity: Small changes trigger wide modifications,
Fragility: Fixing one part of the system breaks another,
Immobility: Useful code cannot be reused,
Viscosity: Taking shortcuts since the right solution takes too much time.
To address the aforementioned issues, design principles such as loose coupling, encapsulation, interface segregation, and clean architecture are recommended to make the software easier to change and safer to maintain.
Cognitive Surrender: This article explores the risk that engineers using AI accept the generated answers without forming an independent understanding. The author argues that this causes a comprehension debt, in which the amount of code in a system and the extent to which engineers actually understand it diverge. He advocates for actively questioning AI outputs. His central message is that AI should enable mutual amplification, in which AI helps engineers think better and learn faster, rather than serving as a substitute for critical thinking and expertise.
Why I don’t like the “staff engineer archetypes”: The staff engineer archetypes are Tech Lead, Architect, Solver and Right Hand. While they describe the common ways senior engineers create value, they emerge naturally from trust, experience and organisational needs rather than from deliberate pursuit. Aspiring staff engineers should focus on consistently delivering value, understanding business priorities, building trust, and taking responsibility for outcomes even when they don’t fully control them. A staff engineer does not fit a particular archetype but is adaptable and capable of filling whatever role the organisation needs most.
Trust Is The Bottleneck: AI is not limited by its ability to generate code but by the difficulty of trusting and safely absorbing the changes it produces. The main idea is that the future challenge for AI-assisted engineering is not scaling code production but scaling the ability to review, understand, and safely trust changes.
Be the Idiot: The best trait an engineer should develop is to ask questions without worrying about appearing uninformed. Many software failures result from misunderstandings and assumptions. Looking temporarily uninformed is far less expensive than building the wrong thing because nobody was willing to seek clarity.
They Requested It. I Built It. Nobody Ever Used It: A common failure in data science and machine learning projects is when teams build impressive models that the shareholders ignore. Adoption fails for one of the following reasons: the team focused on delivering perfection rather than delivering value quickly, or the model is not in the workflows that shareholders actively use. The article recommends focusing on shipping simple versions early that align with the problem at hand and integrating them directly into existing tools. You Taught the Company to Overload You:
The Lies Engineers Tell PMs: Engineers often condense answers about work estimates or implementation efforts into short responses to avoid derailing meetings with technical detail. Experienced engineers learn to resist giving instant answers and instead say, “Let me investigate,” because they understand how much unseen complexity can exist beneath seemingly straightforward requests. For PMs, the lesson is to recognise where hidden complexity tends to live and build trust through curiosity and collaboration rather than assuming estimates are inflated or evasive.
How to Finish Engineering Projects Early Without Added Stress: The article adapts the Critical Chain Project Management (CCPM) by Eliyahu Goldratt, which, instead of padding every task estimate with safety margins, the method cuts estimates by 50% and moves the removed time into a shared project buffer that protects the overall delivery date. The focus shifts away from whether individual tasks finish “on time” and toward monitoring how much of the buffer the team is consuming relative to overall project progress. Teams should manage constraints and shared risk at the project level rather than optimising individual task estimates, while ensuring engineers are never punished for exceeding aggressive estimates, since occasional overruns are an expected part of the system.
Technical Writing In The Age of AI: Human-written technical writing remains important because AI does not create new understanding on its own. It relies on knowledge produced by people. The value of technical writing is also shifting away from simply documenting APIs or explaining syntax and toward making complex ideas approachable, sharing lived experience, providing context, telling the story behind discoveries, and helping humans learn in ways that dense specifications cannot. Writers should focus less on sharing genuine insights, experiments, and perspectives that only humans can provide. Authenticity and experience have now become even more valuable as AI-generated content becomes ubiquitous.
The word of the day is hopscotch. To hopscotch means to jump or leap from one place to another.
Example in a sentence:
The child hopscotched over puddles after the rain.
I am making my grand departure into the unknown.
Take care of yourself!
Until the next fortnight, my treasured reader, go forth, and may the odds be ever in your favour! 👏 🤖 ✊ ☠️ 🏹 🪖
Do you enjoy the latest issues of my newsletter? Buy me a piping cup of hot chocolate today!
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.