DEV Community: Tawanda Nyahuye

Automate Spotify and YouTube Playlists - Chapter 2: Setting Up Spotify

Tawanda Nyahuye — Tue, 21 Jul 2026 05:55:59 +0000

In Chapter 1, we talked about what we're building and what accounts you need. If you've got a Spotify account, a Google account, and a GitHub account ready, you're exactly where you need to be.

Today we set up Spotify. By the end of this chapter, you'll have three things: a CLIENT_ID, a CLIENT_SECRET, and a REFRESH_TOKEN. These are the keys that let our script talk to Spotify on your behalf.

Let's go.

Step 1: Create a Spotify Developer App

Open your browser and go to developer.spotify.com. Log in with your regular Spotify account — the same one you use to listen to music.

Once you're in, click on your profile name at the top right, then click Dashboard.

You'll land on a page that says "My Apps" with a button that says Create app. Click it.

A form appears. Fill it in like this:

App name: Something descriptive. I'll use youtube-to-spotify. You can name yours whatever you like.
App description: " \"Syncs a YouTube playlist to Spotify.\" One sentence is enough."
Redirect URI: Type exactly this: http://127.0.0.1:8888/callback

That Redirect URI looks technical, but it's just a local address on your own computer that Spotify will use during the one-time login step we'll do shortly. Copy it exactly as written.

APIs used: Check the box for Web API.

Accept the terms and click Save.

Your app is created. You'll land on the app's settings page.

Step 2: Copy Your Client ID and Client Secret

On your app's settings page, you'll see two values:

Client ID — visible immediately, a long string of letters and numbers
Client Secret — click "View client secret" to reveal it

Copy both of these somewhere safe for now — a notes app, a text file, anywhere. We'll put them in the right place in Chapter 5 when we set up our project.

These two values identify your app to Spotify. The Client ID is like a username. The Client Secret is like a password. Don't share them publicly.

Step 3: Get Your Refresh Token (The One-Time Login)

This is the step that trips most people up, so read carefully. I promise it's not as bad as it looks.

Here's why we need a Refresh Token: when our script runs automatically every day on GitHub, nobody is sitting there to log in to Spotify. The script needs a way to prove it has permission to modify your playlists without you clicking "Login" every time. The Refresh Token is that proof — a long-lived credential you get once, store safely, and the script uses forever.

We get it by doing a one-time login flow. Here's how.

3a. Build the Login URL

Take the URL below and replace YOUR_CLIENT_ID with your actual Client ID:

https://accounts.spotify.com/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=http://127.0.0.1:8888/callback&scope=playlist-modify-public%20playlist-modify-private

Paste that full URL into your browser and press Enter.

Spotify will ask you to log in (if you aren't already) and then show a permissions screen asking if you want to give your app access to your playlists. Click Agree.

After you click Agree, your browser will try to open a page at http://127.0.0.1:8888/callback — and it will fail with something like "This site can't be reached." That's completely fine and expected. We haven't built a server to catch that request. What we need is already in the browser's address bar.

Look at the URL in your address bar. It will look like this:

http://127.0.0.1:8888/callback?code=AQBvXw3Kv...a_very_long_string_here

Copy everything after ?code=. That long string is your authorization code. Don't close the tab yet.

3b. Exchange the Code for a Refresh Token

Now we'll swap that code for a Refresh Token using a tool called curl. If you're on Windows, open Command Prompt. On Mac or Linux, open Terminal.

Run this command, replacing the three placeholder values with your own:

curl -X POST https://accounts.spotify.com/api/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code" \
  -d "code=YOUR_AUTHORIZATION_CODE" \
  -d "redirect_uri=http://127.0.0.1:8888/callback" \
  -u "YOUR_CLIENT_ID:YOUR_CLIENT_SECRET"

If curl isn't available on your Windows machine, you can use PowerShell instead:

Invoke-RestMethod -Method Post -Uri "https://accounts.spotify.com/api/token" `
  -Headers @{ Authorization = "Basic " + [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("YOUR_CLIENT_ID:YOUR_CLIENT_SECRET")) } `
  -Body @{
    grant_type   = "authorization_code"
    code         = "YOUR_AUTHORIZATION_CODE"
    redirect_uri = "http://127.0.0.1:8888/callback"
  }

Press Enter. You'll get back a block of JSON that looks like this:

{
  "access_token": "BQA...short_lived_token",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "AQA...this_is_the_one_you_want",
  "scope": "playlist-modify-private playlist-modify-public"
}

The value next to "refresh_token" is what we're after. Copy it and keep it safe alongside your Client ID and Client Secret.

The access_token expires in an hour. The refresh_token doesn't expire (unless you revoke it). Our script uses the Refresh Token to generate a fresh access token every time it runs — that's why it works unattended.

Step 4: Note Your Spotify Playlist ID

Remember the playlist you created in Chapter 1? We need its ID.

Open Spotify, right-click on your playlist, and select Share → Copy link to playlist. You'll get a link like:

https://open.spotify.com/playlist/37i9dQZF1DXcBWIGoYBM5M

The part after /playlist/ is your Playlist ID. In the example above, that's 37i9dQZF1DXcBWIGoYBM5M. Copy that too.

What You Have Now

At the end of this chapter, you should have four things written down:

What	Where to find it
`CLIENT_ID`	Spotify Developer Dashboard → Your App → Settings
`CLIENT_SECRET`	Spotify Developer Dashboard → Your App → Settings
`REFRESH_TOKEN`	From the curl/PowerShell command above
`SPOTIFY_PLAYLIST_ID`	From the share link of your playlist

These go into our .env file in Chapter 5. Keep them private.

What's Next?

In Chapter 3, we set up the YouTube side. We'll enable the YouTube Data API, grab an API key, and get the ID of the YouTube playlist we want to mirror.

See you there.

Automate Spotify and YouTube Playlists - Chapter 1: Understanding The Plan, Setting Up Accounts

Tawanda Nyahuye — Mon, 20 Jul 2026 05:34:43 +0000

Have you ever been deep in a YouTube rabbit hole, vibing to a playlist either you or someone made, and thought: "I wish I could listen to this on Spotify while I pretend to be productive at work"?

Well, my friend. It's your lucky day.

We are going to build a Python script that watches a YouTube playlist and automatically mirrors it on Spotify. Every day. Without you lifting a finger. Like a personal music intern who works for free and never complains.

And before you close this tab because I said "Python script" — stay with me. This tutorial is for everyone. Coders, non-coders, the person who still thinks Wi-Fi is witchcraft. We are going step by step, and nobody gets left behind.

What Are We Actually Building?

Here's the vibe in plain English:

"Every day at midnight, a computer (well, GitHub's computer — more on that later) checks a YouTube playlist, finds all those songs on Spotify, and keeps our Spotify playlist perfectly synced."

That's it. That's the whole product. Your YouTube playlist becomes a live feed for your Spotify playlist. Songs added on YouTube? Added on Spotify. Songs removed? Gone from Spotify too. You just... listen.

Here's a peek at what the finished script does when it runs:

----------------------------------------------------------------------------
Search Query: Don’t Stop ’til You Get Enough Michael Jackson
1. Found: Don’t Stop ’Til You Get Enough by Michael Jackson
----------------------------------------------------------------------------
Search Query: I Was Made for Lovin’ You Kiss
2. Found: I Was Made for Lovin’ You by Kiss
----------------------------------------------------------------------------
Search Query: Some Random Deleted Video
3. Skipped (Deleted/Private): [Deleted video]
----------------------------------------------------------------------------
Search Query: Very Obscure Song Title
4. Song Not Found: Very Obscure Song Title

Summary:
Total YouTube songs: 100
Found on Spotify: 97
Not Found on Spotify: 3
Added to playlist: 12
Removed from playlist: 5

Clean. Automatic. No manual effort. Let's build it.

What Is an API? (The Non-Nerd Explanation)

Almost every app you use — Spotify, YouTube, WhatsApp, Instagram — has two faces.

There's the pretty face: the app you see on your phone with the nice buttons and animations. And then there's the back door, which developers use to talk to the app directly without clicking any buttons. That back door is called an API (Application Programming Interface).

Think of it like this. If Spotify were a restaurant:

The app on your phone is the dining area — nice tablecloths, a menu with pictures.
The API is the kitchen window where you shout your order directly to the chef, skip the waiter, and get your food in a bag.

For almost every popular website — spotify.com — there's a developer.spotify.com. That's the kitchen window. And that's exactly where we're going.

In this series, we'll be talking to two kitchens:

🎵 Spotify's kitchen: developer.spotify.com
📺 YouTube's kitchen (run by Google): console.developers.google.com

The Series Map

Here's where we're going, so you know what to pack:

Chapter	What We're Doing
Chapter 1 (you are here)	Understanding the plan, setting up accounts
Chapter 2	Setting up Spotify — creating an app, getting our secret keys
Chapter 3	Setting up YouTube — getting our API key, finding our playlist
Chapter 4	Writing the simplified code — what each part does
Chapter 5	Running it on your computer for the first time
Chapter 6	Deploying to GitHub Actions — making it run daily, forever, for free

By the end of this series, you'll have:

A Spotify playlist that auto-updates from YouTube
The code on GitHub (public, your first open-source project!)
A GitHub Action running it every day on a schedule
Bragging rights

What You'll Need (Before We Write a Single Line of Code)

Good news: Chapter 1 requires zero coding. You just need accounts. Here's the shopping list:

1. A Spotify Account

Go to spotify.com and sign up if you haven't. The free tier works fine for our purposes. You don't need Premium to use the API.

Pro tip: Create a fresh playlist on Spotify right now and call it whatever you want (I will be using this: 70's Music Hits Playlist - Best of 70s Music). This is going to be the playlist our script writes to. Don't put anything precious in it yet — we're going to be playing with it. Later on you should be able to grab any playlist of your choice from YouTube Playlists.

2. A Google Account

You probably already have one. The YouTube API lives inside Google's developer tools, and you'll log in with your regular Google account. If you use Gmail, you're already there.

3. A GitHub Account

GitHub is where we'll store our code and (in the final chapter) run it automatically for free every day. Sign up at github.com if you don't have one.

GitHub is basically Google Drive, but for code. Instead of documents, you store code files. Instead of sharing a link to a spreadsheet, you share a link to your project. It's very normal and not scary.

4. Python (We'll Install This Together)

Python is the programming language our script is written in. We'll install it together in Chapter 5. For now, just know it exists, and it's friendly. It reads almost like English, which is why we picked it.

That's your whole list. Four accounts (you probably have three already), and we're off to the races.

A Quick Note on "Secret Keys"

When you connect to Spotify's or YouTube's API, they give you what are called credentials — essentially a username and password for your app. These are private. You never share them publicly.

In our project, we'll store these in a file called .env (dotenv — just a text file with a funny name). It looks like this:

CLIENT_ID=abc123
CLIENT_SECRET=xyz789
API_KEY=my_youtube_key_here

Think of it as the password notebook that lives only on your computer (and later, securely on GitHub). We will never put this file on the internet. The code goes on GitHub. The secrets stay private.

This is an industry standard practice. Every real app does this. You're already coding like a professional and you haven't written a line yet. 😎

What's Next?

In Chapter 2, we head to developer.spotify.com, create our app, and walk away with the three magic keys we need: a CLIENT_ID, a CLIENT_SECRET, and a REFRESH_TOKEN.

Yes, there are three of them. No, it's not complicated. Yes, I'll show you exactly where to click.

🎵 Final Product

After following the steps in this tutorial, your playlist should look similar to the one below:

🎧 View the completed Spotify Playlist

See you there. 🎧

Got questions? Drop them in the comments. See something confusing? Tell me which part so I can fix it. This series only works if everyone can follow along.

Automate Spotify and YouTube Playlists - The Complete Series

Tawanda Nyahuye — Sun, 19 Jul 2026 19:40:37 +0000

Have you ever liked a YouTube playlist so much that you want to take it with you to Spotify?

This series walks you through building a Python script that syncs a YouTube playlist to Spotify automatically, every day, without you lifting a finger. No experience required. By the end, you'll have real code running on a real schedule, and a Spotify playlist that keeps itself up to date.

Here's everything, in order.

The Series

Chapter 1: Understanding the Plan, Setting Up Accounts
What we're building, how APIs work without the jargon, and the four accounts you need before writing a single line of code.

Chapter 2: Setting Up Spotify
Creating a Spotify developer app, getting your Client ID and Client Secret, and walking through the one-time login flow that gets you a Refresh Token.

Chapter 3: Setting Up YouTube
Enabling the YouTube Data API on Google Cloud, generating an API key, and finding the playlist ID of the YouTube playlist you want to mirror.

Chapter 4: Writing the Code
A plain-English walkthrough of all three files — youtube.py, spotify.py, and script.py — and what each part actually does.

Chapter 5: Running It Locally
Installing Python, setting up the project folder, and running the script for the first time. You'll watch it pull songs from YouTube and build your Spotify playlist live.

Chapter 6: Deployment
Pushing the code to GitHub and setting up a GitHub Action that runs the sync every day on a schedule — for free, forever.

The Code

The full source code is on GitHub: github.com/Towernter/youtube-to-spotify

Who This Is For

This series is for everyone. If you can follow a recipe, you can follow this. The chapters that involve code explain every line in plain English — no assumed knowledge. If something doesn't make sense, drop a comment on that chapter, and I'll fix the explanation.

Start at Chapter 1 and work through in order. Each chapter ends exactly where the next one begins.

Closed World Innovation: Stop Telling People to "Think Outside the Box." There Is No Box.

Tawanda Nyahuye — Sun, 12 Jul 2026 14:14:21 +0000

"Think outside the box!"

Great advice. Incredibly helpful. One small problem: nobody knows where the box is.

What even is creativity, anyway?

Before we get to boxes and closed worlds and all that fun stuff, let's settle on what creativity actually means, because "be creative" is about as actionable as "be taller."

Creativity is when two things are both high at the same time: originality and usefulness. That's it. Something no one's ever seen before and something that actually works. Just weird? Not creative. Just useful? Also, not creative, that's just engineering. Both? That's the good stuff.

There's also simplicity in the mix, but let's not get greedy.

Why "think outside the box" is terrible advice

Here's what actually happens when you tell someone to think outside the box.

They imagine a box. Then they try to think around it. And because the box they imagined is shaped by the exact same problem they're trying to solve, they end up either with solutions so bizarre they'd never survive contact with reality, or they circle all the way back to the traditional solution they started with.

You've just run a very tiring mental exercise to arrive at the answer you already had. Congratulations.

The phrase also has another problem: in the real world, there are no boxes. No one drew a boundary around your problem and labeled it "the box." The "box" is just a metaphor that your brain takes too literally and then gets confused by.

The correct term, the one that actually helps, is the Closed World.

So what's the Closed World?

The Closed World was discovered by a researcher named Roni Horowitz, and the idea is almost annoyingly counterintuitive:

Ideas are more creative when they are confined to what's already around you.

Not outside. Not somewhere exotic. Right there. The resources, people, components, and constraints you already have are your closed world. And here's the punchline: constraints don't kill creativity. They enhance it.

Think about soldiers frying eggs on a shovel over a campfire because there's no pan. Or a forklift being used as an improvised cherry picker because there's no ladder tall enough. Nobody went outside their world to solve those problems. They looked at what they already had and asked: what else can this do?

That's the closed world doing its thing.

Why constraints are actually your friends

You'd think unlimited freedom would produce unlimited creativity. That sounds logical. It is also completely wrong.

When you have too many options, your brain does the creative equivalent of standing in front of a massive restaurant menu for twenty minutes and ordering a burger. You default to the familiar because the familiar is safe, and you're overwhelmed.

Constraints force your brain to actually work. When you can't reach outside the problem, you start looking at the problem differently. You start noticing things about what you have that you'd ignored before. Sometimes the solution was sitting right there the whole time, like the answer to a riddle you'd been overthinking.

The thing traditional thinking gets wrong about problems

Traditional thinking says: problems are bad, solutions are good. Get rid of the problem as fast as possible and replace it with a solution.

This sounds sensible. It is also why so many solutions are completely forgettable.

If you sprint away from a problem, you never actually understand it. And if you don't understand it, you can't use it. Because here's the thing: in many cases, the problem itself is part of the creative solution.

The problem contains information. It contains context. It contains constraints. And those constraints, if you work within them instead of around them, are exactly what will lead you to something original and useful, you know, the two things that make something creative.

Apollo 13, the ultimate closed world story

If you want to see closed world thinking in action at its most dramatic, look up the Apollo 13 CO2 filter problem. The astronauts had square filter cartridges. The ship needed round ones. People were going to die.

The engineers at NASA didn't order new parts. They couldn't. They couldn't go outside the closed world; they were literally 200,000 miles from the nearest hardware store.

So they sat down with exactly what was on that spacecraft and figured out how to fit a square peg in a round hole. And they did.

That's not thinking outside the box. That's thinking inside the only world available, and doing it brilliantly.

So what do you actually do with this?

Next time you're stuck on a problem, instead of trying to escape it, do this:

Draw your closed world. What people, tools, components, and resources are already part of this situation? What's right in front of you that you haven't thought to repurpose? What does the problem itself tell you about the solution?

Then stay there. Don't go looking for something exotic. The opportunity is usually right under your nose; you've just been too busy looking for a box to climb out of.

Stop thinking outside the box. Start thinking inside the closed world. The answers you need are probably already in the room.

New To Backend Development? What You Should Learn

Tawanda Nyahuye — Mon, 06 Jul 2026 05:38:09 +0000

Every week someone asks me some flavour of the same question: "I want to get into backend, what should I learn?" And nine times out of ten, they've already found The Roadmap. They stared at it for ten minutes and quietly concluded that backend development is a thing for other, smarter people.

The honest answer is much shorter than the roadmap makes it look, and it starts with something that isn't even on the roadmap.

Step zero: pick a language and marry it

There's a line usually pinned on Bruce Lee:

I fear not the man who has practiced 10,000 kicks once, but the man who has practiced one kick 10,000 times.

That's the entire beginner strategy in one sentence.

Pick one language. Java, C#, Python, PHP, Go, JavaScript, pick the one your local job market actually hires for, and then stop shopping. The developer who knows one language deeply will run circles around the one who knows five languages well enough to be dangerous and not one of them well enough to be hired.

I know the temptation, because language-hopping feels like progress. New syntax! New shiny tutorial! A fresh "Hello World" in a fresh colour scheme! But it's a trap, you're just re-learning the same beginner content five times in different fonts. Variables are variables. Loops are loops. Functions are functions. Learn them properly once, in one language, and every other language afterwards is just the same kick with a slightly different accent.

And here's the part that makes the rest of this list far less scary: almost nothing below is actually about the language.

These are concepts, not frameworks

This is the thing nobody tells beginners, so they panic and assume they have to re-learn everything every time they switch stacks. You don't.

REST is REST whether you write @RestController in Spring Boot, a controller in ASP.NET, a view in Django, or a route in Laravel. A database index works the same way underneath all four. JWT doesn't care what language signed it. Caching is caching. The frameworks are just different dialects for saying the same ten ideas.

So when you learn the concepts below, you're not learning "the Spring Boot way", you're learning the backend way, and your framework is just where you happen to type it. Learn it once; carry it everywhere.

Now, the list itself. Concepts don't arrive all at once. They arrive in an order, each one because the previous thing started to hurt. So here's that order.

Phase 1 — Make it work

This is where you live for your first several months, and honestly, it's enough to get hired.

APIs (REST, GraphQL, gRPC). An API is just the contract for how the outside world talks to your code. Start with REST, it's the lingua franca, it's everywhere, and 90% of jobs want it. Learn what the HTTP verbs mean (GET, POST, PUT, DELETE), what status codes are for (a 404 and a 500 are telling the client very different things), and what a clean JSON request and response look like. GraphQL (ask for exactly the fields you want) and gRPC (fast, binary, great between services) are real and useful,but they're chapter two. Don't let them distract you from nailing REST first.

Database Systems (SQL, NoSQL). Your app forgets everything the moment it restarts unless you give it somewhere to remember. That's the database. Learn SQL first, properly, no skipping, SELECT, JOIN, WHERE, and crucially indexes (the difference between a query that takes 2 milliseconds and one that takes 2 minutes). PostgreSQL or MySQL are perfect to learn on. NoSQL (MongoDB and friends) is for when your data is genuinely document-shaped or you have a specific reason, not because relational tables look scary. Most beginners reach for NoSQL to avoid learning SQL, and then learn SQL anyway, the hard way, two years later.

Ship a small CRUD app with just these two. Seriously. An endpoint that talks to a database is a complete, employable backend skill. Everything below is what you add when that app starts getting used.

Phase 2 — Make it safe

The moment a real human can reach your app, you have a new problem: not everyone is nice.

Security (OAuth2, JWT, encryption). This is the one beginners skip and later deeply regret. Learn the difference between authentication (who are you?) and authorization (what are you allowed to do?), they're different jobs and confusing them is how breaches happen. JWT is how you carry "I'm logged in" between requests (and remember: a JWT is signed, not secret, never stuff passwords in it). OAuth2 is the "Log in with Google" dance. Encryption is the difference between storing passwords safely and ending up in a data-breach headline. You don't need to be a cryptographer. You need to hash your passwords, check that the logged-in user actually owns the thing they're touching, and never trust input from the outside world.

Phase 3 — Make it real

Your app works on your laptop. Congratulations, your laptop is not the internet.

DevOps (CI/CD, Docker, Kubernetes). Docker comes first and is genuinely worth learning early: it packages your app so it runs the same on your machine, your teammate's machine, and the server. It single-handedly kills, "but it works on my machine." CI/CD is the robot that runs your tests and ships your code automatically so you stop deploying by dragging files around at midnight. Kubernetes, though? Here's me being the annoying friend: You do not need Kubernetes. You have eleven users, and three of them are your co-founders. Kubernetes orchestrates hundreds of containers across dozens of machines, a problem you should be lucky to have one day. Learn it when something actually forces you to, not because a roadmap puts it in a box.

Cloud Services (AWS, GCP, Azure). This is where "real" happens , somebody else's computer that's online 24/7. Pick one provider (AWS has the most jobs, but they all rhyme) and learn the boring fundamentals: run a server, store some files, point a database at it. Ignore the other 200 services with the cryptic three-letter names. You'll meet them if and when you need them, and you mostly won't.

Phase 4 — Make it survive

Now people are actually using the thing, and "works" quietly turns into "works slowly," then "falls over."

Caching (Redis, Memcached). The fastest database query is the one you never run. Caching means storing the answer to expensive questions so you don't recompute them every single time. Redis is the workhorse you'll reach for 95% of the time (Memcached is the simpler, older cousin). The catch, and every cache has it: deciding when to throw the stale answer away is the genuinely hard part. Serve someone yesterday's bank balance, and you'll find out fast.

Performance Optimization (profiling, load balancing). First rule: measure before you "optimize," because your gut is almost always wrong about what's slow. That's profiling, actually looking at where the time goes instead of guessing. Load balancing is splitting traffic across several copies of your app so no single one drowns. Beginners love to optimize a function that runs twice a day while ignoring the query firing ten thousand times a minute. Don't be that person. Find the real bottleneck, then fix it.

System Design (scalability, microservices). This is the big-picture "how do all the pieces fit so this survives a million users" skill, and it's the one everyone wants to learn first because it sounds impressive in interviews. Learn it here, once the smaller pieces make sense, or it's just abstract box-drawing. And on microservices: resist. Splitting your app into 23 tiny services because Netflix does is how a perfectly happy little app turns into a distributed nightmare that needs 40GB of RAM to boot on your laptop. Start with one well-organized app (a "monolith"). Split it only when a real, specific pain forces your hand.

Distributed Systems (consistency, replication). The deep end, and genuinely hard, even seniors get humbled here. The instant your data lives in more than one place, you inherit brutal questions. Replication is keeping copies of your data (for safety and speed); consistency is the headache of those copies briefly disagreeing with each other. You don't need this on day one. You need to know it exists, so that when something impossible happens in production, you know the shape of the monster you're looking at.

Phase 5 — Make it visible

Monitoring (Prometheus, Grafana). An app you can't see inside isn't an app, it's a liability with a login page. Prometheus collects the numbers (how fast, how many errors, how much traffic); Grafana draws them as dashboards you can actually read. Add logging early, correlation IDs so you can trace one request through the whole system, and watch error rates and your slowest responses (the p99, not the average, averages cheerfully hide the pain). The goal is simple: find out your app is sick from a dashboard, not from an angry customer.

The trap on both ends

Because this advice has a failure mode on each side, and I refuse to pretend it doesn't.

Lean too far into theory and you become the person who's watched 60 hours of system-design videos, can recite the CAP theorem in their sleep, and has never actually shipped a single endpoint a real human has touched. Infinite reading × zero building = zero.

Lean too far into building and you become the person who duct-tapes features together, never learns why anything works, and hits a wall the moment something breaks in a way Stack Overflow hasn't pre-solved. Infinite vibes × zero fundamentals = a very confident developer who can't debug.

The whole game is doing both: build real things, and understand why they work. Suffer through the fundamentals a little, that's where the actual skill gets forged.

So what do you actually do tomorrow

Pick one language and stop shopping. The one your local market hires for. Practice the one kick 10,000 times.
Build one tiny thing that's actually complete, an API endpoint that talks to a database. That's Phase 1, and it's already a real, hireable skill.
Then keep asking the next honest question: what breaks when a thousand strangers hit this at once? Security, then shipping, then speed, then scale, then visibility. The concepts show up in that order, every single time, you don't have to summon them all at once.

The roadmap with forty boxes isn't wrong. It's just drawn all at once, with no sense of when, which is exactly why it terrifies beginners. Read it as a story instead. You don't learn the wall of nouns in one sitting, you ship one honest endpoint, and let the next problem introduce you to the next concept.

Why Do I Enjoy Doing Things I'm Not Great At?

Tawanda Nyahuye — Fri, 03 Jul 2026 06:30:03 +0000

If you ask what goes on in my head at 3 a.m., this is it. Cristiano is on TV doing his thing. Croatia is getting robbed. And somewhere in there, my brain starts thinking about why I suck at things that I enjoy doing?.

Let me take you back a little. I write two kinds of articles. Technical ones, which come naturally to me. And the ones which I call business ones (well, the not-so-technical).

I spend most of my time on the business articles. I enjoy writing them. I enjoy reading them back too. And just so you know, I'm not writing all these articles for you. I write to document things. Technical posts are usually just answers to questions people keep asking me. Instead of explaining the same thing again, I write it once and send the link. Someone once told me that the best way to really learn something is to teach it to someone else, or even just say it out loud to a wall (You should be doing the same; trust me, it helps). So this blog is my wall. Turns out my wall has people sitting on it. That's you.

Anyway. Back to the real question.

The real question is about my own head

I think "Why do I enjoy things I'm not great at" is the wrong way to say it. The better question is: why do I think I enjoy things I'm not great at? Because this whole idea lives in my head. And the stats page just proved me wrong.

Here's what happened. I looked at the numbers on my published articles. I don't usually do this, because I write for myself, not for the numbers. But numbers don't lie. My technical articles get read a lot more than my business ones. And the business ones are the ones I enjoy writing the most.

Maybe it's the people around me. Most of them are technical, so maybe the technical stuff feels more exciting to them. Fair enough. But that only explains the blog. It doesn't explain the rest of my life.

It's not just about writing

I like playing soccer. I'm honestly the last person you'd want on your team. I'm bad. I won't pretend otherwise. But do I enjoy playing? Yes. A lot. I also like running. I'm not fast at all. But I still love doing it.

Put that next to the writing, and you can see the pattern. The things I'm good at, like technical writing, get the attention. The things I enjoy, like business writing, soccer, and running slowly, don't need attention to feel worth doing. I'd do them anyway.

So will I stop?

You might be wondering. No, I won't. The Robert Mugabe in me doesn't care. If anything, I'll keep doing what I enjoy more than what people find impressive. The numbers can do whatever they want.

Does this happen to you too?

So here's my question for you. Do you also enjoy things you're not good at? Do you keep doing them anyway, even when people notice your other skills more?

Let me know in the comments.

Applied Creativity and Concept Generation - Brainstorming

Tawanda Nyahuye — Thu, 02 Jul 2026 06:53:00 +0000

Thomas Edison put it plainly: "To have a great idea, have a lot of them." Steve Jobs said something similar. "Creativity is just having enough dots to connect... to connect experiences and to synthesise new things."

Both of them are saying the same thing. Your first idea is rarely your best one.

The reason why people you call creative can come up with great ideas easily is that they have had more experiences or have thought more about their experiences than other people.

So the question becomes: how do you get more ideas, faster?

The Most Used Method for Applied Creativity

The answer has a name. It was coined by advertising executive Alex Osborn in the 1940s. He called it brainstorming - using the brain to storm a creative problem, with each person in the room attacking the same objective.

It sounds simple. Most teams think they already do it. Most of them are wrong.

Real brainstorming is a structured process with rules. Break the rules, and you get something that looks like brainstorming but produces far fewer useful ideas.

Why Most Brainstorming Sessions Fail

Here is what kills a brainstorming session before it even starts.

Someone says an idea. Someone else says, "That won't work." The room goes quiet. People stop sharing.

That is it. That is the whole problem.

When people fear judgment, they self-censor. They only say the safe, obvious ideas. The interesting ones, the ones that could actually lead somewhere, stay locked inside people's heads.

Most teams have that one gaffer who has already decided which ideas are worth hearing before anyone has finished their sentence. Or the one who gives you the floor, listens patiently, and then quietly bins everything you said, not because it was bad, but because it was not theirs. Both types do the same damage. The room reads it. People stop sharing. And just like that, the best idea in the session never gets spoken.

The goal of brainstorming is to get more ideas. That means the number one rule is: defer judgment.

The Rules That Actually Work

1. Defer judgment of ideas

Do not evaluate while you generate. These are two different brain modes and they do not mix well. When someone shares an idea, your job is not to assess it. Your job is to write it down.

2. Build on the ideas of others

Instead of saying "that won't work," try asking "how could we make that even better?" This is sometimes called the "yes, and" rule. You take what someone gave you, and you add to it. The idea evolves into something neither person would have found alone.

3. Encourage wild ideas

This one confuses people. Why would you encourage ideas that cannot possibly work?

Because even a bad idea points somewhere useful, a wild idea might show you a direction you had not considered. Someone else in the room might hear it and think of a version that actually works. Wild ideas are not dead ends. They are arrows pointing at unexplored territory.

4. Express ideas visually

Do not just talk. Draw. Sketch. Make a rough model out of whatever is nearby. A sketch that takes thirty seconds can communicate something that would take five minutes to explain in words, and it gives the group something concrete to react to and build on.

And do not stop at sketching. Build sketch models as early as possible. You do not need a finished prototype. Cardboard, foam, tape, anything that makes the idea three-dimensional. The moment something exists in physical form, even crudely, the conversation changes. People can point at it, hold it, and immediately see things that a drawing hides. The sooner you build it, the sooner you learn what is wrong with it and what is worth keeping.

5. Stay focused on the topic

Good ideas are everywhere once you start. The facilitator's job is to keep the group from drifting. One problem at a time.

6. One conversation at a time

Side conversations fracture the group's energy. When three people are talking at once, nobody is building on anyone else. The facilitator manages this. Everyone gets heard, one at a time.

7. Use stimuli - related or unrelated to the topic

Sometimes you need a jolt from outside the problem. A random image, an unrelated object, a word pulled out of the air. These force unexpected connections. Creativity is connecting dots, remember? More stimuli means more dots.

How to Set Up a Session That Actually Works

The environment matters more than people think.

A comfortable room. Four to eight people, small enough that everyone speaks, large enough to get diversity of thought. Paper and Post-its. Coloured markers. A whiteboard. Coffee and snacks, because people think better when they are relaxed.

Give participants homework before the session. Ask them to come with ideas already formed. This is not just a nice-to-have. Research shows that people generate more and better ideas when they think individually first, before being influenced by the group.

Individuals First, Then the Group

Here is the process that works.

Start as individuals. Everyone works alone on the problem. They come up with ideas without hearing what everyone else is thinking. This builds a genuine variety of starting points, different approaches, different angles, and different assumptions about what the problem even is.

Then come together as a group. Each person shares how they approached the problem. Not just the ideas, but the thinking behind them. This is where the magic happens. One person's framing unlocks a connection in someone else's mind. Ideas combine. They get refined. Something better emerges that nobody could have reached alone.

The group goes from quantity and variety to quality and refinement.

What the Research Actually Says

Classic brainstorming has one famous rule: no criticism. But research from Charlan Nemeth at UC Berkeley suggests that allowing debate and even dissent actually produces more ideas, not fewer.

In a study across groups in France and the United States, participants were split into three conditions. The minimal condition gave people almost no guidance, just the problem. The brainstorming condition followed traditional rules: generate freely, defer judgment, and no criticism. The debate condition encouraged participants to argue, challenge, and push back on each other's ideas.

The results were striking and went in one clear direction. The minimal condition produced the fewest ideas. The brainstorming condition produced more. But the debate condition produced the most, by a meaningful margin, and consistently across both countries.

This does not mean you should tear ideas apart the moment they are spoken. It means healthy challenge, the kind that makes people think harder and explore further, is not the enemy of creativity. Groupthink is.

The rule is not "never criticise." The rule is "never dismiss." There is a difference.

That Being Said

Brainstorming is a skill. Like any skill, it gets better with practice and worse when you ignore the fundamentals.

If your team's sessions always produce the same three ideas, it is not because your team lacks creativity. It is because someone is killing ideas before they can breathe.

Run the process properly. Start individually. Come together. Build on each other. Defer judgment, then apply it.

The best idea in the room is almost never the first one out.

The German Tank Problem: Why You Need UUIDs

Tawanda Nyahuye — Sun, 28 Jun 2026 17:44:35 +0000

In World War II, the Allies had a very expensive question and no good way to answer it: how many tanks is Germany actually building?

The official method was spies, intercepted chatter, and educated guessing. The official method was also, as it turns out, wildly, embarrassingly wrong, intelligence estimates put German tank production at well over a thousand a month.

Then some statisticians showed up and ruined everyone's mystique by doing arithmetic.

See, the Germans were excellent engineers, which is another way of saying they were pathologically organized. Every tank rolled off the line with neatly sequential serial numbers stamped on the gearbox, the chassis, the road wheels, everything. And every time the Allies captured or destroyed a tank, those numbers got written down.

So the statisticians stopped trying to spy on the factories and started reading the serial numbers of the wreckage. If you've captured a handful of tanks and the highest serial number you've seen is m, and you've seen k of them, then the total number produced is roughly:

N ≈ m + (m / k) − 1

The intuition is beautiful and slightly evil: the biggest number you've seen tells you roughly how close you are to the top, and how many you've seen tells you how confident to be about that. The gaps between the serials you do have tell you about the ones you don't.

For one month in 1942, the spies said Germany was making around 1,500 tanks. The statisticians, armed with nothing but captured serial numbers and a formula, said 327. After the war, the actual German production records were recovered.

The real number was 342.

The spies missed by a thousand. The nerds missed by fifteen. Somewhere, a very smug statistician got a medal, and the lesson was carved into the bedrock of intelligence work forever:

Sequential numbers leak. If your serial numbers go 1, 2, 3, 4, anyone who sees a few of them can estimate how many of you exist.

I think about this every single time I look at a URL that says /users/1042.

Your database is the German army

Here's the uncomfortable part. Almost every backend you've ever written is the Wehrmacht, cheerfully stamping sequential serial numbers on everything and then handing them to strangers.

You spin up a Postgres table. The primary key is id SERIAL — auto-incrementing integer, because of course it is, that's the default and it's beautiful and it sorts nicely. User 1 is you. User 2 is your co-founder. User 3 is your mom. Everything is fine.

Then you build the profile page. The route is /users/3. You ship it. You are now a German tank.

Because here is what your competitor, or a bored teenager, or a journalist, or anyone with a browser, can now do. They sign up for your app today and get assigned id = 4,317. They wait a week. They sign up again with a different email and get id = 4,981.

Subtract.

You got 664 signups this week. They didn't breach anything. They didn't hack you. They read your serial numbers, exactly like the Allies read the gearboxes, and your growth rate fell out of the arithmetic. Your "we're crushing it, investors love us" pitch deck just got fact-checked by a stranger with two throwaway emails and the subtraction skills of a nine-year-old.

It gets worse, because IDs leak more than count. They leak order and time:

/invoices/58 on launch day tells the world you have billed exactly 58 times in your company's entire existence.
A support ticket numbered #7 tells your enterprise customer they are, uh, one of your first seven enterprise customers. Inspiring.
Two orders placed a minute apart with IDs 9,000 and 9,003 tell a competitor you process roughly three orders a minute at peak.

And then there's the part the security people care about, which is that sequential IDs aren't just informative, they're guessable. If I can see /api/orders/9000, I can also just... try /api/orders/8999. And 8998. And if your authorization is even slightly lazy, and friend, it is I am now reading other people's orders. This has a name. It's called IDOR (Insecure Direct Object Reference), it's been in the OWASP Top 10 for approximately forever, and it is almost always born the moment someone exposes a sequential primary key to the outside world.

Enter the UUID, wearing a fake moustache

The fix is to stop stamping your serial numbers in order.

A UUID (Universally Unique Identifier) is a 128-bit value that, in its most common form (v4), is essentially random:

f47ac10b-58cc-4372-a567-0e02b2c3d479

Look at that gorgeous nonsense. What's the previous user's ID? You have no idea. What's the next one? No idea. How many users exist? You cannot tell, because there's no sequence to read, no maximum to anchor on, no gaps to measure. The German Tank Problem needs serial numbers in a row. A UUID is a serial number that fell into a wood chipper. The formula has nothing to bite on.

As a bonus, and this is the part that wins over the people who don't care about counting attacks, UUIDs are globally unique without coordination. Two different servers, two different services, an offline mobile client on a plane, can all generate IDs at the same time and never collide. No round-trip to the database to ask "what number am I allowed to use next?" You can generate the ID before the row even exists. For anyone building distributed systems, that property alone is worth the price of admission.

So: random, unguessable, count-hiding, coordination-free. We solved it. Ship it. Close the tab.

Okay, here's where I have to be the annoying friend

Because this idea has a failure mode on each end, and I refuse to write a post that pretends UUIDs are free.

They are not free. A bigint is 8 bytes. A UUID is 16, and if you store it as text like a maniac it's 36. Across a hundred-million-row table with a dozen foreign keys pointing at it, that overhead is not theoretical, it's your storage bill and your RAM.

But the real knife is the index. Your database stores its primary key in a B-tree, which is fastest and tidiest when new values arrive in roughly increasing order, every insert tucks neatly onto the end. A random UUIDv4 arrives like a drunk guest who sits between two people at every table. The database has to constantly split pages, shuffle things around, and re-read cold parts of the index off disk. This is called write amplification and page fragmentation, and it's why someone, somewhere, migrated a high-traffic table to random UUIDs and watched their insert performance fall off a cliff and then wrote a furious blog post about it. (You will read that post right before making the same mistake. It's tradition.)

So we did what engineers always do: we fixed the fix.

UUIDv7 (standardized in 2024) puts a timestamp in the high bits and randomness in the low bits. So IDs trend upward over time — the B-tree is happy again, while still being unguessable and uncountable. You can't subtract two of them to get a signup count. This is, for most apps, the correct default in 2026.
ULIDs do basically the same trick with a friendlier, sortable text encoding.
Snowflake IDs (the Twitter classic) cram a timestamp, a machine ID, and a counter into a compact 64 bits — smaller and sortable, at the cost of leaking a little timing info.

But notice the catch, because it's the whole German Tank Problem sneaking back in the side door: a time-ordered ID still leaks the one thing it's ordered by, time. UUIDv7 won't tell anyone your total user count, but it will whisper roughly when each record was created. That's a much smaller leak than "subtract for the growth rate," but it's not zero. If creation timestamps are sensitive in your domain, even v7 is a partial disrobing. Pick your poison on purpose.

And the sneakiest trap of all: an unguessable ID is not an authorization system. A UUID being hard to guess is not the same as a UUID being protected. If your only defense against me reading someone else's invoice is "well, they'd have to guess a 122-bit random number," you have built a password and called it an ID. UUIDs slam the door on enumeration. They do absolutely nothing if you forget to check whether the person holding the ID is actually allowed to use it. Check your authz. The random ID is the lock; the auth check is the guard. You need both.

So what do you actually do tomorrow

You can't un-stamp the serial numbers on a system you've already shipped, but you fully control two dials, so go set them on purpose:

Stop exposing your primary key. The cleanest move on most teams: keep a boring auto-increment bigint as the internal primary key (your indexes stay fast, your joins stay cheap) and add a separate random external ID — a UUIDv7 — for anything the outside world ever sees. URLs, API responses, invoice numbers. The fast key stays in the basement; the wood-chipper key goes out front.
Default new public-facing IDs to UUIDv7, not v4. You get the count-hiding without setting your write performance on fire. Reach for v4 only when you specifically want zero time signal and don't care about index locality.
Then check your authorization anyway, because the ID was never the security boundary. It just stops people from reading you like a captured gearbox.

The Allies won that particular round of the war with a formula and a pile of serial numbers, because the other side was tidy enough to number everything in order and careless enough to let those numbers be seen.

Don't be tidy where it counts against you. Number your tanks at random.

The statisticians are still out there. They are still very smug. And the next time someone signs up for your app twice in a week just to subtract the IDs, you get to be the insufferable person who already shipped UUIDv7, and is, annoyingly, fine.

DESIGN THINKING SKILLS: What Makes Designers Successful?

Tawanda Nyahuye — Mon, 22 Jun 2026 06:26:00 +0000

People who make great products or services share certain skills. It is not a fancy qualification. It is not natural talent. It is a simple way of thinking called Design Thinking.

It is important to identify these skills so that we can also pick them up.

Why Can't We Just Wing It?

"Why not just build the thing and fix problems later?" A lot of teams do this. Most of them end up with a product that nobody uses.

The difference between a product people love and one that nobody touches is simple. The winning team actually understood the people they were building for. The losing team just guessed.

So What Is Design Thinking?

Design thinking is a way of solving problems that does two things:

It puts the user first, you think about the real people who will use your product, not just your own ideas about them.

It focuses on solutions, instead of spending all your time talking about what is wrong, you spend your time building what could be right. I know this is hard. The normal human instinct when something breaks is to find the person responsible and make it their problem. Design thinking says that is a waste of everyone's time. Find the fix instead.

For example. A company notices its staff avoid using the new internal system. The old way is to scream at employees, threaten them with warnings, make them write reports, or send the classic "please refer to the training manual" email that nobody reads. The design thinking way is to sit with employees, watch them use the system, and find out the main button is hidden on the wrong page. Then you move the button. Simple solution. Real impact.

The thing that makes all of this work is empathy. This means you genuinely care about how other people feel and what they go through. Without this, you are just building things for yourself and hoping others like them.

Design Thinking Framework

The design thinking process can be broken down into three steps:

Explore
Create
Implement

1. Explore — Go and See

This is the step most people skip. It is also the most important one.

Before you build anything, go talk to real people. Watch how they do things today. Ask questions. Listen more than you talk. Ask "why" again and again until you find the real problem hiding under the surface.

You are not trying to prove your idea is right. You are trying to learn something that surprises you. If nothing surprises you, you have not talked to enough people.

2. Create — Try Many Ideas

Most people think this is where design thinking starts. It is not. But this is where the fun begins.

First, write down every idea you have. Even the silly ones. Linus Pauling said the way to get good ideas is to get lots of ideas and throw the bad ones away. So write them all down first.

Then, pick your best ideas and build a rough version of each one. This is called a prototype. It does not have to look good. It just has to be something a real person can try.

A paper drawing is fine. A simple clickable screen is fine. Anything that lets a real human say "I like this" or "this does not make sense" is good enough. As Reid Hoffman said, "If you are not embarrassed by the first version of your product, you've launched too late." You are not trying to get it perfect. You are trying to get feedback fast.

3. Implement — Ship It and Keep Learning

When you finally launch, the work is not done. Watch how people actually use what you built. It will surprise you. Take what you learn and go back to step one.

The best teams never really stop exploring. Every version they ship teaches them something for the next one.

This Is Not Just for Designers

Design thinking is not about colours and fonts. Anyone can use it. A nurse, a teacher, a software developer, a shop owner, if you solve problems for other people, this way of thinking is for you.

The skills are simple: be curious, care about people, try many ideas before picking one, and test before you polish.

Start practising them today. Next time you face a hard problem, do not sit and stare at it. Go talk to the person who has the problem. Build the simplest possible answer. Then learn from what happens.

Is Your AI Assistant Making You a Better Developer, or Just a Faster One?

Tawanda Nyahuye — Fri, 19 Jun 2026 10:57:48 +0000

It's 11 pm. You have been staring at the same bug for three hours. You are tired. You give the whole thing to Codex or Claude and say, "Just fix this".
It gives you a solution. Tests pass. You commit and go to bed.

Did you understand what just fixed your bug?

I have done this, and I am sure most of us have. For me, the problem is not using AI to get unstuck. The problem is that when you do it so often, you stop being able to get yourself unstuck. I am afraid of a situation where one day, you are in an interview, or an outage, or a code review, and there is no AI.

I would also like to assume that for most people, AI handles the boring parts, and you get to focus on the hard thinking, meaning you ship better work in less time. That is real, and it is great.

But there is another version where you are just getting faster at not learning anything.

What do you think? Is Your AI Assistant Making You a Better Developer, or Just a Faster One?

Luck == Opportunity Meets Preparation

Tawanda Nyahuye — Tue, 16 Jun 2026 12:32:41 +0000

There's a line usually pinned on the Roman philosopher Seneca: luck is what happens when preparation meets opportunity. People put it all over social media and like most things on social media, it gets repeated so often that it stops meaning anything.

So let me try to make it mean something again, with a math equation and a football match that happened recently at the latest FIFA World Cup 2026.

The equation nobody writes down

We talk about luck like it's a single mysterious force, either you have it or you don't. But it's not one thing. It's two things multiplied together:

Luck = Preparation × Opportunities

Look at what that multiplication does. If your preparation is zero, it doesn't matter how many opportunities show up, zero times anything is still zero. And if you're the most prepared person alive but you never put yourself in front of a single opportunity, same result. Zero.

The lucky people aren't the ones who got more luck handed to them. They're the ones who kept both numbers high. They got good and they kept showing up to the table where things happen.

Hold that thought. Let's go to Texas.

Japan, the Netherlands, and the 88th minute

On June 14th, 2026, Japan played the Netherlands in their World Cup group opener in Arlington, Texas. On paper it was a mismatch in the most literal, physical sense.

The Netherlands are tall. Van Dijk, Van de Ven, the whole spine of that team is built like a row of wardrobes. Japan are one of the shorter sides in world football, quick, technical, but not the people you'd bet on to win a header. If you were designing a contest specifically to humiliate the Japanese, you'd make it about jumping.

And for most of the night, the script ran exactly as the bodies predicted. The Dutch dominated the run of play, around 60% possession, more passes, more touches in the box, the better expected goals. Van Dijk, a defender, rose for a cross and headed the Netherlands ahead. Later Summerville restored their lead. The Oranje even won the aerial duels comfortably, around 74% of them. The taller, richer, more fancied team was doing exactly what everyone assumed it would.

Then the 89th minute happened. A ball was worked into the box, Koki Ogawa rose at the back of it, and the move ended with Daichi Kamada finishing past a flailing Dutch keeper. 2-2. A point stolen, against giants, right at the death.

(Credit: FIFA)

Now a fun stat that flips the whole story, and the reason this match is actually perfect for what we're about to talk about. You'd assume the dominant Dutch were the ones bombarding the box with crosses. They weren't. Japan attempted more crosses than the Netherlands, 23 to 21. The team that was second-best on possession, second-best on xG, and losing the aerial battle just kept whipping balls into the box anyway, over and over, especially once the subs came on. Most of those crosses went nowhere. And then, in the 89th minute, one of them finally found a head.

So both halves of the truth are true at once, which is what makes it a great story:

They raised their opportunities by crossing it 23 times, and their preparation cashed the one that landed. A team that kept firing balls in long after it looked hopeless, that had drilled what to do when one finally dropped, that hadn't mentally checked out at 2-1 down, that team converted the half-second the universe finally handed them. The volume created the chance; the preparation finished it.

That's the whole equation in one match. Luck = Preparation × Opportunities. Japan cranked both dials, more attempts and the readiness to punish one, and stole a point from a team that, on every other number, beat them.

"Life is a game of numbers" — the other half

Okay, but sometimes you don't have elite preparation yet. Sometimes you're just starting. What then?

Then you turn the other dial: opportunities. You take more shots.

Japan's 23 crosses are a tiny, 90-minute version of this. Stretch the same idea across years and you get the tech world, a graveyard-slash-trophy-room of people who simply refused to stop attempting:

WD-40 — the spray in half the garages on earth, literally means "Water Displacement, 40th attempt." The first thirty-nine formulas failed. Somebody had the patience to label their failures honestly and keep going.
James Dyson built 5,127 prototypes of his bagless vacuum before one worked. Five thousand one hundred and twenty-seven. Read that again. He was wrong 5,126 times in a row, which by any normal emotional standard is a reason to take up gardening instead.
Angry Birds was Rovio's 52nd game. They spent years nearly going bankrupt making 51 things you have never heard of and never will. Game number 52 is the one your aunt has on her phone.

None of these are "luck" in the lottery sense. They're the equation again, just weighted the other way: when each individual attempt has a low chance of landing, you survive by taking more attempts. You buy more lottery tickets in a lottery where skill stacks the odds in your favour over time.

You miss 100% of the shots you don't take. But here's the part the motivational poster leaves off: you also miss most of the shots you do take. That's fine. The whole point is to take enough of them, while getting good enough at them, that the misses become statistically survivable.

"A moving man will surely meet his luck"

This is the line doing laps around the internet right now, and it's basically our equation crushed down into seven words. A moving man will surely meet his luck. It's everywhere, football captions. It spreads because it's true in a very specific, almost boring way: luck travels along roads, and you have to be on the road to get hit by it.

Luck cannot find you in your room. It does not have your home address. It finds you in the meeting you showed up to, the project you actually shipped, the conference you flew to, the cold message you sent, the game you released even though it was your 52nd one. The moving man isn't lucky because the universe likes him. He's lucky because he keeps wandering into the places where luck is standing around looking for someone to bump into.

My favourite proof is Stewart Butterfield, a man so committed to moving that the universe basically had to pay him twice to make him stop.

He set out to build an online game called Game Neverending. The game flopped. But the little photo-sharing tool his team had built inside it became Flickr, which Yahoo bought.
Did he learn his lesson and sit still? Of course not. He went and built another game, Glitch. That one also flopped. But the internal chat tool his team had cobbled together just to talk to each other became Slack — which Salesforce later bought for around $27.7 billion.

Twice he aimed at a target and missed. Twice the act of moving building, shipping, keeping a team in motion, produced the thing that actually mattered, sitting quietly in the corner of his failure. Same energy with Instagram, which started life as a clunky check-in app called Burbn until the founders noticed the only feature anyone used was the photos.

None of these people knew which attempt would land. That's the entire point, you don't get to know. You just keep moving, so that when luck finally comes down the road, you are, in fact, on the road.

The tech hall of accidental fame

Honestly, once you pull this thread, you realise a frankly embarrassing chunk of Silicon Valley is just people who completely failed at their original plan and tripped face-first into a better one. The "visionary founder who knew exactly what they were building" is mostly a story told afterwards, on a podcast, by someone who got lucky and is too polite to admit it.

A quick tour of the graveyard-slash-billionaire-factory:

YouTube was a dating site. The founders registered the domain on Valentine's Day, slapped on the slogan "Tune In, Hook Up," and literally offered women $20 on Craigslist to upload dating videos. Number of videos uploaded: zero. Romance dead, they shrugged, said fine, upload literally anything, and accidentally built the second-biggest website on Earth. The first-ever video was a guy standing at a zoo talking about elephants. Swoon.
Twitter fell out of a podcasting startup. It was born inside Odeo, right as Apple casually rolled iTunes podcasts over the entire industry like a steamroller over a grape. Staring down certain death, the team ran a hackathon, and the dumb little "post what you're doing right now" side-project ate its own parent company. Odeo died so your uncle could argue with strangers about football at 2am.
PayPal was an app for beaming money between Palm Pilots. Yes, the device. Two people had to point their PDAs at each other like wizards casting a spell to send $5. Shockingly, the world did not want to do this. So they tried "what if email, but it's money," and a fintech giant fell out of the side of the failure.
Nintendo — the Mario people, sold playing cards for ~70 years. Before video games, they also tried running a taxi company and, this is genuinely real, a chain of love hotels. The path from hourly-rate rooms to The Legend of Zelda is not a straight line. Nobody's is.

And my personal favourite, pure cosmic comedy: Brian Acton. In 2009 he applied for a job at Twitter and got rejected. Then he applied at Facebook and got rejected there too. His reaction, posted publicly: got denied by Twitter HQ, that's ok, would've been a long commute. He then went and co-founded WhatsApp, which Facebook bought five years later for $19 billion. The company that wouldn't hire him paid nineteen billion dollars for the thing he built because they wouldn't hire him. The man got rejected directly into a yacht. If that isn't "a moving man meets his luck," nothing is.

The pattern under all the jokes is the exact same boring, beautiful equation. None of them knew which attempt would hit. They just kept building, kept shipping, kept pointing Palm Pilots at each other, until something, almost never the thing they were aiming at, finally connected.

The trap on both sides

Here's where I have to be the annoying friend, because this idea has a failure mode on each end.

Crank only preparation and never ship, and you become the person with the perfect, polished, fully-architected app that has zero users because you never put it in front of a single human. Infinite preparation × zero opportunities = zero. You studied for a test you never showed up to.

Crank only volume and skip the preparation, and you become the person who sends 500 lazy job applications, builds 50 half-finished side projects, and pitches the same unbaked idea to everyone, and concludes the world is just unfair when none of it lands. Infinite attempts × near-zero preparation ≈ still basically zero, just louder.

And one more, the sneakiest: don't mistake a survivor's story for a recipe. For every Dyson who attempted 5,127 times and won, there are people who attempted 5,127 times at the wrong thing and quietly went broke, they just don't get a keynote. The equation isn't "suffer long enough and you're owed a win." It's "you control two inputs, your skill and your number of swings, and you cannot control the roll of the dice in between." Stack the inputs. Respect the dice.

So what do you actually do tomorrow

You can't manufacture luck. But luck is the product of two numbers you fully control, so go raise both:

Get genuinely good at one thing — that's your multiplier. Skill is what converts a half-chance into a goal in the 88th minute. Suffer through the reps now so that when the ball comes in, your head's already in the right place.
Put yourself in front of more chances — ship the project, send the message, enter the competition, publish the article you've been sitting on. Every swing is another roll where your preparation gets to do something.

Do both, long enough, and one day something will land and somebody will call you lucky. Smile and let them. You'll know it wasn't luck that showed up, it was you, prepared, standing exactly where the ball was always going to drop.

The short team can out-jump the giants. But only the one that practised the jump.

Now go take your shot. Preferably your 52nd one.

A Love Letter to Survivorship Bias in Tech

Tawanda Nyahuye — Tue, 16 Jun 2026 09:32:49 +0000

How many times have you seen a picture of a plane with red dots posted on the internet without context?

There's a famous story about a statistician named Abraham Wald and a bunch of WWII bombers. The military looked at the planes coming back from combat, mapped where they were riddled with bullet holes, and decided to add armor there. Wald, being the kind of person who ruins meetings by being right, pointed out the obvious thing nobody wanted to hear:

The planes they were looking at came back. The ones hit in the spots with no bullet holes, the engine, the cockpit, were at the bottom of the English Channel, not available for the survey.

Reinforce the parts that aren't shot up. That's where the dead planes got hit.

I think about this story a lot, mostly while reading those blog posts titled "X Habits That Made Me a 10x Engineer."

The entire industry is a returning-plane survey

Here is the uncomfortable thing about software engineering wisdom: almost all of it is collected from the planes that came back.

Successful companies write blog posts. Successful founders do podcast tours. Successful engineers give conference talks with titles like "Scaling to 100 Million Users with Three People and a Dream." The companies that did the exact same things and died do not have a booth at the conference. They are not on the panel. They are in the channel, with the engines.

And yet we keep doing the survey. We stare at the bullet holes on the survivors and go, "Ah, this is where we add armor."

"Netflix uses microservices, so we should too"

You have eleven users. Three of them are your co-founders, and one is your mom.

Netflix runs a globe-spanning streaming empire on hundreds of microservices because they have hundreds of teams, billions in revenue, and problems you will be lucky to have in a decade. You have a Postgres database that is doing just fine, thank you, and a monolith that boots in four seconds.

So naturally, you spend the next eight months splitting your perfectly functional app into 23 microservices, introducing a message queue you don't understand, adding a service mesh to manage the services you didn't need, and now your local dev environment requires 40GB of RAM and a small prayer.

You did what Netflix does! And you will also do what most companies that copied Netflix did, which is quietly migrate back to a monolith in two years and write a blog post about it called "Why We Moved Back to a Monolith." That post will be very popular. It will be read by people who are about to make the same mistake and will not be dissuaded.

The bullet holes are on the survivors. The armor goes where the holes aren't.

"All our best engineers skipped college"

Survivorship bias loves a hiring anecdote.

"Our best people are self-taught, never finished a CS degree, just shipped." Cool. You are describing the four self-taught people you hired and kept. You are not describing the enormous pool of self-taught applicants you rejected, or the ones who flamed out in month two, or the entire category of people who never applied because the job post wanted "10 years of Kubernetes experience" for a technology that is nine years old.

You hired survivors and then concluded that being a survivor is a great predictor of survival. Groundbreaking.

"They don't build software like they used to"

Ah, yes, the legendary robustness of old software. That COBOL system from 1987 that still keeps that one giant corporation afloat. They really knew how to build things back then.

Friend. That COBOL system is the survivor. It is one plane. The skies of 1987 were thick with garbage software that crashed, got cancelled, lost its company, and was mercifully deleted before you were born. Nobody's writing "we don't make 'em like we used to" think-pieces about PayrollSystem_FINAL_v3_actuallyfinal.exe because it was put out of its misery in 1991.

We remember old software fondly for the same reason we remember the planes that landed: the other ones aren't here to interview.

The advice that is secretly just luck wearing a hoodie

The most dangerous survivorship bias is the confident first-person retrospective. It goes like this:

"I never wrote tests. I never used a debugger. I just shipped fast and trusted my gut. And look where I am now."

Yes. Look where you are. You are one data point who happens to be holding a microphone. For every you, there is a graveyard of developers who also never wrote tests, also shipped on vibes, and are now explaining to a very calm room why prod has been down for six hours. They are not at this conference. They are in a Slack channel called #incident-2024 that will never be archived.

The gut-trusting works great right up until it doesn't, and the "doesn't" is invisible because it doesn't get a keynote.

How to actually not be the dumb general

The fix is the whole point of the Wald story, and it's deceptively simple: go looking for the missing planes.

When someone tells you, "Do X, it's why we won," ask the question nobody at the survey wanted to ask:

How many teams did X and lost?

If the trait shows up just as often in the wreckage as in the winners, it didn't cause the winning. Microservices, rewriting in Rust, a four-hour daily standup, unlimited PTO, "we don't do meetings" — run them all through the same filter. The survivors will tell you their habits caused their success. The dead can't tell you their identical habits caused nothing of the sort.

This is why post-mortems are worth more than success stories. A blameless write-up of how something failed is one of the rare documents written from inside the wreckage. It's a transmission from a plane that didn't come back, which makes it the only useful data on the whole map.

Please add the armor where the holes aren't

So go forth. Read the FAANG engineering blog. Admire the architecture diagram with 200 boxes. Feel the pull to adopt all of it.

Then remember that you are surveying returning planes, close the tab, and go ship the boring monolith that your eleven users will actually be served by.

The bullet holes are a trap. The survivors are a biased sample. And the next time someone says "we should do it like Google," you get to be the insufferable person in the meeting who is, annoyingly, correct.

Wald would be proud. Wald would also tell you to write tests.