AWS just launched S3 Files, a new service that lets you mount an S3 bucket as a real file system across EC2, ECS, EKS, and even Lambda. It’s one of those announcements that lands with a quiet sense of inevitability. Of course S3 should behave like this. Of course teams want direct, file‑system‑style access to the data they already keep in S3. It’s surprising how long we all worked around the gap.

For years, we’ve lived with an awkward divide. Object storage was durable, cheap, and the natural home for almost all data. File systems were interactive, hierarchical, and mutable, but expensive and operationally heavy. Any workload that needed “S3 data, but as files” ended up with a patchwork of solutions that always felt slightly off. Sync jobs, FUSE layers, EFS pipelines, custom wrappers — all workable, none satisfying.

S3 Files finally closes that gap in a way that feels native instead of bolted on.

What AWS Actually Shipped

From the announcement, S3 Files provides:

• A proper NFSv4.1+ file system interface backed by S3

• Low‑latency access for active data using a high‑performance layer

• Direct reads from S3 for large sequential access patterns

• Byte‑range reads so you only fetch what you need

• Automatic sync back to S3 with versioning semantics

• Concurrent access across compute without duplication

• IAM and POSIX permissions, CloudWatch metrics, CloudTrail logging

It’s a clean mental model: S3 stays the source of truth, and you get a file‑system view when you need one.

Why This Matters

Every alternative we’ve had until now was always missing something.

• EFS gave us a managed file system, but not a native view of S3 data.

• FSx gave us specialised file systems, but not the universality of S3.

• DIY sync jobs gave us control, but also drift and operational overhead.

• FUSE‑based S3 mounts gave us hope, then reminded us why abstraction layers are hard.

S3 Files is the first option that doesn’t feel like a compromise. It’s S3, presented in a way that aligns with how teams actually work.

🔥 Sponsored by QuickTable

QuickTable is the refreshingly simple way for restaurants to take online bookings. No clunky dashboards, no endless setup — just clean, intuitive design that works. It’s built with the same technical principles we celebrate in The Serverless Mindset: simplicity, resilience, and focus on what really matters.

And here’s the best part: friends of this newsletter get a full year free. That’s right,twelve months of effortless booking, on the house. Don’t miss it, use this signup link.

Pricing: Surprisingly Reasonable

The pricing model is straightforward. Reads served directly from S3 don’t incur additional S3 Files charges, which is exactly the behaviour you’d hope for. You pay for:

• Data stored in the high‑performance layer

• Small file reads and all writes

• S3 requests generated during sync

There are caveats, so the pricing page is worth a proper read, but the overall shape feels fair. For many workloads, this will be cheaper and cleaner than maintaining a separate file system layer or duplicating data across services.

The Bigger Picture

This launch removes a friction we’ve all worked around for years.

It tidies up pipelines, reduces the amount of glue code teams end up maintaining, and lets S3 sit more naturally at the centre of both batch and interactive workloads.

It’s the kind of feature that feels obvious once you see it, yet still manages to open up new architectural paths. S3 Files fits neatly into the way people already think about building on AWS, and that’s exactly why it’s going to matter.

I get it. The last two years have been a psychological earthquake for programmers. But here’s the funny thing. Anyone who knows me knows I’ve been highly critical of LLMs for programming. I’ve never believed in vibe coding. I don’t think these models are anywhere near good enough to replace us. And I absolutely don’t think we should lazily hand over our craft to a stochastic parrot with a GPU bill.

And yet, I’ve been using AI extensively for months now. And I’ve been… enjoying it.

I’m not going to claim I’m “10x more productive” (so cringe). Some things are faster, some things are slower, and a lot of things have simply shifted. I spend less time writing the initial code and more time reviewing, correcting, and steering. But overall, the work feels lighter. My brain isn’t fried at the end of the day. I actually have mental space left for architecture, quality, and strategy.

So why haven’t I fallen into the AI-induced malaise so many developers describe? Why am I not depressed, demotivated, or convinced that my job is meaningless?

For me, it comes down to three habits:

1. I stay inside the code. Every day.

My Neovim is always open next to my AI window. I never vibe code. I never let the model run wild. I’m constantly dipping in and out of the editor, making small manual changes, keeping my hands on the clay.

This keeps me engaged with the codebase. It keeps my skills sharp. And it makes my prompts dramatically better because I’m not guessing. I know exactly what I’m asking for and exactly what I want back.

AI becomes a collaborator, not a replacement. I stay in the loop, not above it.

2. I stay close to the customer.

This one predates AI by years. I used to be the classic ivory‑tower engineer who cared more about the elegance of the code than the people using the product. Thankfully, wiser leaders beat that out of me.

Now, when AI helps me ship something faster or cleaner, I picture the actual human who needs that fix or feature. I picture their relief, their smile, their “oh thank God”.

It’s hard to resent AI for “taking your craft” when you’re busy serving real people better than before.

3. I reject multitasking with religious zeal.

A programmer recently told me her company is obsessed with Conductor, this new tool that lets you run armies of agents in parallel. She’s miserable. She’s thinking of leaving the industry.

I looked at Conductor. It’s monstrous. It’s the worst idea I’ve seen in years.

We have mountains of research showing that multitasking destroys productivity, morale, and cognitive health. Yet tech executives keep pushing it because it looks futuristic. It’s the same logic that gave us open offices. Everyone knows they’re terrible, but they photograph well.

I refuse to play that game. I do one thing at a time. AI or no AI.

So where does this leave us?

I have my bad days. I roll my eyes at the Sam Altman hype machine. I’m allergic to the apocalyptic sermons coming out of Anthropic. But I’m also not blind. LLMs are a cool, powerful technology. They’re genuinely useful for a small subset of tasks, and some of those tasks happen to be part of software development.

The trick is not to surrender your craft, your attention, or your sense of purpose.

Stay in the code. Stay with the customer. Stay with one task at a time.

If you do that, AI doesn’t hollow you out. It just becomes another tool on your bench. A sharp one, sure, but still just a tool.

And you get to keep the part of programming that actually matters: the thinking, the judgment, the care, the craft.

That’s the part AI can’t touch.

🔥 Sponsored by QuickTable

QuickTable is the refreshingly simple way for restaurants to take online bookings. No clunky dashboards, no endless setup — just clean, intuitive design that works. It’s built with the same technical principles we celebrate in The Serverless Mindset: simplicity, resilience, and focus on what really matters.

And here’s the best part: friends of this newsletter get a full year free. That’s right,twelve months of effortless booking, on the house. Don’t miss it, use this signup link.

I’ve been thinking a lot about identity lately — not just national identity, but product identity. It started with a simple observation: more and more French tech websites are branding themselves as “Made in Europe 🇪🇺” instead of “Made in France 🇫🇷”.

Maybe there’s a political reason for it, but commercially it feels like a strange choice. “French” carries meaning. “Europe” doesn’t! When I read “Europe”, my instinct is to go looking for the actual Country.

What am I supposed to picture? German robustness, French flair, Italian aesthetics, Spanish warmth?

And the more I think about it, the more I realise the same thing is happening in software.

We’ve entered an era where every product wants to look like Apple, or Linear, or whatever the current design darling is. Perfect gradients, perfect spacing, perfect icons — all polished into the same smooth, tasteful anonymity.

But sameness is not a strategy. It’s camouflage.

If your product looks and behaves exactly like everything else, you’re not signalling quality. You’re signalling that you have nothing to say.

That’s why Omarchy’s recent success fascinates me. A Linux‑based OS that looks nothing like macOS, Windows, or mainstream Linux distros. It’s opinionated. It’s weird in places. It has a point of view. And people love it for exactly that reason. It stands out in a sea of safe, tasteful, derivative design.

There’s a lesson there.

To succeed, you need to be a little different. You need to find your voice, your angle, your flavour. Otherwise, you’ll be drowned out by the ever‑growing noise, from social media, from AI‑generated content, from the endless stream of “best practices” that slowly sand away anything recognisable.

People don’t connect with generic things. They connect with things that feel rooted, intentional, and specific. They connect with character.

And that’s something worth protecting! In cities, in brands, and in the products we build.

🔥 Sponsored by QuickTable
QuickTable is the refreshingly simple way for restaurants to take online bookings. No clunky dashboards, no endless setup — just clean, intuitive design that works. It’s built with the same technical principles we celebrate in The Serverless Mindset: simplicity, resilience, and focus on what really matters.

And here’s the best part: friends of this newsletter get a full year free. That’s right — twelve months of effortless booking, on the house. Don’t miss it, use this signup link.

A lot is happening.

The world has never been crazier.

We’re all about to be replaced by AI.

We’re on the brink of world destruction.

If you’ve found yourself entertaining these thoughts, you’re not alone. And it’s not because they’re true (well, they could, but there’s no way to know and there’s nothing you and I can do to stop it).

The truth is, we live in a noisy, distracted world.

Social media rewards hot takes over substance. AI tools churn out code, copy, and commentary at industrial scale. And while these tools can accelerate output, they also risk atrophying the very muscle that matters most in tech: the ability to think deeply.

As developers, architects, and leaders, our success doesn’t come from typing faster or consuming more feeds. It comes from cultivating judgment, perspective, and the patience to wrestle with ideas until they yield clarity. In a world where shallow thinking is the default, depth becomes a competitive advantage.

So here’s my recommendation for 2026: read a book.

And while you’re at it, read books that make you think. Not just about technology, but about work, culture, and life.

These are a few of the books that have shaped my thinking in recent times. I highly recommend each one of them.

🔥 Sponsored by QuickTable
QuickTable is the refreshingly simple way for restaurants to take online bookings. No clunky dashboards, no endless setup — just clean, intuitive design that works. It’s built with the same technical principles we celebrate in The Serverless Mindset: simplicity, resilience, and focus on what really matters.

And here’s the best part: friends of this newsletter get a full year free. That’s right — twelve months of effortless booking, on the house. Don’t miss it, use this signup link.

Slow Productivity — Cal Newport

I’ve long felt that the widespread adoption of open offices and always-on chats have, on the whole, a detrimental effect on our productivity and our ability to think.

In this best-selling book, Professor Cal Newport of Georgetown lays out the empirical evidence for why this is the case. He also provides helpful tactics and strategies to prioritise meaningful, sustainable output over frantic activity.

The Revenge of Analog — David Sax

Remember when Kindle was launched, and we were told that physical books were over? Fast-forward 18 years, and physical books are still going strong. The market share of e-readers, on the other hand, has stalled.

The same has been true of watches, music, note-taking, and many other fields.

As a technologist, this book will challenge you profoundly. We work in a field that puts a premium on progress, automation, and efficiency. But efficiency is not the peak of human experience, and automating away the things that give us joy is -arguably- not the way to make progress as a society.

Read this book, and then gift yourself a record player or a beautiful physical notebook.

The Holistic You — Rabbi Daniel & Susan Lapin

Life is about making progress in several areas, all at the same time.

You can push hard on work, but it’s likely to come at the expense of your family life. You can invest a lot of time in your hobbies, but you might find that they don’t pay the bills.

The key to a happy life, then, is to find a way to move forward on all the important areas of life: family, friendship, faith, fitness, and finances.

This Jewish Rabbi and his wife offer a perspective on integrating values, relationships, and purpose.

For anyone in tech, it’s a call to align craft with character, not just output with metrics.

How to Winter — Kari Leibowitz

A guide to resilience and mindset, drawn from cultures that thrive in long, dark seasons.

Some of the happiest societies live in colder climates. You may not need to move to a warmer place to find happiness.

If you apply the philosophies explained in this book not just to the weather, but to most challenges in life, you’ll find that your mindset and how you approach things is all that matters.

Unreasonable Hospitality — Will Guidara

A story of radical generosity in service. A masterclass in exceeding expectations and designing experiences that delight far beyond the functional.

If you live in Europe, this book could make you uncomfortable as it takes for granted American-style customer care and then takes it to a new level. If you’re American, this book will challenge you nonetheless.

The takeaway

In 2026, don’t just consume more content. Read long-form, well thought out content. Choose books that stretch your thinking, challenge your assumptions, and remind you that technology is built by humans, for humans.

Deep thinking isn’t optional. It’s the skill that makes every other skill matter.

AWS just launched Lambda Durable Functions at re:Invent 2025, and they might quietly be one of the most important additions to the serverless toolbox in years.

What are Durable Functions?

Durable functions let you write multi‑step, long‑running workflows directly inside Lambda. You write sequential code in Python or TypeScript, wrap calls in steps (with automatic retries and checkpointing), and use waits to suspend execution for minutes, hours, or even up to a year — without paying for idle compute. When the function resumes, it replays from the start but skips completed checkpoints, guaranteeing consistency.

Think of it as Lambda with a built‑in state machine.

🔥 Sponsored by QuickTable
QuickTable is the refreshingly simple way for restaurants to take online bookings. No clunky dashboards, no endless setup — just clean, intuitive design that works. It’s built with the same technical principles we celebrate in The Serverless Mindset: simplicity, resilience, and focus on what really matters.

And here’s the best part: friends of this newsletter get a full year free. That’s right — twelve months of effortless booking, on the house. Don’t miss it, use this signup link.

How do they compare to Step Functions?

Step Functions have always been the “official” way to orchestrate workflows in AWS. But let’s be honest: they’re verbose, hard to debug, and painful to maintain. Durable functions flip the model: instead of drawing JSON diagrams, you just write code. The SDK handles state, retries, and recovery behind the scenes. It’s simpler, more intuitive, and closer to how developers actually think.

Why not just spin up a long‑running service?

Sure, you could run a workflow engine on EC2, ECS, or Fargate. But then you’re back to managing infrastructure, scaling, and idle costs. Durable functions inherit Lambda’s scale‑to‑zero model: no servers, no idle billing, no ops overhead. For workflows that wait on human approvals, external APIs, or multi‑day processes, this is a huge win.

Does it make sense pricing‑wise?

Yes. The killer feature is that waits don’t cost you compute. You only pay for actual execution time. That makes durable functions far cheaper than keeping a container alive for hours or days. For businesses, this means you can finally build resilient, long‑running workflows without worrying about runaway costs.

The bigger picture

AWS is marketing this heavily for AI agent orchestration — chaining model calls, human feedback loops, etc. That’s fine, but don’t get distracted. The real opportunity is much broader: everything you used Step Functions for, but easier. Payments, order processing, onboarding flows, compliance checks — all now possible with clean, sequential Lambda code.

Durable functions are not just an AI play. They’re a simpler state machine baked into Lambda. And that opens the door to a whole new class of serverless applications.

Building a great startup team is less about perks and more about principles.

I look for three things:

• Ownership: the ability to think about the whole experience, not just “my ticket.”

• Managers of One: people who can handle themselves without hand‑holding or endless 1:1s.

• Love for the craft: the drive to improve, refine, and obsess over the tiny details.

Finding these traits is not easy. Not because there aren't people who would love to be like that. But because so much of the tech world has trained people to work in what Cal Newport calls the “hyper-active hivemind”. Noisy, interruption-prone open offices (coupled with just as noisy Slack channels) are the norm.

But there's something almost magic when I explain to people that I will not be running 1:1s with them, other than a couple of times a year.

When I tell engineers that (provided they comply with the task’s specs and overall architectural guidelines) they are free to make decisions on how to best build something. They don't need my permission, and they don't need to consult with the rest of the team.

I've gotten used to it: after an initial momentary confusion, people who get empowered like this, become extremely productive.

(Incidentally, trusting people this way is what allows me, as a leader, to stay “in the work”. My best contributions happen when I'm close to the code and the overall architecture. I do a disservice to everyone by getting bog down on people management and hand-holding.)

I've worked with many engineers who, after joining, have made the transition to this model. But there's also something that can be done to attract talent like that in the first place.

It's all about what gets offered. For me, it is usually:

• Remote‑first by design.

• Almost meetings‑free: long, uninterrupted blocks of productive time.

• No tool mandates: choose your stack, your setup, your style. I’ll only judge outcomes.

Most people attracted to this environment are exactly the ones who thrive in it: owners who manage themselves, and craftspeople who care about the details.

I see so many companies these days insisting or even mandating how their people should work. This happens a lot with AI, where leaders assume they know best1 how engineers will be most productive (and, surprise surprise, it involves using AI left right and centre).

I don't care if you want to handcraft your code on TextMate, or if you're all-in on the latest specs-driven AI hype. Build me high-quality software in a reasonable amount of time, and I'll cheer you on and support you all the way.

The takeaway

Simplicity isn’t about doing less; it’s about removing friction so the essentials shine. Team‑building works the same way. Strip away the noise, and you’re left with people who own, manage, and craft.

That’s the kind of team worth building (and leading).

Microservices require sophistication. They demand a grasp of architectural principles, distributed systems, and the discipline to design boundaries that hold.

But here’s the uncomfortable truth: Have you ever tried building — and keeping, over years — a truly clean, modular, performant monolith?

The idea that microservices are inherently “more complex” than a monolith is a comforting illusion.

With a monolith, you can cut corners. You can sacrifice quality. And for a while, nobody pays the price. The codebase slowly devolves into spaghetti, but the engineers who wrote it may already have moved on by the time the pain becomes unbearable.

Microservices flip that dynamic.

• For architects, they demand more upfront thought.

• For engineers, they require at least a basic grasp of distributed systems.

But once proper guardrails are in place, the day-to-day work is smoother. You don’t need to constantly second-guess whether your abstractions are perfect. You don’t need to carry the weight of the entire system’s cleanliness in every commit.

A monolith, by contrast, punishes any lapse in discipline. Over time, entropy wins. Maintenance becomes harder, onboarding slower, and change riskier.

With microservices, the architecture itself absorbs the mess. One service may degrade in quality, but the system continues to scale. The boundaries protect you.

The takeaway

Microservices aren’t easy. They demand maturity. But the narrative that they’re “too complex” compared to monoliths misses the point. A monolith only looks simple until you’ve lived with it long enough to see the hidden cost of undisciplined design.

Serverless, microservices, modular monoliths — none of these are silver bullets. But if you’re serious about building systems that last, don’t mistake short-term convenience for long-term simplicity.

Here’s a rule of thumb I use when evaluating whether AI is actually helping me build something valuable:

I should be able to show its value without mentioning AI.

If I need to say “it uses AI” to justify the product, I’m not selling the product. I’m selling the idea of AI.

That’s not the same thing.

Real value doesn’t need a label. It’s felt. It’s obvious.

If the product genuinely helps someone — saves time, reduces friction, solves a real pain — it will stand on its own.

We’ve seen this before.

Facebook didn’t pitch itself as a “Web 2.0 platform”. It just helped people connect.

Web 2.0 made that possible, but it wasn’t the point.

AI is the same.

It’s an enabler. But it’s not the story. The story is: what did we build with it?

Did we use it wisely?

Did we make something simple, clear, and useful?

Right now, I see a lot of businesses selling the concept of AI.

But AI isn’t the goal. Serving people is.

A Staging environment is one of those things in software development that we take for granted. Of course you need a reliable, production-like environment where changes can be pushed to and safely tested without affecting live customers in production.

Here’s the problem though. A “reliable, production-like environment” is fantastically hard to achieve. And that’s not even the worst part. If you get there, it only takes a couple of semi-major changes pushed to it, and the rot begins. Things start to diverge from production in ways that make it hard to predict whether what you’re testing will actually work in production.

“Oh, but we have a rock-solid automated process that keeps everything in sync”, is sometimes the response to this point.

This may be true, but I still have to ask: how expensive (in terms of time and money) is it to set up such a process? And is it even warranted within the context of a startup?

There’s no getting around it. A perfect staging environment (even if it exists):

1. Is expensive to maintain

2. Slows down continuous deployment

3. Encourages big bang releases

I say “even if it exists”, because I don’t take it for granted that it can be achieved. There are, for example, industries where -for regulatory or other reasons- there’s no way to replicate the exact experience of a production workload. You just have to do that final test in production if you want to be absolutely sure.

What happens when you challenge the received wisdom of Staging environments? What’s an even more effective way of testing updates without negatively affecting live customers?

Here’s a few ideas:

1. Embrace trunk-based development

Stop creating big branches, working on them for days on end, and then finally making a big bang release with tons of changes (and things that could go wrong).

Instead, break the task at hand into as many small, discrete sub-tasks as possible. Work on each one at a time. Ideally, each of these sub-tasks should be doable within a working day or less. When you’re done, push your changes directly to the main/master branch (i.e. the trunk).

This has the benefit of making each change more testable and easier to revert if something goes wrong.

2. Use feature flags

Feature flags don’t need to be complicated. There are many cool platforms out there that will help you with feature flags at scale.

But to begin with, it can be as simple as adding some simple conditions in your code:

if (condition) { 
  newBehavior();
} else {
  oldBehavior();
}

The vast majority of customer-facing changes can be safely tested directly in production under a feature flag.

3. Use a CI/CD pipeline

A robust CI/CD pipeline automates testing and deployment, ensuring that each small change is validated quickly and safely before reaching production. This continuous validation reduces the need for a dedicated staging environment by integrating quality checks throughout the development lifecycle.

(bonus) 4. Experiment with Chaos Engineering

The most famous example of Chaos Engineering comes from Netflix, where they introduced Chaos Monkey to their Kubernetes cluster to simulate failures.

It’s a powerful, simple idea. But it’s SCARY to most people. It means building your system so that it can withstand being partially broken. And then, you proceed to actually break some of its parts, to ensure that your resilience assumptions stand up to reality.

In conclusion

Challenging the need for a staging environment isn’t just about saving time and money. It’s about embracing a more dynamic and efficient way of building software. By focusing on small, incremental changes, using feature flags to de-risk deployments, and leveraging a solid CI/CD pipeline, you can ship features faster and with more confidence.

So, before you spin up another complex, production-like environment, ask yourself: do you really need it? Or could you be moving faster and safer without it?

In serverless architecture (as in every non-trivial piece of software), complexity creeps in quietly. A clever pattern here, a nuanced tradeoff there — until your team’s mental model is a maze.

Here’s a rule I use to stay sane:

If a decision takes more than 5 minutes to explain to a teammate, it’s probably too complex for our current stage.

This isn’t about dumbing things down. It’s about protecting clarity, trust, and speed — especially in early-stage products.

Why it matters:

• Serverless is already abstract. Adding layers of cleverness makes it harder to debug, onboard, or pivot.

• Cognitive load is real. Every extra concept costs brainpower — and brainpower is your most expensive resource.

• You’ll revisit it anyway. Most decisions aren’t final. Clarity now beats perfection later.

Would I still choose it if I had to maintain it solo?

This is my favorite sanity check.

Serverless promises scale, speed, and delegation — but those benefits vanish if your architecture demands a team of specialists to understand it.

DHH once called Rails “the one person framework,” designed so a single developer could build and ship a full product without begging ops or frontend experts for help. I’ve had a taste of what that feels like by (re)discovering simple frameworks and libraries like HTMX, honojs, and even Kamal for non-serverless workloads.

That spirit matters more than ever.

Serverless should feel like that — not because you’ll always work alone, but because clarity scales. If your system makes sense to one person, it’ll make sense to ten. If it doesn’t, no amount of documentation will save you.

So when I’m tempted to reach for a clever pattern, I ask:
Would I still choose this if I were the only one maintaining it six months from now?
If the answer is no, I probably shouldn’t choose it now.

We’ve anthropomorphised these models to a ridiculous degree.

We’ve accepted the absurd idea that they’re thinking rather than computing. That they’re performing "advanced reasoning" instead of just running calculations for a bit longer on more powerful hardware. We talk about them as if they’re human.

And now, a judge has ruled that it’s fine for an LLM to ingest and "recall from memory" a book because, well, isn’t that what humans do?

The case in question involves Anthropic, which purchased and scanned millions of print books to train its model, Claude. The judge deemed this "fair use," arguing:

"Everyone reads texts, too, then writes new texts. They may need to pay for getting their hands on a text in the first instance. But to make anyone pay specifically for the use of a book each time they read it, each time they recall it from memory, each time they later draw upon it when writing new things in new ways would be unthinkable. For centuries, we have read and re-read books. We have admired, memorised, and internalised their sweeping themes, their substantive points, and their stylistic solutions to recurring writing problems." 1

This reasoning is flawed because it equates human learning with machine processing. An LLM isn’t "reading" or "recalling from memory"—it’s running an algorithm on stored data.

Would the judge have ruled the same way if, say, Google Search had scanned every book and reproduced its content in search results? Of course not. There would be outrage, and no court would extend the same leniency.

But because we chat with these models—because they call us by name, "remember" our conversations, and their creators insist they’re thinking—we treat them differently. We’ve blurred the line between computation and cognition.

It’s time to regain some sanity in this conversation. These aren’t minds. They’re algorithms running on computers. We already have the words for that—let’s use them.

This is where Retrieval-Augmented Generation (RAG) comes in.

Unlike fine-tuning, which requires modifying model parameters and retraining with domain-specific data, RAG allows models to dynamically fetch relevant information from external sources.

RAG is far more cost-effective and significantly less time-consuming. It is ideal for scenarios where data updates frequently. When it comes to building lightweight business applications, it is likely the better option.

Fine-tuning, on the other hand, is useful for highly specialised applications like medical diagnostics or legal document interpretation, where consistent responses based on structured internal knowledge are required.

While the underlying principles of RAG are straightforward, implementing it effectively can involve a few moving parts. This is where cloud platforms like Amazon Bedrock significantly simplify the process, particularly with their Knowledge Bases feature which enables RAG-based querying.

With Knowledge Bases, you can easily iterate from the AWS Console, adding more knowledge to a model and testing it out until you're happy with the results. When you’re ready, you can integrate everything into your application using the AWS SDK.

Setting Up a Knowledge Base in Amazon Bedrock

Step 1: Define Your Knowledge Base

Amazon Bedrock’s Knowledge Bases can ingest structured and semi-structured data, including documents in various formats like HTML and Markdown.

Step 2: Prepare Your Data

The quality of data ingested directly impacts RAG performance. Typically with RAG, the content you upload as a data source should be as clean as possible. For example, you’d want to:

- Remove unnecessary metadata (such as YAML frontmatter that isn’t useful for querying).

- Standardise headings and formatting to ensure logical information retrieval.

- Chunk content strategically—divide long articles into smaller segments for better retrieval precision.

- Ensure consistency in terminology to improve keyword relevance.

While the gold standard for RAG data is always meticulous cleanliness, one of the real advantages of Bedrock Knowledge Bases for rapid prototyping is its surprising tolerance for less-than-perfect data during initial setup.

Bedrock Knowledge Bases also offers to perform standard chunking out of the box. You can control how the chunking is done, but you may not need to. If you're not happy with the initial results, you can dig a little deeper there and find the chunking strategy that works best for your particular data set.

Step 3: Index Your Knowledge Base

Once your documents are cleaned and structured, they need to be indexed into a data source for efficient retrieval. This step converts textual data into numerical representations, allowing Amazon Bedrock to identify and fetch relevant information.

What You Need:

- An embedding model: Amazon Titan Embeddings is pretty much the only real option here (other Bedrock-supported embedding models might be available depending on the region, or you can integrate custom embedding models via advanced configurations.).

- A vector database: Amazon OpenSearch Serverless is the easiest solution, but Aurora PostgreSQL is a solid option too, especially if you’re already familiar with Postgres.

- Chunking strategy: Optimal chunk sizes (e.g., 200–500 words) for better retrieval. Again, don't worry about this when you're first experimenting with a new data set.

Traditionally, setting up these components can be a significant time investment when building RAG from scratch. However, Bedrock's Knowledge Bases streamline this entire process, allowing you to get these essential pieces in place with just a few clicks.

Step 4: Connect Your Knowledge Base to Amazon Bedrock

Now that your knowledge base is ready to go, you need to connect it to Amazon Bedrock so it can power your RAG-based queries.

How to Connect:

• Configure your Knowledge Base: This involves pointing Bedrock to your S3 bucket (your primary data source) and selecting a vector database (like Amazon OpenSearch Serverless or Aurora PostgreSQL with pgvector) to store the embeddings. Bedrock then automatically handles the indexing and establishes the retrieval pipeline, which converts your queries into vectors and uses them to find relevant information.

• Set up access control: Use AWS IAM roles to make sure your data access is secure and controlled.

• Test it out: Run some sample queries to confirm that Bedrock is pulling the right information.

Step 5: Query Your Knowledge Base

Once everything is connected, Bedrock makes it really use to try out the new knowledge.

What’s fun about it, is that you can quickly and easily switch between foundation models.

Once you’re done playing with it, you can click on the copy icon on top right of the Configurations section. This conveniently places the JSON configuration for your setup into your clipboard, allowing you to easily transfer your experimental settings.

You can then pass that JSON when hitting the service using the AWS SDK from your application.

***

By following these steps, you can build an efficient RAG pipeline in Amazon Bedrock without costly model fine-tuning. The quality of the AI-generated responses will vary based on how well structured the data is.

Thinking about your own AI journey?

I've been working closely with clients to help them navigate their AI strategy, especially when it comes to crucial areas like safety, security, and copyright protection. It's all about empowering your team to leverage AI internally without the risks of exposing sensitive information or compromising company secrets and IP.

If you're looking to integrate AI responsibly within your organisation, I'd love to chat and see how I can help. Feel free to get in touch!

Shoot me an email to find out more!

Several years ago, I met a guy who worked as an ambulance driver in the area where I grew up.

Not being great at small talk myself, I decided to skip past through it and began asking him a bunch of questions about his work. He was delighted; he clearly loved what he did for a living, and had no patience for small talk either.

Within a few minutes, he revealed to me that he was considered one of the top ambulance drivers in the area. Unsure whether I was supposed to take this seriously or not (after all, I thought to myself, how would you even "rank" an ambulance driver?), I waited a few seconds before laughing, rather responding with a curious look which he interpreted as me wanting to find out more about it.

What he proceeded to explain has stuck with me for many years.

As an ambulance driver, there are a few metrics that matter:

• How fast you can get to the scene (and back to the hospital). Obviously this matters as a few seconds can make all the difference.

• How many accidents you get involved in. Ambulances apparently get involved in a lot of them; that makes sense given that they're rushing through traffic trying to get their patients to the hospital as quickly as possible.

• How stable is the ambulance environment while you're driving it. This is helpful as paramedics may try to help the patient while the ambulance is moving. Too much disruption (like hitting hard on the brakes) makes this much harder.

After he told me all this, I was hooked. I had to know: how did he manage to perform better than the other drivers on all of those metrics?

He explained to me: "It's very simple. At the start, I pick a speed that feels comfortable, slightly on the slow side, and I stick to it. I never increase the speed, and I rarely ever stop". "Everyone else", he continued, "pushes on the accelerator as hard as they can, and then keep hitting the brakes HARD at every intersection or whenever another driver cuts them off. Me, I just keep going: slow and steady".

His ability to calmly focus on the task at hand and not be taken over by the frenzy of the moment literally saved lives.

This little anecdote came back to mind as I was reflecting on what it means to "vibe code" your way into working software.

(If you, like me, don't spend much time on X/Twitter these days, you might have missed out on the conversation around "vibe coding". If that's the case, let me thank you on behalf of your neurons. You're a saner person for it. But just for the purpose of this post, I'll give you the tldr: "Vibe coding" is giving up on your hard-earned skills so that some Silicon Valley CEO or VC can get rich. That's it, you're now a vibe coding expert.)

I realised that this is very much what it feels like to write code with AI. You give it a prompt, and straight away you have code that it would have taken you, perhaps, several minutes to write by hand. It feels like going full speed, pushing hard on the accelerator.

What a huge time saver, right?

Not so fast.

Aren't you at least going to read the code and try to get a sense of what it's doing? That's what you would do if this was somebody else's code and you were being asked to approve its deployment.

So you proceed to read that code. This may take a few minutes, and it feels like slowing down drastically, coming from the high of a few moments ago when you were prompting your way to success.

At this point, you have a few scenarios.

The best possible one is that the code looks fine, reads fine, and is doing what you expect it to. This is the equivalent of driving the ambulance through a road with zero traffic.

The evidence is there to tell us that this scenario is pretty rare. Between hallucinations and the tendency to generate over-engineered, convoluted code, the chances of AI churning out highly readable, production-ready code are as slim as finding no traffic in New York City. It can happen, mind you, but you'd count yourself lucky if it did.

Another scenario is that the code is manifestly wrong. That's like hitting a traffic jam on a tight, one-way street. You'll need to turn around, and try another way altogether, assuming there is one. This is a huge waste of time.

There's a third scenario, and it's the most insidious. It's the one where everything looks good, there's nothing obviously wrong, but in the end the code is broken in some hard-to-find way. Perhaps the LLM made up a non-existent library, or it assumed that you could leverage a feature that your language doesn't actually support.

This is like Google Maps taking the inexperienced ambulance driver to the wrong hospital: everything looks good, you're going to a hospital after all, and you've no reason to doubt the GPS. Except that it's taking you to the wrong place, and by the time you realise (and correct) the issue you'll have wasted A LOT of time.

The veteran driver just knows where to go, and doesn't blindly rely on her GPS.

The same can be said for the software engineer. Nothing wrong with enhancing your experience with an LLM, but ultimately you need to know what you're doing.

Speed alone is not a strategy. AI-generated code offers the illusion of instant progress, but without disciplined scrutiny, it leads to fragile results. The best engineers, like the veteran ambulance driver, move deliberately—balancing efficiency with reliability.

Mastery isn’t speed—it’s knowing that slow and steady wins when precision matters most.

Claiming that AI now writes x% of overall code is like saying WordPress powers 40% of the web.

It’s a vast, generic claim about the world out there1. It says nothing about the code you’re writing or the application you’re building.

There are valid use cases for WordPress. And yes, there are valid use cases for code that AI fully generates.

But, in general, you shouldn’t unthinkingly default to WordPress for your next app just because so much of the existing web is powered by it.

Similarly, you shouldn’t delegate your hard-earned ability to think deeply and craft scalable code to AI just because some dude online managed to build a web page in 5 minutes with Cursor.

Keep honing your skills. Don’t allow billion-dollar companies and attention-seekers on social media to dictate what the right way to add value as a software engineer (or as a software business) should or shouldn’t be.

Economies don’t seem to have fully recovered post-pandemic, companies aren’t hiring as much as in the good old days, and of course silicon valley VCs and executives are pouring obscene quantities of money into “AI” just so they can enjoy the look on our faces when they tell us that they’re coming for our jobs (not that they have any idea what our jobs consist of, but that’s kinda why they think ChatGPT can do it).

Meanwhile, I’ve done my best to isolate myself from the noise and focus on getting better at my craft, finding more ways to add value, and helping others grow and succeed.

So I thought I’d spend a moment to write down a few of the tools and technologies that have brought me joy in 2024. Some of them were just plain fun, but others have actually caused me to think more deeply about the way we build software; I’m looking forward to share some of those learnings and reflections throughout 2025.

1. Containers

Frankly, I was quite happy when Lambda opted for zip archives as opposed to Docker for the default runtimes. It’s not that I hated containers, but they always felt quite heavy and cumbersome.

In the past, on the rare occasions when Lambda wouldn’t suffice (and I had to setup ECS or Fargate) I never enjoyed it.

But in 2024 I I got to work with Docker a lot more. We’ve introduced some Rust and Go into our codebase, so we had to use Docker because there are no provided runtimes on Lambda for those languages. I got to interact with the Docker ecosystem again, setting up Docker Compose, pushing images into our private registry, etc.

It all felt polished and robust. I’m impressed by how much progress there has been in container-land and I was pleasantly surprised by how smooth the local development experience was.

2. Kamal

One of the main reasons why I wasn’t so keen on containers in the past is because I always felt that most deployment and orchestration solutions were insanely difficult to setup and operate. It’s always been my argument that unless you’re a Fortune 500, you probably don’t need Kubernetes.

But if you accept my point, then that leaves you with few options. On AWS, we have Fargate which is not that complicated, but it can still be a bit of an overkill depending on what your use case is. There is also AppRunner which is super simple but potentially quite a bit limited in features.

None of the above-mentioned options are possible if you’re not on AWS though (or even if you are, but you’re worried about vendor lock-in).

Kamal is the tool that someone should have come up with years ago, before so many startups built their whole businesses on that monstrosity Kubernetes.

I had the pleasure of working with Kamal for a consulting customer that doesn’t run on AWS. I was SO impressed: it is exceedingly simple to configure and to operate.

3. Go

I wrote a fair amount of Go several years ago, and I really enjoyed it. For various reasons though, for the last few years I’ve been almost exclusively exposed to Javascript (and subsequently Typescript).

As we set out to introduce some Go into our stack (primarily for performance reasons), I got my hands dirty again and it made me so happy. I still can’t get over how quickly you can get from near-zero to super productive with Go.

This experience has made me reflect on what it means to get the right balance between performance and simplicity. I shared some slightly controversial thoughts on the topic, comparing Go and Rust. While Rust is as performant as it gets, it is really quite hard to work with. Early in the year, it took us days to get a tiny bit of Rust code into production (with no prior Rust experience).

Go is so much easier to get going with. Everyone can work with it, everyone can understand it. But it still manages to deliver performance levels approaching those of Rust. That is remarkable, and I don’t think we give enough credit to Go’s designers for this.

4. HTMX

I had heard about HTMX a few times in the past, but I kept assuming that it was something you could only use for childishly simple UIs.

I was intrigued nonetheless.

Since I needed to set up a small dashboard for internal use only, I decided to have fun with it and use HTMX instead of React (which would have been my go-to).

I was astonished at how quickly I got things done. And as I kept digging and pushing, I realised that I could build something truly complex and interactive with it. With no frontend Javascript whatsoever. No heavy frameworks like React. All coming straight from the server.

It is now my belief that most projects should default to HTMX, whereas heavy frameworks like React should be seen as a niche, highly specialised tool for very specific use cases involving an unusually high degree of interactivity.

5. Hono

Hono is a lovely, simple, lightweight, fast framework for building APIs. I was able to play with it and build a few projects in 2024. It is the framework we’ve always wanted (and needed) in the Javascript/nodejs world.

I highly recommend it.

6. Linux

I started using Linux as a teenager, and kept using it all throughout school and even into my first couple of jobs as a young developer. But then I joined a company that had a Mac-only policy; I made the switch to Mac, and decided to stick with it until a few months ago.

Over the summer of 2024, I decided that I wanted to try Linux again. I wasn’t sure what to expect to be honest! As much as I enjoyed playing with it back in the day, I had many memories of days wasted trying to get things working, all while my colleagues using Mac and Windows were busy shipping code.

I imagined that it would be a little better than it used to, but I didn’t think it would be this good.

Linux on desktop (Ubuntu is the distro I’m using) has improved so much. It’s smooth, it looks good, it works like a charm.

Sure some things take a little longer to set up than on Mac, but you get that feeling of true ownership. This truly feels like my machine. It may sound like a silly thing to say, but it’s a feeling worth exploring (and embracing) if you think of your work as your craft (as I do!).

7. neovim

For years, I would look at people working on vim wondering why would anyone want to work like this! But my return to Linux gave me a chance to look afresh at my tooling of choice.

Having used VS Code for the last few years, it didn’t take me long to realise that I felt no affection for it. I’m no Microsoft fan, and although VS Code is a solid product, it’s also quite bland. There’s nothing especially appealing about it apart from the fact that it gets the job done.

So I asked myself if perhaps neovim could be a better companion for my daily work. Having no idea where to begin with, I watched a few videos on YouTube and then installed the standard version of neovim. Within minutes I was banging my head against the wall in desperation. Let’s just say, neovim on its own is not for the faint of heart!

I threw neovim away in rage and contempt and decided that I would stick with VS Code. But something was nagging me! How is it that so many people are using vim and I’m the only idiot who couldn’t get to grips with it?

And then I realised!

It turns out, neovim (much like Linux) has flavours and distros. And, as far as I understand it, almost no one with a life uses the standard version of neovim. Most sane people download one of these distros. There are several, they’re all very nice and they come complete with plugins, plugin managers, sensible defaults, the works.

I ended up downloading lazyvim. After that, everything clicked into place within a few days.

I’ve been using it daily for almost a year now, and I regret not making the switch before. vim motions are a superpower!

As DHH has nicely put it:

It’s just uniquely satisfying to string a handful of these combos together and see the text beneath you radically manipulated. In a way you just know would have been a drag to do in any other editor. That’s the game-like joy of vi’s power moves.

So these were the tools and technologies that brought joy into my daily work in 2024.

Getting exposed to each of them throughout the year made me grow as a professional. They gave me a better appreciation for the value of growing in my craft, picking the right tools, and prioritising simplicity over unnecessary complexity.

This conflict boils down to simplicity versus complexity. Critics argue that the cloud is overly complicated, designed for large enterprises. Just look at the myriad of AWS services—can anyone truly remember them all, let alone use them effectively? And microservices? They’re just as convoluted. Why not embrace the "Majestic Monolith," which is far easier to manage?

Having immersed myself in the cloud and championed Serverless for years, I don’t find myself especially sympathetic to these arguments. Yet, I can’t deny that they resonate with me on some level.

I don’t advocate for on-prem solutions; I genuinely believe Serverless is the way forward for most businesses. The cloud empowers us to focus on our core business logic while leveraging high-performance products and services that would be impossible to replicate on our own.

I also don’t think microservices are inherently bad. Throughout my career, I’ve supported teams in transitioning to microservices, as they help maintain order and cleanliness in our codebases.

Without exceptional discipline, monoliths can devolve into chaotic jungles. Microservices allow us to move quickly, with different teams owning distinct services without stepping on each other's toes.

And yet, there’s something undeniably appealing about the simplicity of tools like Kamal. With just a few lines of code, you can bypass much of the complexity and launch a production-ready application on your server of choice.

Let’s be honest: the cloud can be daunting. While I’ve greatly benefited from re:Invent talks and keynotes, many of them feel more like advanced computer science lectures. This complexity raises a question: aside from major enterprises like Amazon, who truly benefits from such an intricate array of services?

Startups need far less. The fundamental building blocks of Serverless—Lambda, Dynamo (or DSQL), AppSync, and EventBridge—can take you almost anywhere you need to go as a business.

This brings us to a middle ground.

There are builders and architects aiming to create scalable solutions—not monoliths, not on-prem, and not limited to small VPS setups. They may not have a large user base yet, but they’re designing for growth because they believe in their vision.

However, attending cloud events or consulting microservices experts often introduces layers of complexity and bureaucracy that can be overwhelming.

This middle space is for those who want to harness Serverless to build highly scalable microservices in the cloud—without breaking the bank or feeling inferior just because larger enterprises are tackling more complex challenges.

I refuse to settle, but I also don’t want to feel like I need a team of 500 engineers to bring my product to life.

The allure of Serverless has always been its ability to enable rapid, cost-effective scalability with a small team.

That’s the space I’m excited about!

I want to challenge myself to learn from the no-cloud, no-microservices community and I want to take their learnings into the world of cloud and microservices. I want to strip my world out of all complexity, and make building highly scalable products exciting, intuitive, and simple.

I’m excited about HTMX as a way to enable server-driven, truly fullstack development. No more rigid separation between the React experts and the backend-only folks. With HTMX, everyone can build fully functional applications without a phD in frontend development.

I find Hono absolutely delightful. What a great way to build simple, fast APIs that deploy just about anywhere. I think that the so-called best practice of one Lambda function per API endpoint has been overused and abused. You can have a single Hono-based Lambda handling a whole bunch of routes. It’s fine, and it’s plenty fast.

I’m thrilled about Amazon’s DSQL. I feel like a whole lot of complexity over the years has been forced on us as we tried to shoehorne all of our use cases into using DynamoDB. Frankly, we didn’t have a choice because relational database alternatives on AWS were never truly serverless. So we convinced ourselves that it was actually cool and properly serverless to pour hours into designing the perfect Single Table Design data modelling for our Dynamo tables. I’ve personally had enough of that. I’m looking forward to defaulting to a good old relational database unless something that screams “key-value” calls for the use of Dynamo.

There may other tools or technologies that I’m not yet aware of that can remove layers of complexity from our development lifecycle. I will be on the look for those moving forward.

No more blindly accepting what the enterprise thinks is right. Startups are different, and we don’t have to settle.

Amazon’s famous leadership principle of customer obsession is an encouragement to look at what a customer needs and then work backwards from that need towards a solution.

Customer obsession is a spectrum, not a binary switch. On one end, you give customers exactly what they ask for. On the other, you go above and beyond to deliver something truly remarkable. But there's a point where you cross the line from customer obsession to pursuing your own agenda.

Take relational databases, for example. When customers asked for a way to run their databases on the cloud with minimal hassle, Amazon delivered RDS. It was a straightforward solution that met their needs. But then came Aurora, a game-changing reinvention of relational databases that still looked and felt like a traditional RDBMS.

Let’s be honest: with Aurora, Amazon didn’t exactly deliver what customers were asking for. Aurora is such a novel take, and a complete reinvention of how relational databases had worked up until then that, frankly, no customer could have asked for something that specific.

How, then, do we know that Amazon fulfilled their customer obsession principle with Aurora? I think that it comes down to how much overlap there is between the original need and what is being delivered.

With Aurora, no customer had to be convinced of the power of relational databases. Nor did anyone need to embark into a lengthy training programme. Aurora is a good old relational database. It’s compatible with the database engines (PostgreSQL and MySQL) that most developers have known and used for decades.

Aurora is a more innovative answer to the same customer need that brought us RDS.

Sure, it’s technically a new thing. If you’re trying to convince someone to use Aurora (as I have) you do need to explain a little bit of what it is and why it’s better. You can’t just say “It’s PostgreSQL on AWS” (as you would, rightly, if talking about RDS).

However, when we start telling customers that they need to abandon their relational databases and adopt something like DynamoDB, we've crossed the line. We're no longer obsessed with their needs; we're pushing them into something completely different and somehow assuming we know best (with no malice, I’m sure. I’ve done that myself many times).

I’m afraid that’s what's been happening in the serverless world!

For years, we've been evangelising DynamoDB as a key component of serverless architecture on AWS. But what about customers who have invested heavily in relational databases? Do we really think they're just going to rip and replace their entire architecture? It's not only unrealistic but also condescending.

The truth is, there's nothing inherently hostile to relational databases in the serverless paradigm. Cloudflare's D1, a serverless SQLite-based database, is a shining example of what's possible: cheap, fast, and there's nothing new to learn. It's good old SQL.

But if you’re building on AWS and you want the power of a relational database, you’re stuck with Aurora Serverless, a service which is possibly great for the enterprise but is far too expensive at low-to-medium volumes.

As I recently pointed out on X, how is it that DynamoDB can cost virtually nothing at low scale, whereas Aurora has to be so expensive?

Now, if your answer to that question is “oh but you don’t know how hard/expensive it is to set up backups/multi-AZs/read replicas, etc”, let me point out two things.

Firstly, a lot of us do know. We used to do all of that. Back a few years ago, everyone used to be able to set up a MySQL/PostgreSQL database locally and often even on a production server. It wasn’t that hard and it wasn’t at all expensive at low volumes.

Secondly, look again at DynamoDB! It does all of those things for you and you don’t even need to think about it. It just works, and it does so inexpensively (for the customer, that is).

It's time for a change. We need True Serverless® solutions that truly meet customers' needs, without pushing a specific agenda down people’s throats.

That's why my number 1 request for this year’s re:invent is an SQLite-compatible, truly serverless, hyper scalable, cost effective database service from AWS.

It can be done. Amazon knows how to build something remarkable under the pressure of an aggressive deadline. If they need more resources, they could just drop one or two GenAI initiatives. That would be a double gift!

I've long advocated that you need to embrace vendor lock-in to make the most of the cloud.

I'm changing my mind slightly.

Cloud providers can choose to provide a common interface to their services. When they don't provide such an interface, they're creating vendor lock-in. When they do, they're making it easier for customers to switch should they ever need to. It's a choice, whether intentional or not.

Don't believe me?

Take a look at CosmosDB from Azure. It provides, according to some benchmarks, performance comparable to our beloved DynamoDB. And yet, by design, it supports SQL as a query language. It gets better: if you want to, you can even use MongoDB’s syntax!

It's easy to see the implication of this choice: if you have an existing app built on top of a standard relational database, you can point it to CosmosDB instead. You get Dynamo-like performance and scalability, while barely rewriting any code. And, of course, you can ditch CosmosDB as soon as it no longer makes sense to you, and just move over to any PostgreSQL-compatible database.

"Oh", I hear you saying, "but AWS has Aurora/RDS for that!". I know that, but it's not the point. The point is that if you choose to build something on top of DynamoDB, you're never getting out of it (not without massive effort, that is). This simple idea acts as a blocker towards greater adoption not just of DynamoDB, but also of Lambda, EventBridge, you name it.

Serverless as a whole is badly penalised and, arguably, under-adopted because of the lack of common interfaces.

The services mentioned above are, incidentally, my favourite ones. I've spent years advocating for them and the #1 pushback I get ALL THE TIME is that folks don't like getting vendor locked-in.

So here's a simple idea for AWS.

Build interfaces on top of these serverless, cloud-native products that make it easier for people to switch to and from them.

They may never need to leave. But if that's all that's stopping them from adopting these beautiful services and, more broadly, serverless, why not address those concerns? These are potential customers whom AWS claims to be obsessed about.

I like the Amazon way, how they listen to customers and learn from them. I'm not a fan of companies that think they know best, whose mission is chiefly to “educate” their customers.

We’ve been trying to educate people about the value of vendor lock-in for too long.

It's time to embrace a more open approach and to welcome a new cohort of amazing teams that should really be building their products with serverless, but whose leaders are too worried about vendor lock-in to make the leap.

As someone who's spent years working with developers, I've often found myself wondering what sets the truly exceptional ones apart. It's not just about technical skill, although that's certainly important. Nor is it solely about experience, although that helps too.

No, I've come to realise that what makes a great programmer is a rare combination of two essential skills: a sense of urgency and a drive for quality.

Let's start with the sense of urgency. A great programmer knows that time is of the essence. They understand that the best way to add value is by shipping software that users can actually benefit from. Unshipped software, no matter how beautifully crafted or cutting-edge, is worthless. It helps nobody, and it adds no value. This sense of urgency is what drives great programmers to prioritise, to focus on the essential tasks, and to eliminate unnecessary complexity.

But a sense of urgency alone is not enough. Without a corresponding drive for quality, you end up with software that may ship quickly but is riddled with bugs, inconsistencies, and poor design choices. A great programmer has an innate desire to structure things, to create order out of chaos.

As Yegor Bugayenko so eloquently put it, "A talented programmer feels [ambiguity, inconsistency, chaos, irrationality, and lack of logic] physically, while a mediocre one says 'Whatever works!' and gets on with it."

This drive for quality is what sets great programmers apart from the rest. It's what makes them take the time to refactor code, to write automated tests, and to ensure that the software is maintainable, scalable, and efficient. It's what makes them care deeply about the user experience, about the performance, and about the overall craftsmanship of the software.

But here's the thing: these two skills need to exist in tension with each other. A great programmer should feel equally uncomfortable when the quality of what they've built isn't as good as it should be, as well as when something is taking too long and thus no value is being added to paying customers. This tension is what creates a sense of balance, a sense of harmony between the need to ship quickly and the need to build something of high quality.

When I think back to the great programmers I've worked with, I realise that they all possessed this rare combination of skills. They were able to balance the need for speed with the need for quality, and they were able to do so in a way that was both efficient and effective.

So, what can we learn from this? Firstly, we need to recognise that great programmers are not just born, they're made. They're made through a combination of experience, mentorship, and a willingness to learn and improve. Secondly, we need to create an environment that encourages and rewards this rare combination of skills. We need to give our developers the autonomy to make decisions, the resources to learn and grow, and the support to take risks and experiment.

Finally, we need to recognise that great programmers are not just technical experts, they're also craftsmen, artists, and problem-solvers. They're people who care deeply about their work, who take pride in what they build, and who are driven by a desire to create something of value.

In the end, what makes a great programmer is not just about technical skill or experience, it's about a mindset, a way of approaching problems, and a commitment to excellence. It's about finding that delicate balance between the need for speed and the need for quality, and it's about creating software that truly adds value to people's lives.

If you're looking to supercharge your development process and create robust, scalable products quickly, AppSync might just be the secret weapon you've been searching for.

Rapid Prototyping: From Idea to MVP in Record Time

One of AppSync's most compelling features is its ability to accelerate the prototyping process. By leveraging GraphQL, AppSync allows developers to define their data models and APIs quickly and efficiently. This means you can bring your ideas to life faster than ever before, iterating rapidly and gathering valuable feedback early in the development cycle.

With AppSync's schema-first approach, you can start building your frontend applications even before your backend is fully implemented. This parallel development process can significantly reduce time-to-market.

Infinite Scalability: Growing from MVP to Enterprise

Scalability is often a major concern when choosing a technology stack, especially for startups and growing businesses. AppSync's serverless architecture addresses this concern head-on, providing virtually infinite scalability out of the box.

As your user base grows from a handful of early adopters to millions of daily active users, AppSync seamlessly scales to meet demand. There's no need to worry about provisioning servers, load balancing, or managing complex infrastructure. AppSync handles it all, allowing you to focus on what matters most: building great products and growing your business.

Bridging the Gap: Enhanced Team Collaboration

Communication between frontend and backend teams is often difficult. AppSync, with its GraphQL foundation, provides a shared language that both sides can understand and work with efficiently.

Frontend developers can specify exactly what data they need, while backend developers can focus on efficiently providing that data. This clear contract between the two sides reduces misunderstandings, minimises unnecessary data transfer, and ultimately leads to faster development cycles and higher-quality products.

Seamless AWS Integration: Reducing Complexity, Enhancing Reliability

For teams already invested in the AWS ecosystem, AppSync offers a major advantage: native integration with a wide range of AWS services. Whether you're working with DynamoDB for your database needs, Lambda for serverless compute, S3 for file storage, or Bedrock for GenAI, AppSync provides seamless connectors that drastically reduce the amount of glue code you need to write.

This tight integration not only speeds up development but also enhances overall system reliability. With fewer custom integrations to maintain, you're less likely to encounter unexpected issues or performance bottlenecks as your application scales.

Less custom code means fewer potential points of failure, leading to more robust and maintainable applications. This is particularly valuable for small teams who may not have the resources for extensive testing and debugging of complex integrations.

The Evolution of Cloud-Native Development

For many developers, frameworks like Ruby on Rails, Django, or Laravel have long been the go-to choice for rapid application development. While these tools certainly have their merits, AppSync represents the next evolution in this space—offering similar productivity benefits but with the added advantages of a serverless, cloud-native architecture.

With AppSync, you get the rapid development capabilities you love, combined with the scalability, reliability, and cost-efficiency of modern cloud services. It's like having your cake and eating it too—fast development and enterprise-grade infrastructure all in one package.

(I’m of course aware that AppSync is not a battery-included framework like Rails. All I’m pointing out is that AppSync can give us much of the same productivity boost without the obvious limitations of a big, fat framework).

AppSync as Your Competitive Advantage

In my view AWS AppSync offers a compelling solution for teams of all sizes.

Whether you're a startup looking to launch your MVP, a growing company aiming to scale your existing products, or an enterprise seeking to modernise your tech stack, AppSync provides the tools you need to succeed in the modern cloud.

So, as you contemplate your next product or consider ways to optimise your current development process, give serious thought to AWS AppSync. It might just be the key to unlocking your team's full potential and building the successful, scalable products that will define the future of your business.

Do you find that Slack wastes more of your time than it saves?

I definitely feel that way! Countless engineers and creators I've talked to agree.

That’s why I’ve decided to take matters into my own hands. I’ve built an alternative software for communicating with my team. It’s called Roga.

It’s built to deliver the opposite experience to Slack, Teams, and the likes.

• Messages are asynchronous: Instant Messaging is simply the wrong tool for most professional communication. It’s fun if you want to chat with family and friends, but it’s not how serious work should be discussed.

• One clear thread per topic: In Slack, discussions on the same topic can scatter across various channels, threads, and sub-threads, leading to confusion, lost information, and the compulsion to constantly check notifications.

• Host it on your AWS account: Remember when Slack/Salesforce decided to start using your company data to train their own AI models? Yeah, I don’t want that for my team and nor should you. Roga can be deployed with a simple CDK command to your AWS account.

• You pay for it once and it’s yours forever: the ability to communicate with each other is as basic a need as it gets for a team. The idea of having to pay more as the team grows has always bothered me. With Roga, you pay a ridiculously low amount once and then you just own the software. Grow as big as you want.

I’m still finishing up the last touches before I go public with it, but for now I’m giving it away for a super low price.

I’m especially interested in receiving feedback from the amazing readers of The Serverless Mindset.

Get your copy of Roga now, or shoot me a message if you have any questions!