Yes Way Jose

Reading This Month

you@example.com (Jose Villalta) — Mon, 20 Apr 2026 08:18:35 -0700

This month I’m listening to the audiobook “Influence: Science and Practice” by Dr. Robert Cialdini to understand the psychology of persuasion, why people say yes, through six core principles: reciprocation, commitment and consistency, social proof, liking, authority, and scarcity. Cialdini is an academic, not a salesman, and he provides compelling examples and anecdotes. I don’t like to be manipulated and I don’t want to get what I want through manipulative practices, but it pays to understand what makes people tick. Effective leaders seem to have an intuition about this. For some it may come as “common sense,” while others may feel like they just don’t get people. I’d put myself in the latter camp. I can even confess that I chose my university major based on that.

How I Make Hard Decisions Easy

you@example.com (Jose Villalta) — Thu, 16 Apr 2026 07:09:40 -0700

One useful tool I use when I want to make a hard decision easy: I picture myself at 80 years old and ask, will I regret not doing this? If the answer is yes, I have to try it. If the answer is no, I can let it go and move on without losing sleep over it.

I learned about this reading The Everything Store by Brad Stone. The idea is called the Regret Minimization Framework. When Jeff Bezos was deciding whether to leave his job and start Amazon, he used this exact exercise. He imagined himself at 80 and realized he would regret not trying, even if it failed. The potential regret of not trying was worse than the potential regret of trying and failing.

How I Keep Track of Everything at Work

you@example.com (Jose Villalta) — Wed, 15 Apr 2026 04:58:04 -0700

One of the things I learned at Amazon is how to manage a workload significantly larger than any other place I’ve ever worked at. I understand the reason for it: at Amazon the team that creates the service owns it. That means they are the operators and responders as well as designers and testers.

As a result, senior engineers often have more than one project going on at any given time. So how do you keep track of it all? Well, I have a system of “rituals” or routines that I use. It’s very simple and I’ve taken inspiration from the “Getting Things Done” GTD method, as well as other time management books I’ve read.

Eisenhower Matrix

you@example.com (Jose Villalta) — Mon, 13 Apr 2026 07:51:31 -0700

One big challenge that comes up a lot at work is that there are always more things to do than time and people to do them. There’s always tech debt that we want to pay off. Long-term migrations away from systems that are going to reach their end of life, that weird bug that nobody knows for sure what’s causing it, the big project announced publicly that has a lot of visibility. Meetings to attend, Slack messages, emails to reply to, conferences, patents, books to write. You get the picture.

Humble Book Bundle

you@example.com (Jose Villalta) — Fri, 10 Apr 2026 08:34:08 -0700

I just started reading an early access ebook copy of The Linux Memory Manager by Lorenzo Stoakes, thanks to the book bundle Linux the Good Stuff. I am trying to learn all about memory management in Linux. This is deep stuff.

One time, long ago, at a different job, I implemented malloc for an embedded system running on a custom-made RTOS. At the time I felt like a l33t hack3r even though I’m pretty sure I copy pasted the code from somewhere, tested that the system boots, and called it good. Comparing that to Linux memory management is like comparing a tree house to the Empire State Building. So anyway, I need to dive deep and really grok Linux; it comes up a lot when debugging issues at work.

Being Oncall

you@example.com (Jose Villalta) — Tue, 07 Apr 2026 06:54:07 -0700

Being Oncall

I’m primary oncall for my AWS Service this week, so I might not have enough time to write every day, but as promised here’s a quick thing, what’s oncall like? I’m not going to give you stories today, but I can tell you what concepts go through my head during oncall week.

Monitoring Distributed Systems.

Logs, metrics, alarms, how to read them, troubleshoot issues, respond to alarms.

Ticket Response

How to address customer tickets, making sure they have a good experience but have a bias toward self-service, otherwise the system doesn’t scale.

Working Backwards

you@example.com (Jose Villalta) — Mon, 06 Apr 2026 08:00:41 -0700

There’s a mental model that comes up a lot in my day to day. When I’m solving a problem, I start by thinking about the result I want, and work backwards from there. The challenge is having the clarity to define the problem and taking care that I’m solving the right problem. This is why I start with the goal in mind.

I use the working backwards method when designing a feature. We start by writing a PRFAQ document, a document that specifies the public announcement of the feature with a section for frequently asked questions. When doing a small change or a simple bug fix, I also do the same thing, but instead of a PRFAQ doc I imagine sending an email to the team or a message on Slack saying what was fixed and what customers experience after the change.

How to Make Good Decisions

you@example.com (Jose Villalta) — Fri, 03 Apr 2026 11:10:27 -0700

“It’s tough to make predictions, especially about the future”

–Yogi Berra

Making decisions is a life skill, no doubt about that. Making decisions when you have limited info is common and it’s what eventually separates good leaders from the rest.

On today’s episode of “One small thing per day” I want to mention a gem I learned reading “Thinking in Bets” by Annie Duke.

Separate Decision from Outcome

Do not use the result as a perfect signal of decision quality, especially when the sample size is small. A bad result can come from a good decision. For example Pete Carroll’s decision to pass and not rush in Super Bowl XLIX had a bad outcome but the decision making rationale was sound.

Emotional Math

you@example.com (Jose Villalta) — Thu, 02 Apr 2026 05:03:53 -0700

I recently finished reading Thanks for the feedback by Douglas Stone and Sheila Heen and I can’t recommend it enough, especially now that it’s performance review season at many companies.

I’ve taken many lessons from this book, but I want to focus on something that was super insightful when trying to understand people’s interactions.

All of us have blind spots. Things that we don’t see and don’t realize that we don’t see them. One of the causes is that we judge ourselves differently than other people judge us.

Announcing a Small Update per Day

you@example.com (Jose Villalta) — Wed, 01 Apr 2026 08:56:25 -0700

A new goal: publish a tiny micro post every day

I have been meaning to write for a long time. I want to publish updates about what I’ve been learning in real time, but I always want to give beefy, meaningful, and helpful content, and that makes me put things off. So I think that starting now (bad timing, I know, this is not an April Fools’ joke, I promise), I will publish daily: one small thing I have learned. This way I can document my journey and my growth. I promise you this will be my real voice, not a chatbot instructed to give some buzzword-riddled slop.

Understanding Container Networking

you@example.com (Jose Villalta) — Sun, 09 Nov 2025 12:47:55 -0800

The Problem Containers Solve

Docker emerged as a lightweight alternative to virtual machines. VMs consumed significant resources and took 3-5 minutes to boot, making horizontal scaling expensive. Containers package applications with dependencies into images that start in seconds, not minutes.

The Networking Challenge

Without network connectivity, containers offer limited utility. Running a single container on host networking mode works fine - the process accesses the host machine’s network resources directly. But what happens when you need:

My AI and Machine Learning Reading Journey

you@example.com (Jose Villalta) — Wed, 22 Oct 2025 00:00:00 +0000

A look at the AI and ML books that shaped my understanding of artificial intelligence, data science, and the ethics of technology.

A Deep Dive into Network Namespaces in AWS ECS Containers

you@example.com (Jose Villalta) — Sun, 12 Oct 2025 17:12:00 -0700

Ever wondered what happens under the hood when you launch an ECS task with awsvpc networking? Let's explore how network namespaces are put together when you run containers in ECS Managed Instances.

KPI for Career Success

you@example.com (Jose Villalta) — Mon, 17 Mar 2025 08:22:45 -0700

What is the one metric for sucess in your career?

Lately I’ve been thinking about what it means to grow in my career. Like, How do I know I am doing a good job? Is there a metric I can track? It turns out there’s people way smarter than me that have already thought about that and written about it.

Tanya Reilly wrote an excellent book on that subject The Staff Engineer’s Path which I reference a lot, specially when I try to figure out how I should approach my career path. I am clear in the fact that I want to stay technical, I don’t want to be a manager, not because there’s anything wrong with being a manager. The thing is: I don’t want to stop writing sofware. I want to design, implement, test, deploy, maintain and deprecate software systems. I don’t want to stop doing that, at least, not for now. So anyway, there’s a lot of good advice out there, there’s a lot of things you can optimize for. If you want to go from software engineer to senior you need to know things, you need to be responsible and reliable. If you want to grow in your career then you need to be a leader, a role model, you need to be the glue that facilitates collaboration. Since there’s so much to know, so many different ways to help a team. There are so many rabbit holes one can go down in depth: Business Domains, Customers, new fields developments. There’s so many good people to meet. So, you can’t know and do everyting. You have a limitied amount of time and everything counts. So then, how do you know you are doing a good job? What is the North Star?

How to be Right a Lot (or at least Not Wrong A Lot)

you@example.com (Jose Villalta) — Fri, 14 Mar 2025 15:53:03 -0700

I’m lucky that I get to work with people who are good at what they do. The corporate-speak term we use at Amazon is the Leadership Principle of “Right A Lot”

For me it’s about having a scientific mindset, or more plainly, constantly wondering, “how does this work?” “Why are things working this way, instead of that way?” or my favority “What would happen if I do this” but wondering and inquiring is not the whole thing, is actively working to disconfirm your beliefs. It’s about being open to the possibility that you might be wrong. I love that.

Practical Engineering

you@example.com (Jose Villalta) — Wed, 05 Mar 2025 09:21:38 -0800

Practical Engineering by Peng Zhang

I want to give a quick shout out to Peng’s blog peng.fyi Peng works with me writing software for AWS Fargate’s Dataplane. I have been following his posts the last few days and I really like this blog because:

Technical topics that apply to most folks in my team
His posts are short and to the point.
He illustrates his points with code.
The code is formatted with beautifcul syntax highlits that makes it easy to read.
I get inspired myself to share my insights in writing.

Thanks Peng!

The Sirens Call: How Attention Became the World's Most Endangered Resource

you@example.com (Jose Villalta) — Wed, 05 Mar 2025 08:49:27 -0800

Book Review

I’m almost finished with The Siren’s Call by Chris Hayes and it’s interesting enough to call out here.

The book starts with an excellent explanation of what attention is and how it works. Then the book presents two analogies to use when thinking about attention.

The first one is to think of Attention as a resource that drives the economy, like labor, it is commodified, it can be monetized, marketed bought and sold. Since information is now pletiful, (there’s too much of it, really) attention is scarce, we have a limit of how much information we consume, how much we can pay attention to. So now market forces, tech companies, politicians they are all competing for our attention. Our attention has value, it yields money, power and fame.

How do you architech change? The answer is simple, but not always easy

you@example.com (Jose Villalta) — Sat, 01 Mar 2025 16:13:55 -0800

This week I had an Eureka moment at work. You see, there are many things I see at work that I would like to improve. Technical debt in our codebase. Inefficient processes. Communication silos across teams. The list of things one can improve never ends, this is true in all software shops. System complixity grows as new functionality gets added, inefficiencies optimized, bugs fixed. Secuirty hardened, etc.

How do you increase the quality of your system without interrupting the flow? Well, obviously, you break it up, one tiny thing at time. That’s how. Yeah it’s obvious but (this is embarrasing to admit) I get the urge to make BIG changes, I’d like to rewrite whole chuncks of the codebase, I’d like to build a brand new release pipeline, and we might do that someday, but not today. When you have a team that’s busy doing the work, tidying up gets deprioritized. After all, that bug in prod needs to get fixed yesterday, that new feature needs to ship on time. Oh, by the way, the developer that was working on that thing your system depends on quit last week.

Understanding Container Port Mapping

you@example.com (Jose Villalta) — Thu, 19 Dec 2024 11:00:00 -0800

The Problem Containers Solve

The Networking Challenge

Learning Go

you@example.com (Jose Villalta) — Tue, 27 Aug 2024 08:32:11 -0700

I have been an official Go programmer for three years now. Unlike many people in my team, I remember the day Google announced go. I don’t remember if it was in Hacker News or /programming reddit, but I do remember watching the go math package compiling in less than a second, at the time, I was writing C++ for an embedded system. Building the whole model as we used to say took 45 minutes, this compiled our C/C++ project into a .out file for an ARM9 and a C55 DSP. When I saw how quickly Go built I was like, wow. To be fair, our build was for a Real Time OS so it didn’t even include the C++ standard library. Most of the time, if I remember right, was spent linking everything. THe linker was getting it’s poor butt kicked. Anyyway, I looked at Rob Pike (?) on YouTube and I was like,

Awesome Falsehoods Programmers Believe

you@example.com (Jose Villalta) — Wed, 08 Nov 2023 07:57:58 -0800

A curated list of falsehoods programmers believe in.

The Code we write is a representation of the things we believe are true about the world. Every one has just one name, right? Well, most of the time, yes. All of the time? No. If you write an app for yourself, or your small business most of these assumptions are fine. If you write code for millions of users, you are going to find exceptions. Some of them surprise me. Dealing with Time sucks, dealing with addresses, names, supporting multiple languages it’s really hard to get it right 100% of the time.

Book Summary: Thinking in Systems by Donella Meadows

you@example.com (Jose Villalta) — Sat, 04 Nov 2023 16:18:25 -0700

Book Summary: Thinking in Systems

Let’s say you want to build the perfect self-driving vehicle. This thing you want to make is composed of many parts. There’s the car itself made up of many subparts (engine, tires, transmission, etc) as well as the AI tech. Realistically you will need a bunch of speciallized embedded systems as well as a central computer to orchestrate everything. There’s sensors, actuators, orchestrators, etc. In short, how does one person know if a design is good? How do you know how fast the visual recognition needs to be to handle controlling a car going 60 mph?

The top 3 podcasts for Software Developers

you@example.com (Jose Villalta) — Tue, 31 Oct 2023 09:05:57 -0700

The Top 3 Podcasts for Software Developers

Go Time by Changelog

link

This is the podcast to keep up-to-date with all things Go. The jokes are nerdy and the hosts are sometimes not as funny as they think they are, but the content is great and they have a wide set of guests in the show that make it a must for all people who write go for a living

Article Review: Lessons Learned from Twenty Years of Site Reliability Engineering

you@example.com (Jose Villalta) — Tue, 31 Oct 2023 08:29:26 -0700

Article: Lessons Learned from Twenty Years of Site Reliability Engineering

Link to article

The site realibility team at Google put together a summary of the lessons they have learned over the years. I am glad they decided to share. The best way to learn is by trial and error. Want your product or service to be better? Launch it, monitor it, and learn from the mistakes. It nice to learn from others, but there is no substitue to first hand experience. This is the list they came up with:

Staff Engineer Path

you@example.com (Jose Villalta) — Mon, 24 Jul 2023 09:05:00 -0700

Book Review: The Staff Engineer’s Path by Tanya Reilly

Tanya Reilly gives a guide for individual contributor software engineers who wish to grow their career but do not want to become managers. It gives insights about what a staff engineer does, and what you need to do to perform at that level. This is a technology-agnostic book. It gives the reader a high level view of the functional areas that matter.

Coroutines for Go

you@example.com (Jose Villalta) — Tue, 18 Jul 2023 06:51:45 -0700

Go

Russ Cox put out an article yesteday about adding the abilities to run coroutines in go. Today I learned the difference between a goroutine and a coroutine. Coroutine is a concurrency pattern in which only one runs at a time. Say we have coroutine A and B. B waits while A runs then A yields to B and A waits while B runs. It turns out this is useful in a few scenarios.

Learning File Systems

you@example.com (Jose Villalta) — Sat, 15 Jul 2023 21:21:31 -0700

Lately I have been learning about File Systems from the book “Operating Systems. Three Easy Pieces” by Remzi Arpaci-Dusseau.

I used to think that I knew how file systems worked because the interface open, read and write is so straight forward, what else could there be to it? But then at work some weird issues come up where some weird behaviour happens, like, du says the disk has space but df says the disk is full, what could make that happen? Or when an issue mounting a volume occurs and you realize that you don’t know the difference between mounting a block device versus mounting a file system. Are they both the same thing? I need to have a mental model of what the system is doing in order to debug it. Knowing the data structures in the file system and having an idea of what happens when you open a file, how does the operating system find the file? how does it traverse the file tree? What is in memory versus disk? I must confess I am still in the dark when it comes to container images and union file systems. I understand how a container is made up of many layers over imposed on top of each other. An image is essentially a tar file of different file systems on top of each other. But, how is it implemented? how do you, can you just put a whole other /proc and other system files on top of a kernel? So anyway, that’s what I have been up to.

My Tsundoku Pile

you@example.com (Jose Villalta) — Sun, 22 Jan 2023 20:02:32 -0800

I’m trying to get through all my technical books that I’ve adquired, and never gotten around to. Not going to lie, the Knuth books are intimidating. They are actually not that bad to get through, but they are books that I pick up, read a few pages on a specfic project, try to do a problem or two, and that’s it.

The other books are less intimidating, more doable, I’m pretty sure al but one of these books were lying around the Amazon campus just sitting on shelves.

Paper every Day. Day ten: The Unix Timesharing System by Dennis Ritchie and Ken Thompson

you@example.com (Jose Villalta) — Sun, 31 Jul 2022 10:40:30 -0700

Link to Paper

This paper, published in July 1974 is remarkable because the design decisions that were made back then by these guys working at Bell Labs on an operating system for the PDP-11 are still relevant.

I am still struggling to create a mental model of the unix file system, the fact that it looks like a single tree with the root at the top while simultaneously you can have multiple devices mounted dates back to these guys at Bell Labs.

Paper every day: Day Nine: An Analysis of Linux Scalability to Many Cores

you@example.com (Jose Villalta) — Mon, 25 Jul 2022 09:13:41 -0700

Link to Paper

From the abstract:

“This paper analyzes the scalability of seven system applications running on Linux on a 48-core computer…using mostly standard parallel programming techniques -this paper introduces one new technique sloppy counters these bottlencek can be removed from the kernl or avoided by changing the application slightly”

This paper has an excellent system level tutorial on scalability. They explain that you don’t get linear increase in performance because in real life applications parallel tasks usually interact, an interaction forces serial execution. Then they list the common causes with common solutions. This paper is throughly written and researched. Writing truly parallel code is difficult and even then applications still compete for some shared resouce, be it a local cache, network access or disk I/O.

Lets Go

you@example.com (Jose Villalta) — Sun, 24 Jul 2022 21:42:07 -0700

Go

I have been writing go since a little after last year. I actually remember hearing about go when it first came out, back then I honestly never thought I’d be getting paid to work in it.

Even though I’ve been writing code in go for a while, I don’t think I know the language in enough depth to consider myself a go expert. I want to change that. So I am going to start writing about go here as a way to “learn in public” Expect posts on the following topics:

Paper every day. Day Eight. Omega: flexible scalable scheduler for large compute clusters

you@example.com (Jose Villalta) — Sun, 24 Jul 2022 21:30:27 -0700

Omega

Link to paper

Omega was the second cluster manager system built by Google. It is Borg’s sucessor and it was designed as a happy medium between Borg’s centralized scheduler architecture and Mesos’s two-level approach where the placement is delegated to the running framework. Omega shares the state of the cluster among leaders and uses optimistic concurrency control (detect when different cluster schedulers are competing for the same resource)

The premise of the whole paper is that a centralized scheduler does not scale well, so there must be a better way to handle scheduling different types of workloads in a fast and conrrect manner. The two main types of workloads, services and batches have different requriements and present their unique challenges. The paper explains the type of simulations the engineer at Google used to determine that conflicts among different scheduler is not that common and that Omega manages to fit more tasks in the clusters than Mesos.

Paper every day. Day Seven: Large-scale cluster management at Google with Borg

you@example.com (Jose Villalta) — Sat, 23 Jul 2022 18:56:09 -0700

Borg

Link to Paper

Borg is the cluster management system that runs hundreds of thousands of jobs at Google, it is the original system, it’s sucessor Omega was written as a reaction to the lessons learned from it. Kubernetes is the third system written with the lessons from those two. This paper helped me understand a few things about my own system since we have our own cluster managenet and scheduler system that work a little different but in general do the same job.

Paper every day. Day Six: Hints for Computer Design

you@example.com (Jose Villalta) — Fri, 22 Jul 2022 08:13:55 -0700

Link to Paper

This paper was published originally in 1983 by the legendary folks from the Xerox Palo Alto Research Center. The hints and tips should sound familiar but it’s interesting to notice the layer the author is talking about, these guys were designing at very low level. The fact that the same rules apply now it’s remarkable. It turns out breaking up a system into the right abstraction with a good interface it’s rather hard.

Paper every day. Day Five: On Designing and Deploying Internet Scale Services

you@example.com (Jose Villalta) — Thu, 21 Jul 2022 07:07:19 -0700

Link to Paper

This paper is a list of recommendations for running a large-scale system that aims to keep quality high and costs low. The author comes from the Windows Live Services Platform but this might as well be read as an Amazon internal guide since I didn’t see a thing in this list that we don’t do (or aim to do) in AWS. EDIT: Of course all these things sound familiar! The author is James Hamilton! He’s a VP and distinguished engineer here at AWS, I know him from leading the weekly AWS Ops Review meeting.

Paper every day. Day Four: Harvest, Yield, and Scalable Tolerant Systems

you@example.com (Jose Villalta) — Wed, 20 Jul 2022 06:28:24 -0700

Link to paper

Today’s paper comes thanks to Will Larson this is a recommended paper in his book Elegant Puzzle

This paper builds on the concepts from the the CAP Theorem which essentially says that when it comes to distributed systems you can only have 2 out of these 3 qualities:

Consistency
Avalaibility
Partition Tolerance

Then it introduces two concepts harvest and yield which is interesting because it’s not something you usually hear in distributed systems (this is a paper from the ’90s) and yet I think it’s import to know and to think in these terms.

Paper every day. Day Three: Container Design Patterns

you@example.com (Jose Villalta) — Tue, 19 Jul 2022 07:23:34 -0700

Day three: Design patterns for container-based distributed systems

Link to paper

Containers provide the ability to package, deploy and reuse applications using a natural isolation boundary. Developers can expose application-specific functionality as interfaces as well as more generic hooks for many systems like metrics, health, etc.

In this paper the authors present the readers with two types of container design patterns: Patterns for container in the same machine (Single node) and patterns where the containers are spread out in different machines (multi node)

Paper every day. Day Two: Kubernetes

you@example.com (Jose Villalta) — Mon, 18 Jul 2022 06:33:49 -0700

Welcome to day 2 of my paper-every-day journey. Today we’re going to cover Borg, Omega and Kubernetes This paper goes over how Kubernetes, the de-facto, open-source orchestrator of containers was developed using the lessons learned from building Borg and Omega, Google’s internal job orchestrator.

Kubernetes is a container orchestration system that aims to make developing and deploying complex distributed systems easier. The Borg and Omega papers are excellent papers on their own right, but this explanation original published in ACM Queue is very insightful. These are the lessons I gathered:

Goal: A Paper Every Day. Day One: Mesos Paper

you@example.com (Jose Villalta) — Sun, 17 Jul 2022 13:04:01 -0700

I’ve decided to read a research paper each day. I am doing this in order to get better at my craft. I want to be better at designing software and it has been shown in research that the people who are really good at what they do are those that do “delibarate practice” I am most definitely NOT the best software system designer out there, but talent is overated and I intend to improve my knowledge one day at time. You are welcome to follow along.

About Me

you@example.com (Jose Villalta) — Mon, 01 Jan 0001 00:00:00 +0000

About Me

I’m Jose Villalta, an infrastructure engineer at Amazon Web Services building the systems that power millions of containerized workloads. I maintain the Fargate agent - the data plane that creates and manages serverless containers at AWS scale.

My Path to Infrastructure

My career has been about building systems that work when it matters most. I spent seven years at Motorola writing embedded software for P25 radios - the devices that first responders depend on when lives are on the line. Police and firefighters still use radios running code I helped build.

New blog!

you@example.com (Jose Villalta) — Mon, 01 Jan 0001 00:00:00 +0000

Started a new page to write about tech stuff. Work in Progress

Professional Experience and Education

you@example.com (Jose Villalta) — Mon, 01 Jan 0001 00:00:00 +0000

Summary

Amazon 2018 - present

AWS Fargate: Dataplane team. Writing Golang mostly.
Worked on retail site for 2.5 years using the away team model.

Impinj 2014 - 2018

Wrote Ruby on Rails

Motorola 2007 - 2014

Low level firmware

Co-op Intern at IBM 2005 - 2006

ASIC design model testing

Education

Master’s Degree in Electrical and Computer Engineer from the University of Florida
Bachelor’s Degree in Computer Engineering from Florida Atlantic University

My Career Journey

This is a more detailed narrative of my carreer so far. I’ve been lucky to work on cool projects solving interesting problems.