Forem: Juan Rueda

Agile Is Not About Speed

Juan Rueda — Wed, 11 Mar 2026 00:00:00 +0000

Speed without direction is just chaos with a deadline.

Along my professional journey, I've come to realize that many people confuse what Agile and Scrum actually mean. It is not about speed, or delivering ultra fast. It is about being resilient to change and delivering value constantly.

I've sat through countless meetings where a manager says "we need to be more agile" and what they really mean is "we need to ship faster." That's not agile. That's just pressure with a trendy label.

What Agile Actually Means (And What It Doesn't)

The Agile Manifesto was never a productivity hack. Read it. It says nothing about velocity charts, burndown metrics, or cramming more story points into a sprint. Its actual goal is to bridge the gap between technical and non-technical stakeholders, deliver real value to users, and most importantly, be able to shift gears when the world changes under your feet.

Here's the thing: when agile is applied well, teams do deliver faster. But that's a side effect, not the goal. It's like exercise. You don't run to sweat. You run to get healthy, and sweating just happens along the way. Teams that genuinely embrace agile can orchestrate changes across large codebases without the usual delays and miscommunication. Not because they're rushing, but because they've removed the friction.

The Ceremonies Nobody Wants (But Everyone Needs)

Let's be honest. Nobody wakes up excited about a daily standup. Sprint planning can feel like pulling teeth. Retros sometimes devolve into polite silence or complaint sessions.

But here's what those ceremonies actually do: they build synergy. And I don't mean that in the corporate-buzzword way. I mean that a team that talks every day, that plans together, that closes a sprint and reflects on what happened, develops a shared rhythm. They start anticipating each other. They know who's blocked before they ask. They course-correct in days instead of months.

The alternative? Feature branches that drift for weeks, a "big reveal" at the end of a quarter that nobody asked for, and the classic "but I thought you were handling that" conversation.

I'll take the standup, thanks.

Trunk-Based Development: One Truth, Many Hands

Speaking of tools that make agile actually work, trunk-based development is one of the most underrated. The idea is simple: everyone works against a single source of truth. No long-lived feature branches. No merge request that sits open for two weeks collecting cobwebs.

If conflicts arise, they surface early and get tackled in small increments. Compare that to the alternative: three developers working in parallel on branches for a month, then spending an entire Friday playing merge-conflict whack-a-mole right before a deploy. We've all been there. It's not fun.

Trunk-based development doesn't eliminate conflict. It makes conflict manageable. And that's a very different thing.

Automate Everything You Don't Want to Screw Up

Here's a paradox I love: manual testing is done by humans to ensure quality, and yet humans are terrible at repetitive quality checks. We get bored. We skip steps. We convince ourselves "I already checked that, it's fine." Then production breaks at 2 AM.

Automating your deployment and release process removes the human error from the equation. But automation isn't just about CI/CD pipelines. It's about automated tests that run every single time, without fatigue, without shortcuts, without "I'll write the tests later" (spoiler: later never comes).

Automated tests are a safety net. They don't guarantee you won't fall, but they guarantee the fall won't kill you.

Test-Driven Development: Writing Code With Intent

Test-Driven Development takes this a step further. You write the test before the code. Sounds backwards? It's actually the opposite. You're forced to think about what the code needs to do before you think about how.

That single shift changes everything. You stop over-engineering. You stop building features nobody asked for. You write exactly what's needed and nothing more. Pair that with end-to-end testing, and you get a layered verification system where unit tests handle the details and E2E tests handle the flow.

The result? Cleaner code, fewer bugs, and the confidence to refactor without breaking things. When the test comes first, the design follows.

Domain-Driven Design: Speaking the Same Language

All of these practices, agile ceremonies, trunk-based development, automated testing, TDD, they work even better when wrapped in a Domain-Driven Design approach.

DDD is one of those concepts that sounds academic until you live through the problem it solves. I've been in rooms where the backend team calls something an "Order," the frontend calls it a "Request," and the product owner calls it a "Transaction." Same thing, three names, endless confusion. DDD fixes that by establishing a shared language, a Ubiquitous Language, so that when someone says "Order," every person in the room pictures the same thing.

Beyond naming, DDD helps you draw clear boundaries between services. Changes in billing don't ripple into shipping. Each domain owns its logic. It's not just good architecture. It's organizational sanity.

The AI Era: Agents, Prompts, and the Developer's New Role

And then there's the elephant in the room. In the era of AI, new paradigms are emerging. Agent-driven development is reshaping what it means to be a developer. The human has become more of a manager and auditor of the software. In extreme cases, developers have turned into prompt architects, feeding direction to swarms of agents that do the heavy lifting.

I find this fascinating and slightly terrifying in equal measure.

But here's my take: this doesn't diminish the value of engineering fundamentals. If anything, it amplifies them. An agent that writes code without agile principles, without tests, without clear domain boundaries? That's not productivity. That's chaos at scale. The principles we've been discussing aren't made obsolete by AI. They become the guardrails that keep AI-generated code from going off the rails.

The developer who understands TDD, DDD, and trunk-based development will guide agents to produce maintainable software. The one who doesn't will just produce more technical debt, faster.

The best methodology is the one that keeps you moving forward, not the one that keeps you busy.

Simple vs Complex: When to Level Up Your Solutions

Juan Rueda — Mon, 05 Jan 2026 00:00:00 +0000

Complexity is like salt, essential in the right amount, but ruinous if you pour the whole shaker.

I recently came across a dev commentary that sparked an interesting discussion about solution complexity. The scenario involved implementing an internal feature to convert natural language into SQL queries. A tenured engineer (with what you might call a god-like complex, pun intended) suggested building a complex RAG system in-house. The alternative? A simpler approach: connect ChatGPT or Claude to a read-only database and teach users basic prompting techniques to generate the queries they need.

Both solutions work. But that's not really the question, is it? The real question is: which solution makes sense for your constraints, your scale, and your team?

The Cost-Effectiveness Lens

I believe we need to weigh cost-effectiveness and necessity before jumping to either extreme. Let me share a personal example that illustrates this principle perfectly.

The Unicode Book Name Problem

In our book catalogue system (names changed to protect the innocent), we encountered an issue with special non-ASCII characters in book names. The problem stemmed from using VARCHAR for the name field in our T-SQL schema, which can't properly handle Unicode characters.

The correct solution from the start would have been using NVARCHAR to support Unicode. But that comes with a cost: double the storage size for that field. It's a tradeoff that should have been made during initial design, but hindsight is 20/20.

That only solves half our problem anyway. We have existing books with malformed characters. The book masters want us to strip these characters out (yes, this will create some weird names temporarily, but there's a post-processing strategy to fix them later, bear with me).

Iteration 1: The Naive Approach

The simplest solution? A straightforward UPDATE statement:

UPDATE Library.Books
SET Name = Library.cleanBookNameFn(Name)
WHERE Library.cleanBookNameFn(Name) != Name

Simple enough. If our cleaning function produces a different result, update the name. But this is inefficient. We're invoking the function twice per row , doubling our processing cost and locking the table longer than necessary.

Iteration 2: Table Variables

An improvement would be using a table variable to separate the computation from the update:

-- Retrieve all books with dirty names
DECLARE @BooksWithDirtyNames TABLE (IdBook INT, CleanName VARCHAR(MAX))
INSERT INTO @BooksWithDirtyNames (IdBook, CleanName)
SELECT IdBook, Library.cleanBookNameFn(Name) as CleanName
FROM Library.Books WITH (NOLOCK)

-- Update book names in a single sweep
UPDATE Library.Books
SET Name = new.CleanName
FROM Library.Books b
INNER JOIN @BooksWithDirtyNames new ON b.IdBook = new.IdBook

Better. We're still calling the function for each affected row, but we're not locking the table during computation, only during the update. This assumes no users are actively updating book names with special characters (an edge case we can probably ignore).

This performs reasonably well for tables with up to a hundred thousand books, especially during off-peak hours. Even then, it might take 10+ minutes to complete.

But what about larger tables? What if you have hundreds of thousands (or millions) of records in a highly concurrent table that's central to your business logic? Suddenly, this "simple" solution becomes inefficient and unviable.

Iteration 3: Batched Processing with Temp Tables

When simple reaches its limits, it's time to be more resourceful. For backfills on huge, highly concurrent tables, we need a different strategy: batch processing with temporary tables.

-- Ensure the temporary table doesn't exist
DROP TABLE IF EXISTS #BooksWithDirtyNames

CREATE TABLE #BooksWithDirtyNames (
    IdBook INT PRIMARY KEY,
    CleanName VARCHAR(9000), -- Using MAX may be overkill
    Cleaned BIT DEFAULT 0 
);

INSERT INTO #BooksWithDirtyNames (IdBook, CleanName)
SELECT IdBook, Library.cleanBookNameFn(Name) as CleanName
FROM Library.Books
WHERE Library.cleanBookNameFn(Name) != Name

DECLARE @WindowSize INT = 2000; -- Fine-tune for optimal performance
DECLARE @CleanedRows INT = 1;
DECLARE @CleanedTotal INT = 0;

WHILE @CleanedRows > 0
BEGIN
    UPDATE TOP (@WindowSize) book WITH (ROWLOCK) -- Row-level locking prevents inconsistencies
    SET Name = new.CleanName
    FROM Library.Books book
    INNER JOIN #BooksWithDirtyNames new ON book.IdBook = new.IdBook
    WHERE new.Cleaned = 0;

    SET @CleanedRows = @@ROWCOUNT; -- Iterate until nothing left to update
    SET @CleanedTotal = @CleanedTotal + @CleanedRows 

    UPDATE TOP (@WindowSize) new
    SET Cleaned = 1
    FROM #BooksWithDirtyNames new
    WHERE Cleaned = 0;

    IF @CleanedRows > 0
        WAITFOR DELAY '00:00:00.100' -- Small delay allows other transactions to proceed
END

PRINT 'Total records updated: ' + CAST(@CleanedTotal AS VARCHAR(20));

DROP TABLE #BooksWithDirtyNames

Yes, this is definitively more complex. But we gain significant advantages:

Performance control : We can fine-tune the window size for optimal throughput
Minimal disruption : We don't lock a crucial table for extended periods
Flexibility : We can run this during business hours if needed
Observability : We can track progress and adjust on the fly

The Principle: Iterate Deliberately

There's no universal "rule of thumb" or "one size fits all" solution. But I do believe in systematic analysis and strategic iteration.

Here's my approach:

Start small and simple - Implement the most straightforward solution first
Analyze the impact - Measure performance, identify bottlenecks, observe real-world behavior
Understand the constraints - Consider scale, concurrency, business requirements, and team capacity
Have a clear goal - Know what "good enough" and "excellent" look like for your use case
Iterate deliberately - Add complexity only when simpler approaches demonstrably fail

This way, solutions unfold organically and, most importantly, logically and understandably. You're following a process others can understand and replicate, dramatically reducing the "WTF per minute" metric (assuming we document clearly).

Back to the RAG vs API Question

Returning to the original natural language to SQL scenario: maybe the simple API integration handles 90% of use cases perfectly. Maybe the complex RAG system is needed for security, offline operation, or specialized domain knowledge. The point isn't which is inherently better. It's understanding your specific context well enough to make an informed choice.

And sometimes, like with our book name cleanup, you start simple and discover you need to level up. That's not failure. That's engineering.

Complexity is a tax you pay every time you touch the code. Make sure the purchase is worth it.

From Startup CTO to Enterprise Tech Lead: What I Learned About Leadership

Juan Rueda — Fri, 26 Dec 2025 00:00:00 +0000

Sometimes you have to trade the compiler for a calendar.

I used to think I was a CTO. In my previous role at a small startup, I designed the entire application architecture from scratch, managed backend and database design, handled DevOps, and orchestrated our APIs. I was a one-man army who eventually mentored a growing team of frontend developers working on our complex 3D product design tool. I was strict about code style, made all the tough technical decisions, and people came to me when they hit walls.

But as I gained experience, I realized something: I wasn't a CTO. I was a Tech Lead. And that distinction taught me one of the most important lessons of my career.

The Illusion of Technical Excellence

We started with no roadmap, just a goal and my technical vision. I vested myself as CTO because, well, someone had to. I mentored engineers from zero background to full-fledged developers, pushing them beyond their comfort zones while maximizing their strengths. When they became capable enough, I learned to trust them with critical work.

We grew tremendously as individuals and professionals. But the project? Not so much.

That's when the hard truth hit me: code alone doesn't make a product. You can write beautiful software, follow every best practice, ship relentlessly, but if there's no real value being delivered, the software is effectively dead. The solution matters more than the code.

We didn't have a tech bottleneck. We had a management problem.

I left because it became a burden, like a toxic relationship where I'd invested everything but received little in return. Sure, they kept the code, but I built it, and they can't take that talent. They miss me for that. The only consolation: I never stopped trying to improve myself.

A Different Kind of Challenge

Now I work for a big company with a massive software ecosystem. The contrast couldn't be starker.

Before, I called all the shots and held the master key to everything. Now, even when I have brilliant database optimizations with tremendous positive impact, I need to convince DBAs it's the right call. I need to dance through processes and arrangements just to gain access to critical systems. Minimum privilege access. Yay!

It's frustrating at first. Going from architect of everything to needing permission for routine tasks feels like a demotion.

But here's what I discovered: once a Tech Lead, always a Tech Lead.

Leadership Without Authority

In less than six months, I've moved between teams, had two manager changes, and experienced constant organizational shifts. Change is the only constant. Yet somehow, I've managed to make an impact:

I learn fast and stay ahead of the curve.
I unblock QA when they need fixes so features ship on time.
I provide genuine feedback to peers because I truly value their work.
I focus on results and being helpful.

I'm no longer the mastermind behind everything. Honestly, I feel clueless sometimes. But I do my research, I constantly learn, and I prove myself through outcomes.

Now they want me to become a Technical Leader/Owner. After less than six months. While I'm still learning the business domain and internal workings. They appreciate how I tackle problems, and my manager sees me as an asset who helps achieve team goals, not as a responsibility to manage.

What Leadership Actually Means

Some people think being a leader means being a boss, telling others what to do and how to do it.

That's not leadership.

A leader paves the way and shows how things get done. A leader provides insight and listens to feedback.

In war room discussions or architectural design meetings, I barely talk. I let my peers lead the conversation because they're confident and have strong input. I trust them, and I want to learn how they approach problems. When I do speak up, it's to ask follow-up questions or respectfully disagree when needed, not to justify my position or hijack the meeting.

A leader isn't obligated to dominate every discussion. A leader is entitled to disagree, ask questions, and broaden the scope so the team makes informed decisions together.

Lessons for Aspiring Leaders

I'm still learning, and I have a long way to go. But I'm surrounded by smart, capable peers who teach me something new every day. If I had to share what I've learned so far:

Be proactive. Ask any doubts you have. Don't be scared to sound silly or disagree with something that doesn't convince you.

Don't wait for others. Instead of relying on your manager to reach out to the client for input, ask the client directly. First-hand insight is invaluable.

Be methodical. Develop rituals in your routine that help you tackle daily goals, which accumulate into weekly and monthly progress, which impact your long-term objectives. Don't lose focus of yourself.

Know your role. A leader isn't someone who knows all the answers. A leader is someone willing to find them and provide solutions. And when they're not the ideal person to solve a problem, they make sure to find the right person who can.

True leadership isn't measured by the code you write, but by the engineers you grow.

Why I Keep My Kids Away From Screens (Even Though I Work in Tech)

Juan Rueda — Mon, 22 Dec 2025 00:00:00 +0000

Sometimes the best firewall is a physical one, made of wooden blocks and pure imagination.

Next week, my youngest turns one. My oldest is eight. As a father who spends over eight hours a day staring at screens for work, I've made a choice that surprises many people: I deliberately keep my children away from tablets, smartphones, and the digital noise that dominates modern childhood.

This isn't technophobia. This is informed caution.

The Paradox of the Digital Worker

I live in code. I architect systems. I debug, deploy, and iterate. Yet when I need to truly retain information, in a meeting, during a critical discussion, I reach for something analog: a real notebook and a pen.

There's something about the physical act of writing that creates a different kind of engagement. My hand moves, my brain processes in real time, acting as a throughput for information rather than a passive receiver. The connection between listening, thinking, and writing forces focus in a way that typing on a keyboard never quite achieves. I retain more. I understand deeper.

If I, someone who builds digital systems for a living, need to step away from screens to think clearly, what does that tell us about developing minds?

The Nintendo Switch Principle

My eight-year-old doesn't own a laptop or smartphone. He has a Nintendo Switch, and I love it for one specific reason: it's just a gaming device. No Spotify. No Google. No real internet access. No infinite scroll of content designed by engagement engineers to hijack attention.

When it's meal time, he turns it off. When he's ready to play again, he turns it on and resumes exactly where he left off. No lost progress. No notifications pulling him back in. No algorithms learning his preferences to serve him "just one more" video.

I still remember my mother's frustration when I was a kid, unable to understand that some games couldn't be paused. He's too young for online multiplayer, but the principle stands: we've designed a boundary around gaming that keeps it contained, intentional, and controllable.

And the beautiful thing? He handles time away from screens marvelously. He plays with his toys, makes up elaborate stories, builds worlds from his imagination. His creativity isn't depleted; it thrives.

What We're Really Stealing

I've seen children his age who own smartphones, who play Roblox (which I genuinely believe is a pedophile's playground), who lack any sense of imagination. It breaks my heart because I know what's been stolen from them, not maliciously, but carelessly.

Their parents didn't set out to harm them. They wanted to buy themselves some peace, some "quality time" without the constant demands of engaged parenting. And I get it. Parenting is exhausting. But the trade-off is devastating.

Yes, those kids are "tech savvy." They can navigate apps better than my son can navigate a computer login screen. He still depends on us to open his school assignments. He struggles with digital tasks that his peers breeze through.

But I'm not in a hurry.

He'll have decades to become fluent in digital interfaces. He'll learn when he's developmentally ready, when he can communicate assertively, when he actually needs a phone for safety or coordination. And even then, it won't be a smartphone, it'll be a basic device with Snake or Brick Breaker, something that serves a purpose without becoming a portal to infinite distraction.

The Infra Engineer Who Won't Smart-Home

There's an old saying in tech: true infrastructure engineers don't have smart homes. They've seen behind the curtain. They know the vulnerabilities, the data collection, the attack surfaces. They understand that the convenience isn't free, it's financed by surveillance, by vendor lock-in, by security risks that most consumers never consider.

I apply the same logic to childhood screen exposure. I know enough to know that the risks outweigh the benefits. The price we pay for that "freemium" childhood is far higher than most parents realize: depleted attention spans, reduced frustration tolerance, algorithmic manipulation, privacy invasion, and the slow erosion of the skills that make us human.

Building Humans, Not Users

I'm not protecting my children from technology. I'm protecting their humanity.

I'm giving them the gift of boredom, which is the birthplace of creativity. I'm teaching them frustration tolerance by not letting them skip past every moment of difficulty with a dopamine hit. I'm preserving their ability to engage with the physical world, to "touch grass," to develop the deep focus that will become increasingly rare as AI handles more of our cognitive load.

These aren't just soft skills. These are survival skills for an uncertain future.

While their peers may grow up dependent on ChatGPT to decide what to eat for breakfast, my children will have something more valuable: the ability to think critically, to create from nothing, to adapt to changing circumstances, and to maintain their agency in a world designed to extract it.

When the time comes for them to engage with technology, and it will come, they'll do so from a position of strength. They'll have the cognitive tools to use technology rather than be used by it. They'll have imaginations that weren't outsourced to algorithm-driven content. They'll have experienced enough of reality to know when the digital world is failing them.

The Long Game

This approach isn't easy. My son struggles with online school assignments while his classmates don't. We have to be more present, more engaged, less able to use screens as a babysitter. We get judged by other parents who think we're overprotective or unrealistic.

But next week, when my youngest turns one and we celebrate another year of protecting their childhood, I'll know we made the right choice.

Because in a world where everyone is optimizing for convenience, we're optimizing for humanity.

And that's a bet I'm willing to make.

In a world of infinite digital input, the most radical act of rebellion is to remain beautifully, inefficiently analog.

The Mechanical Turk Redux: Why Your AI Assistant Carries a Wand

Juan Rueda — Fri, 19 Dec 2025 00:00:00 +0000

The original black box algorithm: A human hidden inside a machine.

The other day, I stumbled upon a thought-provoking post that asked a seemingly whimsical question: Why do so many AI tools dress themselves up with wands, crystal balls, and mystical imagery? The answer, it turns out, takes us back to one of history's most elaborate illusions, the Mechanical Turk.

The Original Illusion

For over 80 years, the Mechanical Turk toured the world, challenging chess masters and dignitaries alike. It defeated Benjamin Franklin. It beat Napoleon Bonaparte. This automaton, dressed in Ottoman robes and sitting behind an ornate cabinet, appeared to be the world's first thinking machine, a genuine artificial intelligence before electricity was even properly harnessed.

Except it was all a hoax. Hidden inside that elaborate cabinet was a human chess master, operating the mechanical arms through a clever system of levers and magnets. The Turk wasn't artificial intelligence at all. It was artificial artificiality, an illusion wrapped in gears and showmanship.

Sound familiar?

The Modern Illusion

Today's Large Language Models are, in many ways, our generation's Mechanical Turk. Don't get me wrong, they're remarkable technological achievements. But they're not the "real AI" that science fiction promised us. They're extraordinarily sophisticated text prediction machines, pre-trained on massive datasets and frozen in time at the moment of their training.

Here's the uncomfortable truth: LLMs don't learn. They don't get smarter through experience. When GPT-5 or Claude 5 arrives, it won't be because the previous model evolved. It will be because engineers trained an entirely new model from scratch on new data.

And that's where things get interesting, and a bit terrifying.

The Model Decay Problem

We're rapidly approaching a crisis point. As AI-generated content floods the internet, we risk training future models on content created by previous models. It's like making a photocopy of a photocopy of a photocopy. Each generation loses fidelity. Each iteration risks amplifying the biases, hallucinations, and artifacts of its predecessors.

This phenomenon, sometimes called "model collapse" or "model decay," threatens the very foundation of how we improve these systems. The internet, once a vast library of human knowledge and creativity, increasingly resembles a hall of mirrors reflecting AI-generated content back at itself.

The Illusion of Intelligence

LLMs are brilliant mimics. They can write poetry, debug code, explain quantum physics, and even simulate empathy. But it's crucial to understand what they are: pattern-matching engines operating at incomprehensible scale and speed. They have no intuition, no genuine reasoning, no understanding in any meaningful sense.

Yet their capabilities are undeniable. They process information faster than any human ever could. They can synthesize information across domains in milliseconds. They're becoming so pervasive that we're approaching a future where computing intelligence is truly ubiquitous. Embedded in our environments, available everywhere and at all times.

Soon, even your milk carton might have more computing power than the Apollo missions (and yes, it might tell you when you're out of milk before you know it yourself).

Don't Be Fooled by the Automaton

This is why developing a certain kind of literacy, let's call it "AI skepticism", is more critical than ever. We need to see through the illusion, to understand the Mechanical Turk for what it is: impressive mechanics, not genuine intelligence.

The mystical imagery, the wands, the crystal balls, the magical branding, isn't accidental. It's the modern equivalent of the Turk's Ottoman robes and ornate cabinet: theatrical dressing designed to make the technology feel more capable, more mysterious, more intelligent than it actually is.

What Makes Us Human

In this AI-saturated future, our uniquely human capabilities become not just valuable, but essential:

Critical thinking : The ability to question outputs, to probe for weaknesses, to ask "does this actually make sense?"

Deduction : The capacity to reason from first principles, to spot logical fallacies that pattern-matching might miss.

Intuition : That ineffable "gut feeling" that something is off, even when the surface looks perfect. The kind of knowing that comes from lived experience, not statistical correlations.

No machine will possess true intuition until we figure out how to give them actual guts. And I mean that both literally and figuratively (though I'm not holding my breath for biological AI anytime soon).

Moving Forward

I'm not arguing that LLMs are useless. Far from it. They're powerful tools that can augment human capability in remarkable ways. But they are tools, not colleagues. They are sophisticated instruments, not thinking beings.

The danger isn't that these systems are too intelligent. It's that we might mistake their fluent outputs for genuine understanding. That we might defer to their certainty when we should be exercising skepticism. That we might let our own critical faculties atrophy because it's easier to ask an AI than to think through a problem ourselves.

The Mechanical Turk fooled audiences for 80 years. Let's not let history repeat itself.

As we hurtle toward a future of ubiquitous intelligence, real or simulated, our greatest asset isn't the AI in our pocket. It's the messy, intuitive, gloriously imperfect intelligence between our ears.

Don't let the wand and crystal ball fool you. There's still a person hiding in that cabinet. It's just that now, the person is you, and you're the one who needs to stay sharp.

In a world of artificial illusions, reality is the only magic that matters.

The Pragmatist's Dilemma: When 'Wrong' Solutions Work Better

Juan Rueda — Wed, 17 Dec 2025 00:00:00 +0000

Sometimes the crooked path is the only one that leads home.

There's a certain satisfaction in doing things "the right way." We read the RFCs, we follow the best practices, we architect our systems according to well-established patterns. But sometimes, in the trenches of real-world development, you encounter solutions that make you pause and think: "Wait, that's not how you're supposed to do that... but it actually makes sense."

The Base64 Revelation

I recently stumbled upon something in our company's web platform that challenged my assumptions about file uploads. Instead of the standard multipart/form-data approach we all learned to use (probably with multer or similar libraries), our custom API requires files to be converted to base64 strings and embedded directly in JSON payloads.

My first reaction was textbook: "That's inefficient! Base64 encoding bloats the file size by approximately 33%." And I'm not wrong about that. A 1MB file becomes 1.33MB when base64-encoded. On paper, this is wasteful, especially at scale.

But here's the thing: it works beautifully for our use case.

The Hidden Benefits of "Inefficiency"

When you step back from the theoretical overhead, some practical advantages emerge:

Simplicity in testing. No need to wrestle with multipart forms in your API client. Every request is just JSON. You can test endpoints with a simple curl command or any basic HTTP client. The friction disappears.

Consistent serialization. Your entire request body follows the same structure and validation patterns. No special handling for file parts versus data parts. The mental model is cleaner.

Easier debugging. JSON is human-readable. You can log entire requests, inspect them in browser dev tools, and understand exactly what's being sent without specialized tooling.

For an internal API serving a controlled set of clients with modest file sizes, that 33% overhead might be a small price to pay for dramatically improved developer experience.

Code-First Templates: Another "Wrong" That's Right

I encountered another unconventional choice recently. One of our backend developers generates CSV templates dynamically in code rather than storing static template files in the assets folder.

My instinct said: "Just put the CSV in assets. Why generate something that never changes?"

But his approach has merit:

Single source of truth. The CSV structure lives in the same place as the code that validates and processes uploaded CSVs. When the schema changes, the template automatically reflects it. No risk of the template and validation logic drifting apart.

No asset management overhead. No questions about cache invalidation, versioning, or deployment pipelines for static files. It's just code.

Programmatic flexibility. Need to add helpful comments or examples based on user permissions? Need to generate slightly different templates for different contexts? The code can handle it.

Yes, you're "wasting" CPU cycles generating the same CSV repeatedly instead of serving a static file. But we're talking about microseconds of processing time versus the very real cost of maintaining consistency between code and assets over time.

The Pattern: Optimizing for Maintainability

Both of these "wrong" solutions share a common thread: they optimize for maintainability and developer experience rather than theoretical efficiency.

This isn't new. The entire history of software development is filled with examples of "slower" solutions winning because they made developers more productive:

Python is slower than C, but we use it anyway
React's virtual DOM adds overhead, but simplifies our mental model
Docker containers have more overhead than bare metal, but we containerize everything

The key insight is understanding what you're actually optimizing for.

When to Break the Rules

I'm not advocating for throwing out best practices. Base64-encoding gigabyte-sized files would be ridiculous. Generating massive, complex templates on every request would be wasteful.

The question to ask is: What are the actual constraints of my system, and what trade-offs make sense given those constraints?

For our internal API with controlled clients and modest file sizes, the base64 approach works. For CSV templates that are tiny and generated infrequently, code-first makes sense.

The "right" way is contextual.

The Pragmatist's Mindset

As engineers, especially as senior engineers who've been burned by technical debt, we can become dogmatic about best practices. We've seen the consequences of shortcuts, and we're rightfully cautious.

But there's wisdom in recognizing when a solution that seems "wrong" by the book is actually the most pragmatic choice for your specific context. Sometimes the code that makes you raise an eyebrow on first glance is the same code that will be easiest to maintain three years from now.

The craft isn't just in knowing the patterns. It's in knowing when to apply them, when to adapt them, and when to ignore them entirely.

After all, there are many ways to kill a mockingbird. The best way depends on what you're actually trying to accomplish.

The map is not the territory. In the end, our job isn't to follow patterns, but to solve problems.

Google DevFest Quito: A Journey into Modern Engineering

Juan Rueda — Mon, 16 Dec 2024 00:00:00 +0000

The volunteer got a bit nervous and skipped the 'n' in my name, so we had to perform a hot-fix and squish it in.

This past month, I attended Google DevFest Quito 2025 at Universidad San Francisco de Quito. While the event showcased the latest from Google, the real value lay in the architectural discussions that cut through the hype. It wasn't just about tools; it was about strategy.

Here are the key takeaways that are reshaping my perspective on modern engineering.

📊 Modern Data Architecture: Actionable vs. Just "Big"

Speaker: Erick Andre Naunay

The industry definition of "Big Data" is maturing. It's no longer just about hoarding terabytes; it's about shifting from "data without action" to data as a competitive advantage. If your data doesn't drive decisions in minutes, it's just a cost center.

The Shift to ELT

The classic ETL (Extract, Transform, Load) model is rigid and hard to scale. The modern approach is ELT (Extract, Load, Transform), where raw data lands first, and transformations happen within the warehouse.

Transformation Layer : Tools like dbt (data build tool) allow us to version, test, and document transformations like software code.
Orchestration : Mage AI was highlighted as a modern alternative for orchestrating pipelines, integrating seamlessly with Spark and monitoring tools.

The Medallion Architecture

To ensure quality, data should flow through distinct layers:

Bronze : Raw data (Data Lake).
Silver : Cleaned and filtered data.
Gold : Business-level aggregates ready for consumption.

Crucially, Kimball modeling remains the gold standard for structuring this "Single Source of Truth," proving that foundational theory often outlasts trend cycles.

🧠 Agentic AI & The Local Web

Speakers: Braulio Otavalo & Erick Wendel

We are moving past the era of simple chatbots into Agentic AI , systems with memory, reasoning, and tool access. But the most interesting shift isn't in the cloud; it's in the browser.

The Browser as an AI Runtime

Erick Wendel demonstrated that the web is evolving. With Chrome's built-in AI APIs, we can run LLMs locally. This solves two massive problems: Privacy (data never leaves the device) and Cost (no per-token fees).

Small Language Models (SLMs)

The future is likely Small Language Models. They are operational, cost-effective, and fast. While they struggle with the O(n^2) complexity of transformers, for specific tasks, they blow massive models out of the water in terms of ROI.

Other notables: Model Context Protocol (MCP) for standardizing tool access, and llms.txt as the new robots.txt for AI crawlers.

⚙️ Infrastructure as Code: Foundational, Not Optional

Speakers: Luis Carlos Reyes Vanegas & Camilla Martins

In 2024, "click-ops" is technical debt. Scalability, security, and maintainability must be baked in from day one.

The winning formula presented was IaC + AI + Google Cloud :

Terraform: Provides the immutability and state management required for team collaboration.
Traceability : Every change is versioned. If it's not in code, it doesn't exist.
Environment Parity : Creating exact replicas of Prod in QA and Dev environments becomes trivial, reducing the "it works on my machine" syndrome.

🎨 Domain Driven Design: Organization as Code

Speaker: Tex Albuja

DDD is often treated as abstract theory, but Tex framed it as an organizational necessity. The biggest challenge in product teams isn't coding; it's communication.

Event Storming

The highlight was a practical approach to Event Storming using a standardized color code for sticky notes:

Orange : Domain Events (Past tense verbs, e.g., OrderPlaced).
Pink : Problems/Risks.
Blue : Commands (Imperative, e.g., PlaceOrder).

This visual language allows the design to "emerge" naturally. By clearly defining Bounded Contexts , we ensure that changes in one domain (e.g., Shipping) don't ripple out and break another (e.g., Billing). It’s about keeping systems decoupled and maintainable.

Thanks to the GDG Quito team for hosting such a high-signal event. It’s exciting to see the local community converging on these global best practices.

Mac M1 | Apple Silicon - Death Valleys

Juan Rueda — Mon, 17 May 2021 16:38:56 +0000

Sweet Apple MacBook M1

I am not an apple fan/boy. I mean, I get it. They provide this unique and friendly ecosystem of products that now are consolidating under one hardware architecture. But along those changes, their OS also changes too. On previous jobs I used the iMac 4K 27 inch display. They used intel and they were nice. And working on those machines is pretty sweet! I think it was macOS Catalina?

Personally I own an ASUS gaming machine with windows, I mostly use it for gaming! But I can tell that many workflows change and maintaining the code can have slight differences on either OS. Which was the brand new macOS BigSur meant for the apple silicon systems that they were releasing.

just use docker!

Yeah! We did! An amazing guy setted up our dev-ops and I never managed to run some bash scripts on my docker windows container.

insertSadFace.webp

Anyways, run forward to last week and I've just got a brand new Macbook Air M1. I remember that Big Sur brought some aesthetic and GUI changes overall. But I had no issue getting use the the machine...

Until I decided to do a factory reset and deleted the disk.

Never delete the disk

Usually, or at least it's how I used to do this. I would delete everything from the disk. And do a fresh install of the OS. Yeah, ok. But why?! You might be asking yourselves. And well, I do this when I want to sell it. Or I usually leave the company so I hand all the work and I do a factory reset. This time I just needed to do it because "work reasons". So, when I tried to do the fresh install of the OS I came with an odd looking message:

No users available for authorization.

What?...

I have never encountered this before. So I decided to do a google research, and things started to look dark.

Some dude on Reddit said:

M1 machiens have a known issue with Restoring. Basically, it doesn't work.

Link to reddit thread

Holy fudge, I almost flipped and after some digging and one and a half hour of cold sweating; I managed to fix it like this:
(I had around 4 hours to solve it before I met with the IT security officer to see some features I needed)

Solution to this

Start up in Recovery Mode
From the Utilities Open the terminal
In the terminal run resetpassword
This will prompt you to a screen where it tells you there are no users.
On the bottom part there should be an option for Delete Mac (You can also select this option from the task bar).
After it reboots the Recovery Utility open the Disk Utility.
Create a new Volume. (My default vas called Untitled)
Delete the old volume. (The one that was created by default)
Now you can reinstall your OS.

After thoughts

I haven't felt like that in some time. And oh boy, Apple did it again! Getting this workaround took me some time and if I didn't have previous experience this would had been a gruesome situation. Other solutions involved creating volumes, using other devices to install the OS. I even tried doing the OS install using the terminal but it also failed with weird errors!

I felt so relieved when the OS started to download and the authorization user error was gone. I hope this solution fits any of you useful! If you got any similar issues I would love to read them! Also any comments or suggestions are more than welcome!