Week 42-43, 2025 - Thousand Words
We're working hard behind the scenes with Jeremy to prepare for the third season of our engineering leadership podcast, The Retrospective. I don't want to jinx it, but at this point, it seems safe to say we'll start releasing episodes soon, so I want to put the spotlight on our little show for those of you who joined later.
We started rough and unedited, but after a few episodes of finding our voice, we switched to a new format and started focusing on one single leadership challenge for every episode. We discussed quiet quitting, seniority, technical debt, and taking breaks, amongst other things. Catch up on us if you missed a few episodes, and subscribe to The Retrospective wherever you get your podcasts, so you'll receive Season 3 automatically on launch day!
📋 What I learned recently
There's an important, but often-forgotten clarification that helps in discussions: to understand what the other person is expecting from you exactly. Both in friendly talks and mentorship sessions, I've had to remind myself of this more than once recently, so here it is: sometimes the other person wants advice, help with their problems, but in many cases, they just need someone to vent to. If you don't recognize (or explicitly confirm) which one of these discussions you're having, your reaction can be really off-putting.
I recently learned that I'm uncomfortable with problems lingering too long without being addressed. I either want to attack it or dismiss it as something I don't have an impact on. It seems like something inside me freaks out when I just hear complaints. So I tend to jump into the solution phase too quickly, even when the person would find the solution themselves; or I point out that it's like the weather – they can't do anything about it, so why care. Depending on the relationship, this can be perceived as ignorant, hurtful or dismissive – all very ineffective.
So, nowadays I'm practicing getting comfortable with having the problem up in the air, just talking about it, examining it from different points of view. And only moving on to solutions when I feel the time is right – or maybe not at all.
🤔 Articles that made me think
Use Images instead of Text when working with AI
This goes against all my engineering insights: a large language model’s internal representation of an image is ten times as efficient as its internal representation of text! Yes: taking a screenshot of a big chunk of text means fewer tokens used than the plaintext version! 🤯
There's even a startup selling this as a service, providing a Gordian solution to the problem of parsing complex multi-element documents. Amazing!
What if Specifications were Executable?
We're not there yet, but pretty close. Spec Kit implements what they call "Spec-Driven Development", where LLM is used to work on all the specification aspects of a software development project, then AI coding agents implement these based on these specification files. And then of course, since you have all these specifications available, versioned in git, you can simply modify and re-implement if something changes.
I used this method manually a year or so ago when I worked on a small hobby project, so I'm excited to try out an automated, streamlined version of the same approach.
Less is Safer
Obsidian explains their approach to third-party libraries. Based on the complexity of the functionality, they reimplement, fork, or include carefully. This "carefully" means preferring version-locking, slow and deliberate updates, and minimizing what ships to users. I'm not sure this is applicable for every organization, but even acknowledging and approaching the supply chain attack risks consciously in a similar engineering strategy document is a great way to surface and argue about tradeoffs.
That’s it for today, sit back and listen this weekend,
Péter