DEV Community: Matías Denda

The four decisions every team makes about Git (whether they realize it or not)

Matías Denda — Wed, 13 May 2026 13:00:00 +0000

Most teams think they have a "Git workflow." What they actually have is a set of habits that accumulated over time, often made by people who left the company years ago, based on assumptions that no longer hold.

Ask three developers on the same team to explain "how we use Git" and you'll get three different answers. Not because anyone is wrong — because the team never actually made the decisions explicitly. They made them by accident.

This article is about surfacing those decisions. Not telling you what's right — telling you what you're implicitly choosing, so you can choose deliberately.

The four decisions

Every team, whether they know it or not, has made a choice about four things:

Branching strategy — How does code move from idea to production?
Tracking methodology — How do you decide what to work on and measure progress?
Release cadence — How often does code reach users?
Automation level — How much of the workflow is human-driven vs event-driven?

Each decision constrains the next. Each one, if not made explicitly, gets made implicitly — and implicit decisions tend to contradict each other.

Decision 1: Branching strategy

Your options, roughly:

Trunk-based development — everyone commits to (or merges small changes into) main, multiple times a day
GitHub Flow — feature branches, short-lived, merged via PR to main
GitLab Flow — feature branches + environment branches (staging, production)
Git Flow — long-lived develop + main branches, release branches, hotfix branches
Custom hybrid — some combination of the above

Most tutorials frame this as "which is best?" The honest answer is: it depends on the next three decisions. Git Flow with continuous deployment is a contradiction. Trunk-based with a monthly release train is a waste.

The right question isn't "which strategy should we use?" — it's "which strategy supports the other three decisions?"

Decision 2: Tracking methodology

This one most teams think they've decided, but haven't.

Scrum — sprints, story points, planning/retro ceremonies
Kanban — continuous flow, WIP limits, no sprints
Waterfall or phase-gated — requirements → design → build → test → deploy
SAFe or other scaled framework — multiple teams coordinating via ARTs or similar

The question that reveals your actual methodology: what triggers work to start?

If it's "this sprint's plan" → you're doing Scrum (or pretending to)
If it's "capacity is available and this is prioritized" → you're doing Kanban (or should be)
If it's "this phase is complete and signed off" → you're doing Waterfall (admit it)
If it's "a manager said so" → you're in a methodology vacuum, which is its own problem

The implications for Git are direct. Scrum with 2-week sprints wants branches that close before sprint end. Kanban doesn't care about time — it cares about WIP limits. Waterfall expects phase-gated tags. These are incompatible constraints on how your branches live.

Decision 3: Release cadence

This is the one most teams lie to themselves about.

Continuous deployment — every merge to main goes to production (with canary, feature flags, etc.)
Continuous delivery — every merge to main is production-ready, but deployment is a manual trigger
Release train — scheduled releases (weekly, biweekly, monthly)
Ad-hoc releases — "when it's ready," which usually means "when someone has time"

The diagnostic question: how long from a developer's merge to users seeing the change?

Hours → you're on continuous deployment
A day or two → continuous delivery
Consistent schedule → release train
"Varies" → ad-hoc (and your lead time is probably terrible)

Release cadence is the cruellest decision to get wrong, because it interacts with everything:

Long cadence + trunk-based = huge batch risk
Short cadence + Git Flow = unnecessary overhead
Ad-hoc + Scrum = sprint goals that never ship at sprint end

Decision 4: Automation level

Unlike the others, this is a spectrum, not a discrete choice. But at a high level:

Fully automated — PR opens → CI runs → auto-merge on approval → auto-deploy to staging → auto-promote to prod (with gates)
Event-driven — Git events trigger most transitions; humans handle exceptions
Semi-manual — CI runs, humans approve and merge, humans decide when to deploy
Fully manual — every step requires a human action

The test of your automation level: what happens at 2 AM when a hotfix needs to ship?

If the answer is "we page someone who manually runs the deploy script," your automation level is semi-manual at best. If the answer is "the hotfix workflow handles it; we review the result in the morning," you're much closer to the automated end.

The decision table

Here's what it looks like when a team makes all four decisions consistently:

Team Type	Branching	Tracking	Release	Automation
SaaS startup	Trunk-based	Kanban	Continuous	High
Regulated fintech	GitLab Flow	Scrum	Biweekly	Medium
Enterprise product	Git Flow	SAFe	Quarterly	Medium-high
Open source project	GitHub Flow	Issue-driven	Ad-hoc	High
Regulated hardware	Custom	Waterfall-hybrid	Milestone-based	Low-medium

Notice that each row is internally consistent. The branching strategy supports the cadence. The tracking methodology matches the release frequency. The automation level is appropriate for the regulatory context.

Natural combinations that work

Trunk-based + Kanban + continuous deployment + high automation. This is the SaaS ideal. Works when the team is small-to-medium, the product tolerates continuous change, and there's sufficient test coverage. Fastest feedback loop, but requires discipline.

GitHub Flow + Scrum + continuous delivery + medium-high automation. The most common mid-size-team setup. Feature branches align with sprint items. Continuous delivery means each sprint can ship if the business decides. Good for product teams at B2B SaaS companies.

Git Flow + SAFe + release train + medium automation. Enterprise reality. Multiple teams coordinating, scheduled releases, version-branching for support of multiple production versions. Unfashionable, but genuinely correct for some contexts.

Combinations that create friction

Git Flow + continuous deployment. Your long-lived develop branch creates unnecessary batching. Why have develop if you deploy on every merge? You're paying the cost of Git Flow without getting its benefits.

Trunk-based + quarterly release train. You're merging to main continuously, but users don't see the changes for 3 months. Either deploy more often, or use longer-lived branches. The current setup batches risk without batching value.

Scrum + ad-hoc releases. You commit to sprint goals, but the output doesn't reach users at sprint end. The team's measurement of success (sprint completion) is divorced from actual delivery. Over time, developers stop believing sprints matter.

Kanban + Git Flow. Kanban is about continuous flow; Git Flow creates flow-blocking integration points. Every release branch is a ceremony Kanban is designed to eliminate.

The test: can you write down your answer?

Here's a diagnostic exercise that takes 10 minutes and is worth more than most consulting engagements:

Write down the four decisions for your team, as one sentence each.

"We use GitHub Flow."
"We use Scrum with 2-week sprints."
"We release every Thursday at 2 PM."
"PR opens trigger CI automatically; merges trigger deploy-to-staging automatically; promotion to production requires manual approval."

If you can write these four sentences confidently, and every senior person on the team would write approximately the same four sentences, you have a workflow.

If different people would write different sentences, or if you find yourself writing "it depends," or "we kind of do X but sometimes Y" — you don't have a workflow. You have accumulated habits pretending to be a workflow.

And that's fine to discover. The discovery is the start of fixing it.

Your workflow will evolve

One more thing: these four decisions aren't permanent. Teams grow, products mature, regulations change.

A startup that started with trunk-based + continuous deployment may, at 50 developers, realize that coordination requires feature branches. That's not a failure — that's scale demanding a new set of decisions.

A mature enterprise product might, after adopting feature flags and improving test coverage, discover it can move from quarterly release trains to biweekly. That's not a rebellion — that's capability unlocking a new set of decisions.

The mistake isn't in the specific decisions. The mistake is making them implicitly, letting them drift, and then wondering why delivery is slow and everyone's frustrated.

Make them explicit. Revisit them quarterly. Change them when the context changes.

That's how you go from "we have a Git workflow" to actually having one.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book with a full chapter on the complete map connecting board columns, Git states, and deployment environments — plus decision frameworks for choosing the right combination for your team.

See all my articles on Git and engineering practice: dev.to/matutetandil.

N! Ways to Hide a Message: Multi-Carrier Encoding in Rust

Matías Denda — Tue, 12 May 2026 14:00:00 +0000

Post 2 of 6 in the series on building Anyhide, a Rust steganography tool. This post is about a small feature that multiplies your adversary's work by a factorial.

I like features that give you an outsized security improvement for very little code. Multi-carrier encoding is one of those. The implementation is maybe twelve lines. The effect is that the set of carriers you use becomes an ordered secret — and getting that order wrong produces deterministic garbage, which an attacker can't distinguish from using the wrong files entirely.

Let me explain.

The single-carrier recap

In a normal Anyhide flow, both parties share one file. They use it as a reference, and the sender encodes a message by computing byte positions into that file. Single file, single shared secret.

But "the carrier is the file we both have" is a constraint I wanted to relax. What if the carrier is a set of files? What if the set is ordered, and the order itself is a secret nobody but the two parties knows?

That's multi-carrier encoding.

The API

From the command line, you just pass -c multiple times:

# Sender
anyhide encode \
  -c song.mp3 \
  -c photo.jpg \
  -c document.pdf \
  -m "meeting moved to 9pm" \
  -p "passphrase" \
  --their-key bob.pub

# Receiver needs the SAME files in the SAME order
anyhide decode \
  --code "..." \
  -c song.mp3 \
  -c photo.jpg \
  -c document.pdf \
  -p "passphrase" \
  --my-key bob.key

If Bob swaps photo.jpg and document.pdf, he does not get an error. He gets garbage — random-looking bytes that happen to decode cleanly from the wrong carrier. He won't know whether the message was the wrong passphrase, the wrong key, the wrong files, or the wrong order of the right files.

The math

The number of ways to order N distinct files is N! (N factorial). That means if an adversary has all four of your carrier files and the passphrase and the private key, they still have to try up to 24 orderings to recover a 4-carrier message.

N carriers	Orderings to try
2	2
3	6
4	24
5	120
7	5,040
10	3,628,800

This isn't cryptographic security — factorial growth is polynomial next to exponential keyspaces. But it's not meant to be. It's an additional layer of ambiguity, and more importantly, it's ambiguity that an attacker can't distinguish from other failures. They can't test "is this the wrong order?" without a ciphertext oracle, which they don't have.

The implementation

Here's the actual code. It lives in src/text/carrier.rs and is 17 lines:

/// Creates a carrier from multiple files concatenated in order.
///
/// *Order matters!* Different order = different carrier = different decoding result.
/// This provides N! additional security combinations for N carriers.
///
/// - Single file: Delegates to `from_file()` (preserves text vs binary detection)
/// - Multiple files: All read as bytes and concatenated (always binary carrier)
pub fn from_files(paths: &[std::path::PathBuf]) -> std::io::Result<Self> {
    if paths.is_empty() {
        return Ok(Carrier::from_bytes(vec![]));
    }

    if paths.len() == 1 {
        return Self::from_file(&paths[0]);
    }

    // Multiple files: read all as bytes and concatenate in order
    let mut combined = Vec::new();
    for path in paths {
        let data = std::fs::read(path)?;
        combined.extend(data);
    }
    Ok(Carrier::from_bytes(combined))
}

That's it. Read each file as bytes, concatenate them in the provided order, hand the resulting buffer to the binary carrier machinery, and move on. The rest of the encoder and decoder doesn't even know it's dealing with multiple files — to them, it's just a longer buffer.

Why the single-file branch matters

Notice the early return at paths.len() == 1. Without it, a single-carrier call would lose the text/binary autodetection that from_file gives you. A .txt with one carrier would be treated as binary, and suddenly substring matching becomes byte matching. The search still works, but you lose the case-insensitive lookup that text carriers give you for free.

Keeping the single-file case routed through from_file means the multi-carrier feature is a pure extension — existing callers and existing encoded codes are untouched. This is the kind of thing I care about when adding features to a tool people might already depend on.

Why ordered concatenation instead of something cleverer

I considered a few alternatives while designing this:

Hashing the carrier set and using the hash as a seed. Too indirect. The whole appeal of Anyhide is that the carrier is the file, not a digest of it. Hashing would also make the "why wrong order gives garbage" property harder to reason about.
Interleaving bytes from each file in a passphrase-derived pattern. More complex, marginally better, and it made the error surface much bigger. Every bug would be a silent decoder failure, which is exactly what Anyhide is designed to never surface.
Each carrier gets its own search, and fragments are distributed across carriers. Elegant on paper, but it changes the security model: now partial knowledge of one carrier compromises the whole message instead of just its fraction. Worse.

Concatenation in caller-provided order is the simplest model that works and the easiest to reason about. Boring. Correct.

Plausible deniability across the factorial

Here's where this gets fun. Imagine you encode a message with [A, B, C]. Six orderings are possible:

[A, B, C]  → "meeting at 9pm"  (real)
[A, C, B]  → garbage
[B, A, C]  → garbage
[B, C, A]  → garbage
[C, A, B]  → garbage
[C, B, A]  → garbage

All five "wrong" orderings produce outputs indistinguishable from random. An attacker who recovers your files, your key, and your passphrase — but not the ordering — sees six plausible-looking plaintexts. None of them says "ERROR". One says "meeting at 9pm". The other five say things like \x8f\x3aq#w....

Now pair this with the duress-password feature from Post 3 and the adversary's problem gets harder still: they can't tell whether a given output is "the real message in the right order", "the decoy message in the right order", or "the wrong ordering producing noise".

A note on testing

The integration test that verifies this is one line of logic:

#[test]
fn test_multi_carrier_wrong_order_produces_garbage() {
    let msg = "top secret";
    let carriers = vec!["a.txt", "b.txt", "c.txt"];
    let code = encode_with(carriers.clone(), msg);

    // Wrong order
    let wrong = vec!["b.txt", "a.txt", "c.txt"];
    let decoded = decode_with(wrong, &code);

    // Does not return Err(); returns Ok with garbage
    assert_ne!(decoded, msg);
    // And it's "garbage" in the sense that re-encoding it
    // wouldn't round-trip either
}

The interesting assertion isn't assert_ne!. It's that the function returns Ok with bytes, not an error. That's the "never-fail decoder" invariant Anyhide is built around, and multi-carrier inherits it for free because it's just a longer buffer going through the same pipeline.

What you get for 17 lines of Rust

To recap:

N! additional orderings an adversary must exhaustively search through.
Zero impact on single-carrier code paths (backwards compatible by design).
Order is a new secret, composable with the passphrase, key, and (see Post 3) duress password.
Wrong order produces garbage indistinguishable from any other failure mode.

The lesson for me, writing this: the best additions to a security tool are the ones you can explain in two sentences and implement without touching the core. If your new feature reshapes the pipeline, you've probably made a mistake.

Next up in the series: Post 3 — Plausible Deniability and Duress Passwords. How to encode two messages under two different passphrases, so that under coercion you can reveal a decoy that's cryptographically indistinguishable from the real one. Dropping in two weeks.

Repo: github.com/matutetandil/anyhide. If you spot a way multi-carrier breaks the security properties I claimed above, open an issue — I want to know.

Stop estimating in hours. Start estimating in complexity.

Matías Denda — Thu, 07 May 2026 13:00:00 +0000

Stop Estimating in Hours. Start Estimating in Complexity.

There's a quiet truth every developer knows but nobody says out loud at sprint planning:

When we estimate in hours, we always estimate low.

Always. The senior estimates low because they want to look efficient. The junior estimates low because they don't want to seem slow. The team estimates low because the PM is in the room. And then the sprint ends, half the tickets roll over, and everyone pretends to be surprised.

After years of watching this play out across teams, languages, and stacks, I've come to believe that the problem isn't that we're bad at estimating hours. The problem is that hours are the wrong unit.

Let me explain why I now estimate in complexity, and why I think it leads to better software, better teams, and — surprisingly — better deadlines.

The misunderstanding at the core

Here's the trap most teams fall into: they treat complexity and time as the same thing measured with different rulers. They're not. They're two independent axes.

Consider translation. Translating a paragraph from English to Spanish is easy. There's almost no complexity. But translating the entire Bible? That's still easy — the per-sentence cognitive load hasn't changed — it's just long. Easy doesn't mean fast.

Now flip it. A complex distributed-systems migration sounds like it should take weeks. But if your platform happens to have the right tooling already in place, you might pull it off in an afternoon. Complex doesn't mean slow.

Once you internalize this, the whole hour-based estimation game starts looking absurd. You're collapsing two dimensions into one and pretending the result is meaningful.

So what is complexity, then?

In the teams I've worked on, we settled on a Fibonacci-ish scale: 3, 5, 8, 13. Anything bigger than 13 wasn't an estimate — it was a signal to break the task down.

The numbers themselves don't matter much. What matters is what they represent:

3 — Well-understood. We've done this kind of thing before. Few moving pieces. Low risk.
5 — Some unknowns, or more pieces involved, but nothing scary.
8 — Several systems touched, real risk, or genuinely new territory.
13 — Too big. Stop. Break it apart.

You can layer in dimensions like uncertainty, coupling, blast radius, dependencies, team familiarity — but the goal isn't to build a precise rubric. The goal is to give the team a shared vocabulary for talking about how hard something is, separate from how long it takes.

The real magic isn't the number — it's the conversation

Here's what nobody tells you about story points: they're not better than hours because they're more accurate. Honestly, they're probably less accurate in absolute terms.

They're better because they change the conversation.

When you ask someone "how long will this take?", the conversation is individual and defensive. Whoever knows the most throws out a number. Everyone else nods. The junior who's actually going to do the work quietly panics, because they know they can't hit that number, but pushing back means admitting they're slower.

When you ask "how complex is this?", the conversation is collective. Why is this a 5 and not a 3? What pieces does it have? What could go wrong? Juniors learn by watching seniors reason through problems. Seniors occasionally discover that something they called "trivial" wasn't trivial at all. The team understands what they're about to build before they build it.

That's what hours don't give you, no matter how precise they are.

The split that changes everything

Here's the part of my workflow that I think is genuinely underrated:

The team estimates complexity. The individual developer estimates their own hours.

Complexity is a property of the problem. Hours are a property of the person solving it.

I'm a senior architect. A junior on my team is not going to take the same time I do on the same task. That's not a flaw — it's reality. Telling a junior "this should take you 3 hours because the senior said so" is one of the cruelest, most counterproductive things we do in this industry. They burn out trying to hit a number that was never theirs to hit.

So instead: the team agrees this task is a 5. Then the developer who picks it up estimates their own hours. Those hours are mostly for them — to plan their day, to learn calibration, to flag early when they're slipping. We sum them as a sanity check against the sprint capacity, but the commitment to the business doesn't come from those numbers. It comes from velocity (more on that in a sec).

Junior devs get the low-complexity tasks first. Not because we don't trust them, but because low-complexity tasks are where it's cheap to be wrong. That's where you learn to estimate without blowing up the sprint.

"But the junior will estimate wrong too"

Yes. They will. That's the point.

I get this objection every time I describe this system: "if the dev estimates their own hours, they can still get it wrong — for any of the reasons people get hours wrong in the first place." True. A junior estimating their own hours will probably underestimate 9 times out of 10. A senior in unfamiliar territory will do the same.

The difference isn't that the estimate magically becomes correct. The difference is what happens when it's wrong.

When hours are imposed top-down by whoever-knows-most, a missed estimate is a personal failure. The junior is just behind. Tough luck, work weekends.

When the dev estimates their own hours, a missed estimate is a calibration signal. It's the moment the team lead — the architect, the TL, the assigned senior — steps in. Not to scold, but to give context. To explain what the dev didn't see. To walk through why this task that looked like 4 hours was actually 12.

This is where the didactic side of the senior matters, and where teams really differ. Some leads let juniors slam their heads against the wall and call it "learning by doing". Others sit down and unpack the problem with them. The system doesn't fix that for you — but at least it makes the moment visible, instead of burying it under a missed deadline that nobody wanted to admit was unrealistic from the start.

Over time, the junior's estimates get sharper. Not because they got faster, but because they learned to see more of the task before starting it. That's a skill hours-based estimation never teaches, because in hours-based estimation, the junior never gets to estimate at all.

What about the unknown?

Every estimation system breaks at the same place: how do you estimate something nobody has done before?

You don't. You spike it.

A spike is a timeboxed investigation. "Spend 4 hours figuring out if this is feasible, then come back." The output isn't an estimate — the output is enough understanding to estimate. And honestly, half the time the spike basically solves the problem, because the hard part wasn't the doing, it was the figuring out.

This is the part I think most teams miss. They try to estimate the unknown anyway, padding numbers "just in case", and end up with stories that are 80% mystery and 20% work. Spikes are the escape valve. Use them.

How to actually do this

If you're sold on the idea but wondering how it looks in practice, there's no single right answer. Here are a few techniques teams use — pick whichever fits your group's vibe:

Planning poker. Everyone on the team has a deck of cards with the values (3, 5, 8, 13, plus a "?" for "I have no idea, we need a spike"). Someone reads the task. Everyone picks a card face-down, then reveals at the same time. If the numbers diverge wildly, the highest and lowest explain their reasoning, and you re-vote. The simultaneous reveal is the whole point — it stops people from anchoring on whatever the most senior person said first.
T-shirt sizes. Same idea, but with S / M / L / XL instead of numbers. Useful for teams that find numbers feel falsely precise, or for early-stage estimation where you just want a rough bucket. You can always map sizes to points later if you need velocity tracking.
Affinity estimation. Print all the tasks on cards, lay them on a table, and have the team physically group them by relative complexity — "this feels about as hard as that one". Fast for large backlogs, and surprisingly accurate, because humans are much better at comparing than at measuring.

You can mix these. Some teams use affinity estimation for backlog grooming and planning poker for sprint refinement. Others just default to a quick t-shirt sizing in a 15-minute meeting and call it done.

The technique matters less than the conversation it produces. If your team is genuinely talking about the problem — surfacing risks, sharing context, learning from each other — the format is just scaffolding. Pick whatever scaffolding gets you there.

"But the business needs dates"

This is the objection that always comes up, and it's a fair one.

The answer is velocity. Track how many points your team actually completes per sprint over time. After a few sprints, you have a reasonable estimate. Multiply points-remaining by velocity and you have a date range.

I want to be honest, though: velocity isn't magic. It has real problems. It can be gamed by inflating points. It assumes a stable team — when people leave or join, it breaks. It works badly for highly exploratory work. And in the wrong hands it stops being a planning tool and becomes a productivity stick to beat people with.

But used carefully, it gives you something hour-based estimation never does: a system that gets more accurate over time instead of less. The curve is bumpy at first, and then it smooths out. With hours, the curve never smooths out, because the underlying signal was noise from the start.

When this doesn't apply

I'm not selling a silver bullet. Complexity-based estimation is overkill when:

Your team is 1–3 people and you all have the same context anyway
The work is repetitive (pure bug fixing, low-novelty maintenance)
You're in an early prototype phase where everything is changing every day

In those cases, hours — or no estimates at all — are probably fine. Don't impose ceremony where it doesn't earn its keep.

The honest summary

After years of doing this, I don't think estimating in complexity is more accurate than estimating in hours. Probably it isn't. But that was never the right question.

The right question is: what kind of conversation do you want your team to have?

When you estimate in hours, the conversation is individual and defensive. Whoever knows the most throws out a number, everyone nods, and the person with the least experience ends up trapped trying to hit a commitment they never had a real say in. Nobody learns. Nobody talks about the problem itself. Numbers just get distributed.

When you estimate in complexity, the conversation is about the problem. Why is this a 5 and not a 3. What's hiding inside it. What risks it carries. Juniors learn by watching seniors reason. Seniors sometimes realize the "trivial" thing wasn't trivial. The team understands what they're about to do — together — before they do it.

That's what hours don't give you, no matter how precise.

If your team estimates in hours and it works for you, great — keep going. But if you find yourselves fighting estimates that never land, devs burning out, and PMs disappointed sprint after sprint, maybe the hours aren't being measured wrong.

Maybe hours are just the wrong question.

What does estimation look like on your team? Do you fight with hours, swear by points, or have you found something else that works? I'd love to hear it in the comments.

Your team isn’t slow — your WIP is too high (Little’s Law explained)

Matías Denda — Wed, 06 May 2026 13:00:00 +0000

A team with 20 open PRs is mathematically slower than a team with 3.

Not “feels slower.” Not “probably slower.”

Is slower.

If your tickets take two weeks to cross the board while coding takes a few hours, the problem isn’t effort — it’s how much work your team keeps in flight at the same time.

And there’s a 65-year-old law that explains exactly why.

The equation

Little’s Law, proven by MIT professor John Little in 1961, applies to any stable flow system over a long enough interval.

Lead Time = WIP / Throughput

In plain English:

Lead Time — how long it takes for a ticket to go from started → merged → deployed
WIP — Work In Progress, the number of items currently in flight
Throughput — how many items your team completes per unit time (usually per week)

This is not a metaphor. It governs factories, airport security lines, and fast-food drive-throughs.

It also governs your Git workflow — whether you acknowledge it or not.

The example that breaks the illusion

Let’s run the numbers on a real team.

Priya’s team closes 10 PRs per week on average (measured over the last 8 weeks). At any given moment, they have 20 PRs open (in progress + in review).

Their lead time is:

20 WIP / 10 PRs per week = 2 weeks

That means every ticket entering the system today is guaranteed to take about two weeks to ship — even if the code itself takes 3 hours.

When someone asks:

“Why does this take two weeks if coding takes half a day?”

This is the answer.

The code is not slow.

The developers are not slow.

The queue is long.

The part that actually changes how you work

If throughput is roughly stable (your team works at a certain pace), then:

Lowering WIP lowers lead time proportionally.

Same team:

WIP 20 → 10 → lead time drops from 2 weeks to 1 week
WIP 20 → 6 → lead time drops to ~3 days

Nothing else changes.

No overtime.

No process overhaul.

Just finishing work before starting new work.

This is why WIP limits exist in Kanban — not as a constraint on developers, but as a way to shorten delivery time by physics.

“If I limit WIP, people will sit idle”

This is the most common objection — and it’s backwards.

A team with 10 open PRs is slower than a team with 3.

Why?

Context switching is expensive

Every open branch is cognitive load. Ten branches means ten partial states competing for attention.
Half-done work has zero value

A PR at 90% is still 0% delivered.
Waiting PRs are inventory, not progress

In manufacturing, inventory is waste. In software, a PR sitting in review for days is exactly that.

Limiting WIP forces a simple rule:

Finish something before starting something new.

That alone compresses your delivery timeline.

You can measure this from Git (no fancy tools needed)

You don’t need Jira dashboards or expensive analytics. You can get all three variables directly from Git.

Throughput — PRs merged per week

gh pr list --state merged --limit 200 \
  --json mergedAt \
  --jq '[.[] | .mergedAt | fromdate | strftime("%Y-W%V")] 
        | group_by(.) 
        | map({week: .[0], count: length})'

Average the last 8 weeks for a stable number.

WIP — what’s currently in flight

# PRs in review
gh pr list --state open | wc -l

# Branches not yet merged (likely in progress)
git fetch --prune
git branch -r --no-merged origin/main | wc -l

Add both — that’s your WIP.

Lead time — created → merged

gh pr list --state merged --limit 50 \
  --json number,createdAt,mergedAt \
  --jq '.[] | {n: .number, hours: (((.mergedAt|fromdate) - (.createdAt|fromdate))/3600|floor)}'

Don’t just look at the average — look at the spread. A few PRs taking 10+ days can dominate the system.

What to do with the numbers

Once you have all three:

If the equation matches your lead time → your system is stable. Lower WIP to go faster.
If your lead time is longer → you have bottlenecks (reviews, CI, environments). Fix those first.
If it’s shorter → you’re likely measuring WIP wrong or hiding variance.

If you’re leading a team and this number is higher than expected, you’re not alone — most teams never measure it.

A practical starting point for WIP limits

There’s no universal number, but these are solid defaults:

In Progress ≈ team size
In Review ≈ team size ÷ 2

Example (6 devs):

In Progress = 6
In Review = 3

From there, adjust slowly. Not weekly — quarterly. The signal takes time.

If lead time is too long:
Don’t add people — lower WIP.

When perception and math disagree

This is the uncomfortable part.

A team with:

WIP = 20
Throughput = 5/week

Has a 4-week lead time.

It doesn’t matter if individual PRs “feel fast.”

Users don’t feel individual PR speed.

They feel system lead time.

When the board says “we’re delivering” but the math says 4 weeks — the business experiences 4 weeks.

The takeaway

You don’t need a new process.

You don’t need better estimates.

You need a constraint:

Stop starting. Start finishing.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book covering Git the way it’s actually used in real engineering teams.

Little’s Law looks simple — until you apply it and realize your entire workflow is shaped by it. In the book, I go deeper into how this connects to branching strategies, PR flows, and why some teams get faster as they scale while others slow down.

I shipped a feature in a language I barely know — thanks to AI (and not for the reason you think)

Matías Denda — Thu, 30 Apr 2026 13:00:00 +0000

Last week, I built a small service in Go.

I don’t write Go.

I don’t know its idioms. I don’t have muscle memory for its syntax. I’ve never used it in production.

And yet, in a couple of hours, I had something working. Clean enough. Tested. Doing what it was supposed to do.

AI did most of the typing. That part isn’t surprising anymore.

What was surprising is that the bottleneck wasn’t the language.

It was me.

The part that feels like magic

If you haven’t tried this yet, it does feel like a superpower at first.

You describe what you want:

“Build a REST endpoint that processes X, stores Y, and returns Z.”

AI gives you:

project structure
handlers
models
tests
even some documentation

You iterate a bit:

“this should be async”
“add retries”
“separate this into a service layer”

And you end up with a working feature in a language you barely know.

No docs. No Stack Overflow. No long detours learning syntax.

It’s tempting to conclude:

“Languages don’t matter anymore.”

That’s not what’s happening.

What actually made it work

I didn’t know Go.

But I knew what I wanted the system to do.

I knew:

this endpoint shouldn’t block on external calls
this logic needed to be isolated from transport concerns
this data access pattern would become a bottleneck if left naive
this part would need caching if traffic increased
this failure mode needed explicit handling

None of that is Go.

That’s architecture. That’s design. That’s experience.

AI was just translating those decisions into code.

And that translation layer is exactly what AI is incredibly good at.

AI is a universal translator for code — not a substitute for thinking.

Where things start to break

Here’s the part that’s easy to ignore when everything is working.

I could build the service.

I couldn’t own it.

If something subtle went wrong, I wasn’t operating from intuition. I was guessing.

Is this idiomatic Go, or just something that compiles?
Is this memory-safe under load?
Is this concurrency model correct, or just “seems fine”?
Is the performance acceptable, or accidentally terrible?

When I write in a language I know well, those questions don’t feel like questions. They feel like constraints I naturally design around.

Here, they were blind spots.

AI helped me move fast. It didn’t remove those blind spots.

It just made them easier to miss.

The real shift

Before AI, learning a new language had a steep upfront cost.

You had to:

learn syntax
understand standard libraries
internalize patterns
build enough context to be productive

Now, that cost is dramatically lower.

You can get to “working code” almost immediately.

But something important didn’t change:

The quality of the system still depends on the quality of the decisions behind it.

AI removed the friction of writing code.

It did not remove the need to decide:

what code should exist
how components should interact
what trade-offs are acceptable
what will break at scale

That’s still on you.

What this enables (and what it doesn’t)

This is genuinely powerful.

It means:

you can explore new stacks without a huge upfront investment
you can prototype across ecosystems quickly
you can apply your knowledge in more places than before

But it does not mean:

you understand the language
you can debug deep issues
you can reason about edge cases confidently
you can make informed trade-offs inside that ecosystem

You can switch languages. You can’t switch fundamentals.

The uncomfortable implication

Two developers can now build the same feature in a language neither of them knows.

Both use AI. Both get working code.

The difference isn’t in how well they prompt.

It’s in what they know to care about.

One will ship something that works.

The other will ship something that keeps working.

From the outside, those look identical — at least at first.

What changed (and what didn’t)

AI didn’t make programming languages irrelevant.

It made them less of a bottleneck.

The bottleneck moved somewhere else:

system design
understanding trade-offs
anticipating failure modes
reviewing and validating code

In other words: fundamentals.

Not the kind you memorize.

The kind you only get by building, breaking, and fixing systems over time.

What I took away from this

Using AI in a language I barely know wasn’t impressive.

It was revealing.

It showed me very clearly what parts of my skillset are portable — and what parts aren’t.

Syntax? Portable.
Patterns? Mostly portable.
Judgment? Not portable. Earned.

And AI amplifies all three.

What I’ll write about next

This might look like AI is leveling the playing field.

It’s not.

If anything, it’s making the differences between developers harder to see — and more important.

Two people can now produce similar-looking code at similar speed.

That doesn’t mean they built the same system.

I’ll dig into that in the next post.

I write about Git and engineering practice for working developers. My book Git in Depth is 658 pages of the fundamentals AI assumes you already know.

If you're trying to build stronger foundations — not just ship faster — you can check it out here: https://mdenda.gumroad.com/l/git-in-depth

Your Kanban board is lying to you (and Git knows it)

Matías Denda — Wed, 29 Apr 2026 13:00:00 +0000

Look at your team's board right now.

How many tickets are in "In Review" that haven't been looked at in three days? How many are in "In QA" even though nobody's tested them? How many jumped straight from "In Progress" to "Done" without ever appearing in the intermediate columns?

If you're like most teams, the answer is "a lot." Your board is not reflecting reality. It's a fiction your team politely maintains.

Here's the uncomfortable truth: your Git repository knows the real state of every ticket. Your board just hasn't caught up.

This article is about bridging that gap.

The problem: columns designed by process people, not by engineers

Most boards are designed by someone who thinks about process, not about what actually happens in Git. That's why you end up with:

"Ready for Development" — a holding pen for tickets nobody wants to admit aren't ready. If it's prioritized and has detail, it's "To Do." If it doesn't, it's still "Backlog."
"Ready for QA" — this implies a manual handoff. If the code is merged and deployed to a place QA can access, it's in QA. The deployment is the handoff, not a ticket drag.
"Deployed" as a column separate from "Done" — if the code is in production and verified, it's done. If it's deployed but not verified, it's still in QA (in production). A column between them means nobody is verifying production deployments. These columns feel orderly on a wiki diagram. In practice, they're fiction. Tickets skip them. Developers lie about their state. The board drifts from reality.

The test: can someone verify the column from Git alone?

Here's the rule that cuts through all the noise:

Every column must correspond to a state that someone can verify, independently of anyone else's memory.

"In Progress" passes this test — is there a branch with commits? Verifiable.

"Code Review" passes — is there an open PR? Does it have an approving review? Verifiable via gh pr view or the hosting platform's API.

"Ready for Testing" fails — ready according to whom? Tested where? This is a human statement, not a Git state.

If a column can't be verified from the repo, one of two things is happening:

The column represents a task-flow state, not a code-flow state. That's fine — but it needs to be a lateral exit, not part of the main flow. "Blocked" and "Needs Spec" are valid columns, but they're paused states, not progression states.
The column is fiction. Remove it, or fix the process so it becomes real. ## Two dimensions that most boards collapse into one

The biggest insight I had while designing boards with teams: there are two independent dimensions of ticket state, and teams keep smashing them into a single horizontal flow.

Code-flow columns (left to right): To Do → In Progress → In Review → In QA → Done. These map directly to Git states.

Task-flow columns (lateral exits): Blocked, On Hold, Needs Spec, Waiting for Client. These don't map to Git at all — they reflect the state of the work, not the state of the code.

A ticket in "Blocked" still has a Git branch open. It hasn't moved backward in the flow — it's paused. When you separate these two dimensions, you prevent the common mistake of adding "Blocked" as a column between "In Progress" and "In Review," which breaks the flow and confuses everyone.

The reality: columns that get skipped

On paper, tickets move through every column. In practice, developers skip half of them.

Tickets jump from "In Progress" directly to "Done" — skipping "In Review" and "In QA" entirely. Why? Because the developer merged the PR, verified it themselves in production, and dragged the ticket in one motion.

This isn't laziness. It's the board not matching reality. If the team doesn't have a dedicated QA person or a staging environment, the "In QA" column is fiction. Tickets skip it because the state it represents doesn't exist.

The rule: if a column is consistently skipped, remove it or fix the process. Either add the missing step (a real QA phase, a real staging environment) or remove the column that pretends it exists. A board with skipped columns is a board that lies.

The solution: let Git move the tickets

The best boards are updated by Git events, not by humans dragging cards. Most tracking systems support this natively:

Opening a PR moves the ticket to "In Review" — automatically
Review approval can move it to "Approved" — automatically
Merging the PR moves it to "In QA" or "Done" — automatically
Tagging a release can move it to "Done" — automatically Here's a GitHub Actions workflow that moves a GitHub Projects card when a PR is opened or merged:

# .github/workflows/board-automation.yml
name: Board automation
on:
  pull_request:
    types: [opened, closed]

jobs:
  move-card:
    runs-on: ubuntu-latest
    steps:
      - name: Move to In Review when PR opens
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        with:
          script: |
            // Move the linked issue to "In Review" column
            // Uses GitHub Projects V2 API
            const query = `mutation($projectId: ID!, $itemId: ID!, $fieldId: ID!, $value: String!) {
              updateProjectV2ItemFieldValue(input: {
                projectId: $projectId, itemId: $itemId,
                fieldId: $fieldId,
                value: { singleSelectOptionId: $value }
              }) { projectV2Item { id } }
            }`;
            // projectId, fieldId, and optionId come from your project's
            // settings — query them once with the GraphQL explorer

      - name: Move to In QA when PR merges
        if: github.event.action == 'closed' && github.event.pull_request.merged
        uses: actions/github-script@v7
        with:
          script: |
            // Same mutation, different singleSelectOptionId
            // pointing to the "In QA" column

For Jira, it's even simpler — built-in automation rules handle this:

Rule 1: Trigger: Pull request created. Condition: Issue status is 'In Progress'. Action: Transition to 'In Review'.

Rule 2: Trigger: Pull request merged. Condition: Issue status is 'In Review'. Action: Transition to 'In QA'.

Linear, Shortcut, and Azure DevOps have similar integrations. The specifics differ, but the pattern is universal: Git event → webhook → board transition.

What you need to make this work

The automation is trivial. The discipline it requires is the hard part:

1. Branch names must include ticket IDs.

# Good — automation can match on this
git checkout -b feature/PROJ-247-search-filters

# Bad — automation has nothing to match
git checkout -b sam/search-thing

2. PR descriptions must reference the ticket.

gh pr create --title "feat(search): add filters" \
             --body "Closes PROJ-247"

3. Accept that some transitions stay manual.

"In Progress" is manual — and that's fine. When a developer picks up a ticket, they drag it and create a local branch. Nobody else knows about the branch until they push. Moving the ticket is faster than pushing a WIP commit just to trigger automation, and it avoids polluting Git history with empty commits.

The goal isn't 100% automation. The goal is that the board reflects reality, even when nobody has time to update it.

Reading the board from Git (when you don't trust the board)

Once you accept that Git is the source of truth, you can answer board questions without even looking at the board.

"What's actually in progress right now?" Remote branches ahead of main with no open PR:

git fetch --prune
for branch in $(git for-each-ref --format='%(refname:short)' refs/remotes/origin/ \
                | grep -v 'origin/main$' | grep -v 'origin/HEAD'); do
  ahead=$(git rev-list --count origin/main.."$branch" 2>/dev/null)
  [ "$ahead" -gt 0 ] || continue
  has_pr=$(gh pr list --head "${branch#origin/}" --state open --json number --jq 'length')
  [ "$has_pr" = "0" ] && echo "In Progress: $branch ($ahead commits ahead)"
done

"What's in review?" Open PRs — simplest query, most useful:

gh pr list --state open \
  --json number,title,author,reviewDecision,createdAt \
  --jq '.[] | "\(.number)\t\(.author.login)\t\(.reviewDecision // "PENDING")\t\(.title)"'

"What's merged but not deployed?" Commits on main since the last production tag — the invisible column most teams don't track:

# What's on main that hasn't been tagged yet?
git log --oneline $(git describe --tags --abbrev=0)..origin/main

# Extract ticket IDs — these are "done but undelivered"
git log --pretty=%s $(git describe --tags --abbrev=0)..origin/main \
  | grep -oE '[A-Z]+-[0-9]+' | sort -u

"What's actually in production right now?" Tickets referenced by commits reachable from the production tag:

CURRENT_PROD_TAG=$(git describe --tags --abbrev=0 --match 'v*')
git log --pretty=%s ${CURRENT_PROD_TAG} \
  | grep -oE '[A-Z]+-[0-9]+' | sort -u

Run these for a week. Compare against what the board shows. If they disagree, the board is lying — and now you have the data to fix either the board or the process.

The mindset shift

The board isn't the truth. It's a summary of the truth that drifts whenever someone forgets to drag a ticket.

Git is the truth. Every branch, every PR, every merge is a real event with a real timestamp. You can't forget to tell Git — it records everything automatically, as a side effect of doing the work.

Teams that embrace this get three wins:

The board starts matching reality (because Git drives it, not human memory)
"Where is this ticket?" gets one answer, not three
Standup meetings stop being ticket-hunting exercises and start being real conversations about blockers That's what a good board does. That's what yours could be doing, if you let Git update it.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book covering Git the way it's actually used in real engineering teams — including a full chapter on aligning board columns with Git states.

See all my articles on Git and engineering practice: dev.to/mdenda.

Hiding Data in Plain Sight: Building Anyhide in Rust

Matías Denda — Tue, 28 Apr 2026 14:00:00 +0000

This is the first post of a 6-part series where I unpack the design of Anyhide — a steganography tool I built in Rust. Each post tackles one feature, one decision, and the code behind it.

Classical steganography is simple: you take an image, flip the least-significant bits of some pixels, and smuggle your message inside. The image now carries a payload. You send the image. The recipient extracts the payload.

It works. It's also, in 2026, kind of a disaster.

LSB steganography is detectable by statistical analysis. Any carrier you modify is evidence. Any file you transmit is a file someone can analyze. If your threat model includes an adversary who can examine the files you send, then hiding data inside those files is exactly the wrong move.

So I spent the last few months building a steganography tool that works the other way around. The carrier is never modified. The carrier is never transmitted. What goes over the wire is a short encrypted code — a set of positions into a file both parties already have.

It's called Anyhide. It's written in Rust. The repo is here. This post is a walkthrough of the core idea.

The inversion

The mental model of classical steganography is "hide the payload in the carrier." The mental model of Anyhide is "hide the map to the payload in a shared reference."

SENDER                         RECEIVER

carrier.mp4 ──┐                      ┌── carrier.mp4
              │                      │   (same file, unchanged)
secret.zip ───┼──► ANYHIDE CODE ─────┼──► secret.zip
              │   (only this         │
passphrase ───┘    is sent)          └── passphrase

Both parties hold the same file — any file. A video, a PDF, an MP3, a PNG, a Linux kernel tarball. It doesn't matter. The file is never touched and never transmitted.

The sender encrypts their message and encodes it as a sequence of byte positions that reconstruct the ciphertext when read out of the shared carrier. Those positions, compressed and encrypted again, become the "Anyhide code" — a base64 string that fits in a tweet.

That string is all that travels.

Two things this gets you for free

Plausible deniability. The string on the wire looks like any other base64 blob. An adversary can't even tell there's a payload in the carrier, because the carrier isn't involved. There's nothing to analyze.

No forensic artifacts on the carrier. Traditional stego tools leave telltale statistical anomalies in the carrier — histograms that don't match natural images, file sizes that are off by exactly the right number of bits. Anyhide touches nothing. If law enforcement seizes your laptop and finds the MP4, they find an ordinary MP4.

The demo

Here's what the actual flow looks like on the command line.

# Both parties generate keypairs once
alice$ anyhide keygen -o alice
bob$   anyhide keygen -o bob

# They exchange public keys somehow — this is standard PKI
# Alice has bob.pub, Bob has alice.pub

# Alice hides a message using a shared carrier both of them have
alice$ anyhide encode \
  -c shared_video.mp4 \
  -m "meet at the usual place, 8pm" \
  -p "correcthorse" \
  --their-key bob.pub

# Output:
# AwNhYmMxMjM0NTY3ODkwYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXox... (~200 chars)

# Alice sends that string to Bob. Any channel. SMS, email, a napkin.
# Bob decodes using the same carrier + his private key + passphrase

bob$ anyhide decode \
  --code "AwNhYmMxMjM0..." \
  -c shared_video.mp4 \
  -p "correcthorse" \
  --my-key bob.key

# Output: meet at the usual place, 8pm

The shared_video.mp4 never moved. The passphrase never moved. Only that one base64 string moved.

If an adversary intercepts the string and doesn't have the carrier, they have nothing. If they have the carrier but not the passphrase, they have nothing. If they have everything but the wrong passphrase, they get deterministic garbage — not an error message. (More on that in Post 3.)

The Rust that makes it possible

At the heart of Anyhide is a small, clean abstraction: the Carrier enum. It's the kind of thing Rust lets you write that would be awkward in most languages.

// src/text/carrier.rs

pub enum Carrier {
    /// Text carrier - uses substring matching (case-insensitive)
    Text(CarrierSearch),
    /// Binary carrier - uses byte-sequence matching
    Binary(BinaryCarrierSearch),
}

impl Carrier {
    pub fn from_text(text: &str) -> Self {
        Carrier::Text(CarrierSearch::new(text))
    }

    pub fn from_bytes(data: Vec<u8>) -> Self {
        Carrier::Binary(BinaryCarrierSearch::new(data))
    }

    /// Detects carrier type from file extension and loads appropriately.
    pub fn from_file(path: &std::path::Path) -> std::io::Result<Self> {
        let extension = path.extension()
            .and_then(|e| e.to_str())
            .unwrap_or("")
            .to_lowercase();

        match extension.as_str() {
            "txt" | "md" | "text" | "csv" | "json" | "xml" | "html" | "htm" => {
                let content = std::fs::read_to_string(path)?;
                Ok(Carrier::from_text(&content))
            }
            _ => {
                let data = std::fs::read(path)?;
                Ok(Carrier::from_bytes(data))
            }
        }
    }
}

Two variants, one trait-like surface. Text carriers use substring matching (so you can hide a message by pointing at character positions in Shakespeare). Binary carriers use byte-sequence matching (so you can hide a message inside a raw MP4). The encoder and decoder don't care which one they got — they pattern-match on the enum and dispatch.

This is where Rust earns its keep. In a dynamic language I'd be doing runtime type checks and praying. Here the compiler forces every code path to handle both variants, and I can extend the enum later (a third Chunked variant for very large files is on my list) without touching any calling code.

What's under the hood

Internally, encoding a message goes through this pipeline:

message  →  compress (DEFLATE)
         →  sign (Ed25519, optional)
         →  symmetric encrypt (ChaCha20-Poly1305, key from HKDF(passphrase))
         →  asymmetric encrypt (X25519 ECDH + ChaCha20-Poly1305)
         →  find byte positions in carrier
         →  distribute positions via passphrase-seeded PRNG
         →  base64 encode
         →  ANYHIDE CODE

Every stage is there for a reason. The symmetric layer protects the positions even if you leak the long-term keys (the passphrase is a second factor). The asymmetric layer makes it end-to-end so only the intended recipient can decode. The position distribution means the same message encoded twice with the same keys and passphrase still produces different outputs.

The whole thing is ~16,300 lines of Rust. There are 319 tests and they all pass. I know because I just ran them:

$ cargo test
test result: ok. 260 passed; 0 failed  (unit)
test result: ok. 15 passed;  0 failed  (chat)
test result: ok. 43 passed;  0 failed  (integration)
test result: ok. 1 passed;   0 failed  (doctest)

What's coming in this series

This is Post 1 of 6. The roadmap:

This post — What Anyhide is and why the carrier-is-never-sent model matters.
Multi-carrier encoding — Using multiple carrier files together, where the order is itself a secret. N carriers → N! additional combinations for an adversary to brute-force.
Plausible deniability with duress passwords — How to encode two messages under two different passphrases. Under coercion, reveal the decoy. The real message stays hidden and is cryptographically indistinguishable from a wrong guess.
Forward secrecy and the Double Ratchet — Per-message key rotation, ephemeral keypairs, and the three storage formats I ended up supporting because chat has different needs than file transfer.
P2P chat over Tor — Building a chat client on top of arti-client (Rust's native Tor implementation), with hidden services as the transport and the Double Ratchet doing end-to-end encryption.
A multi-contact TUI with ratatui — The terminal UI: sidebar, tabs, a Doom-style command console, request/accept for incoming connections, and the UX work that goes into making cryptography usable.

Each post stands alone, and each one is grounded in the actual code — no hand-waving. If you want to skim the repo first, it lives at github.com/matutetandil/anyhide.

Post 2 drops in two weeks.

If you build privacy or security tooling in Rust, I'd love to hear what you're working on. If you think the "carrier is never sent" model is broken somewhere, I'd love to hear that too — drop a comment or open an issue on the repo.

SOLID isn't overrated, it's misapplied

Matías Denda — Mon, 27 Apr 2026 15:42:09 +0000

Another article about SOLID. Original, I know.

But I want to discuss something different from the usual letter-by-letter explanation: why entire ecosystems — Node.js, Kotlin/Android, parts of the Python world — treat SOLID as a relic of Java enterprise that's better avoided. And why I think that reading is wrong.

The problem isn't SOLID, it's the cargo cult

When someone says "SOLID is overrated," nine times out of ten, they're not attacking the principles. They're attacking the caricature: five layers of abstraction for a CRUD, an IUserRepositoryFactory that returns a UserRepositoryFactory that builds a UserRepository, interfaces declared "just in case we need them someday," dependency injection containers to resolve a pure function.

That's not SOLID. That's overengineering wearing SOLID vocabulary. The distinction matters because when you discard the principles along with their misapplication, you end up making the opposite mistakes: 2000-line files, classes that do seven things, and code that's impossible to test because business logic is coupled to the HTTP framework.

The cultural bias by language

This is where it gets interesting. The same principle — say, Single Responsibility — produces different reactions depending on the ecosystem, and that has less to do with the language itself than with the culture built around it.

Node.js / Express. Open any mid-sized Express project, and you'll likely find a routes.js with 800 lines mixing route definitions, validation, business logic, and database queries. It's not that SRP "doesn't apply" in JavaScript. It's that the "move fast" culture treats it as an unnecessary ceremony — until the file becomes unmaintainable and subtle bugs from inconsistently duplicated validation start appearing. A quick look at popular Express tutorials makes this pattern clear: many introduce route handlers with inline business logic and only mention separation of concerns as an advanced topic, if at all.

Kotlin / Android. Particularly interesting case. The language gives you data class, sealed classes, extension functions, top-level functions — tools tailor-made for SRP and ISP without Java's verbosity. And yet, "God ViewModels" — ViewModels mixing UI logic, network calls, DTO mapping, and caching — are common enough that Google's own architecture guide for Android explicitly warns against them and recommends splitting responsibilities into dedicated classes. The language enables doing it well; many tutorials and starter templates don't model that.

Go (positive contrast). Go is one of the few ecosystems where the culture embraces ISP and SRP as idiomatic, without anyone calling it "SOLID." The proverb "the bigger the interface, the weaker the abstraction" — attributed to Rob Pike — is ISP in another language. Single-purpose packages, small interfaces defined on the consumer side, composition over inheritance — all SOLID, no ceremony.

Idiomatic SOLID ≠ SOLID in Java

The central misunderstanding is assuming SOLID demands the format it was originally taught with: classes, explicit interfaces, and hierarchies. It doesn't.

SRP doesn't require one class per responsibility. It requires one reason to change. In TypeScript, that can be a pure function:

// This satisfies SRP perfectly
export function calculateShippingCost(order: Order, rates: ShippingRates): Money {
  // one responsibility, one reason to change
}

DIP doesn't require a DI container with XML config. A function parameter is already dependency inversion:

// The dependency is a parameter, not an import. That's DIP.
async function processPayment(
  order: Order,
  charge: (amount: Money) => Promise<Receipt>
): Promise<OrderResult> {
  const receipt = await charge(order.total);
  return { order, receipt };
}

OCP in Go looks like this, with no inheritance:

// Adding a new connector requires no changes to existing code.
// Just implement the interface.
type Connector interface {
    Execute(ctx context.Context, input []byte) ([]byte, error)
}

Three languages, three syntaxes, same principles. What changes is the implementation; what stays is the intent.

A heuristic

Before dismissing SOLID in your stack, ask yourself: Am I rejecting the principle, or a Java 2008 enterprise implementation that scarred me years ago?

If your routes file has 800 lines mixing five responsibilities, you're not being pragmatic. You're being disorganized and calling it pragmatism. If you have an AbstractFactoryBuilderStrategy to build a config object, you're not applying SOLID. You're cosplaying architecture.

The middle ground exists, and it's where most code that ages well lives: functions with one clear responsibility, explicit dependencies as parameters, small interfaces defined where they're consumed, and modules that do one thing.

That's SOLID. You don't have to call it that.

Git worktree: the stash replacement nobody teaches you

Matías Denda — Fri, 24 Apr 2026 13:00:00 +0000

The scenario every developer knows: you're deep in a feature, 15 files modified, half-working tests, and the production alert hits. You need to fix a bug on main, now.

The standard advice: git stash. Switch branches. Fix the bug. Come back. Unstash. Pray nothing conflicts.

There's a better way, and it's been in Git since 2015.

Meet `git worktree`

A Git worktree lets you check out multiple branches simultaneously, each in its own directory, sharing the same underlying .git repository. No stashing, no context switching, no rebuilding node_modules.

# You're in ~/work/app on feature/profile, deep in dirty changes
$ pwd
/Users/you/work/app
$ git status
On branch feature/profile
Changes not staged for commit:
    modified:   src/profile.js
    modified:   src/avatar.js
    (10 more files...)

# Production alert — open a worktree for the hotfix
$ git worktree add ../app-hotfix -b hotfix/payment-500 main
Preparing worktree (new branch 'hotfix/payment-500')
HEAD is now at a3f1d22 feat(profile): add avatar

# Switch terminal to the new directory
$ cd ../app-hotfix
$ git status
On branch hotfix/payment-500
nothing to commit, working tree clean

That's it. You now have two directories:

app/ — your feature work, untouched, 15 dirty files exactly where you left them
app-hotfix/ — a clean checkout of main in its own folder

Fix the bug in app-hotfix/, commit, push, open the PR. When the hotfix merges, remove the worktree:

$ git worktree remove ../app-hotfix

The branch lives on (on the remote). The extra directory is gone.

Why this beats stash

Stash works for small, short interruptions. But it has real problems:

Stash assumes you can only run one environment at a time. With a worktree, you have two node_modules/, two running npm run dev processes, two build caches. No conflict, no rebuild.

Stash is fragile. git stash pop with a conflict can leave your working tree in a mess. A worktree is just a checkout — nothing special can go wrong.

Stash is invisible. Three days later, did you git stash pop? Did you have two stashes? Which one was which? Worktrees are directories — you can see them, ls them, run them side by side.

The other big use case: reviewing PRs

If you review a lot of PRs, you know the pain: to test someone else's branch locally you have to stash your work, check out their branch, run it, switch back, re-stash, re-rebuild.

With worktrees:

$ git worktree add ../app-review origin/coworker-branch
$ cd ../app-review
$ npm install && npm run dev
# Poke around, test, review, come back to your own work untouched

Useful commands

# List all active worktrees
$ git worktree list
/Users/you/work/app           a3f1d22 [feature/profile]
/Users/you/work/app-hotfix    7e4b9c1 [hotfix/payment-500]

# Add a worktree tracking an existing branch
$ git worktree add ../app-qa qa-branch

# Remove a worktree (the branch stays)
$ git worktree remove ../app-qa

# If you deleted the directory manually, clean up the reference
$ git worktree prune

When NOT to use worktree

Stash is still the right tool when:

The interruption takes 5 minutes and you don't need to run anything
You're on a disk-constrained machine (each worktree is a full checkout)
Your build system assumes a single working directory (some old monorepo tooling has trouble)

The one gotcha

You can't have the same branch checked out in two worktrees at once. If you try, Git refuses. This is a feature, not a bug — it prevents you from committing to the same branch from two places and creating a mess. If you need the same branch twice (to compare states, for example), check out a detached HEAD in the second worktree instead:

$ git worktree add --detach ../app-compare main

Make it a habit

I have three muscle memories now:

5-minute interruption, nothing to run → stash
Longer interruption, different branch, needs full env → worktree
Reviewing a PR locally → always worktree

After a year of doing this, I almost never stash anymore. And I never panic when production pages me while I'm mid-feature.

This post is adapted from Git in Depth: From Solo Developer to Engineering Teams, a 658-page book covering Git the way it's actually used in real engineering teams — from day-to-day commands to CI/CD, branching strategies, methodology alignment, and Git at organizational scale.

What cave diving taught me about distributed systems

Matías Denda — Thu, 23 Apr 2026 16:32:38 +0000

What cave diving taught me about distributed systems

I've been building backend systems for 14 years. I've also spent a decent chunk of the last decade underwater, mostly in caves.

At some point I stopped being surprised by how often the two worlds rhyme. The deeper you go into either, the more you notice the same ideas showing up in different costumes. Here are a few that stuck with me.

You plan the dive, then you dive the plan

In open water, if something goes wrong, you go up. That's it. The surface is always there, a few kicks away, a guaranteed exit.

In a cave, there is no "up". There's a ceiling, and between you and air there's sometimes hundreds of meters of rock and a specific path you came in through. If something goes wrong at the end of a one-hour penetration, the solution is still one hour of swimming away — and you're the one who has to swim it, with whatever gas, light, and composure you have left.

So technical divers plan everything before getting in the water. Gas volumes for every phase, with reserves for the worst case and the worst case after that. Turn points. Decompression schedules. Equipment failures and who does what when they happen. Team positions, signals, lost-diver procedures. Murphy's law isn't a joke in this context — it's a design input.

The rule is: plan the dive, dive the plan. You don't improvise
underwater. You execute what you already decided on land, when your
brain had oxygen and no time pressure.

Software has the same trap, and most teams fall into it. "We'll figure it out in production" is the engineering equivalent of "we'll figure it out at 80 meters." Sometimes you get lucky. Often you don't.

The work that matters — capacity planning, failure mode analysis,
runbooks, rollback procedures, on-call rotations, dependency mapping — happens before the system is under load. Before the incident. Before anyone is stressed. Because the incident is not the time to start thinking. It's time to execute what you already thought through.

And just like diving, the planning doesn't eliminate failure. It just makes sure that when failure shows up, you've already met it on paper.

Failures cascade. Plan for the second failure, not the first.

The thing that kills divers isn't usually the first problem. It's the panic reaction to the first problem that causes the second one — and the second one is the one you weren't ready for.

Same in distributed systems. The database slowdown isn't what takes you down. It's the retry storm from 400 service instances hammering the recovering database that takes you down.

Good divers train for compound failures: light out and low on gas, lost line and silted visibility. Good systems are designed for compound failures too: circuit breakers, exponential backoff with jitter, bulkheads, and graceful degradation. Not because the first failure is rare, but because the second one, triggered by your response to the first, is where the real damage happens.

Turn pressure is a circuit breaker

Before a cave dive, you calculate your "turn pressure" — the tank pressure at which you stop going in and start coming out, regardless of how close you are to the thing you wanted to see. It's non-negotiable. You don't get to feel your way through it.

Circuit breakers work the same way. You pick a threshold in advance, when you're calm and have a clear head. And when the threshold trips, the system doesn't get to argue with it. It just turns around.

The hardest part of both is the same: accepting the limit you set for yourself when you were thinking clearly, even when the situation makes you want to push past it.

Checklists feel stupid until they save you

Every cave diver I respect uses a pre-dive checklist. Not because they forget things — but because under stress, everyone forgets things. The checklist is what your past, calm self leaves behind to protect your future, stressed self.

Runbooks are the same. The incident is not the time to remember the command. The deployment at 2 am is not the time to improvise the rollback procedure. Write it down when it's quiet. Read it when it's loud.

The real lesson

Both disciplines teach you the same uncomfortable thing: most disasters are built in advance, by people who assumed the happy path was the only path.

The habits that keep you alive in a cave are the same ones that keep systems running at 3 am on a Saturday. Redundancy, calm limits, planning for the compound failure, trusting your past self's checklist over your present self's instincts.

The costume is different. The physics of failure is the same.

If you're into either distributed systems or cave diving, I'd love to hear what overlaps you've noticed. Always surprising how many fields converge on the same answers.

One TUI for RabbitMQ, Kafka, and MQTT: why I built queuepeek

Matías Denda — Wed, 22 Apr 2026 13:00:00 +0000

The problem I was trying to solve

I work across a few projects that all talk to message brokers, but never the same one. Some services are on RabbitMQ. The data pipeline runs on Kafka. A handful of IoT integrations use MQTT. Normal stuff.

What wasn't normal was the amount of context-switching every time something went wrong in production. Three different web UIs, three different mental models, three different ways to peek at a message without accidentally consuming it.

The RabbitMQ Management UI is fine, but it's a web app — and half the time I'm already in a terminal next to the logs. Kafka UIs are a whole can of worms (every company seems to use a different one). MQTT doesn't really have a good "just let me see what's retained on this topic" tool for free.

So after one too many incidents where I wanted to diff two DLQ messages and ended up pasting JSON into an online diff tool, I started building what became queuepeek.

What it is

queuepeek is a terminal UI written in Rust (on top of ratatui) that speaks RabbitMQ, Kafka, and MQTT from the same interface. You launch it, pick a profile, drill down through queues/topics, and land on individual messages.

The entire thing is keyboard-driven and follows the same wizard flow regardless of the broker:

Profiles -> Queues/Topics -> Messages -> Message Detail

Esc always pops one level up. / always filters. ? always shows help contextual to where you are and which broker you're on.

No mouse. No tabs. No switching apps.

Design choices that paid off

Non-destructive peek

This was the whole point. A "queue inspector" that consumes messages while you're reading them is not an inspector — it's a silent bug waiting to happen.

For RabbitMQ, queuepeek uses the Management HTTP API's get endpoint with ack_requeue_true. You read, the message stays.
For Kafka, every read session spins up an ephemeral consumer with a unique group ID. You're not stealing offsets from anyone.
For MQTT, you're subscribing to a topic so it's inherently non-mutating, but retained message management has its own explicit screen with a clear "this will clear the retained payload" confirmation.

Sounds basic. A surprising number of tools don't do this.

Same keybindings, different brokers

Kafka doesn't have queues, it has topics. RabbitMQ has exchanges and bindings. MQTT has topic hierarchies. Under the hood these are very different beasts, but from the user's point of view, "show me what's in here" should feel the same.

The footer at the bottom of every screen dynamically filters shortcuts to the backend you're connected to — G:groups only shows on Kafka, X:topology only on RabbitMQ, H:retained only on MQTT. No dead keys, no "this doesn't work on your broker" errors.

Multi-select bulk ops

Checkboxes in a TUI sound fiddly, but they turned out to be one of the most useful features. Space toggles selection on the current message, then any operation you trigger (delete, copy, move, export) applies to all selected messages — streamed, not loaded into memory.

Want to delete 10,000 messages from a DLQ after confirming none of them match a pattern you care about? Filter, select all, delete. Done from the keyboard.

A few features I'm particularly happy with

Side-by-side message diff. Select two messages, press d, get a colored diff. Uses the similar crate. Embarrassingly useful for "why does this one message fail and the other succeed?"

Schema Registry integration. If you configure a Confluent-compatible Schema Registry URL, queuepeek auto-decodes Avro and raw Protobuf payloads using the Confluent wire format (magic byte 0x00 + 4-byte schema ID + body). Toggle raw/decoded with
s.

Real concurrent benchmarking. Press F5 on a queue to run a flood-publish benchmark with N worker threads (via std::thread::scope), rendering a live gauge and p50/p95/p99 latency percentiles at the end. Useful for capacity-planning conversations
that usually start with "how fast can this queue take?"

Webhook alerts. Configure a regex pattern in config.toml, point it at a webhook URL, and queuepeek polls every 30 seconds and POSTs on match (deduplicated by message hash so you don't spam yourself). Good for catching a specific error pattern appearing in a queue before it becomes an incident.

Payload templates with interpolation. Ctrl+T to save the current message, Ctrl+W to insert it. Supports variables like {{timestamp}}, {{uuid}}, {{random_int}}, {{counter}}, and {{env.VAR}} for anything you export in your shell.

DLQ reroute. RabbitMQ x-death headers get parsed and displayed, and L re-routes a message back to its original exchange. Mostly because I got tired of manually copy-pasting routing keys out of x-death.

Interesting implementation bits

A few things that weren't obvious going in:

ratatui + crossterm + mpsc channels is all you need for a responsive TUI. Background I/O (broker calls, file operations, webhook polling) runs in std::thread workers and posts results back through a channel that the event loop drains each tick.
No async runtime, no Tokio. The whole app feels instant.
Auto-refresh is dumb and works. Queue list refreshes every 5 seconds, message list every time tail mode is on. No WebSockets, no push. The Management API is cheap enough that polling is fine.
Scheduled messages persist to disk. ~/.config/queuepeek/scheduled.json with epoch seconds. If you schedule a publish and the app crashes or you close it, the schedule survives.
79 unit tests across filters, comparison, operations, schema decoding, and config. TUI logic is hard to test end-to-end, but the pure functions underneath are easy.

Try it

# From crates.io (needs cmake for librdkafka)
cargo install queuepeek

Or grab a prebuilt binary: https://github.com/matutetandil/queuepeek/releases

Supported platforms: macOS (ARM/Intel), Linux (x86), Windows (x86/ARM). Linux ARM builds need cargo install because cross-compiling librdkafka is its own adventure.

Minimal ~/.config/queuepeek/config.toml:

[profiles.local]
type     = "rabbitmq"
host     = "localhost"
port     = 15672
username = "guest"
password = "guest"
vhost    = "/"

Repo: https://github.com/matutetandil/queuepeek

Docs: /docs folder covers configuration, keyboard shortcuts, backends, and architecture.

What I'd love feedback on

It's a solo side project and I'm the main user. That means the keybindings reflect my own muscle memory, the defaults reflect my own workflows, and the rough edges are the ones I don't personally bump into.

If you spend time in any of these brokers and something feels off — a missing shortcut, a feature you'd expect, a decoding format I'm not handling — please open an issue. Especially on MQTT, which I use least.

MIT licensed. No telemetry. No signup. Just a binary that reads queues.

What actually happens when you `git merge --no-ff`

Matías Denda — Tue, 21 Apr 2026 14:48:28 +0000

Most developers use git merge without ever thinking about what's happening internally. Then one day they see --no-ff in a team's workflow documentation, Google it, read three Stack Overflow answers, and walk away with a vague sense that "it creates a merge commit or something."

This post is the version I wish I'd read earlier. Two diagrams, one clear distinction, and why it actually matters for your team.

The setup

You're on main. Your coworker merged their feature. You branched off, added two commits, and now it's time to merge your branch back. What happens next depends on one flag.

# You're here
git checkout main
git merge feature

Git has two ways to integrate your feature branch into main. The one it picks by default depends on whether the branches have diverged.

Case 1: Fast-forward (the default, when possible)

If main hasn't moved since you branched off, Git doesn't create a new commit. It just moves the main pointer forward to the tip of your feature branch.

That's it. No merge commit. The feature branch and main now point to the same commit. If you look at git log on main, it reads like D and E were always there. The branch effectively disappears from history.

Case 2: `--no-ff` (always create a merge commit)

With --no-ff, Git creates an explicit merge commit even when a fast-forward was possible:

M is a new commit whose parents are C (the previous tip of main) and E (the tip of feature). It has no code changes of its own — its diff is empty — but it records that these commits were integrated together at this point.

Why this distinction matters

The two histories above contain the same code. So does it matter? Yes, and here's where it bites real teams.

It matters for `git bisect`

git bisect helps you find which commit introduced a bug by doing a binary search through history. With fast-forward merges, the search descends into individual feature commits — you might land on a half-finished refactor where the bug is genuinely present but so is a broken test, making the bisect useless.

With --no-ff, you can run git bisect --first-parent and bisect merge commits only, treating each feature as an atomic unit. Found the regression? You know which feature to revert, not which arbitrary mid-feature commit to blame.

It matters for `git revert`

If you merged with --no-ff and need to roll back the feature, you revert the single merge commit:

git revert -m 1 <merge-commit-hash>

That undoes all of D and E in one go. With fast-forward, you'd need to revert each commit individually — or figure out which commits belonged to the feature in the first place.

It matters for reading history

git log --graph --first-parent main with --no-ff merges shows you a clean list of features integrated into main, one per line. Without merge commits, the log is a flat stream of every individual commit ever made. For a large team, the difference is between "I can see what shipped last week" and "good luck."

What GitHub and GitLab do

When you click "Merge pull request" on GitHub or GitLab, they default to creating a merge commit (--no-ff behavior). The "Rebase and merge" and "Squash and merge" options exist too, but the default merge commit exists precisely because of the benefits above.

This is why teams that use the GitHub/GitLab UI religiously often have cleaner history than teams that merge locally on the command line — the UI forces a pattern that the command line leaves optional.

When fast-forward is fine

For throwaway branches, personal experiments, or single-commit fixes where the commit already tells the whole story, fast-forward is perfectly appropriate. The rule of thumb I use:

Single commit fix → fast-forward is fine
Feature branch with 2+ commits → --no-ff preserves the grouping
Release branch merge → always --no-ff
Hotfix branch merge → always --no-ff (you want revertability)

Making it a team default

If you want the team to use --no-ff consistently, either set it at the repo level:

git config --global merge.ff false

Or — better — require it via branch protection rules on your hosting platform. That way nobody's local config can bypass it.

This post is adapted from a chapter of Git in Depth: From Solo Developer to Engineering Teams, a 658-page book I just released on Git for working developers — from day-to-day tools to CI/CD, branching strategies, and Git at organizational scale. Launch price $29 with code EARLYBIRD (first 100 copies).

Next week: git worktree — the stash replacement nobody teaches you.