Spec-Driven Development

I recently read Spec-Driven Development by Haim Michale, and it resonated with some day-to-day thoughts about SDD.

The problem SDD aims to solve isn’t new

Missing, incomplete, and ambiguous requirements that evolve over time have always plagued software delivery, but it is now amplified: the pace is faster, LLMs have a strong tendency to fill gaps by guessing, and they carry zero tribal knowledge – no kitchen-table conversations, no “oh, we tried that in 2022” instincts. EARS syntax (Easy Approach to Requirements Syntax) is an interesting framework for making requirements more machine-readable, but it still requires a human to steer it. The spec is only as good as the intent behind it.

Legacy code and brownfield projects are the elephant in the room

Most SDD content assumes you’re starting fresh. But the vast majority of engineering work happens in systems with years of accumulated decisions, undocumented assumptions, and implicit context baked into the codebase. Making that accessible to coding agents, let alone to SDD, is a real and largely unsolved problem. As far as I’m aware, there are no clear best practices or guidelines here yet. This is an area we need to tackle head-on.

SDD also accelerates a role blur we’re already talking about

If specs are first-class artifacts that live in the repo, who writes them? Do PMs start pushing requirements documents directly into codebases, expanding into territory traditionally owned by engineers? Do developers take on deeper responsibility for refining and maintaining specifications? Both are plausible. Neither is cost-free. The boundary is getting blurry fast.

And drift…

Drift is what happens when specs and code silently diverge: a requirement changes, but the spec file doesn’t, or a PR lands and the corresponding document isn’t updated. Over time, specs stop describing the system, and that’s arguably worse than having no specs at all, because they create false confidence. My suggestion: drift detection should be treated as a core part of repo gardening. Flag when code changes without a corresponding spec update, and vice versa. Make it visible, not something that accumulates quietly in the background. Expect spec debt terminology coming soon.

While different SDD methodologies vary in the exact documents they produce, I found the attached screenshot a useful cheat sheet for knowing when to update which document.

RAG Made Simple

📚 Just finished “RAG Made Simple: The Complete Visual Guide to Retrieval-Augmented Generation” by Nir Diamant, and it happened to be one of those rare cases where the book actually matches how I learn. What worked especially well for me are the summaries – when to use each technique, when it’s overkill, and what the trade-offs are. That comparative lens – grounding new methods against what came before is exactly what I need to internalize something. If you only have time for a sneak peek, read the appendix on debugging and choosing the right approach.

Theory vs. practice – in real production systems, no single RAG method is enough. Different techniques address different failure modes, and a stable, reliable system almost always requires combining several of them. 

Three techniques worth calling out:

🔮 HyDE (Hypothetical Document Embeddings) – my most surprising find. The idea is to generate a fake answer to the query, then use it to retrieve real documents. Elegant solution to the structural mismatch between how questions are phrased and how answers are written. “Fake it ’til you make it” as a retrieval strategy.

🎯 Dartboard Retrieval – most useful for me personally. A problem I’ve bumped into repeatedly – in RAG and in recommendation systems + where you need to balance precision with coverage across varying distance thresholds.

 🖼️ Multi-modal RAG – most overlooked, and massively underrated, usually skipped when building an MVP. Especially for internal knowledge bases: being able to retrieve diagrams, tables, screenshots, and slides alongside text is genuinely transformative. In my experience, much of an organization’s information is in decks, charts, images, etc.

Learn In Public – week 04

A sense of humor is one of the most underestimated leadership skills

Following the recommendation in “The Great CEO Within” I listened to “The One Minute Manager”. In one of the chapters, they mention the usage of Humor as a leadership tool. It is not about becoming a comedian but rather showing up as humans. Humor is a powerful and often overlooked tool.
Why it matters:

  • Humor helps build trust and rapport – people are more likely to engage and collaborate when they feel comfortable and connected.
  • It can reduce stress and tension, boosting well-being and performance.
  • Humor makes leaders more approachable and memorable, signaling confidence and emotional intelligence.
  • Shared laughter fosters psychological safety, helping teams voice ideas and take risks.

Of course, balance is key – humor should complement clarity and respect, not replace them. Too many jokes or poorly timed humor can actually backfire, so think of it as a strategic leadership tool, not a default setting. It’s about knowing when a light moment can lower defenses, reset the room, or simply remind everyone that work is done by humans, not robots.

Related resources –

Learn in Public – week 03

I finished listening to “The Great CEO Within” by Matt Mochary and Alex MacCaw. A few thoughts:

1️⃣ A tactical cheat sheet
I view the book as a tactical cheat sheet: short, practical chapters you can skim for ideas. It’s great for quick exposure, and most chapters include references for deeper dives. For me, this book has excellent value for time.

2️⃣ Revisit in the LLM era
Two well-known ideas in the book are Getting Things Done and Inbox Zero.
Inbox-zero and productivity advice hit differently today. With LLMs helping triage emails, summarize threads, and highlight what actually matters, the principles remain the same – but the execution is far more automated.

3️⃣ Optimizing meetings
TL;DR: come prepared, use written communication in advance, and don’t deviate from the planned agenda.
The authors suggest holding all meetings, including 1:1s, on the same day. From my experience, for 1:1s that go beyond status updates and require real attention (e.g., feedback), stacking too many of them on the same day can be overwhelming for most people.

4️⃣ “The first thing to optimize is yourself”
One of my favorite quotes from the book. It emphasizes founders’ and leaders’ health, mental and physical, something that has historically been overlooked. A good reminder that sustainable leadership starts with managing your own energy.

The book also mentions principles of conscious leadership: listening to feedback and acting on it, and not being afraid to make (and admit) mistakes.
This week, I also read a blog titled “Reflection is a Crucial Leadership Skill”, which made these ideas more actionable and down-to-earth.

What should I read next?

Better Plotly Bar Chart

I’m reading “storytelling with data” by Cole Nussbaumer Knaflic. I plan to write my thoughts and insights from the book once I finish it. For now, I wanted to play with it a bit and create a better bar chart visualization that –

  1. Highlight the category you find most important and assign a special color to it (i.e prominent_color in the code), while the remaining categories used the same color (i.e. latent_color)
  2. Remove grids and make the background and paper colors the same to remove cognitive load.

The implementation is flexible, so if you feel like changing one of the settings(i.e., show the grid lines or center the title) you can pass it via keyword arguments when calling the function.


from typing import Any
import pandas as pd
import plotly.graph_objects as go
import pandas as pd
def barchart(
df: pd.DataFrame, x_col: str, y_col: str,
title: str | None = None,
latent_color : str = 'gray',
prominent_color: str = 'orange',
prominent_value: Any | None = None,
**kwargs: dict,
) -> go.Figure:
"""_summary_
Args:
df (pd.DataFrame): Dataframe to plot
x_col (str): Name of x coloumn
y_col (str): Name of y coloumn
title (str | None, optional): Chart title. Defaults to None.
latent_color (str, optional): Color to use for the values we don't want to highlight. Defaults to 'gray'.
prominent_color (str, optional): Color to use for the value we want to highlight. Defaults to 'orange'.
prominent_value (Any | None, optional): Value of the category we want to highlight. Defaults to None.
Returns:
go.Figure: Plotly figure object
"""
colors = (df[x_col] == prominent_value).replace(False, latent_color).replace(True, prominent_color).to_list()
fig = go.Figure(data=[
go.Bar(
x=df[x_col],
y=df[y_col],
marker_color=colors
)],
layout=go.Layout(
title=title,
xaxis=dict(title=x_col, showgrid=False),
yaxis=dict(title=y_col, showgrid=False),
plot_bgcolor='white',
paper_bgcolor='white'
)
)
fig.update_layout(**kwargs)
return fig
if __name__ == "__main__":
data = {'categories': ['A', 'B', 'C', 'D', 'E'],
'values': [23, 45, 56, 78, 90]}
df = pd.DataFrame(data)
fig = barchart(df, 'categories', 'values', prominent_value='C', title='My Chart', yaxis_showgrid=True)
fig.show()

📚 Book club Q2 2024 – 3 Reading recommendations

This quarter, I read 3 books that relate to France and the resistance during the 2nd world War –

  • Code Name Hélène by Ariel Lawhon. This thriller is based on Nancy Wake’s story. It also reminded me of “Agent Sonya” by Ben Macintyre, which I read a while ago and enjoyed.
  • The Paris Architect by Charles Belfoure – is a touching story with lots of imagination but I was a bit disappointed it was not based on a real story.
  • The Dressmaker’s Secret by Rosalie Ham – this book tells the story of Coco Chanel during WWII from the prism of her personal assistant or more accurately from the granddaughter of her personal assistant who unpacks the story. I didn’t know about her relationships with the Nazis, and it was interesting to learn about them.

I also listened to “Setting the Table” by Danny Meyer, and it was very insightful, it even made me publish a LinkedIn post.

📚 Book club Q1 2024 – 3 Reading recommendations

This year, I track my book reading for the first time. I don’t know if I’ll keep doing it after this year or if I’ll last until the end of the year, but for now, I’m all in. This helps me reflect on my reading and remember the books I enjoyed.

Fundable: Why Some Entrepreneurs Get Funded, And Others Do Not! by Sephi Shapira

This is the best value for my time in a long time. The book is filled with concrete and practical advice, which I immediately found myself using.

Beartown by Fredrik Backman –

That’s the perfect book for me—it has lots of sports and a human story, some gender tension, and two more books in this series (Us Against You and Winners). 

STFU: The Power of Keeping Your Mouth Shut in an Endlessly Noisy World by Dan Lyons

For long parts of this book, it was a paradox to me – why write 200+ pages to say we should all shut up – just do it.

I listened to this book after also listening to Disrupted by Lyons. I like his style and narration. When listening to Disrupted, I thought that it probably damaged his employability, which turned out to be true, as he discussed in STFU.

The book can sometimes be extreme or refer to an extreme crowd (50 out of 50 in the Talkaholics test). However, I liked the book because it discusses many aspects of our lives – friends and family, work, etc.- and a few things I can immediately adapt. For example, I lowered my cell phone usage near my kids and hope to stick with it.

In one of the last chapters, he mentions Never Split the Difference by Chris Voss and Tahl Raz, which I also recently listened to. I listened to Never Split the Difference after a friend told me that she was starting to reread this book, and after listening to it, I completely understood why she wanted to reiterate it.

I read the book to improve my negotiation skills. I’m not sure there is an immediate effect, but as the two books pointed out – I talk less and actively listen more. So I try to pause before I answer, be succinct and hum, and let the other person talk.