Forem: Manuel Artero Anguita 🟨

You're not falling behind - «Tend and Befriend» Theory

Manuel Artero Anguita 🟨 — Fri, 20 Feb 2026 15:06:35 +0000

Breathe.

Just breathe.

Yes, my bookmarks in the AI folder keep growing. Actually, the first ones can be removed? not because I've read them, but cause they're already deprecated.

From the "two weeks ago" ancient past.

I'm a developer.

Nowadays I'm attending meetings with a clear message:

We KNOW we're falling behind. You guys shouldn't be typing code by hand anymore. Product teams shouldn't be working use cases the way they used to. QA should be automating... something. no wait! Everything!

We do know we need to change something. We're still deciding what... and how.

And that is ok.

I'm not in denial of the change. Let's do it.

Just, remember: there's big money in making you feel this way. You, your boss, their boss, the CTO, and the CEO. And they're human. (Yes, CEOs are humans too.) They are not immune to the psychic attack.

There's big money in play, and big money is rolling a serious amount of psy damage (and not over one individual dev, this is an area attack).

They're human and they KNOW they need to move fast. The opportunity window!!! If the org doesn't catch the wave, someone else will!!!! Someone else gets that 10x productivity boost!!!!!!!

...And those?

Yep. They are feeling the same. You get it.

The thing is... nobody knows shit. That guy on Tech Twitter claiming they're already ahead? Well... I honestly don't know. Maybe? But I've been in tech enough to know that the loudest voice in the room is rarely the one who figured it out.

And most of them, they're running alone. Let's see how far that takes them.

The pressure is real. I'm not going to pretend it isn't.

what does pressure do to us, humans?

Let's go anthropologist here for a second, shall we?

There's a term interesting for this: tend and befriend. Shelley Taylor, researcher, coined it in the 00's.

Shelley Taylor, distinguished research professor of psychology in the UCLA College.

Her team found that under stress, our bodies don't just go fight-or-flight. We release oxytocin (an hormone) that literally pushes us to seek the group, to protect, to bond.

To be specific, her research actually found that this response is stronger in women (while men might default more to fight-or-flight) alone.

This post is not a feel-good quote. It's about biochemistry.

The body, under pressure, is screaming at you: don't run alone.

This hormone isn't restricted to women, so:

Group up. Protect the one next to you. Share what you know. This isnt idealism, that's how we made this far as humans.

Greek hoplites. Roman Legions. Spanish Tercio. they didn't win battles by being the fastest runners. They won by lifting their shield to cover the soldier next to them.

You protect me, I protect you. We move together, or we don't move at all.

Right now, the AI hype machine is rewarding lone wolves. The hot takes. The "I replaced my whole team" crowd.

Well, I'm not entering your game. Im not going to make it with a better prompt. My bet is on the Phalanx.

Before you doom-scroll another "you're falling behind",

Breathe.

You're not falling behind. You're human. And humans don't survive by running alone.

RAISE YOUR SHIELD SOLDIER

We'll figure this out. As a pack.

--
thanks for reading.

"loading..." vs. "thinking..."

Manuel Artero Anguita 🟨 — Fri, 20 Feb 2026 08:34:50 +0000

loading..." -> Boring, Classic server, Outdated.

vs.

"thinking..." -> AI-Powered, 12 agents, 40M investment, Orchestrated System with Collaborative Agents.

Let's talk about grief.

Manuel Artero Anguita 🟨 — Mon, 16 Feb 2026 09:24:33 +0000

Let's talk about grief.

Grieving isn't restricted to a relative passing away. We also mourn the death of ideas, expectations, ideals and dreams. We grieve for the future.

The death of what we were expecting.

I'm no stranger to this. I've been mourning for years a particular future that is not to come.

No need to enter into details, but I've gone through every single step for years and I've learnt a little bit about loss.

We, programmers, software engineers, coders (whichever name you like) are entering (or perhaps have been for a while?) a grieving process.

Some might have lost an identity mark, others may be afraid of the future to come, and others might be crying for a golden, glorious "used to be"

I think there won't be two people sharing the exact dead ideal, but we all share the same context.

There are steps. If you want, it's like a state machine:

S0 → S1 → S2 → S3

And.... again to S0 (yep, it's a cycle... well, it would be better to say a spiral).

S0 → S1 → S2 → S3 → S4 → S0 → S1

But here's the thing: every time you close a loop, there is a minor change, a progress.

S0 → S1 → S2 → S3 → S0' → S1' → S2' → S3' → S0''...

The end of this spiral is a final state. It's called Acceptance.

Depending on how deep your loss sits in your heart, it's possible to "touch" that final state, Acceptance, and then fall back to another state of the spiral.

this is normal, and it's part of the healing process.

enum GrievingSteps {
  Denial,      // S0
  Anger,       // S1
  Bargaining,  // S2 
  Depression,  // S3
  Acceptance,  // S4
}

Denial: AI could never replace me. Im special, I'm the smartes guy in the room there will be always room for the human spark, i will be needed.

Anger: I reject AI. I reject anything created , the human touch is needed. Everything will collapse if they keep replacing human work with AI

Bargaining: I need to adapt, i won't type code but im vital for reviewing the diffs, if ever, my work and my mind is more needed than anytime. Im needed

Depression: whatever, the world is to end. If AI take every single work outthere anything is meaningless.

Acceptance: I have no analogy here. I haven't reached this state yet. I've been cycling myself through S0 → S3 for a while now.

The spiral gets smaller

The first loop hits hard. Denial might last weeks. Anger. Depression was... well, depression. But the second time around? I recognized the states. I could almost see the transitions happening in real time. "Oh, I'm in S1 again. Cool. I know where this goes."

It still hurts.

But there's a difference between walking a path for the first time and walking it again knowing where the edges are. The duration of each state gets smaller.

You don't stop cycling; you just cycle faster, and with less damage.

loop_duration(n) > loop_duration(n+1)

That's the quiet progress.

What now

So, if you're somewhere in the spiral right now: welcome.

You're not broken. You're processing.

And if you're able to see which state you're in, you're already ahead.

I haven't reached Acceptance yet.
I'm somewhere between S2' and S3'? on my third loop?

So here's my promise: when I get there: when I finally touch S4 and it sticks... I'll write about it.

thanks for reading.

You're Falling Behind

Manuel Artero Anguita 🟨 — Mon, 02 Feb 2026 11:26:31 +0000

"You're falling behind"

* Looks up the latest trend

* Does ln -s ~/.foo-model/skills/file.md

About Wizards & Warlocks, Programmers & Vibe Coders

Manuel Artero Anguita 🟨 — Wed, 28 Jan 2026 10:39:32 +0000

We used to be similar to wizards.

Wizards have no intrinsic power by themselves: they must earn it.

We studied. For years. There was effort in the transaction, and as a reward you got a valuable skill. And because of this, you were able to find a lord to work for. You got to the lord's court to work as a wizard full time.

Thanks to the wizard academy, I started at Lvl. 1. Knowing 3x cantrips and having 2x level 1 spell slots.

I got a job at the fortress of a powerful lord. They paid for my wizard services and gave me daily tasks to solve.

When stuck, I would turn to the other wizards employed in the castle, the books I used at the academy, or the well-known oracle of knowledge called "the Overflowing Stack": a shrine of the Fae where answers were found (but it was extremely difficult for them to accept a new question).

This is how things used to be.

Then the Warlocks appeared.

The new order of the "Vibe Coders".
And their power was astonishing. All the lords of the land were impressed by their gifts.

In Dungeons & Dragons, mechanically speaking, one of the main differences between wizards and warlocks is how their spells level. Wizards have this "mana" resource (called spell slots) and they need to manage it carefully; let's say a wizard has mana to cast the "good refactor" transmutation spell at max level once, then they won't be able to cast this spell at the same power for a (long) time.

Warlocks have all their "mana" (spell slots) at max level. All the time. Meaning: they only cast spells at max level. And they need almost no rest! they're ready to cast "astonishing new project" illusion spell riiiight away.

That's why the lords are looking to these brand new spell casters with wide-opened eyes.

So they started asking all their employed wizards: "Hey, this guy over there is able to cast 'full REST API' at max level with no effort" ... "Go multi-class to Warlock, you puny wizard."

What is the trick here?

Wizards studied magic, they earned it.

Warlocks borrow their magic. They don't wield it, they borrowed it from an external, powerful entity: The Patron.

They made a pact with their Patron.

Once a pact is made, a ~~Warlock’s~~ VibeCoder thirst for ~~power~~ tokens can’t be slaked with mere study.
Most ~~Warlock’s~~ VibeCoders spend their days pursuing greater ~~power~~ tools and ~~deeper knowledge~~ new models
– Dungeons&Dragons Player Handbook (2024)

The Player Handbook continues:

On level 3, You gain a ~~Warlock~~ VibeCoder subclass of your choice:
the ~~Archfey Patron~~ OpenAI Patron,
the ~~Fiend Patron~~ Anthropic Patron
and ~~Great Old One Patron~~ Perplexity Patron are the most notable subclasses.

Their Patron grants them otherworldly powers.

And sometimes we forget who's the Subject and what's the verb in this sentence.

Let's do second grade syntax here, shall we?

Subject: their Patron → who performs the action
Verb: grants → to grant: to give something to someone.
Complements:
- them → Indirect Object (the person who receives something)
- otherworldly powers → Direct Object (the thing that is given)

I, myself, have multiclassed to Lvl. 1 Warlock. (I guess.... Level 3 Wizard + Level 1 Warlock?).
Not because I wanted to? but rather because I want to remain employable by a lord.

The pact is tempting: forget all my Wizard levels and just use the Patron's source of power. It's soooo easy.

Still...

The thing about borrowed power, it's still borrowed. Patrons can change the terms of the pact. Anytime.

The Patron giveth, and the Patron can taketh away.

And when that day comes, I mean...

Don't give up those wizard levels just yet.

--
Thanks for reading

Docker Zootopia Networking

Manuel Artero Anguita 🟨 — Fri, 17 Oct 2025 12:46:49 +0000

I want to talk a little bit about Docker Compose, networking, and services calling each other. This is a super regular scenario that ‘ve already talked/posted/written, but I keep these post mostly for myself? if that makes sense.

So, from the beginning;

A docker-compose file, there is service-a (the main service) and service-b. I need service-a to ping to service-b.
And service-a has an environment variable to define the URL for service-b.

The happy case works right out of the box; service-a can reach http://service-b:1080

why? cause there is a default Docker network configuration (I pretend that this is already written in my compose file)

networks:
  default:
    driver: bridge

Which means:

Each service you define in the compose joins the network tagged default (its named like {folder-name}_default ).
Each service is automatically assigned automatically an IP address (like 172.x.x.x).
key thing: service-a can reach service-b by name cause this network already has a DNS resolution built-in

(I made up these IPs):

# DNS resolution example inside the Docker network
service-a -> 172.18.0.1:8080
service-b -> 172.18.0.2:1080

Quick note!

Inside the Docker network they can call each other using these names… but from your machine you can’t use these names.

It’s like in Zootopia.

In Zootopia, a bunny can call another bunny "cute," but when other animals do it, it's a little… well, you know what I mean.

This is the same, you computer can’t use the name alias referring to service-a, it needs to use localhost and the forwarded port, that’s why we do this forwarding port thing like 4080:1080

Anyway, this isn’t what I want to focus 👯,

because my particular use case has an additional key requirement:
service-a can not use http://service-b:1080 (there was an explicit code guard, an if) and NEEDED a address like http://domain.something:port, instead of http://service-b:1080

Note: due to this particular requirement (it was hardcoded in the code itself), I had to understand Docker networking a bit better; this post is about summarizing this mini-journey.

So, yay, easy right? if the requirement is:

- http://service-b:1080
+ http://service-b.local:1080

just create an alias:

service-b:
  image: ...
  networks:
    default:
      ports:
        - 4080:1080
+     aliases:
+       - service-b.local

So instead of

- http://service-b:1080
+ http://service-b.local:1080

Except this needs an extra step.

Remember that DNS mapping we have by default? we neet to create a subnet and assign the IPs to each service manually….

…maybe there’s a more ‘DevOps-ish’ way to do this? but I find statically assigning the IPs pretty straightforward, im opened to alternatives:

services:
  service-a:
    image: ...
+   networks:
+     default:
+       ipv4_address: 172.21.0.10
    environment:
      SERVICE_B_URL: http://service-b:1080

  service-b:
    image: ...
    networks:
      default:
+       ipv4_address: 172.21.0.20
        aliases:
          - service-b.local
    ports:
      - 4080:1080

+ networks:
+   default:
+     ipam:
+       driver: default
+       config:
+         - subnet: 172.21.0.0/24

IPAM means “Ey Docker, Im to assign manually the IPs”; The subnet part: 172.21.0.0/24 is creating a range of IPs between:

172.21.0.1 , 172.21.0.2 , 172.21.0.3 … 172.21.0.254

And I assign each service… honestly, somewhat random (.0.10, 0.20).

Just one thing left, the DNS; we need to tell service-a to map the name and the IP:

  service-a:
    image: ...
    networks:
      default:
        ipv4_address: 172.21.0.10
+   extra_hosts:
+     - "service-b.local:172.21.0.20"
    environment:
      SERVICE_B_URL: http://service-b:1080

And that’s it. Happy ending. service-a can now reach service-b using the name service-b.local, and everything works inside the Docker network.

The Project Ended. What to Keep.

Manuel Artero Anguita 🟨 — Tue, 05 Aug 2025 17:33:40 +0000

The project I've worked on for the last 3.5 years has shut down permanently. For good.

These things happen when building software. I guess it's human to feel... failure?
Even if it's unrelated to our tech work.

Projects die. This is a reality

We, tech workers, must gather the experience and move on.

So I started on this project in December 2021. The project was live for 6? 7 years when I came on board. I work at MegaCoorp™, pretty sure I've mentioned this in another post.

At this scale, a 'project' doesn't just mean devs. it's Product designers + designers + product management + marketing + legal + operations + customer service + dev + QA + infra team.

MegaCoorp™ is relocating all these people. I've already been allocated to another project (more on this in another post soon!)

---🪾---

I'm going off on a tangent. What I wanted to tell you today is,

what I think you should carry with you when you close the chapter on the last N years of your life ✨💕✨✨

Let it go. 🎶❄️🎵

Elsa working in Tech, generated by Grok3

NO, seriously.

Let it go.

Let the frustration, the rage, the bitter-ness fade

Those last N years did happen; but the project, your work, is gone.

There are just two things you should keep:

what you learned technically, so you'll apply those to your next step AND
the human connections you've made. Even if you're not going to interact with those people in the short term, I've learned that the tech world is really, like REALLY small.

You will–
listen–
you WILL meet some of those people again in your career. I bet you.

So, keep the tech learning, keep the human connections you've made. And let the rest go.

--
thanks for reading.

Reach Out to the Da Vincis of Our Time

Manuel Artero Anguita 🟨 — Tue, 29 Jul 2025 10:45:21 +0000

A reflection.

In the 15th century, if you wanted to learn from the best, you had to embark on a journey (picture the galleons and nao of that era) and try to reach the last known location of someone considered as master of their craft.

If you were lucky enough to find them, you could offer yourself as an apprentice and, with even more luck, learn directly from them.

Programming comes with an incredible advantage:

the great masters of our profession are alive.

Not only that, you can access them.
Most of them have blogs, or are active on social media.

You can read what they’re working on.
You can even write to them. Just like that.

Take advantage of it.

My Personal Top

Professionals who are also great teachers (no particular order):

Josh Comeau: Front end. CSS, Animations, React.
Wes Bos: Css, Animations, JS.
Matt Pocock: Typescript. AI Agents.
Dan Abramov: React, RSC.
Nadia Makarevich: React, Performance
Dominik Dorfmeister: React, Performance.
Ryan Florence: React, Remix.

Maybe Someone finds this useful.

--
thanks for reading.

Why I’ll Never Trust Carets Again

Manuel Artero Anguita 🟨 — Mon, 30 Jun 2025 14:17:37 +0000

There once was a good ol’ boy.
Grew up fixing things with instinct and duct tape,
built his apps the same way:
solid, fast, and no time to waste.

(this poem was created by ChatGPT im not hiding it)

One day, though, he had to delete his package-lock.json.

Maybe it got messed up. Maybe Git went weird. Maybe he just wanted a clean install. So he did what any of us would do:

rm package-lock.json && npm i

But that’s when the snake bit the horse.

Because somewhere in his package.json, hiding in plain sight like a viper 🐍 in the grass, were these little traps: ^1.2.3, ^6.0.1...

They looked harmless; just caret (^) versions. But those carets were telling npm:

“Yeah, sure, install the latest minor version. What could go wrong?”

And the internet, as always, did moved on.

A dependency of a dependency had released a "compatible" update.

Except it wasn’t.

A function behaved differently. The app crashed. Logs were useless. He didn’t even touch his code, and still… it broke.

All because of a version upgrade he didn’t control.

Cause ^6.0.1 isn't safe, 6.0.1 is what you do want.

See ya, old buddy.

The cases i can think of where ^ are going to bite you.

CI suddenly start failing: everything works locally. But a new version of a sub-dependency makes your tests fail. You waste hours debugging, thinking you broke something.
Two devs. Same codebase. Different node_modules because of ^ pulling different versions. One dev gets a bug. The other can’t reproduce it.
Breaking changes hidden in minor updates. If hte npm pacakge don’t follow semver. They might introduce breaking changes in a 1.4.0 that’s technically "safe" for ^1.2.3 (but it isn't).

How to ~~protect your buddy~~ solve this:

check this script: exact-versions.cjs on GitHub

it will replace all those nasty ^ with the actual version you've installed. Read the lock.json and replace the ^ with the correct version.

For instance this could be the output (changes to your package.json):

Ride safe buddy.

-- thanks for reading.

The JS Bundle Wars [1/n]

Manuel Artero Anguita 🟨 — Tue, 24 Jun 2025 16:26:48 +0000

If you're in the JS ecosystem, at some point you'll face this duo: esm & cjs...
are umd & amdstill a thing?

and you'll be like «what is exactly es referencing here?» «do i need es2020 or esnext?»

and if you have an internal library —especially if it’s frontend related–someone on the team will eventually ask:
«Wait, how are the assets/CSS being bundled exactly?»

that's The JS Bundle Wars.

It's a war.
isn't pretty.
isn't easy.

BUT it's interesting as f*

this topic could lead to a complete book (Have I mentioned I dream about writing a dev book and selling it on Amazon?)

Today, I’m just kicking things off...as every complex topic should, with a simple hello world.

I’m not even using React yet, let’s start with a plain Vanilla JS hello world page.

This is the repo im playing with: js-bundle-war

the code is super simple.
We just need an import, an index.html and the <script type="module"> tag.

index.html

is importing a ES module: main.js

Which in turn imports other ES modules: app.js

so far, so good.

I'm using Vite as bundler. I don't want to get back to webpack.

so , if we create a package.json and define how to build this:

 "devDependencies": {
    "vite": "6.3.5"
  },
...
 "scripts": {
    "build": "vite build "
 }

leaving the default vite.config (no config file at all), its' going to bundle this:

dist
├── assets
│   ├── index-16Psp_lK.js
│   └── index-CrYBktwj.css
├── index.html
└── vite.svg

which is the real thing. I mean, this is the actual code read/rendered by the browser.

let's open the bundled js shall we?

I highlight:

An initial IIFE to polyfill modulepreload: this is a Vite-specific detail. Vite uses modulepreload links in the HTML to prefetch JS modules for better performance.
BUT some browsers might not support modulepreload, so Vite includes a polyfill to make sure the assets are still fetched properly.
SOME SVGs are inlined in the build, while others are referenced as external modules.
(The screenshot was tweaked in this part — let’s take a clearer one to explain it better.)
The key difference is where we did place the asset:
- if it’s under /public, it’s served as-is;
- if it’s inside src/, it gets bundled as part of the code.

Our components, minified.
And finally, the last lines: our main.js file.

So, we're building modern ES modules, the bundling process takes our clean, modular code (what we wrote) and outputs the real .js file... which isn't meant to be read by humans but is executed by browsers.

This bundling process handles dependencies, minification, and assets.

...but

why are we even doing this? I mean, ok this is how we bundle , this is the output that is consumed by the browser... why? 🤔

That’s it for today — but this is just the intro, see you in the next article of the series.

Thanks for reading.

Library vs. Framework

Manuel Artero Anguita 🟨 — Sun, 15 Jun 2025 10:19:57 +0000

I really thought this was solid established, but the other day there was a bit of a discussion at work about React, and I was shocked.

This isn’t subjective. The difference is rock-solid 🤘🗿

~~Library: a collection of functions...~~ ok, no.
I loathe book definitions.

Nobody, ever, has truly learned something from reading a book-definition. (besides, defining something has this vibe: 🤓)

Let’s go real with this one

The key is who is executing the code.

If your code is executing the thing; you're using a library
If your code is being called by something else... something that expects it to be in a specific place, with a specific convention, then you’re using a framework.

Frameworks use your code as input. It’s code that is picked up and executed by the framework, following conventions like:

A function implementing some @Runnable interface.
A file named ${}-controller that is expected to contain specific exports.
A component function in a file whose path determines the route.

You feed the framework with your code. The framework executes.

React is a library

You’re in charge. You call it from your index file:

import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App.jsx';

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(<App />); // go react go!

You decide when and how to render.

You’re executing React.

Next.js is a framework

Cause, now, context does matter.

The following file is located at /app/page.tsx:

// app/page.tsx
export default function Home() {
  return <h1>Hello from Next.js</h1>;
}

cause the location itself has meaning. It tells Next.js:

ey, this function returns the component for the / route."
Next will compile the files in /app/, generate the routing, and execute that function at runtime.

There is code in shadows, it does something like this:

// at some point behind the scenes...
import FunctionWrittenByDev from './app/page.tsx';

app.get('/', (req, res) => {
  const html = renderToHTML(<FunctionWrittenByDev />);
  res.send(html);
});

You export a function. The framework runs it.. That’s the key.

Thanks for reading.

My Local Works™: A Docker Tale (+ Handy Script)

Manuel Artero Anguita 🟨 — Fri, 13 Jun 2025 12:34:02 +0000

Today I faced one of those "this is Witchcraft" moments.

CI was failing for a specific commit. I checked out that exact commit locally… everything clean. Built fine. No errors.

Witchcraft 🧙! "I'm exactly on the same commit, and in my local machine it does build with no problems".

This was a JS project. And in JS (TS doesn’t matter here), my first suspect is always dependencies.
So, I removed node_modules and rebuilt from scratch.

Witchcraft x2 🧙🧙! still couldn’t reproduce the error.

So I went to the workflow file and started following step by step what CI was doing.

Witchcraft x3 🧙🧙🧙! it can't b... oh wait.

Of course the CI runs everything in a clean, pure node:20-alpine image.

So I fired up the same container locally to see what was going on.

Now, this is just he context to what i want to share:
I use this tiny script like...a lot.

If you use oh-my-zsh, you can add it to ~/.oh-my-zsh/custom/docker-run.zsh (adapt to your setup):

docker-run.zsh

function docker-run() {
    if [[ -z "$1" ]]; then
        echo "Usage: docker-run <image>"
        return 1
    fi

    local container_image="$1"
    local workdir="/app"

    docker run --rm -it \
        -v "$PWD:$workdir" \
        -w "$workdir" \
        "$container_image" \
        /bin/sh
}

Super simple. Just go to your project folder:

$» docker-run node:20-alpine
/app #

The devil’s in the details:

--rm so the container is gone when you exit
$PWD mounts the current project inside the container
it so you’re dropped into the terminal
sh cause these minimal images usually don’t have bash

Back to the mysterious "Witchcraft!🧙 error" —>
Turned out there was a node version mismatch: v20.18.1 locally vs. v20.19.2 in the container.

No magic for today.

--
thanks for reading.