Jordan Terry

Juste Cinq Minutes

Tue, 09 Jun 2026 00:00:00 +0000

Maintenant, je travaille (pas super dur) pour obtenir une qualification B2 en français. Dans ma vie, c’est un but important : avec un B2, dans deux ans je peux obtenir une nationalité française, grâce à ma femme!

J’ai un problème : je suis paresseux, très paresseux. Je n’utilise pas mes journées pour cet objectif. Aujourd’hui je commence un nouveau project: “Francais sur le ferry”. Je vais écrire quelques phrases chaque jour pendant moins de cinq minutes et essayer d’être moins paresseux!

Hot TAIke Two: TDD is back, baby

Sun, 01 Feb 2026 00:00:00 +0000

Test Driven Development gets a bad rap. I don’t understand why; you derive your tests from your functional requirements, and thanks to Continuous Integration those tests then run on every push, merge, and release of your code. Sounds great to me.

I once worked at a really, really, really boring software development job. It was so boring that I started reading the books I thought were boring at university. Except this time I had to buy them, rather than take them out of the library. Namely Working Effectively with Legacy Code, Test-Driven Development, and Extreme Programming Explained. They left an impression on me. That boring job became a lot less boring once I started applying what I’d read. These books gave me a framework for thinking about, and addressing Software Engineering.

These books are a well of great quotes that I come back to regularly.

On the definition of Legacy Code:

To me, legacy code is simply code without tests.

And a couple of bangers from Kent Beck:

I’m not a great programmer; I’m just a good programmer with great habits.

And:

Test-driven development is a way of managing fear during programming.

Over time I was lucky enough to have these mantras drilled into me by working with some great mentors.

But I often despair that the fine art of validating your work before you even write it is dying off. So imagine my delight when I read that TDD is in the Claude Code best practices documentation.

The concept of Continuous Delivery was created in order to continuously validate your code. Without tests, we lose confidence in the code we write. This is even more crucial in a world of Claude Code, where we should by default distrust the code that is written.

So what if we turn the current way of working on its head? If our intention is to deliver projects for our users, can we turn our roles into a job of writing tests? A harness that allows us to validate the work done by our untrustworthy friend, Claude.

I think test libraries are some of the most creative spaces in software development. They give us room to experiment with new patterns, explore edge cases, and stress-test our assumptions. In a future where Claude writes the production code, this becomes our playground. The place where we flex our craft and define what “correct” actually means.

Hot TAIke One: Software Development is going back to its roots

Thu, 29 Jan 2026 00:00:00 +0000

There is no getting around it, we can bury our heads in the sand, but LLMs like Anthropic’s Opus 4.5 or OpenAI’s Codex can do a fair chunk of the job for us Software Developers. I belive this is cause for us to change our relationships with our careers of choice.

But what if we thought of this as a good thing? What if writing less code ourselves allows us to return to the roots of our profession? Two books that I read at University, and a number of times after come to mind: The Mythical Man Month and the Pragmatic Programmer.

These are two books that you would be mistaken as thinking are about programming. Well, they aren’t they describe the broader topic of the Software Development Lifecycle; the process that results in an artefact that we know as code.

They describe what I think is the social aspect of our jobs. The discussions with our stakeholders, the experience of producing requirements and defining those.

Whilst it has been a while, I regularly marveled at the artefacts discussed in the books. “Manuals” and “Functional Requirements”. Exhaustive lists of functional requirements:

F1. Allow user to make a search from the home screen
- F1.1. When the user taps the search bar, it opens the search interstitial
- F1.2. yawn, these were so boring, even more annoying when QA told us our implementation was wrong
F2. Allow users to see their past searches
- F2.1. …

Why was this the way? Well, code was expensive! Deploying accounting software to an IBM mainframe took time. Debugging took longer. You could say that code was expensive. A mistake could be costly, measuring twice with exhaustive requirements was a good thing.

This isn’t the case nowadays. Software Development has made a shift left. We have concepts such as Continuous Integration and Deployment. If you make a mistake, or miss a requirement it’s fine we can just push a new release. Code became cheaper. We don’t write the great technical documents of yesteryear.

But now, code has become incredibly cheap. It is now cheaper for my employer to ask Claude Code to resolve simple bugs. Let’s take a lifecycle issue, this does not require specialist knowledge. Claude Code just Googles the issue and finds a solution to the problem.

So, how do I as a Software Developer justify my and my team mates roles in two to three years?

What do all of those technical documents above have in common? They all exhaustively define requirements for a system. What do LLMs need to do a good job? Exhaustive requirements. They can’t Google what we need from them to satisfy our user requirements, but we can tell them that.

In cheapening the cost of code, we’ve returned to a time where code was expensive. The similarity between them is the requirement for manuals and well defined requirements.

So I think it is time to blow the dust off the covers of the books of our elders in order to rediscover the art of exhaustive definitions of requirements.

mortgage-cli

Thu, 08 Jan 2026 00:00:00 +0000

My wife and I are looking to buy a property in France. We want to rent it out and, ideally, have it pay for itself. Simple enough, right?

The problem is there’s a lot to get your head around: French mortgage rules, notary fees, property taxes, management fees, and rental yields that vary wildly by location. We found ourselves running the same calculations over and over, tweaking one variable at a time. Is this property viable at 4% interest? What if we put 20% down instead of 15%? What rent do we actually need to break even?

The iteration journey

We’ve been through a few iterations trying to solve this:

Spreadsheets - The classic. Works until you want to compare multiple scenarios or share your assumptions with someone else.
Scrapers - I built tools to pull property listings automatically. Turns out data ingestion is hard and websites don’t like being scraped.
A website - More engineering than the problem warranted.

In the end, I landed on a CLI tool. Claude Code made building it remarkably quick, and a CLI fits how I actually want to use this: run a quick command, see if a property makes sense, move on.

What it does

The tool has two main concepts: profiles and analysis.

A profile stores your investment parameters - things you don’t want to re-enter every time:

How much you can put down
The interest rate you’ve been quoted
Your target rental income
French-specific costs (notary fees, property taxes, etc.)

Then you can analyse properties against that profile:

mortgage-cli analyze --price 150000 --rent 900

This calculates the break-even rent - the minimum you’d need to charge to cover all expenses - and compares it to your target. The output tells you whether the investment is viable (green), marginal (yellow), or a bad idea (red).

For comparing multiple scenarios at once, there’s a sensitivity matrix:

mortgage-cli matrix --price-min 100000 --price-max 200000 --rent 1000

This shows how break-even rent varies across different price points and down payment percentages. Useful for understanding how much flexibility you have.

Why a CLI?

I keep coming back to command-line tools for personal projects. They’re quick to build, easy to script, and you can pipe the output wherever you need it. Need a CSV for a spreadsheet? --format csv. Want to save scenarios for later? Redirect to a file.

Early days

These early days for tools like this are exciting. Pre-Claude Code, this project would have joined the graveyard of half-finished side projects. I’d have got the core logic working, lost momentum on the CLI interface, and never come back to it.

Instead, I have something I actually use. Something with practical benefit for a real decision my wife and I are making. That’s the shift I keep noticing: the gap between “I should build something for this” and “I have something that works” has shrunk dramatically.

The tool is up at jordanterry.github.io/mortgage-cli if you’re interested.

Function Colouring and Structured Concurrency in Kotlin

Thu, 08 Jan 2026 00:00:00 +0000

In Kotlin, not all functions are created equal. Some are suspend, others are not. This distinction matters more than you might think.

Bob Nystrom wrote a fantastic piece called What Color is Your Function? that introduces a helpful mental model. Functions have colours: red and blue. Each colour comes with rules:

Red functions can call blue functions
Red functions can call red functions
Blue functions can call blue functions
Blue functions cannot call red functions

In Kotlin, red maps to suspend functions. Blue maps to regular blocking functions. The metaphor maps cleanly.

// Red function
suspend fun fetchUser(): User { ... }

// Blue function
fun processUser(user: User): String { ... }

Kotlin bends the rules slightly with coroutine builders like launch and async. These let blue functions start red work. But there’s a cost to bending rules.

The Conductor

The “magic” behind Kotlin coroutines is the Continuation. Think of it as a conductor for an orchestra. It’s always there, orchestrating the asynchronous work: managing suspension points, state machines, and cooperative cancellation.

The Kotlin compiler adds a Continuation as the final parameter to every suspend function. When one suspend function calls another, the continuation travels with it. This is how structured concurrency works - when a parent coroutine is cancelled, all children are cancelled too.

Here’s the problem: if a suspend function calls a blocking function, the continuation can’t travel into that call. It pauses outside until control returns. The conductor has left the room.

Crossing the Boundary

Consider this pattern:

suspend fun collectEvents() {
    eventFlow.collect { event ->
        handleEvent(event) // Blue function
    }
}

fun handleEvent(event: Event) {
    coroutineScope.launch {
        // Red work inside a blue function
        val result = repository.fetch(event.query)
        dispatcher.dispatch(Result(result))
    }
}

The call stack goes: red -> blue -> red. We’ve crossed the boundary twice. The launch call returns immediately, and the handler continues. The launched coroutine runs on its own timeline.

Three things happen:

Loss of Continuation - The blocking function doesn’t receive the Continuation from the suspend function above it. The conductor can’t orchestrate what happens inside launch.
Non-determinism - Once the handler returns, cooperative sequencing is lost. We can’t guarantee the launched coroutine finishes before the handler does.
Detached lifecycle - The new coroutine executes independently, which can result in multiple overlapping jobs if the same event is triggered rapidly.

The Search Problem

Imagine a search bar. A user types “gold necklace”. Every keystroke produces an event: “g”, “go”, “gol”, “gold”, “gold “, and so on. Each event might trigger a network request.

Requests vary in latency. The request for “gold” might complete after the request for “gold necklace”. If you update your UI with whatever response arrives, you get stale results overwriting fresh ones.

The manual fix looks like this:

class SearchHandler(
    private val coroutineScope: CoroutineScope,
) {
    private var job: Job? = null

    fun handle(event: Event) {
        job?.cancel()
        job = coroutineScope.launch {
            val results = searchRepository.search(event.query)
            dispatcher.dispatch(SearchResults(results))
        }
    }
}

This works in the narrow sense - only the latest search survives. But we’ve reinvented concurrency control, and done it worse than what Kotlin already provides.

Keeping the Conductor in the Room

The fix is simple in principle: stay red. If we keep every step in the suspend world, we never lose the continuation.

class SearchHandler(
    private val searchRepository: SearchRepository,
) {
    suspend fun handle(query: String): Event {
        val results = searchRepository.search(query)
        return SearchResults(results)
    }
}

Wire this up with Kotlin Flow’s built-in operators:

queryFlow
    .distinctUntilChanged()
    .mapLatest { query ->
        searchHandler.handle(query)
    }
    .collect { event ->
        // Process result
    }

mapLatest does what our manual job tracking tried to do, but correctly. Each new emission cancels any in-flight work before starting fresh. The continuation never leaks across the boundary. Cancellation propagates from the Flow collector through every emission.

The Takeaway

Function coloring isn’t just a theoretical concept. It has practical consequences. Every time you cross the red/blue boundary with a coroutine builder inside a blocking function, you’re dismissing the conductor.

For most code, this is fine. But for high-frequency events - search typing, rapid button taps, pull-to-refresh - the consequences compound. Out-of-order results, stale state, wasted work.

The solution is to respect the colours. Keep red work red. Let Flow’s operators handle the cancellation semantics. The conductor knows what they’re doing.

Grph

Sun, 04 Jan 2026 00:00:00 +0000

I’m curious about how agentic tools can better understand a codebase if they know how to traverse a Graph.

For that reason, I (read Claude Code) have put together a CLI tool to easily consume a Graph. I call it grph.

How does this work?

The CLI is a thin wrapper around the Python library NetworkX. The codebase exposes a number of features.

The CLI ingests a graph formatted with GEXF format. This is a universal way of defining a graph.

Neighbours

Imagine you have an airline route network. You’re at Gatwick and want to know where you can fly direct:

$ grph neighbors routes.gexf Gatwick

Neighbors of Gatwick (depth=1, direction=all)

┌───────────┬─────────────┐
│ ID        │ Label       │
├───────────┼─────────────┤
│ Barcelona │ Barcelona   │
│ Amsterdam │ Amsterdam   │
│ Nice      │ Nice        │
│ Berlin    │ Berlin      │
│ Lisbon    │ Lisbon      │
└───────────┴─────────────┘

What about with one layover?

$ grph neighbors routes.gexf Gatwick --depth 2

Shortest Path

How do I get from Edinburgh to Dubrovnik with the fewest connections?

$ grph path routes.gexf Edinburgh Dubrovnik

Path found (length: 3)
Edinburgh → Gatwick → Split → Dubrovnik

Or find all the options:

$ grph all-paths routes.gexf Edinburgh Dubrovnik --max-depth 4

PageRank

Which airports are the most critical hubs in the network? PageRank reveals where traffic flows through:

$ grph centrality routes.gexf --type pagerank --top 5

┌───────────┬───────────┐
│ Node      │ Score     │
├───────────┼───────────┤
│ Gatwick   │ 0.0892    │
│ Barcelona │ 0.0734    │
│ Amsterdam │ 0.0651    │
│ Milan     │ 0.0612    │
│ Paris     │ 0.0598    │
└───────────┴───────────┘

And more

Find isolated route clusters - are there parts of the network disconnected from each other?

$ grph components routes.gexf --list

Blast radius - if Gatwick closes, which destinations become unreachable from Edinburgh?

$ grph reachable routes.gexf Edinburgh

Extract a subgraph - pull out just the UK airports for focused analysis:

$ grph subgraph routes.gexf --nodes Gatwick,Edinburgh,Manchester,Bristol --output uk-routes.gexf

But why?

I work in a medium-sized Android codebase. It has a lot of complexity baked into it: modularisation and a complex DI graph. I want Claude Code to be able to browse and understand both static and dynamic connections.

The same queries that answer “how do I fly from Edinburgh to Dubrovnik?” can answer “how does MainActivity depend on DatabaseHelper?” - it’s all just graph traversal.

Query Languages: Declarative and Imperative

Tue, 02 Dec 2025 00:08:00 +0000

Chapter two of Designing Data-Intensive Applications is called “Data Models and Query Languages”. It touches on a vast array of topics: the competition between Relational and Document models in the 70’s, through to the Relational model victory through to the introduction of Not-quite SQL databases. It takes us on a tour of one-to-many and many-to-many databases and explains how these relations dictate your underlying data model choices.

Query Languages

The book proposes that there are two types of query languages: declarative and imperative. Before reading this, I had some vague notion of this, but I can’t say I had ever deeply thought about the relationship. I’ve found the section discussing Query Languages to be simple, but to have caused a small revolution in my mental model for data models and querying them.

Declarative

SQL (Structured Query Language) is a declarative query language. Everyone knows and ~~loves~~ ~~hates~~ loves it.

SELECT 
  * 
FROM 
  animals 
WHERE 
  family = 'shark';

This is declarative because the query is defining what data is required, not the how. The query engine is responsible for that.

Contrast this to the an imperative alternative:

fun sharks(): List<Animal> {
    val sharks = arrayListOf<Animal>()
    for (animal in animals) {
        if (animal.family == "Sharks") {
            sharks.add(animal)
        }
    }
    return sharks
}

Imperative instructions have been written to define the how. We are locked into this implementation as it is the code we have written.

What’s the difference?

The imperative code above is going to always have a time-complexity of O(n) where n is the count of animals. Parallelising the code above is going to be complex, too. The declarative code is not tied to an implementation in any way. The query engine is responsible for applying queries; it knows how to leverage the computer it is running on to parallelise and run as quickly as possible. Perhaps we can introduce a new index that allows us to search with O(log n) time complexity? And then there are joins, joins are complex too! Imperative joins require two outbound database connections, whereas the declarative query runs on the same machine.

Where else does this apply?

Data models don’t only exist on databases. If you write HTML, JSON or any UI code, you are creating a data model. Often, they are defining a tree.

To lift another shark-related example from the book, here is a HTML data model:

<ul>
    <li class="selected">
        <p>Sharks</p>
        <!-- More HTML -->
    </li>
    <li>
        <p>Whales</p>
        <!-- More HTML -->
    </li>
</ul>

Cascading Style Sheets (CSS) are used to style different elements in the data model.

li.selected > p {
    background-color: blue;
}

CSS is another declarative query language; it doesn’t tell CSS how it should traverse the Document Object Model (DOM), that is left to the browser engine.

The imperative alternative is to query the DOM using JavaScript. Each instruction for the machine will be typed out and executed, perhaps inefficiently!

What about Jetpack Compose?

All of this talk of data models and query languages is very exciting. It got me thinking about Jetpack Compose. For Android developers, this introduced the concept of declarative UIs. We define what we want but not the how. The creation of the underlying UI tree is delegated to the library:

@Composable
fun AnimalList() {
    Column {
        Row {
            Text("Sharks")
        }
        Row {
            Text("Whales")
        }
    }
}

At runtime, the UI can be updated to change the background colour:

@Composable
fun AnimalList() {
    Column {
        Row {
            Text(
                "Sharks",
+                modifier = Modifier
+	                .background(Colors.Blue)
            )
        }
        Row {
            Text("Whales")
        }
    }
}

Compose is both the data model and a query language. By changing the user interface at runtime, it knows how to efficiently find relevant parts of the data model and update them. The user doesn’t need to know about slot-tables or gap buffers. The library handles these for us.

Obviously, duh?

Maybe this isn’t “revolutionary” to others, but it was for me. The chapter introducing the relationship between databases and the web’s data models has helped me open my eyes to further relationships.

I love this book!

Nerd Club

Fri, 28 Nov 2025 00:08:00 +0000

I spend a lot of time working with technology that I don’t understand. They are black boxes to me; I write code, it does what I want it to do. Great!

Let’s use SQLite as an example: I can write SQL, and I understand that indexes are efficient because they are B-trees. But I certainly do not understand how the query engine converts my SQL to an algorithm, nor do I understand how a B-tree is serialised to disk. I do have a rough mental model, though. Even if I did learn how B-tree storage worked, I still wouldn’t know how memory really works on disk; a black box remains.

The fun of my job is to reduce those black boxes. But I have to choose where to do that. Will learning how flash memory works in conjunction with SQLite be the best use of my time? No.

The biggest black box I have right now is the backend at work! I know roughly what happens: I send a network request, it gets routed to a computer in our fleet, data is hydrated (we fan out?), it reads data from memcache, and we map data to JSON. Oh, hang on, I don’t have a clue how that works. I have a rough blurry mental model, in fact, its a blackbox. I don’t have a clue how the backend works!

Working on reducing the black box of the backend and the systems that run it makes me more effective at work.

Whilst pondering how on earth I was going to tackle this in short succession, two of my colleagues mentioned the book Designing Data-Intensive Applications written by Martin Kleppmann. Someone even had it on their desk!

I vaguely knew of this book, and browsing through it I realised this book contained a literal map to understanding a lot of the black box that was the « backend »!

One button click on Amazon and two days of waiting later I was the proud owner of the first edition! I now carry it around the office doing what I call « Performative Software Engineering ». I find it makes me look far more intelligent than I am!

A few days later, we have a small group of us assembled. We’ve read the first two chapters now and it has been exciting! Our general pattern has been to read for a week or two, and then get together in a meeting room and talk about what we’ve learned. In the space of a few hours of talking I’ve had so many questions answered, and found that I know more than I thought and can engage on topics of systems at scale!

Chapter One

Day to day, I work on Etsy search. The first paragraph of the book neatly summarises the domain we work on:

Many applications today are data-intensive, as opposed to compute-intensive. Raw CPU power is rarely a limiting factor for these applications - bigger problems are usually the amount of data, the complexity of data, and the speed at which it is changing.

A big chunk of our work is actually moving data around and analysing it. One colleague has been working on analysing consecutive sales, yes, algorithms do show up in your day-to-day work (leetcode)!

We do a lot of work analysing data and moving it from one place to another. Imagine analysing listings on sale and finding consecutive sales! This is data-intensive work, we have never discussed if we will overload CPUs.This paragraph (yes, the first in the book!) has opened my eyes to a new approach to thinking about what the blackbox of a backend does. This doesn’t change how I do my work, my job has always been about marshalling data from one place to another. But it has made it explicit.

The first chapter introduces four terms:

Faults - Something that can go wrong in your application. These are split neatly into Hardware, Software, and Human errors. I’m a few chapters ahead « Fault » is a consistently used word throughout the book.
Reliability - This is how your application handles faults, regardless of type. Unreliable software impacts money, trust and reputation. Reliability isn’t only for Nuclear Power Stations.
Scalability - How does your program handle growth in load? The case study is how Twitter manages accounts with varying numbers of followers Tweeting. It’s not straightforward! We also learn how to quantify Load, perfect for Observability!
Maintainability - This introduces more terms: Operability, Simplicity and Evolvability. All descriptors of how to make operations run smoothly and make it easy for new devs to onboard and improve a system.

These are such simple terms, but already they have made their way into our day-to-day conversations. At first, this would evoke reactions of « ha! That’s from the book ». But we’ve realised these terms bring consistency and definitions to our conversations. It actually roots our conversations in a shared vocabulary that we all understand.

Not only that, but we’ve applied these to what Etsy does. For example, how does clearing up data we’ve saved to a cache for an experiment fit into Maintainability? Our documentation and processes are now improving as we know our observability must be better for the Reliability of our systems!

Start a book club

I’ll leave with this: start a book club. Every one of your colleagues can help you learn by providing diffierent pieces of knowledge or points of view. You will leave every book club better off for it.

We’ve also named our book club Nerd Club, because frankly who else is reading O’Reilly books?

Android NYC Meetup - Reusable Modules: It's as Easy as ABI

Thu, 20 Nov 2025 00:08:00 +0000

An opportunity to talk at a naecent meetup group presented itself! I had recently given the talke “Reusable Modules: It’s as easy as ABI” in Mexico and thought it would be great to go again. I wasn’t able to make the improvements I wished to, due to illness and other work commitments. Regardless, it was a great night!

App Dev Nights Mexico - Reusable Modules: It's as easy as ABI

Tue, 11 Nov 2025 00:08:00 +0000

I’ve been sitting on some improvements to a previous talk I have given by the same name. This presentation seeked to improve upon it. I’ve added an introduction to build systems and how they work, this provides a nice introduction into the world of Application Binary Interfaces.

This was a special event for me as I traveled to it with work, I was able to meet some CDMX based colleagues in person. Note to remember, Mexico City is very high!