The Last Layer Standing

Wed, 24 Jun 2026 00:00:00 +0000

“It is unsinkable. God himself could not sink this ship.”
— Cal Hockley, Titanic (1997)

After more than two decades in software, I’m probably closer to the end of my career than the beginning.

Lately I keep wondering what software will even look like by then. AI has already changed everything, and it’s only getting started. So what comes after?

When I want to imagine the future, I look at my past. I’ve been doing this long enough to have watched the industry tear itself down and rebuild from scratch more than once. The details change every time. The pattern doesn’t. Every era is certain its dominant platform is unsinkable, and every era has been wrong.

The industry never sits still

When I started writing code, the internet didn’t exist yet, not for most of us, anyway. The industry ran on desktop software: office suites, productivity tools, business systems, ERPs, CRMs. You shipped on floppies and CDs, and a “deploy” meant someone installing it by hand.

And then came the internet. Everything changed. The client-server model, a new programming paradigm, a new kind of usability, an entire category of problems nobody had solved yet. But the same internet that broke everything also connected us: suddenly we could share ideas, read each other’s articles, steal each other’s tricks, and ask strangers for help. We learned faster because we learned together.

Then infrastructure became the bottleneck. Running software meant buying racks of expensive hardware and hiring a dedicated team to babysit it. It was slow, it was costly, and it didn’t scale.

And then came AWS. Everything changed again. Almost overnight, owning hardware stopped being an advantage and started to look like a liability. A small team could suddenly rent world-class infrastructure for pocket change, and a whole class of scalability problems vanished behind a single click.

And then came the SaaS economy. Why build authentication, payments, search, or messaging yourself when you could rent each one and wire them together in an afternoon? Whole categories of software that used to take a team a year shrank to a few lines of integration and a monthly invoice. Building started to look less like engineering from scratch and more like assembling parts someone else maintained.

Notice the rhythm. Every decade or so, something arrives that resets the board. Each time, the skills that felt essential become optional, and the ones that felt optional become survival.

And then came AI

Before, learning to do something new took weeks. You picked up a new language or framework, read a mountain of documentation, fumbled through examples, broke things, fixed them, and two or three weeks later you had that fancy integration working. Today I describe it in a paragraph and have a working draft in thirty minutes.

That speed-up isn’t a one-off. It shows up everywhere:

A CRUD app that used to need a team of five (backend, frontend, database, a little DevOps, someone to glue it all together) can now be scaffolded by one person in an afternoon.
Boilerplate that took a day writes itself in seconds: models, migrations, endpoints, forms, validation, tests.
The documentation safari (twelve browser tabs and a pilgrimage to Stack Overflow) collapses into a single question.
Translating a service from one language to another, generating tests for legacy code, drafting the first version of a CI/CD pipeline: all of it, faster and cheaper than ever.

The economics are simply different now. Work that justified a team and a quarter can be done by one experienced person in a sprint.

Software is becoming a commodity

Follow the trend to its end and the conclusion is uncomfortable but hard to dodge: the production of code can be almost entirely automated. Not assisted — automated. Be precise about what that means, though: it’s the writing of code that gets automated, not the deciding of what to write. Each wave so far abstracted away a layer we used to sweat over, and the last layer standing is the code itself.

We’re already partway there. A non-technical person can ship a real feature just by describing what they want, but only because a developer built the machine that makes it possible: the architecture, the infrastructure, the security model, the guardrails. Someone defined the rules of the game so others could play it without knowing them. Soon even that layer gets abstracted away. The same way AWS turned hardware into something you rent by the minute, building software becomes a feature of a platform: you describe the rules, and it writes, tests, and runs the code underneath. If that sounds far-fetched, remember that “rent a supercomputer with a credit card” sounded far-fetched too.

And the early versions already exist. Cursor, Replit, Lovable, v0, Claude Code: these are crude, first-generation sketches of that platform, and they’re improving faster than anything I’ve watched in twenty years. They already scaffold a working app, wire up a database, and fix their own errors from a plain-English prompt; the things they still get wrong are shrinking release by release, not decade by decade. Each iteration eats a little more of the work that used to require someone who knew the syntax by heart. Extrapolate that curve (not to magic, just to “considerably better than today”) and a platform that writes, tests, and runs its own code stops reading like science fiction and starts reading like the next obvious thing to rent.

And no company gets to sit this one out. Every one of those waves left bodies on the path: outfits that owned their era and were too comfortable, too slow, or too afraid to follow it into the next. Borland owned developer tools and dissolved into a footnote; Kodak invented the digital camera and then buried it. The rule never changes: when the ground moves, you move with it or you become history. This wave won’t spare anyone who stands still either.

So, are developers history?

That’s the companies. But what about us, the people who actually write the software? If building really can be automated, is the developer, as we know the role, about to become history?

The code-typist version of the job is. The person whose value was mostly turning tickets into syntax is in for a hard decade. That part of the work is exactly what the machine is best at.

But “developer” was never really about typing. The new developer is the person who uses creativity, judgment, and tools (AI included) to create value and solve real problems. Does that person need to be deeply technical? Well… it depends (says the senior developer).

Because here’s the thing the hype skips: there is an ocean of legacy out there. Gigantic codebases, decades old, quietly running the world’s banks, hospitals, logistics, and governments. Nobody is going to throw all of that away and migrate to some shiny describe-it-and-it-appears platform. Some of them can’t. When the software is the business, you don’t get to start over.

Those systems need people who actually understand them: experienced, technical, stubborn people who can read a mess, hold the whole thing in their head, and make the call.

So no, skilled people don’t disappear. The seats reserved for genuinely capable professionals are never empty, because businesses still need humans to run them. What disappears is the comfortable middle: the role that was only ever about producing code.

There’s a catch I won’t gloss over, though. That comfortable middle was also the path in: the rung where juniors used to climb from turning tickets into syntax up to making real calls. Automate the bottom of the ladder and you have to ask how anyone is supposed to reach the top of it. I don’t have a clean answer. The honest version is that the way in gets narrower and steeper: the people who make it will be the ones who jump straight to judgment instead of spending years earning it one ticket at a time. Pretending the senior seats stay full without asking who gets to fill them would be dishonest.

What AI still can’t do

It’s worth being concrete about why those seats stay filled. For all its speed, AI still can’t do the things the job actually rewards.

It doesn’t know what to build. Hand it a vague, contradictory, half-formed idea (which is what real requirements always are) and it can’t tell you which parts matter, which are wrong, and which the stakeholder forgot to mention. That’s still a human problem.

It doesn’t understand why. It has no model of your business, your customers, your constraints, or the three years of decisions that explain why the code looks the way it does. It optimizes the question you asked, not the one you should have asked.

It drowns in real legacy. A clean greenfield CRUD is one thing. A fifteen-year-old codebase full of implicit rules, undocumented quirks, and load-bearing hacks is another. AI will confidently “fix” something and quietly break three things you didn’t know were connected.

It produces plausible-but-wrong code. The output always looks right. Telling the difference between code that works and code that merely compiles still takes someone who actually understands the system. That someone is you.

And it doesn’t carry responsibility. When the deploy takes down production at 2 a.m., the AI doesn’t get paged. It doesn’t make trade-offs it can be held to, doesn’t navigate the politics of a reorg, doesn’t decide what risk is acceptable. Accountability has no API.

This is the gap. And it’s exactly where the value moved.

The last layer

Strip away the specifics, and the second half comes down to four things I try not to forget, and what each one means for what I’m actually going to do over the next ten or fifteen years.

AI is a tool. A genuinely powerful one, but a tool, in the same lineage as the compiler, the cloud, and the framework. It’s the next chapter, not the last word. So I won’t fight the tide. I’ll surf it. I intend to use AI harder than anyone around me, mastering it the way I once mastered the compiler and the cloud, until it’s an extension of my hands and I’m the one shipping what used to take five.

Tools exist so that someone can make something. Nobody remembers the hammer; they remember the house. The value lived in what you built and the problem you solved, never in the instrument. So I’ll stay glued to the outcome, not the code: closer to the business, the customer, and the money, the context no model can infer from a ticket. Whoever understands the problem best is the last to be automated away.

Every tool has to be mastered. The developers who thrived through each shift weren’t the ones with the most to protect; they were the ones who learned the new thing fastest. The ones who refused, who insisted the old way was the only real way, became the bodies on the path. So I’ll move up the stack deliberately, putting my hours where AI is weakest: architecture, system design, the trade-offs and the calls that carry consequences. Deciding what to build and why is the job now; the how is becoming a prompt.

Read the signals and adapt. Watch the environment. Notice what’s becoming a commodity and move before the floor you’re standing on disappears. Clean greenfield is the first thing to go, so I’ll go the other way: toward the gnarly legacy, the mission-critical, the can’t-just-restart-it systems where someone has to understand the whole machine and answer for it when it breaks. Relevance isn’t a position you hold; it’s something you keep earning.

None of this is guaranteed. Nothing is, anymore. But a plan beats hoping the tornado skips your house. “God himself could not sink this ship,” they said, and every unsinkable ship belongs to someone who stopped watching the water. Borland was unsinkable once. So was Kodak.

I’ve watched this industry demolish and rebuild itself several times now, and the lesson is always the same. The technology that arrives isn’t what kills you. Standing still is. Each wave abstracts away another layer, and one day it will come for the code itself, but the last layer standing was never the code. It’s the person who knows what to build, why it matters, and who answers for it when it breaks. That layer is you.

I’ve had to reinvent how I work every decade. Here we go again.

How to not destroy your production database

Fri, 12 Jun 2026 00:00:00 +0000

“Data is a precious thing and will last longer than the systems themselves.”
— Tim Berners-Lee

TL;DR

Keep data changes out of migration files. Make every data script idempotent, batched, and dry-run by default — and never trust an ALTER you haven’t read. A bad deploy can be reverted; an UPDATE without a WHERE clause cannot.

Over the years I’ve collected a fair share of scars — what worked, what didn’t, and the mistakes that were entirely avoidable. What follows are the practices that came out of them: the kind that keep you from being paged at 3 a.m. or frantically restoring a database backup while production is on fire.

The rules below are stack-agnostic. The examples use plain SQL (MySQL/PostgreSQL flavors noted where they differ) and pseudocode — adapt the syntax to your framework, keep the rules.

Keep migrations schema-only

Migration files exist to evolve the schema. They must not contain INSERT, UPDATE, DELETE, backfills or seeding of reference rows. This is the anti-pattern:

-- migration: add_status_to_orders
ALTER TABLE orders ADD COLUMN status VARCHAR(20) NULL;

-- BAD: data change smuggled into a schema migration
UPDATE orders SET status = 'pending' WHERE status IS NULL;

Looks harmless, works fine in development, and fails in production in several independent ways:

Your migration may not run where you think it does. Branching platforms (PlanetScale, for example) apply schema changes on an isolated copy and merge only the schema back — data written by the migration is silently lost.
It couples a slow operation to a fast one. A backfill over millions of rows can take hours, hold locks, stall replication, or get killed by the pipeline’s timeout halfway through.
A failure mid-data-step corrupts your migration state. MySQL implicitly commits around DDL, so the ALTER can’t be rolled back when the UPDATE dies. PostgreSQL’s DDL is transactional — but only if your migration tool actually wraps the migration in one, and a long backfill should never live inside one transaction anyway.
It can’t be batched, throttled, resumed or dry-run. All the safety tooling from the next two sections is unavailable inside a migration file.

The correct shape is a three-step pattern you’ll see again in this post: add nullable → backfill via script → tighten.

-- migration 1: schema only
ALTER TABLE orders ADD COLUMN status VARCHAR(20) NULL;

-- data change: separate idempotent script (next section)

-- migration 2, days later, after the backfill is verified:
ALTER TABLE orders MODIFY COLUMN status VARCHAR(20) NOT NULL DEFAULT 'pending';  -- MySQL

The column DEFAULT handles new rows from the moment the schema lands; the backfill handles existing rows; the tightening migration runs only when both are true.

And no, lookup tables (countries, roles, currencies) are not an exception. Seeders handle fresh environments; a one-time idempotent script introduces them into existing ones. Both are versioned code; neither lives inside a migration.

Make data changes idempotent, rerunnable scripts

Any change to data — backfill, correction, deletion — is a standalone command in your framework’s task runner, versioned in the repo and code-reviewed like everything else. Two things, no exceptions:

It must be safe to run twice

Retries, partial failures and overlapping executions happen. Pick an idempotency mechanism and test the re-run: execute it twice in staging; the second run must change zero rows.

Naturally idempotent predicates — the WHERE selects only un-migrated rows, so each run processes the remainder:

UPDATE orders SET status = 'pending' WHERE status IS NULL;

Upserts for inserting reference rows (requires a unique key on the natural identifier):

-- PostgreSQL
INSERT INTO roles (key, name) VALUES ('auditor', 'Auditor')
ON CONFLICT (key) DO UPDATE SET name = EXCLUDED.name;

-- MySQL 8.0.19+
INSERT INTO roles (`key`, name) VALUES ('auditor', 'Auditor') AS new
ON DUPLICATE KEY UPDATE name = new.name;

An execution ledger for scripts whose effect can’t be detected from the data itself: a tiny table recording which named scripts already ran; the script checks it and exits early.

It must be batched

A single UPDATE over millions of rows holds locks for the full duration, bloats the undo log and stalls replicas. Process in batches over an indexed key:

BATCH = 1000
last_id = checkpoint.load() or 0

loop:
    ids = sql("SELECT id FROM orders
               WHERE id > :last_id AND status IS NULL
               ORDER BY id LIMIT :batch", last_id, BATCH)
    if ids is empty: break

    within transaction:
        sql("UPDATE orders SET status = 'pending'
             WHERE id IN (:ids)
               AND status IS NULL", ids)   # repeat the predicate on the write!

    last_id = max(ids)
    checkpoint.save(last_id)               # crash here → resume, not restart
    progress.log(last_id, rows=len(ids))
    sleep(throttle)

Why each piece matters:

Repeat the predicate on the write. Live traffic may have set a row to 'paid' between your SELECT and your UPDATE — without AND status IS NULL on the write, you clobber it back.
Keyset pagination, never OFFSET. OFFSET re-scans skipped rows on every batch and skips or repeats rows when the data shifts underneath it — which is exactly what a backfill does.
One transaction per batch. A multi-hour transaction is an outage waiting for a deadlock.
Checkpoint, throttle, log progress. A crash at row 4,000,000 resumes instead of restarting; replicas keep up; “is it stuck?” becomes a glance instead of a guess.

Run it manually, per environment, after the schema migration has landed — on purpose, watching it run. Never as a hidden deploy side effect.

Default to dry-run

Every script that deletes or bulk-modifies data supports a dry-run mode — and dry-run is the default. Mutation requires an explicit opt-in:

purge_abandoned_carts [--execute] [--max-affected=N]

  affected = count rows matching the predicate
  print("would delete {affected} rows; sample:")
  print(first 10 matching rows)

  if not --execute:
      print("DRY RUN — re-run with --execute to apply"); exit

  if affected > --max-affected (default 50k):
      abort("affected rows exceed safety ceiling")

  ... batched deletion as in the previous section ...

Safe by default. The flag enables danger (--execute), never disables it. Forgetting a flag should always land you on the safe side.
Counts AND a sample. The count tells you the magnitude; ten concrete rows tell you whether the predicate selects what you believe it selects. Most data incidents are a WHERE clause that meant something else.
A sanity ceiling. If you expect ~10k rows and the script computes 4 million, that’s a bug in the predicate, not a bigger job.

And the part everybody skips: a dry run predicts the change, but only a restore path lets you undo it. Confirm a snapshot covers the affected tables — and know the restore time; a backup you can’t restore within tolerance isn’t a safety net.

For targeted operations: archive the rows first.

CREATE TABLE _archive_2026_06_cart_purge AS
SELECT * FROM carts
WHERE status = 'abandoned' AND updated_at < :cutoff;

That one table makes the operation reversible in minutes instead of via a full restore. Drop it after an agreed retention period.

Protip: save the dry-run output (count + sample) in the PR or ticket before executing. Write the expectation down first.

Don’t ALTER columns in place

Never change a column’s type in place. Add a new column, migrate onto it, and once everything has stabilized — every instance writing and reading the new one — drop the old. The safe operations are the additive ones: ADD COLUMN (nullable) is cheap, and DROP COLUMN is destructive but safe once nothing reads the column, which is exactly why it ships last and on its own. The moves in between — a MODIFY or RENAME on the column your whole fleet and every replica are reading right now — look like one-liners, but their blast radius is the entire table and every running instance at once.

Change columns additively, not in place

The “safe rename” is a sequence, not a statement — and the same sequence covers any column change (retype, widen, split, merge), not just renames:

   (renaming customer_code → customer_ref)
migration:  ADD COLUMN customer_ref (nullable)
code:       write to BOTH columns
script:     backfill customer_ref from customer_code   (batched, idempotent)
code:       read from customer_ref, stop writing customer_code
migration:  DROP COLUMN customer_code   (days later, after metrics
                                            confirm nothing reads it)

A direct RENAME COLUMN is atomic for the database but not for your fleet: during a rolling deploy, old instances are still querying the old name the instant the rename lands, and they start erroring. Routing through a new column keeps both names valid until every instance has moved over.

The principle under the whole sequence: for the entire migration period the schema lives in two shapes at once, so your application code has to work against both — the old column and the new — until every instance has rolled over. That compatibility window is exactly what steps 2–4 buy you; skip it and the change only survives if the database and the whole fleet flip in the same instant, which during a rolling deploy they never do.

Narrowing a type is the sharpest reason to work this way: a direct ALTER to a smaller width silently truncates every overflowing value under a non-strict MySQL — data loss with a green checkmark. Migrate through a new column and the overflow surfaces in the backfill, where you decide what happens to it instead of the engine deciding for you.

What an in-place ALTER quietly takes from you

The additive rule isn’t dogma — it’s because of how much an in-place change silently destroys. Many engines treat a column modification as a replacement, not a patch:

-- existing: status VARCHAR(20) NOT NULL DEFAULT 'pending'

-- BAD: "just widen it" — MySQL silently drops NOT NULL and the DEFAULT
ALTER TABLE orders MODIFY COLUMN status VARCHAR(40);

-- to survive it, you must restate every attribute, by hand, every time
ALTER TABLE orders MODIFY COLUMN status VARCHAR(40) NOT NULL DEFAULT 'pending';

And that’s the easy trap. For the in-place changes you genuinely can’t avoid — the tightenings below — the same rule holds: spell out the full definition and read the generated SQL before it ships. Miss one attribute and it’s silent data loss; the additive path never asks you to remember.

PostgreSQL’s ALTER COLUMN ... TYPE preserves nullability and defaults, but ORM “change column” helpers often regenerate the full definition from whatever you declared — same trap, different layer.

For string columns, “complete” includes character set and collation: MySQL resets omitted ones to the table defaults, and a collation change alters which strings compare equal — silently breaking unique indexes and lookups.

Datetime type changes deserve their own paragraph of fear. Converting DATETIME ↔ TIMESTAMP in MySQL, or timestamp → timestamptz in PostgreSQL, rewrites every stored value through the session time zone unless you pin it. A uniform N-hour shift looks plausible row by row and errors nowhere.

And on a large table the ALTER itself can be the outage: the same statement is instant on one engine version and an hour-long lock on another. Know the locking behavior of every ALTER you write, reach for online schema-change tooling (gh-ost, pt-online-schema-change) on hot tables, and rehearse against production-sized data — a migration’s profile on a 10k-row staging table tells you nothing about 200M rows.

If you must tighten, gate it first

Tightening is the in-place change you can’t always route around: NOT NULL and unique constraints land after the backfill, and each gets a pre-flight violation query before it ships.

Unique constraints: duplicates fail the ALTER at deploy time — but NULLs slip right past it. In MySQL and (by default) PostgreSQL a unique index permits any number of NULL rows, and the usual GROUP BY ... HAVING COUNT(*) > 1 dup-check is no help here: it collapses every NULL into a single group and reports it as a false duplicate. Verify zero remaining NULLs separately, then pair the index with NOT NULL.

Name your indexes and constraints

Index naming isn’t an ALTER problem, but it’s the same lesson — don’t let the tool decide for you:

CREATE INDEX orders_customer_created_idx ON orders (customer_id, created_at);

Tool-generated names drift between environments (breaking the “drop the index” migration later), hit identifier length limits, and make incident work painful. A convention like {table}_{columns}_{type} costs nothing and pays forever.

Don’t use referential integrity

Heresy first, justification after: keep foreign keys out of your database. Declare the relationship in your code, index the column, and enforce integrity where you can actually reason about it — not in a constraint that fires on every write and fights you on every migration.

This is the one rule here people will argue about, so let me make the case.

Why foreign keys cost more than they’re worth

They lock the parent on every child write. InnoDB takes a shared lock on the referenced row whenever you insert or update a child, so a hot parent — the users row of your busiest account, a popular product — turns into a contention point and a deadlock factory, all to enforce a check that says nothing about your business rules.
ON DELETE CASCADE is the exact thing the rest of this post warns against. It’s an unbounded, unbatched, un-throttled, un-dry-runnable DELETE fired as a side effect of another DELETE. A single DELETE FROM users WHERE id = 42 can drag a million rows across ten tables down with it, holding locks the whole way — and you find out from the graphs. Everything in “Default to dry-run” becomes impossible the moment the database does the deleting for you.
They break online schema changes. gh-ost refuses to touch a table that has foreign keys; pt-online-schema-change supports them only through fragile, risky workarounds. The tooling you most need on large tables (previous section) is exactly what FKs disable.
They don’t survive scale or service boundaries. You can’t enforce a foreign key across shards, across a partition boundary, or across two services that each own their own database. The day orders and customers live apart, the guarantee you leaned on is gone — better to have never depended on it.
They turn routine data work into a fight. Backfills, archival, soft deletes, reparenting, importing legacy rows in the “wrong” order — all of it has to be choreographed around a constraint that rejects every intermediate state, even a temporary and intentional one.

What FKs actually buy you — “a child never points at a missing parent” — is real, but it’s a guarantee about a single moment, paid for on every write forever. You can get the same correctness far more cheaply.

Enforce integrity where you can reason about it

Validate the relationship in the application, on write, alongside every other business rule — because the useful conditions live there anyway: the parent must exist and belong to the right tenant, be in the right state, not be archived. A foreign key can’t express any of that.

Index the referencing column yourself. A FK in PostgreSQL does not auto-create an index on the child column (MySQL/InnoDB does); either way, add it explicitly — you want it for joins and lookups whether or not a constraint is attached.

CREATE INDEX orders_customer_id_idx ON orders (customer_id);

A bug can still slip an orphan through. Fine — you detect it, instead of locking your tables on every write to prevent it. The audit is a cheap anti-join you run on a schedule:

-- orphaned orders: child points at a parent that isn't there
SELECT o.id
FROM orders o
LEFT JOIN customers c ON c.id = o.customer_id
WHERE o.customer_id IS NOT NULL
  AND c.id IS NULL;

Alert on a non-zero count and you learn about drift in minutes — with the offending row IDs in hand, not a constraint violation blocking an unrelated deploy at 3 a.m.

Handle deletes on purpose

Without CASCADE, deleting a parent becomes an explicit, reviewable operation — which is the entire point. Pick the policy per relationship:

Cascade in application code, child tables first, using the batched, dry-run script from earlier. Now the cascade is countable, throttled, resumable and reversible.
Nullify the reference (SET customer_id = NULL) when the child outlives the parent — an anonymized order, a retained event log.
Block the delete with a pre-flight check (“does this customer still have orders?”) when children should keep the parent alive — the same intent as RESTRICT, but with a real error message and your own timing.
Soft-delete the parent and let a background job reconcile children, when an inline hard delete is too expensive to do on the request path.

Every one of these you can dry-run, batch, log and resume. A foreign key gives you exactly one option — CASCADE — and it’s the one that violates every other rule in this post.

Wrapping up

Before shipping anything that touches schema or data:

migrations: DDL only
data scripts: idempotent, batched, re-run tested
dry-run by default, --execute explicit
sanity ceiling on affected rows
restore path before any destructive run
change columns additively (add → migrate → drop), never ALTER/RENAME in place
if you must ALTER, restate the full definition and name your indexes
tighten only after a verified backfill
no database-level foreign keys; enforce in code, index the column, audit for orphans
destructive steps ship separately
know your lock profile; rehearse on production-sized data

Schema is code — it can be reverted. Data is forever. Respect that, and you’ll never have to explain why the orders table has 4 million rows with status 'pending'.

COMMIT;

How Dark Souls Made Me a Better Software Engineer

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

“Today is victory over yourself of yesterday.”
— Miyamoto Musashi, The Book of Five Rings

Dark Souls is not a game for the masses. It’s known for its brutal difficulty, its near-total lack of guidance, and a story buried so deep in item descriptions and environmental detail that most players never piece it together.

I first played it when it launched, and I hated it. I spent hours trying to understand how to level up my character and make it stronger, and found only death, again and again. Every path I took ended the same way: killed by an enemy, or falling into a trap I never saw coming.

The game never told me where to go. No tips, no shortcuts, no markers. I’d find an item with no idea where to use it. I’d meet an NPC with no way to know if they were friend or foe. Even the weakest enemy could kill me if it caught me off guard, or if I let myself get surrounded.

After enough suffering, I quit. But the feeling of defeat followed me for years. What had I done wrong? Was the game just bad? Was it punishing for the sake of being punishing, designed only to make players angry?

It took me years to find the answer. I’d grown up a little, both as a person and as an engineer, and I decided to give it another try — this time with a more mature, more patient, more deliberate approach. And almost immediately I understood what had gone wrong the first time.

I Was Playing It Wrong

Dark Souls is not a game that holds your hand and hands you free doses of dopamine to keep you hooked. It doesn’t show you where to go. Instead, it lays every path in front of you and lets you choose, and then expects you to learn — the hard way — that the path you picked wasn’t the one you were ready for yet.

It teaches through its mechanics, not through tutorials:

You can’t be good at everything at once. Instead of leveling every attribute, you learn to focus on one or two, and to pick the weapons and armor that scale with them. That’s how the game teaches you to specialize.
Spend your progress with parsimony. After killing a few enemies, it’s smarter to rest at a bonfire, level up, review your build, and move on. Push your luck instead, and you risk losing all your souls to a single trap or an invader.
Keep one eye on everything at once: your stamina, your weight load, your build, and the strengths and weaknesses of your own character.
Don’t rush a new enemy. It’s probably a trap, and most of the time it is. Retreat, think through your strategy, then advance one hit at a time. Be greedy, and you die.

The first time around, I had done the exact opposite of every one of these. I spread my levels across every attribute and mastered none. I burned my souls the instant I had them instead of banking my progress. I sprinted into every new room with my eyes on the loot, and walked face-first into every ambush. I wasn’t fighting the game. I was fighting the way I’d decided to play it.

The difficulty wasn’t cruelty. It was a teacher. I just hadn’t been listening.

You Are Your Own Enemy

The hardest enemy in Dark Souls is the player. Smash buttons, rush forward, fight without strategy or restraint, and you will die — a lot.

The game becomes easy the moment you understand this. You learn to control your anxiety, study your enemies, move with patience, and make progress one deliberate step at a time.

Died for the tenth time to the same boss? Don’t give up. Persist, but change something each attempt. Study the boss’s behavior, learn its patterns, find the openings between its attacks. And when you finally win, the real reward isn’t in the game. It’s the knowledge that you kept control and discipline when it would have been easier to rage and flail.

I know that moment intimately. Ornstein and Smough killed me so many times I was sure the fight was simply unfair, controller halfway to the wall. The shift came when I stopped playing angry. Instead of charging in to get it over with, I’d put the controller down, breathe, and actually watch what they did before each swing. The fight never got easier. I did. The same attacks I’d been dying to became a rhythm I could finally read.

You didn’t beat the boss. You beat your own internal enemy.

The Software Engineering Connection

Software engineering, it turns out, demands almost the same set of skills — and most of them are not technical.

You have to resist the urge to reach for the hyped new framework just because it’s there. You have to study the problem before attacking it, and come up with the best strategy to beat it. You have to read the situation, find the openings, and pick the right weapon — the right tool — for each occasion instead of swinging the same one at everything.

Re-read that list of lessons with an engineer’s eye, and it’s almost the same list:

Specialize before you generalize. You can’t master every language, framework, and platform at once, just like you can’t max out every attribute. Go deep on one or two things first, and let the rest transfer from there.
Make progress in small, safe steps. The bonfire is a commit. Do a focused piece of work, consolidate it, verify your build still stands, then move on. Try to do everything in one heroic push and you’ll lose hours to a single bad bug.
Watch your own capacity. Stamina and weight load are your bandwidth and your tech debt. Overload yourself and you’ll be too sluggish to react when something goes wrong.
Don’t charge into unfamiliar territory. A new codebase, a new system, an unfamiliar problem — treat it like a new enemy. Observe, understand the patterns, then move one careful step at a time.
Persist on the hard problems, but change your approach. Banging your head against the same bug the same way is just button-mashing. Step back, study the behavior, and form a new hypothesis on each attempt.
Read the lore before you touch anything. Dark Souls hides its story in item descriptions and the shape of its world; a legacy codebase hides its story in commits, comments, and tribal knowledge. Nobody hands you the plot. You reconstruct it, piece by piece, before you act.
Not every newcomer is on your side. In Dark Souls you meet characters with no way to know whether they’ll help you or knife you in the back. Every new dependency, library, or “quick” integration is that NPC. Vet it before you trust it with your build.

But the most important thing I took from the game and applied to my work was this:

“If it’s too hard, you’re doing it wrong.”

This doesn’t contradict the difficulty being a teacher — it completes it. The difficulty is always real. The question is whether you’re facing a wall you must learn to climb, or standing at the wrong wall entirely: under-leveled, wrong area, wrong weapon. In Dark Souls, grinding harder against the wrong wall just feeds it your souls. Telling the two apart — climb, or walk away and come back stronger — is the whole skill.

Learning to stay calm — and keeping enough emotional intelligence to recognize those moments where the difficulty is a signal, not a wall — was the turning point in my career. When something feels impossibly hard, it’s rarely because the problem is impossible. It’s because I’m approaching it wrong: wrong tool, wrong abstraction, wrong order, or simply rushing. The difficulty is feedback. Listen to it.

Conclusion

You won’t prosper by rushing, or by trying to do everything at once without thinking through your strategy. Success — in the game and in the work — comes after you learn to master and dominate your own flaws: impatience, ego, the craving for instant gratification, and the impulse to flail when things get hard.

Dark Souls didn’t make me a better engineer by teaching me anything about software. It made me a better engineer by teaching me about myself. The enemies, the bosses, the traps were never the real challenge. I was. And once I learned to beat that enemy — with patience, discipline, and the willingness to step back and rethink instead of pushing harder — everything else got easier.

Praise the sun.

How Agile made the software industry worse

Wed, 22 Apr 2026 00:00:00 +0000

“Individuals and interactions over processes and tools.”
– The Agile Manifesto, 2001 (RIP)

Let me be blunt: what we call “Agile” today killed the software industry. Not the real Agile - that died years ago, suffocated by consultants, certification programs, and managers who confused act[…]

What we have now is a bureaucratic frankenstein wearing Agile’s clothes, shambling through sprint ceremonies and demanding story points while the original principles rot in meeting room graveyards[…]

The Great Agile Scam

Somewhere between 2001 and today, we took four simple principles and turned them into an industrial complex of frameworks, tools, and processes. The irony is so thick you could sprint through it.

If you need tools and processes to be “Agile”, you aren’t Agile. You’re just doing waterfall in two-week chunks with better marketing. The manifesto literally starts with “Individuals and inte[…]

If you need contracts and closed scope to manage your projects, you aren’t using Agile. You’re using traditional project management with daily standups. Real Agile thrives on ambiguity and emb[…]

If you don’t trust your team, you aren’t using Agile. You’re using surveillance with colorful sticky notes. All those ceremonies, metrics, and reporting requirements? They’re trust-filling mec[…]

If you only ship “perfect software”, you aren’t using Agile. You’re using traditional development with shorter iterations. The whole point is to ship early, ship often, and learn from real use[…]

The Ceremony of Control

Modern “Agile” is a collection of countermeasures masquerading as methodology. Every ceremony exists because someone, somewhere, didn’t trust someone else:

Daily standups exist because managers don’t trust developers to communicate
Sprint planning exists because stakeholders don’t trust teams to prioritize correctly
Sprint reviews exist because business doesn’t trust development to build the right thing
Retrospectives exist because organizations don’t trust teams to improve naturally

None of this is Agile. It’s all about control, predictability, and filling the gaps left by poor management and broken trust.

Real Agile isn’t Scrum. It isn’t daily meetings. It isn’t planning poker or story points or sprint reviews. These are all bureaucratic barnacles that attached themselves to the Agile ship until it[…]

What Real Agile Actually Looks Like

Real Agile is about outcomes, not output. It’s about adaptable chaos, not predictable processes. It’s about communication, not documentation. It’s about trust, not surveillance. It[…]

Here’s how you actually do it:

Focus on outcomes, let the team organize the workflow

Stop measuring velocity and start measuring impact. Your team should organize around problems to solve, not tasks to complete. If they need to reorganize every week based on what they learned, gre[…]

Make sure everyone understands and commits to the WHYs

Don’t just tell people what to build - tell them why it matters. When your team understands the business context and user problems, they make better decisions than any process ever could.

Communicate as much as possible; adopt extreme visibility

Not through status reports - through actual conversation. Make everything visible: progress, blockers, decisions, trade-offs. Use whatever tools work, but prioritize human communication over tool […]

Decide what can be decided; leave future decisions for later

Stop trying to plan everything upfront. Make the decisions you can make now with the information you have now. When you have more information, make more decisions. Uncertainty isn’t a bug - it’s a[…]

Collaboration is key. There’s no “my job scope”

The team works together on whatever needs to be done to achieve the goals. If the backend developer needs to write CSS, they write CSS. If the designer needs to update documentation, they update d[…]

A shared doc or canvas should be enough to “register” the entire work scope

You don’t need project management software. You need shared understanding. Whether it’s a Figma board, a Miro canvas, or a Google Doc, the tool doesn’t matter - the clarity does.

Just Drop the Label

If you can’t accept this - if you need your frameworks and processes and ceremonies - just drop the Agile label. Call it “Interactive Process Management” or “Structured Development” or whatever yo[…]

The real Agile died when we turned principles into processes, values into ceremonies, and trust into tools. What we have now is just mediocre project management with better branding.

The software industry doesn’t need more Agile. It needs fewer meetings, more trust, clearer communication, and teams that are actually empowered to solve problems instead of following processe[…]

Until we get back to the original principles - until we value individuals over processes, working software over documentation, customer collaboration over contracts, and responding to change over […]

The manifesto is only 68 words long. Maybe it’s time we actually read it.

Protip: If your “Agile transformation” requires hiring consultants, buying tools, and training everyone on new processes, you’ve already lost.

What 6 months of PHP/Laravel taught me as a Ruby/Rails developer

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

“Good programmers use their brains, but good guidelines save us having to think out every case.”
— Francis Glassborow

After many years working with Ruby on Rails, I’ve spent the last six months working full time with PHP and Laravel. What surprised me the most was not learning a new syntax, but how little friction I felt switching stacks.

Not because the languages are the same (they aren’t) but because Rails and Laravel share a very similar philosophy: convention over configuration, developer happiness, and code that reads like intention.

Below are the main similarities and differences I noticed from a very practical, day-to-day perspective.

Eloquent Models feel like ActiveRecord (and that’s a good thing)

If you’ve used Rails’ ActiveRecord for years, Eloquent will feel instantly familiar.

Model definition

Rails (ActiveRecord):

class Post < ApplicationRecord
  belongs_to :user
  has_many :comments

  scope :published, -> { where(published: true) }
end

Laravel (Eloquent):

class Post extends Model
{
    protected $fillable = ['title', 'body', 'published'];

    public function user()
    {
        return $this->belongsTo(User::class);
    }

    public function comments()
    {
        return $this->hasMany(Comment::class);
    }

    public function scopePublished($query)
    {
        return $query->where('published', true);
    }
}

Querying feels almost identical

This is where Rails muscle memory really kicks in.

Rails:

Post.published
    .where(user_id: 1)
    .order(created_at: :desc)
    .limit(10)

Laravel:

Post::published()
    ->where('user_id', 1)
    ->orderBy('created_at', 'desc')
    ->limit(10)
    ->get();

Chaining, scopes, lazy evaluation - the flow and intent are basically the same.

Collections API: Ruby vibes everywhere

Laravel’s Collection API is one of its strongest features — and clearly inspired by Ruby’s Enumerable.

Ruby:

users
  .select { |u| u.active? }
  .map(&:email)
  .sort

Laravel:

$users
    ->filter(fn ($u) => $u->active)
    ->map(fn ($u) => $u->email)
    ->sort()
    ->values();

Once you stop thinking in raw arrays and start thinking in collections, PHP becomes much more expressive.

Hash vs Array: different names, same idea

This is one of the first mental adjustments when moving from Ruby to PHP.

In Ruby, Hash is the natural structure for key-value data. In PHP, arrays do everything - lists, maps, hashes - which feels odd at first but works well in practice.

Defining key-value data

Ruby (Hash):

user = {
  name: "User",
  email: "user@example.com",
  active: true
}

PHP (array as hash):

$user = [
    'name' => 'User',
    'email' => 'user@example.com',
    'active' => true,
];

Accessing elements

Ruby:

user[:email]
user.fetch(:email)

PHP:

$user['email'];
$user['email'] ?? null;

The null-coalescing operator makes safe access very straightforward.

Adding or updating values

Ruby:

user[:role] = "admin"
user.merge!(last_login: Time.now)

PHP:

$user['role'] = 'admin';

$user = array_merge($user, [
    'last_login' => now(),
]);

With Laravel Collections:

$user = collect($user)
    ->merge(['last_login' => now()])
    ->toArray();

Transforming data

Ruby:

prices = { apple: 10, banana: 5 }
prices.transform_values { |v| v * 2 }

PHP (Collection):

$prices = collect(['apple' => 10, 'banana' => 5])
    ->map(fn ($v) => $v * 2)
    ->toArray();

Nested access

Ruby:

user.dig(:profile, :address, :city)

PHP (Laravel helper):

data_get($user, 'profile.address.city');

Different syntax, same intent.

Request validation is as simple as Rails strong params

Validation in Laravel feels very close to Rails - simple, readable, and explicit.

Rails:

params.require(:user).permit(:name, :email)
validates :email, presence: true, uniqueness: true

Laravel:

$request->validate([
    'name'  => 'required|string',
    'email' => 'required|email|unique:users',
]);

In both frameworks, validation lives close to where data enters the system.

Routes: familiar DSL, different syntax

Routing is another area where the philosophies strongly align.

Rails:

Rails.application.routes.draw do
  resources :posts
  get "/health", to: "health#check"
end

Laravel:

Route::resource('posts', PostController::class);
Route::get('/health', [HealthController::class, 'check']);

RESTful by default, expressive, and easy to reason about.

Artisan feels like Rails generators on steroids

If you like rails generate, you’ll feel at home with Artisan.

Rails:

rails generate model Post title:string body:text
rails routes

Laravel:

php artisan make:model Post -m
php artisan make:controller PostController --resource
php artisan route:list

Artisan goes beyond generators:

queue workers
cache management
app optimization
custom CLI commands

It’s a very strong part of the Laravel ecosystem.

PHP is simple, explicit, and predictable

Modern PHP is very different from what many of us remember.

Less magic, more clarity

Ruby:

user.find_by_email("test@test.com")

PHP:

User::where('email', 'test@test.com')->first();

No hidden meta-programming - what you see is what runs.

Interfaces and typing help a lot

interface PaymentGateway
{
    public function charge(int $amount): bool;
}

Clear contracts reduce ambiguity, especially in larger teams.

The not-so-great parts

No stack is perfect.

Laravel caching can be annoying and inconsistent across environments
Finding libraries for newer or niche services can be harder than in Ruby
PHP still requires more boilerplate in some areas
The ecosystem is more fragmented (versions, extensions, hosting)

None of these are deal breakers - just trade-offs.

Final thoughts

After six months working daily with Laravel, one thing is very clear to me:

PHP is not dead. Not even close.

Laravel delivers:

a modern developer experience
a familiar MVC philosophy
excellent productivity
and a surprisingly smooth transition for Rails developers

Rails still shines in elegance and ecosystem maturity, but Laravel proves that PHP has evolved - a lot - and in the right direction.

At the end of the day, good software is less about the language and more about:

clear code
good tests
solid architecture
and teams that know what they’re doing

And in that sense, both Rails and Laravel get the job done - really well.

My thoughts about AI tools, vibe coding, and some predictions about the future of programming

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

“AI tools are great if you know what you’re doing.”
— A tired developer

“Magical tools” aren’t new

I started programming about 25 years ago. Self-taught. A lot of trial and error. When I was lucky, I had access to books. When I wasn’t, I explored every corner of the Help menu of Delphi. I learned by breaking things, fixing them, and slowly understanding how everything fit together. The learning curve was high.

At that time, the “best” tools were the ones that promised productivity through visual components: drag-and-drop forms, buttons, grids, data sources, and magically “connected” events. The pitch was always the same: “You don’t need to write code. Just drag components and connect them.”

Delphi, Visual Basic, PowerBuilder, and similar tools built entire empires on that promise.

Old-school developers hated it. They said it wasn’t real programming. That it was cheating. That people using those tools didn’t really understand what was happening underneath.

The market didn’t care.

Companies shipped software faster. Businesses made money. And those tools dominated for years. Eventually, they shaped the industry, influenced modern frameworks, and became the foundation of what we now call “rapid application development”.

AI tools feel different — but they really aren’t. They are just the next iteration of “magical tools”.

AI tools are great if you know what you are doing

If you just ask an AI to solve a problem for you, you’re doing it wrong.

AI is not a replacement for thinking. It’s an advanced code generator.

The quality of the output is directly proportional to the quality of your prompt — which, in practice, means the quality of your understanding of the problem, the codebase, and the architecture.

A bad prompt looks like this:

“Add a button that lists people on this page.”

In the best case scenario, the AI will generate something that works. In the worst case, it will dump a pile of spaghetti code that ignores conventions, architecture, separation of concerns, permissions, tests, and long-term maintainability.

A good prompt looks like this:

“Add a button that lists people on this page.
Use the MyButton component and centralize all fetching/mutation logic into the api.ts file.
Get the list of people from the ContactsService class, but keep all filtering logic inside PeopleController.
Make sure to verify user permissions to create a new Person using the User.canExecute("action") method.
Write an integration test covering this usage scenario.”

Now you are in control.

You already know what needs to be done. You know where the logic belongs. You know how your system should evolve. You’re just delegating the mechanical part — writing code — to the AI.

That’s not laziness. That’s leverage.

“You’ll become dependent and forget how to code”

This argument keeps coming back. And yes — it’s partially true.

When you don’t have to worry about syntax, language quirks, or framework boilerplate, you naturally forget some details. You might not remember the exact syntax of a for loop in Go, or how Ruby blocks behave in edge cases.

But here’s the uncomfortable truth: languages are commodities now.

It really doesn’t matter that much if your backend is written in Go, JavaScript, Ruby, or Python. What matters is that you understand:

logic
data flow
architecture
patterns
trade-offs
constraints
failure modes

If you have that, the AI can handle the syntax.

We already went through this transition before. We stopped memorizing assembly when high-level languages appeared. We stopped writing raw SQL everywhere when ORMs became popular. We stopped managing servers by hand when cloud platforms emerged.

This is just the next step.

Junior developers will disappear

AI tools are the new junior developers.

A mid/senior developer, using AI effectively, can be dramatically more productive than a senior leading and coordinating a team of juniors. There’s no onboarding, no context switching, no waiting for pull requests, no repeated explanations of architecture decisions.

More importantly:

AI doesn’t forget conventions
AI can instantly generate alternatives
AI can refactor relentlessly
AI can write tests, docs, and examples on demand

For companies, the cost/benefit equation changes completely. Instead of hiring multiple juniors and hoping they grow, a smaller team of experienced developers with AI assistance can deliver faster and with more consistency.

That doesn’t mean people disappear — it means the traditional entry point to the industry will change radically.

Generalists will rule

For the vast majority of companies, you no longer need deep specialists in frontend, backend, and database just to build and run a product.

A single developer, armed with AI tools, can:

design APIs
build frontend interfaces
model databases, write migrations
configure infrastructure
handle authentication and security practices
set up CI/CD
deploy and monitor applications

This is not science fiction. It’s already happening.

Of course, I’m talking about common software — the kind that runs most businesses. Not rocket science. Not medical devices. Not highly specialized domains.

If your company operates in a niche area that requires deep domain knowledge, specialists will still be essential — not because of coding itself, but because of the knowledge required to make correct decisions.

But for most cases, generalists who understand the whole system will be far more valuable than narrow specialists.

Software development will still need people

Despite all the hype, software development won’t disappear.

What will change is the role of the developer.

Developers will increasingly become the bridge between business intent and technical execution. AI lowers the learning curve, but it doesn’t remove the complexity. Someone still needs to:

understand what the business actually wants
translate vague ideas into concrete systems
make trade-offs
define boundaries
ensure quality
manage risk

The “new programmers” will orchestrate execution. They’ll use AI, vibe coding, text-to-code, diagrams, prompts, and automation to transform business needs into working software — faster than ever before.

Conclusion

Every generation of developers believes their tools are the last ones that require “real skill”. And every generation is wrong.

We’ve always built abstractions to move faster. AI is just the most powerful abstraction we’ve seen so far.

The core skill has never been typing code. It has always been thinking clearly, designing systems, and solving real problems.

AI doesn’t replace that. It amplifies it.

If you don’t know what you’re doing, AI will happily help you create a mess — faster than ever.
If you do know what you’re doing, AI becomes a force multiplier.

And that’s why I truly believe this:

AI tools are great if you know what you’re doing.

Personal notes

This text was partially written using AI. The content is mine, thoughts, examples, topics, and logical structure. I just asked IA to transform my notes into a blog post format. This is why I kept the “AI dash” on it.
If you’re a junior developer, don’t focus on just writing code; you should learn the concepts, software patterns, best practices, and soft skills. Achievements and deeds have more weight on your profile than technical skills purely.

Useful Ruby methods and tips that you might not know (or remember)

Thu, 29 May 2025 00:00:00 +0000

“Code is like humor. When you have to explain it, it’s bad.”
— Cory House

Enumerable Methods

Enumerable#tally

The tally method groups and counts elements in an enumerable. It’s great for frequency analysis.

irb> ["apple", "banana", "apple", "orange"].tally
=> {"apple"=>2, "banana"=>1, "orange"=>1}

Enumerable#inject

inject accumulates a result by applying a block to each element. It’s useful for summing, multiplying, and more.

Using with an accumulator:

irb> [1, 2, 3, 4].inject(0) { |sum, num| sum + num }
=> 10

Or passing a method proc as argument:

irb> [1, 2, 3, 4].inject(:+)
=> 10

Enumerable#chunk

chunk groups consecutive elements based on a block condition.

irb> [1, 2, 2, 3, 1, 1].chunk(&:even?).to_a
=> [[false, [1]], [true, [2, 2]], [false, [3]], [true, [1, 1]]]

Enumerable#each_with_object

each_with_object iterates and builds an object like a hash or array.

irb> ["apple", "banana"].each_with_object({}) { |fruit, hash| hash[fruit] = fruit.length }
=> {"apple"=>5, "banana"=>6}

Enumerable#slice_when

slice_when splits an enumerable when the block returns true.

irb> [1, 3, 6, 10].slice_when { |a, b| (b - a) > 3 }.to_a
=> [[1, 3, 6], [10]]

Enumerable#flat_map

flat_map maps and flattens the result in one step.

irb> [[1, 2], [3, 4]].flat_map { |arr| arr.map { |x| x * 2 } }
=> [2, 4, 6, 8]

Hash Methods

Hash#dig

Extracts the nested value specified by the sequence of key objects.

irb> h = { foo: {bar: {baz: 1}}}
irb> h.dig(:foo, :bar, :baz)
=> 1
irb> h.dig(:invalid, :key)
=> nil

Hash#invert

invert swaps keys and values in a hash.

irb> { a: 1, b: 2 }.invert
=> {1=>:a, 2=>:b}

Hash#transform_keys

transform_keys lets you change hash keys with a block.

irb> { a: 1, b: 2 }.transform_keys { |key| key.to_s.upcase }
=> {"A"=>1, "B"=>2}

Hash#transform_values

transform_values creates a new hash with the values transformed by the given block, while keeping the keys unchanged.

irb> { a: 1, b: 2 }.transform_values { |value| value * 10 }
=> { a: 10, b: 20 }

Array Methods

Array#rotate

rotate shifts elements to the left by default, or by a given count.

irb> [1, 2, 3, 4].rotate
=> [2, 3, 4, 1]

Array#combination

combination generates all combinations of a given length.

irb> [1, 2, 3].combination(2).to_a
=> [[1, 2], [1, 3], [2, 3]]

Array#permutation

permutation returns all possible permutations of a given length.

irb> [1, 2, 3].permutation(2).to_a
=> [[1, 2], [1, 3], [2, 1], [2, 3], [3, 1], [3, 2]]

Object Methods

Object#method(:method_name).source_location

Find where a method is defined in your source code.

irb> g = Greeter.new
irb> g.method(:say_it).source_location
=> ["/Users/home/app/models/greeter.rb", 5] 

Object#method(:method_name).arity

Check the number of arguments a method accepts.

irb> foo = "Hello"
irb> foo.method(:slice).arity
=> -2

Object#methods(false)

List only methods defined directly on the object, excluding inherited methods.

irb> obj = Object.new
def obj.greet; "Hello!"; end
irb> obj.methods(false)
=> [:greet]

Kernel Methods

callee

callee returns the current method’s name.

irb> def example
irb>   __callee__
end
irb> example
=> :example

rescue/retry

retry restarts the block after a rescue clause.

irb> attempts = 0
irb> begin
irb>   raise "Error" if (attempts += 1) < 3
irb> rescue
irb>   retry
irb> end
=> nil

BEGIN / END

BEGIN and END define blocks executed before and after the script runs.

BEGIN { puts "Starting..." }
END { puts "Ending..." }
puts "Hello!"

ActiveSupport Methods

Enumerable#compact_blank

compact_blank removes blank elements from an enumerable.

irb> [nil, "", "Hello", [], {}].compact_blank
=> ["Hello"]

Array#index_by

index_by creates a hash where keys are determined by the block.

irb> ["apple", "banana", "pear"].index_by { |fruit| fruit[0] }
=> {"a"=>"apple", "b"=>"banana", "p"=>"pear"}

Miscellaneous

Right Assignment

Assign results in reverse order for cleaner syntax.

irb> Users.where(active: true).all => users
=> nil
irb> users
=> [#<Contact:>,...]

Destructuring Block Arguments

Pattern matching in blocks lets you destructure array elements.

irb> a = [[1, 2], [3, 4]]
irb> a.each do |(first, last)|
irb>   puts "First: #{first}, Last: #{last}"
irb> end
First: 1, Last: 2
First: 3, Last: 4

Calling Procs

You could call procs in different ways:

irb> my_proc = -> arg { puts arg }
#<Proc:0x007fb1ebe9c1a0@(irb):1 (lambda)>

irb> my_proc.call('hello')
hello

irb> my_proc.('hello')
hello

irb> my_proc['hello']
hello

Command line Ruby tips

Given the following files in the current directory:

$ ls -l
-rw-r--r--@ 1 user  group    36 28 Mai 17:57 file1.txt
-rw-r--r--@ 1 user  group     8 28 Mai 17:57 file2.txt
-rw-r--r--@ 1 user  group   613 28 Mai 17:58 file3.txt
-rw-r--r--@ 1 user  group  3143 28 Mai 18:48 photo.jpg
-rw-r--r--@ 1 user  group  1004 28 Mai 18:47 report.ofx

Using -n and -e to Process Lines

-n wraps your code in a loop that reads each line from input. Combine with -e for quick one-liners.

$ ls -1 | ruby -n -e 'puts $_ if $_.match(/\.txt/'
file1.txt
file2.txt
file3.txt

Using -p to Modify Lines in Place

-p is like -n but automatically prints each line. Great for filters and transformations.

$ ls -1 | ruby -p -e '$_ = $_.capitalize'
File1.txt
File2.txt
File3.txt
Photo.jpg
Report.ofx

Using STDIN

The command below returns the total size of all files returned by ls -l command:

$ ls -l | ruby -e 'puts STDIN.to_a.map { |l| l.split[4].to_i }.sum'
4804

I've been writing software for the last 25 years. Here are a few more things I've learned so far (part 2)

Mon, 14 Apr 2025 00:00:00 +0000

The code you write makes you a programmer. The code you delete makes you a good one. The code you don’t have to write makes you a great one.
– Unknown

This is part 2 of the previous post: I’ve been writing software for the last 25 years. Here some things I learned so far

But first, some context

I’m a self-taught generalist (aka full-stack) software engineer experienced mainly in web applications, having a strong focus on pragmatism and problem solving. Over the last 25 years, I’ve worked in small startups, mid-sized companies, and large enterprises—mostly in Linux environments, using open-source languages and tools. Along the way, I’ve also had some experience leading and managing teams.

The lessons below come from years of seeing what works and what doesn’t. Some are the result of success, others from hitting the wall—hard.

Building and Designing Software

Automate your workflow

Automate everything you can—project setup, configuring local environments, creating test data with scripts, etc. If you do it more than once, automate it. Your future self (and teammates) will thank you.

Applications should run locally

If your app can’t run on a dev machine, you’re doing it wrong. Make local setup simple—native or Docker, doesn’t matter. Devs need full control to reproduce problems, debug, and test… locally. Include scripts to generate sample data, simulate API calls, and preload images or documents. These tools are part of the product too.

Design your code to fail

Don’t trust inputs. Add logs where it matters. Write checkers, guard clauses, notifications for edge case scenarios. Expect things to break—and make it easy to recover.

Track requests and responses

Log everything used in third-party integrations—requests, responses, and payloads. You will need it for debugging and audits.

Don’t blindly trust your data

Users send broken data. Bugs introduce garbage into database. Validate everything—on input, on output, on storage. Your system is only as good as the data flowing through it.

Don’t ignore idempotency

If something fails, you should be able to retry it without causing damage. Idempotency is your friend. Don’t ship production code without it.

Be explicit

Write greppable code. Use "mobile" instead of 3 to describe enums. Name things clearly: has_balance, requested_amount, etc. Never assume something is “obvious”. It never is. More on this here: Greppability: A code metric

Testing > Debugging

Relying only on debugging tools could lead you to chase problems after they happen. Testing (especially TDD) helps you move in small, safe steps. You define expectations first, then work towards meeting them. It’s like climbing a mountain one secure foothold at a time.

Avoid unnecessary frameworks

The web is just HTTP—receive a request, send a response. That hasn’t changed in decades. You don’t need heavy frameworks to handle 90% of what you build. Stick with boring, battle-tested tools.

Monoliths aren’t always bad. Microservices aren’t always good.

Don’t split your system into pieces unless you have a really good reason. Scale only when you must. Premature complexity is the real bottleneck.

Worse is better

Keep it simple. Forget hexagonal architecture and all the over-engineered “best practices” that solve problems you don’t have. Worse is better—and often faster, clearer, and easier to maintain.

Don’t try to make it perfect. Make it adaptable.

There’s no silver bullet. Instead of aiming for the perfect solution, aim for something adjustable, configurable, flexible, and easy to change when needed. Prioritize adaptability over perfection.

Shipping and Maintaining Software

You won’t get it right the first time

No matter the architecture, design, or framework, your first attempt won’t be perfect. You’ll need to iterate to make it truly work. So don’t overthink or over-plan. Ship something functional as soon as possible and let feedback guide you.

Monitor and observe your software

Know something’s broken before your users do. Instrument your systems. Set alerts. Pay attention to the data.

Always have a Plan B

Have redundancy. Keep backups. Make sure someone else can step in if needed. Single points of failure—whether in infrastructure or people—are liabilities.

Care about the UX

Interfaces aren’t just forms anymore. Users talk to systems with voice and text (Alexa, ChatGPT, etc.). If your signup form has 12 fields, they’ll probably quit halfway through.

Working with Teams and People

Estimates are bad. Manage expectations instead.

Software estimates have never worked—and never will. Communicate uncertainty. Share tradeoffs. Set expectations early and often.

Extreme visibility

Keep your teammates, managers, and stakeholders aware of what you’re doing, your progress, and what’s blocking you. It builds trust and reduces surprises.

Don’t micromanage

If you don’t trust your team, why are they on the team? Focus on outcomes: what’s the impact on the product, team, or company? What’s blocking them? How can you help? Let people figure things out—it’s how they grow.

Communicate decisions

Why this framework instead of that one? Why this database, this design, this pattern? Write it down. Share it. It prevents repeat mistakes and helps others understand the “why.”

Sharing accelerates your career more than anything else. Teach. Present. Write. Share what you learn, what you build, and what you discover. The more you share, the more you grow.

Don’t postpone obvious decisions

You’re going to make a lot of decisions. Some are big, others are trivial. Don’t waste time overthinking the obvious ones. Make the call, communicate it, and spend your energy where it really matters.

Reject dogma

Take principles like the ones in this post as guidance—not gospel. Don’t follow advice blindly just because someone said it’s best practice. Think. Understand the context. Apply what makes sense.

Wrapping up

After all these years, one thing is clear: writing software isn’t just about code. It’s about people, communication, trade-offs, and learning to live with imperfection. You won’t get everything right. You’ll ship things that break. You’ll rethink decisions. That’s normal. That’s healthy.

What matters is staying curious, being honest about what works (and what doesn’t), and helping those around you grow. The lessons in this post aren’t universal truths—they’re just what I’ve picked up from the trenches. Take what’s useful, challenge what isn’t, and keep moving forward.

And above all: keep it simple, keep it working, and keep learning.

Enjoy o/

How to backup your photos from Google and fix the Exif metadata

Sun, 16 Mar 2025 00:00:00 +0000

Any sufficiently advanced incompetence is indistinguishable from malice.
– Grey’s Law

Downloading your whole backup from Google Photos should be easy, right? Well, not really. Google’s Takeout service makes it way more annoying than it should be. Not only do you have to wait for about 3 days, manually download a bunch of ZIP files from a page with the worst usability I deal it in the last decade, and discover that the files didn’t come with the info metadata on it (which keeps the correct photo date, time, location, etc), but stored separately in JSON files with inconsistent naming.

So, sharing my frustration here and how I dealt with it to clean up Google’s mess and get my photos back in order.

Step 1: Getting the backup from Google Takeout

First, I requested my export from Google Takeout. This took three days to process, since I had about 150GB of photos.

Once it was ready, I had to manually download 72 ZIP files, one by one, because Google apparently hates bulk downloads. Super fun.

Step 2: Extracting everything

After finally downloading all the files, I extracted them into a single directory with this command:

for zip in downloaded/*.zip; do unzip $zip -d extracted/; done

This dumped all the files into a structure like this:

extracted/
  Takeout/
    Google Fotos/
      Photos From 2024/
        image1.jpg
        image1.jpg.supplemental-metadata.json
      Photos From 2025/
        image1.jpg
        image1.jpg.supplemental-m.json
        image1.jpg.supplemental-metadata(1).json
        image1(1).jpg
        image2.jpg
        image2.jpg.sup-meta.json

As you can see, consistency isn’t Google’s strong point. I need the metadata filenames to follow the same pattern because it will be used in the next step.

Step 3: Fixing the metadata filenames

The correct format of metadata files should be:

image.jpg.supplemental-metadata.json

But I found things like:

image.jpg.sup-meta.json
image(1).jpg.supplemental-meta.json

To clean this up, I wrote a Ruby script that:

Finds all metadata files with weird names.
Renames them to match the expected format.
If an image doesn’t have a metadata file, it tries to guess the date from the filename (e.g., IMG_20240515.jpg → May 15, 2024).

Here’s the Ruby script I used:

To run it, simply execute on the terminal:

ruby fix_metadata.rb extracted/Takeout/Google\ Fotos/

The output will be like:

$ ruby fix_metadata.rb ./extracted/Takeout/Google\ Photos/
Total files found on ./extracted/Takeout/Google Photos/**/*: 555
Total photos from YYYY dirs found: 539
Total supported photos formats found: 131
Total metadata files found: 408

Process finalized with 3 errors:
[1/3] Unable to infer metadata for ./extracted/Takeout/Google Photos/Photos from 2013/CameraZOOM-01611c5b98.jpg
[2/3] Unable to infer metadata for ./extracted/Takeout/Google Photos/Photos from 2013/CameraZOOM-20131224200750052.jpg
[3/3] Metadata file: .//extracted/Takeout/Google Photos/Photos from 2014/IMG_1181.JPG.supplemental-metadata(1).json not exist for image: ./extracted/Takeout/Google Photos/Photos from 2014/IMG_1181(1).JPG

Process finalized with 22 fixes:
[1/22] 5142914356_01611c5b98_o.jpg.supplemental-metad.json moved to 5142914356_01611c5b98_o.jpg.supplemental-metadata.json
[2/22] 1-3922-1990-20121024123511.jpg.supplemental-me.json moved to 1-3922-1990-
...
[22/22] IMG_1182.JPG.supplemental-metadata(1).json moved to IMG_1182(1).JPG.supplemental-metadata.json

Metadata not found for 21 files:
[1/21] ./extracted/Takeout/Google Photos/Photos from 2013/CameraZOOM-20131224200623261.jpg
[2/21] ./extracted/Takeout/Google Photos/Photos from 2013/CameraZOOM-20131224200750052.jpg
...
[21/21] ./extracted/Takeout/Google Photos/Photos from 2025/IMG_5854.HEIC

Step 4: Applying the metadata to files

Once the filenames were fixed, I used exiftool to write the correct metadata into the photo files:

exiftool -r -d %s -tagsfromfile "%d/%F.supplemental-metadata.json" \
  "-GPSAltitude<GeoDataAltitude" "-GPSLatitude<GeoDataLatitude" \
  "-GPSLatitudeRef<GeoDataLatitude" "-GPSLongitude<GeoDataLongitude" \
  "-GPSLongitudeRef<GeoDataLongitude" "-Keywords<Tags" "-Subject<Tags" \
  "-Caption-Abstract<Description" "-ImageDescription<Description" \
  "-DateTimeOriginal<PhotoTakenTimeTimestamp" \
  -ext "*" -overwrite_original -progress --ext json -ifd0:all= \
  extracted/Takeout/Google\ Fotos/

(just change the last argument to the directory where you extract the photos)

This does a bunch of things:

Reads the correct timestamp from the JSON file.
Writes it into the photo’s EXIF data.
Restores GPS location and descriptions.
Fixes bad tags in one go.

Wrapping Up

Now that all the metadata is fixed, I can import everything back into iCloud Photos (my case) or any other storage service without messing up the timeline.

Let me know if you have any other tricks or improvements!

References

Monitoring my swimming pool temperature with a cheap BLE sensor and ESPHome

Tue, 03 Sep 2024 00:00:00 +0000

One accurate measurement is worth a thousand expert opinions.
– Grace Hopper

Maintaining the right temperature for my swimming pool is crucial for enjoying a good swim. Instead of frequently checking a thermometer or relying on a mobile app, I wanted to get real-time temperature updates remotely. Here’s how I achieved this using an affordable BLE sensor and ESPHome.

BLE Sensor

I found a suitable BLE sensor on AliExpress that fit my requirements perfectly:

Power efficiency: the sensor runs on two AAA batteries, lasting about six months.
Precision: it has good precision with an error of just 1° C approximately.
Data collecting: it works well with its dedicated mobile app, but doesn’t integrate with third-party apps.

Despite its limitations, the sensor was perfect for my project. However, I needed a way to access the temperature data in real-time without using the mobile app or being near the pool.

ESPHome

To bridge this gap, I used an ESP32-WROOM-32U, which I also bought from AliExpress. The external antenna on this model ensures a reliable connection over a longer range.

The ESP32 will work just as a BLE <> Wi-Fi bridge, connecting to the sensor on each hour, reading the temperature and sending the data to Home Assistant sensors.

Here’s how I set it up on ESPHome config:

esphome:
  name: "esphome-pool-monitor"
  friendly_name: Pool Monitor

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "wmIdKCoFredactedNGeGZHeQI="

ota:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

time:
  - platform: homeassistant
    id: homeassistant_time
    on_time:
      - seconds: 0
        minutes: 30
        then:
          - switch.turn_on: ibs_p01b_switch
          - delay: 5s
          - while:
              condition:
                and:
                  - switch.is_on: ibs_p01b_switch
                  - binary_sensor.is_off: ibs_p01b_connected
              then:
                - logger.log: "Trying connection to IBS-P01/B"
                - esp32_ble_tracker.stop_scan:
                - delay: 5s
                - esp32_ble_tracker.start_scan:
                - delay: 1min

esp32_ble_tracker:
  scan_parameters: 
    active: false
    continuous: false
    duration: 1min
  on_ble_advertise:
    - mac_address: "XX:XX:XX:XX:XX:XX"
      then:
        - lambda: |-
            ESP_LOGD("ble_adv", "IBS-P01/B device found");

button:
  - platform: template
    name: "BLE Start Scan"
    on_press:
      - esp32_ble_tracker.start_scan:
  
  - platform: template
    name: "BLE Stop Scan"
    on_press:
      - esp32_ble_tracker.stop_scan:

  - platform: restart
    name: "ESP32 Restart"

binary_sensor:
- platform: status
  name: "ESP32 Status"

- platform: template
  id: ibs_p01b_connected
  icon: mdi:bluetooth-connect
  name: "IBS-P01/B Connected"

ble_client: 
  - mac_address: XX:XX:XX:XX:XX:XX
    id: ibs_p01b
    on_connect:
      then:
        - wait_until:   
            lambda: |-
              esphome::ble_client::BLEClient* client = id(ibs_p01b);
              esphome::ble_client::BLECharacteristic* chr = client->get_characteristic(0xFFF0, 0xFFF2);

              return chr != nullptr;              
        - lambda: |- 
            ESP_LOGD("ble_client_lambda", "Connected to IBS-P01/B");
            id(ibs_p01b_connected).publish_state(true);

    on_disconnect:
      then:
        - lambda: |-
            ESP_LOGD("ble_client", "Disconnected from IBS-P01/B");
            id(ibs_p01b_connected).publish_state(false);

switch:
  - platform: ble_client
    id: ibs_p01b_switch
    ble_client_id: ibs_p01b
    name: "IBS-P01/B Enabled"
    restore_mode: ALWAYS_OFF

sensor:
  - platform: uptime
    name: "ESP32 Uptime"

  - platform: template
    device_class: timestamp
    name: "IBS-P01/B Last Measurement"
    id: "ibs_p01b_last_measurement"

  - platform: template
    name: "IBS-P01/B Temperature"
    id: ibs_p01b_temperature
    unit_of_measurement: "°C"
    accuracy_decimals: 1
    state_class: measurement
    device_class: temperature

  - platform: ble_client
    id: ibs_p01b_sensor
    type: characteristic
    ble_client_id: ibs_p01b
    service_uuid: 'fff0'
    characteristic_uuid: 'fff2'
    notify: true
    internal: true
    update_interval: 30s
    lambda: |-
      if (x.size() == 0) return NAN;

      // https://community.home-assistant.io/t/hex-string-to-dec-value/458945/2
      auto temp = (float)((int16_t)(x[1]<< 8) + x[0])/100;

      if (temp != NAN) {
        id(ibs_p01b_temperature).publish_state(temp);

        // https://community.home-assistant.io/t/publish-timestamp-into-text-sensor/122531/11
        id(ibs_p01b_last_measurement).publish_state(id(homeassistant_time).now().timestamp);

        id(ibs_p01b_switch).turn_off();
      }

      return 0.0;

Notes:

For obvious reasons, I redacted the mac address of my device.
You can find the mac address and inspect the characteristics for your sensor with apps like BT Inspector or LightBlue.
IBS-P01/B is the name/model of my sensor. You can use other devices for this purpose since they have bluetooth support.
I’ll not cover the details for setting up ESPHome and devices, but you can watch a detailed tutorial from Everything Smart Home Youtube channel.

After uploading the firmware to ESP32 and with a little luck, you will see something like that on the logs:

[16:24:04][D][switch:012]: 'IBS-P01/B Enabled' Turning ON.
[16:24:04][D][switch:055]: 'IBS-P01/B Enabled': Sending state ON
[16:24:05][D][button:010]: 'BLE Start Scan' Pressed.
[16:24:05][D][esp32_ble_tracker:266]: Starting scan...
[16:24:11][D][ble_adv:069]: IBS-P01/B device found
[16:24:11][D][esp32_ble_client:110]: [0] [XX:XX:XX:XX:XX:XX] Found device
[16:24:11][D][esp32_ble_tracker:665]: Found device XX:XX:XX:XX:XX:XX RSSI=-82
[16:24:11][D][esp32_ble_tracker:686]:   Address Type: PUBLIC
[16:24:11][D][esp32_ble_tracker:215]: Pausing scan to make connection...
[16:24:11][D][esp32_ble_tracker:303]: End of scan.
[16:24:11][I][esp32_ble_client:067]: [0] [XX:XX:XX:XX:XX:XX] 0x00 Attempting BLE connection
[16:24:24][I][ble_sensor:031]: [ibs_p01b_sensor] Connected successfully!
[16:24:26][I][esp32_ble_client:227]: [0] [XX:XX:XX:XX:XX:XX] Connected
[16:24:26][D][ble_client_lambda:115]: Connected to IBS-P01/B
[16:24:26][D][binary_sensor:036]: 'IBS-P01/B Connected': Sending state ON
[16:24:32][D][sensor:094]: 'IBS-P01/B Temperature': Sending state 22.77000 °C with 1 decimals of accuracy
[16:24:32][D][sensor:094]: 'IBS-P01/B Last Measurement': Sending state 1722626688.00000  with 1 decimals of accuracy
[16:24:32][D][sensor:094]: 'ibs_p01b_sensor': Sending state 0.00000  with 0 decimals of accuracy
[16:25:02][D][sensor:094]: 'IBS-P01/B Temperature': Sending state 22.77000 °C with 1 decimals of accuracy
[16:25:02][D][sensor:094]: 'IBS-P01/B Last Measurement': Sending state 1722626688.00000  with 1 decimals of accuracy
[16:25:02][D][sensor:094]: 'ibs_p01b_sensor': Sending state 0.00000  with 0 decimals of accuracy
[16:25:43][D][ble_client:121]: Disconnected from IBS-P01/B
[16:25:43][D][binary_sensor:036]: 'IBS-P01/B Connected': Sending state OFF
[16:25:43][W][ble_sensor:037]: [ibs_p01b_sensor] Disconnected!

And, of course, the data in Home Assistant device:

Wrapping Up

It’s working but it’s not finished. I need to keep the ESP32 turned on and near the pool, running continuously.

I used a standard USB 5V DC adapter plugged into a wall outlet near the pool. To protect the hardware from the elements, I 3D printed a box to accommodate both the ESP32 and the DC adapter:

If you want to print the same box for your project, download the model from my Printables profile.

This setup has been running flawlessly for the past 10 months, providing me with accurate and (almost) real-time water temperature, making pool maintenance much easier. From here, I can create automations to turn the heater on, send a message on family group when the temperature is ideal, and much more.

Enjoy o/