Home on Arnau Díaz

build a library

Sun, 24 May 2026 18:56:00 +0000

Eight months ago I started dumping everything I read into Apple Notes. Every day. At the end of the month I review it, keep what’s worth keeping, merge it into a file, push it to a forge. That’s it.

I didn’t do this to build a “second brain”. I wanted to solve a simpler problem: remember what I read.

A few months later, something else started happening. I had references. When talking with teammates or friends, I could quickly pull papers, blog posts, talks or examples. Now, instead of vaguely remembering ideas, I had the actual source. One of the reasons I started this blog too. I share my own posts frequently and my posts have references.

offline

Fri, 08 May 2026 14:24:00 +0000

If my development environment needs the internet to work, that’s a dependency bug.

The network is the least reliable resource I have. Keep it out of the critical path.

I test this by turning Wi-Fi off.

If the build fails, or the tests stop, or the docs disappear, something still lives outside the machine. That’s the thing to fix.

A good development loop works offline. cargo build builds. cargo test tests. cargo doc --open opens the docs. The binary runs. The help text works. The man page is there.

stress your tests

Mon, 09 Feb 2026 18:46:00 +0000

Most integration tests can be load tests. I don’t see this done enough.

Good testing advice is clear. “Write tests. Not too many. Mostly integration.” I add a layer: most tests can be stress tests. Or load tests, if you prefer.

A load test is not defined by tooling, but by intent. It saturates a constrained resource (CPU, memory, disk, network) until limits are reached. Assertions move past correctness and into stability, throughput, latency, failure modes.

you will be google

Wed, 28 Jan 2026 00:00:00 +0000

Early in my career I worked with a Google team on an open-source project. I didn’t like it. Strict reviews, rigid style, heavy testing discipline. Everything felt slow and overengineered. A waste of time. I moved on, and everyone said the obvious thing: you’re not Google, you don’t need to do what Google does. That’s true. But it’s incomplete.

Teams don’t stay small and stable. People move. Engineers leave. New ones arrive. Managers become directors. Projects change owners. Roadmaps change. Priorities shift. What started as a greenfield project, written with the latest tools, becomes legacy faster than expected.

user experience is the tool

Mon, 26 Jan 2026 00:00:00 +0000

Tools

When I use a tool, I want the tool to care about me. I want it to be good. I want it to explain itself. I don’t want to search Google for documentation, skim blog posts, or click through SEO just to remember how something works.

I want examples. I want clarity. Everything I need should be part of the tool itself. That’s not how most software works anymore. Everything is monetized. Everything is optimized for ads, engagement, and searches.

one test to rule them all

Tue, 30 Dec 2025 16:42:00 +0000

What I’m aiming for:

make test

One test harness everywhere. If wiring it to a new environment needs special glue, the issue is almost always in your system boundaries, not the tests. And it doesn’t need to be make. It could be cargo, go, bazel.

One entry point. Let config handle the differences. Sometimes it’s simple:

ENV=local make test
ENV=ci make test
ENV=staging make test
ENV=prod make test

Sometimes it needs more variables:

jujutsu techniques

Wed, 17 Dec 2025 00:00:00 +0000

I was upgrading a project to Spring Boot 4. Multiple modules and libraries. Java, Gradle, AWS, CI, Docker… The kind of change that usually demands long-lived branches, careful sequencing, and a lot of trial and error.

What surprised me wasn’t the technical complexity. It was how much the shape of the work changed once the cost of being wrong went to zero.

This is what my tree looked like:

➜ java-upgrade git:(5561fa3) ✗ jj
@ nruuvkns arnau@local 2025-12-12 20:31:20 spring4 27d4b705
├─╮ upgrade to spring boot 4.0
│ ○ rzoyrzpv arnau@local 2025-12-12 20:30:29 jackson3 d76dcecc
│ │ upgrade from jackson2 to jackson3
○ │ yyxuxnmk arnau@local 2025-12-12 20:31:17 aws-cloud git_head() 5561fa39
├─╯ upgrade aws cloud 4
○ ttusytzr arnau@local 2025-12-12 20:30:29 spring35 5a817998
│ upgrade to spring boot 3.5
○ uolmolxo arnau@local 2025-12-12 20:30:29 java-25 26dda0de
├─┬─╮ upgrade to java sdk 25
│ │ ○ yvklzspu arnau@local 2025-12-12 20:29:47 aws-sdk-2 e2045bf6
│ │ │ upgrade to java aws sdk 2
│ ○ │ mkwpqylt arnau@local 2025-12-12 20:30:18 refactor-cache 36105341
│ ├─╯ simplifies cache by removing external dependencies
○ │ qxmnvtxp arnau@local 2025-12-12 20:29:56 docker-image 49a19a38
├─╯ ci uses in-house image and new action gradle tasks
○ kpqwwnkk arnau@local 2025-12-12 20:29:42 gradle bf2b0dad
│ upgrade gradle 8 to gradle 9
◆ zzzzzzzz root() 00000000

Nothing was planned in advance.

noise is not music

Thu, 11 Dec 2025 00:00:00 +0000

On Simulacra and Simulation we see how easily we mistake motion for meaning. Borges wrote that two mirrors are enough to create a labyrinth. Now, consider sound.

We make noise to be noticed. We announce, post, ping, repeat. Sometimes visibility, sometimes ego. Noise tempts us because it feels like progress. It gives shape to uncertainty. It fills gaps that should stay empty for real work to happen. But like Borges’ mirrors, it creates infinite reflections—convincing, familiar, and entirely false.

writing hard things

Sun, 09 Nov 2025 00:00:00 +0000

I’ve worked on hard problems: implemented AI papers, optimized backend services, troubleshot networking issues in production, databases. Some for work, some for fun.

Building hard things gives you understanding and skills. Everyone talks too much about understanding. Nobody talks enough about skills. If you don’t build hard things, you won’t know these skills exist. You won’t learn them.

Understanding:

What I cannot create I don’t understand! - Richard Feynman

Skills:

resource driven design

Tue, 28 Oct 2025 00:00:00 +0000

In this post we explore how starting from resources (CPU, RAM, DISK, NETWORK) can drive clearer, simpler and more robust system design — rather than beginning with features, frameworks or fancy architecture.

Modern software don’t fail because they lack abstractions. They fail because they ignore hardware.

Cultural disconnect

Engineering is about solving a problem in a specific context: time, team, budget, tools, and both functional and non-functional requirements.

Yet many projects start from features, then pick tools, patterns, and scaling strategies without ever asking what hardware they actually need. It’s what the Three Big Lies of software engineering called out years ago, abstraction sold as progress.

snapshots, property and simulation testing

Tue, 21 Oct 2025 00:02:00 +0000

Your test suite passes. Your coverage is 90%. You deploy to production. Your software breaks.

Traditional testing measures the wrong things. It counts lines of code covered, not bugs prevented. It tests components in isolation, not how they interact in the real world. It catches the bugs you expect, not the ones that actually matter.

You ship correctness bugs that unit tests never catch. The best way to avoid bugs is to not write them in the first place—but when you do, you need tests that actually catch them.

invariants

Tue, 21 Oct 2025 00:01:00 +0000

making impossible states impossible

Last week, a race condition crashed production at 3 AM. The bug was impossible to reproduce in development, but a single assertion would have caught it immediately. This is why assertions exist: they make impossible states impossible.

Some developers think assertions are just debugging tools. Not true. Assertions are contracts that prevent your code from reaching invalid states. Without assertions, bugs hide in impossible states. With assertions, impossible states become impossible. When combined with good CI, every change becomes visible, every assumption gets tested, and every deployment becomes predictable. As this analysis shows, assertions are crucial for catching correctness violations that types cannot prevent.

this is ci

Tue, 21 Oct 2025 00:00:00 +0000

Last month, a developer updated a library version. The application worked fine in development, but production crashed at 2 AM. The deployment pipeline had passed all tests—but it hadn’t tested the actual change. This is why most CI fails: it tests code, not changes. When CI fails, production breaks, teams lose trust, and changes become dangerous.

Most teams think CI is about running tests on GitHub. They’re wrong. CI is about correctness and detecting changes automatically. We test to have correct code and detect changes, and CI is that process being continuous.

dev log

Thu, 16 Oct 2025 00:00:00 +0000

This year I started a development log for my work notes. It made me far more effective. I control my work, measure my impact, and keep visibility on what I am doing and with whom.

Tools support the method. Pick one you will use consistently; the method drives results.

Remember:

Use tools and adapt them so they feel natural.
Simple and easy beats complex and hard.
Clarity beats volume.
Use references for easy and fast navigation.
Keep your notes structured and easy to search.
A note is useful if it moves a decision, an action, or a result.
A note is useful if you can share it with somebody else.

Structure

I use Apple Notes. It is simple. It supports tags, search, and note references. It syncs with my work phone and, most importantly, it works for me.

design is not a senior priviliege

Mon, 16 Jun 2025 00:00:00 +0000

Some teams treat architecture as a separate role reserved for “senior” engineers. They draw the diagrams, make the decisions, and pass the work.

This separation is a problem.

Design isn’t a reward for experience. It’s a skill that improves with practice, not just time. Like any skill, it should be part of the job from the start.

You grow by doing

You don’t learn implementation all at once. You start small: an endpoint, a form, a script. Later, you take on a bigger piece: auth, infra, data flows. Eventually, you ship whole services, across teams or markets.

visibility and collaboration

Tue, 03 Jun 2025 00:00:00 +0000

Software engineering requires collaboration by nature.

Consider the classic split: one engineer builds the backend while another builds the frontend. They can work in parallel, but only if they know what each other is doing and they know what to do. The moment they don’t, progress slows.

Two methods address this. Management-enforced process with agile techniques like daily standups and bureaucracy. Or software engineering culture born from the team itself. They serve different goals. Management wants visibility to control, monitor and “check in.” Good software engineers want to get the work done and do it well. The latter is the foundation of good team culture.

how to code clearly

Sun, 22 Dec 2024 00:00:00 +0000

This piece adapts the wisdom from the International Paper Company’s famous writing campaign

How to code clearly

If you are afraid to code, don’t be. If you think you’ve got to string together big fancy constructs and high-flying functions, forget it. To code well, you only need to know how to get your ideas across simply and clearly.

It’s not easy. But it’s easier than you might imagine. There are only three basic requirements:

oblique strategies

Tue, 17 Sep 2024 22:00:00 +0000

These cards evolved from our separate observations on the principles underlying what we were doing. Sometimes they were recognized in retrospect (intellect catching up with intuition), sometimes they were identified as they were happening, sometimes they were formulated.

They can be used as a pack (a set of possibilities being continuously reviewed in the mind) or by drawing a single card from the shuffled pack when a dilemma occurs in a working situation. In this case, the card is trusted even if its appropriateness is quite unclear. They are not final, as new ideas will present themselves, and others will become self-evident.

pg on tech managers

Sat, 07 Sep 2024 22:00:00 +0000

pg’s savage take on tech managers:

“Hire good people and give them room to do their jobs.” He followed this advice and the results were disastrous.

What this often turns out to mean is: hire professional fakers and let them drive the company into the ground.

C-level execs, as a class, include some of the most skillful liars in the world.

what is code

Mon, 22 Jul 2024 14:16:00 +0000

What is code? An instruction, a creation, a structure, a symphony.

AND

How do you use it? When it computes.

What is a program? A medium.

What is a machine? A collaborator, a colleague.

What is a byte? A unit of movement.

What is an algorithm? A means to an end.

What is data? A pulse, a narrative.

What is refactoring? Another chance.

What is design? A conversation, a dialogue.

simulacra and simulation

Fri, 05 Jan 2024 15:23:00 +0000

In his book “Simulacra and Simulation” published in 1981, Jean Baudrillard concluded that we were living in a simulation constructed by the media. We could argue that in tech companies, we live in a simulation constructed by management.

Baudrillard categorizes the breakdown of the image into simulation via four successive phases in his book “Simulations”:

The image first reflects a basic reality.
Then it masks or perverts that basic reality.
Then it masks the absence of a basic reality.
Finally, the image bears no relation to any reality whatever, it is its own pure simulacrum.

In a company, processes and methodologies are distorted until they only exist in a pure simulacrum. Take meetings as an example:

the way of a true leader

Mon, 04 Dec 2023 15:25:00 +0000

A reflection on Ursula K. Le Guin.

Acting simply.

A true leader remains almost invisible to those they guide, letting their actions speak for themselves.

Lesser leaders may be known, admired, feared, or even despised. If someone is admired, feared, or despised for being a leader, can they truly be one? True leaders don’t seek the spotlight.

Trust is a reflection. What you give is what you receive.

When work is done quietly and effectively, people will say, “We did it.”

before you speak

Sat, 09 Sep 2023 22:00:00 +0000

Is it true?
Is it necessary?
Is it kind?

borges

Tue, 23 May 2023 09:46:00 +0000

Creating abstractions means traversing an endless maze of illusions and distorted information. Mirrors deceive.

Simplifying abstractions is to submerge oneself in the limitless complexity of reality. Myriads of grains of sand.

It only takes two facing mirrors to build a labyrinth.

Our fate is either to perish, disoriented in the labyrinth, or to be swallowed by the sands.

On Exactitude in Science

… In that Empire, the Art of Cartography attained such Perfection that the map of a single Province occupied the entirety of a City, and the map of the Empire, the entirety of a Province. In time, those Unconscionable Maps no longer satisfied, and the Cartographers Guilds struck a Map of the Empire whose size was that of the Empire, and which coincided point for point with it. The following Generations, who were not so fond of the Study of Cartography as their Forebears had been, saw that that vast Map was Useless, and not without some Pitilessness was it, that they delivered it up to the Inclemencies of Sun and Winters. In the Deserts of the West, still today, there are Tattered Ruins of that Map, inhabited by Animals and Beggars; in all the Land there is no other Relic of the Disciplines of Geography.

this is not a hello world

Mon, 22 May 2023 10:03:00 +0000

#include <stdio.h>

int main() {
printf("Hello World");
return 0;
}

This is not a hello world.

This is not a program.

This is not code.

creative space and time

Fri, 21 Apr 2023 10:06:00 +0000

Software engineering runs on creativity and problem solving. Some people call it an art.

space: choosing your projects, your methods, your tools. where anything personal in the work comes from
time: setting your own pace. when a feature ships, how long you sit with it, whether you get to go back and make it better

For company growth

Hire skilled engineers. Give them space and time.

For team growth

Hire skilled engineers. Give them space and time.

impact metrics

Tue, 11 Apr 2023 00:00:00 +0000

Impact is not how many operations you have. It’s which ones matter when they break.

Some teams track total traffic, average response times, aggregate error rates. Those numbers hide the story. The useful question is which endpoints hurt a user most when they fail.

Someone is setting up your tool for the first time. If the onboarding call fails, they leave. That single failure costs you more than a thousand slow searches, and it has nothing to do with volume.

david lynch motivates you

Wed, 25 Jan 2023 10:44:00 +0000

Stay alert
Do your work
Don’t worry about the world going by
Don’t sit around doing nothing
Get in gear and do it
Don’t take no for an answer
Figure out how to get it done

Translate these lessons to Cinema, or a painting, or to whatever.

emotional micromanagement

Fri, 12 Aug 2022 16:33:00 +0000

Examples of Micromanagement and Emotional Micromanagement

Classic micromanagement:

They demand to be copied on every email, even when it’s irrelevant.
They refuse to delegate even the smallest tasks.
They constantly monitor where employees are: at desks, online, even bathroom breaks.
They ask for updates on every minor task and obsess over deadlines.
They never ask for input from others.
They enjoy correcting tiny mistakes in other people’s work.
They overanalyze even the lowest-priority tasks.
They are never satisfied with anything employees do.

Emotional micromanagement:

They force themselves into all casual conversations.
They organize team activities and off-sites to build a “family” feeling.
They constantly check on employee emotions, believing it’s their job to fix them.
They demand frequent updates about feelings and personal issues.
They act as unasked-for coaches and psychologists, pushing employees to “find their passion”.
They take pleasure in correcting how others manage mental health or soft skills.
They will OKR your personal life: “When was the last time you saw your mom? How did it make you feel? Can I help you? Let me help you!.
They are never satisfied with your well-being. yYu must grind harder, achieve more, smile wider.

code readibility

Tue, 07 Jun 2022 00:00:00 +0000

Two definitions, from one of the best courses I’ve taken.¹

syntax: the rules that say what counts as valid code. punctuation, keywords, structure
semantics: what that code means. what it does, what it represents

So readability is syntax that makes semantics obvious.

not imperative versus functional
not tabs, spaces, or where the braces go
whether a value is being moved or copied
whether I’m holding a reference or the thing itself
whether a loop mutates what it touches or leaves it alone

A good language makes semantics obvious. A good programmer does it anyway, when the language won’t.

engineers as gardeners

Fri, 06 May 2022 00:00:00 +0000

We need to let go of the idea that software development is about planning and execution.

Never forget, agile is here to save management, not software.

Software development as an act of gardening rather than architecting:

Planting seeds: Just as gardeners start with seeds, we begin with initial ideas or prototypes. We cultivate these ideas, allowing them to grow and evolve.
Tending the garden: We set up our infrastructure and build pipelines to nourish our code, much like watering plants and providing nutrients.
Adapting to changes: We face challenges like bugs and incidents, similar to dealing with pests or weather conditions in a garden. We adjust and care for our software as it matures.
Growing new features: As our product evolves, we cultivate new features or adjust existing ones. As planting new seeds or grafting branches to ensure the garden continues to thrive.

By thinking of ourselves as gardeners, we focus on nurturing software through its life cycle. We prepare the soil, plant seeds, and guide their growth, adapting as needed and celebrating the results.

traits of good programmer

Fri, 11 Feb 2022 00:00:00 +0000

checklist

say please and thank you
show respect for the other person’s opinion, never say “you’re wrong”
if you are wrong, admit it
talk about your own mistakes before criticizing
be a good listener
be a good friend and a good son
don’t criticize, condemn, or complain
give honest and sincere appreciation
treat people well
become genuinely interested in other people
breathe clean air
exercise your body, mind and spirit

think in 3d

Wed, 12 Jan 2022 00:00:00 +0000

Traffic goes up, performance goes down, and the team reaches for one of two levers:

horizontal scaling, adding more instances
vertical scaling, buying bigger machines

Pause for a moment. Did you notice something missing? If not, you might be seeing in 2D.

Both levers treat the symptom. Both assume the application is already as fast as it can be. That assumption costs money, adds moving parts, and slows the team down.

unix philosophy

Thu, 03 Jun 2021 19:39:00 +0000

the unix philosophy 1

born from practice, not theory. bottom-up. small systems. real interfaces. built by engineers who debugged their own ideas.

the unix philosophy isn’t a method. it’s a mindset — simple parts, clean rules, and just enough abstraction.

there is no rule six

you can’t predict where code will be slow.
measure before you optimize.
don’t use fancy algorithms unless n is huge — and even then, measure.
simple is faster to write, easier to debug.
data structures matter more than algorithms.
there is no rule six. 2

modularity

write simple parts with clean interfaces

bill evans

Mon, 01 Mar 2021 23:00:00 +0000

The Creative Process and Self-Teaching

Evans explains the step-by-step process of creative problem-solving.

Be real and true

People approximate the result instead of tackling it honestly at even the simplest level, yet each effort must be entirely true, real, and accurate.

They prefer to blur the whole problem rather than focus on one small piece with precision.

If you’re confused, you won’t find your way out

Approximating the whole thing vaguely may feel like touching it, but the path leads to confusion, and soon you become so lost that you cannot find your way out.

elements of programming

Tue, 01 Dec 2020 20:19:00 +0000

The Elements of Programming Style (1974) by Brian Kernighan and P.J. Plauger

clarity first

write clearly. not cleverly. say what you mean. directly. let the reader see the intent.

use libraries. reuse what works. copy the good parts. improve them. good artists copy. great engineers don’t waste time.

avoid unnecessary variables. prefer simple, immutable data when you can. benchmark before you trade clarity for performance.

computers are fast. let them handle what they’re good at.

now

Mon, 01 Jan 0001 00:00:00 +0000

2026 / 09

I quit my last job to bet on text. Text still wins.

Most of what I think about now is spec-driven development and agentic flows. Same bet, really: a machine does the right thing when somebody bothered to write down what the right thing was.

Reading:

Clarice Lispector’s The Hour of the Star
Calvino’s Cosmicomics
Sam Sheridan’s The Fighter’s Mind.

Listening to lots of salsa and bachata!

the library

Mon, 01 Jan 0001 00:00:00 +0000

A long-term collection of texts I revisit.

Five layers: Programming (implementation), Tests (quality) , Engineering Process (structure), Culture (foundation), and Others (misc high-quality references).

Programming

How we implement ideas

Knuth – Programming as an Art
Peter Naur – Programming as Theory Building
OSTEP — the definitive OS textbook.
What Every Programmer Should Know About Memory
Simple Made Easy
Joe Armstrong Thesis — concurrency and fault tolerance.
Peter Norvig – Good Style
Peter Norvig – Design Patterns
Armstrong – Why OOP Sucks
PACELC Theorem — latency vs consistency.
Tiger Style — system design philosophy.
5 Rules Programming (Rob Pike)
Napkin Math — intuitive performance math.

Tests

Quality: Design, strategy, and verification