DEV Community: Tawanda Nyahuye

Don't Make Me Think: What Actually Separates Good UX from Digital Torture

Tawanda Nyahuye — Thu, 13 Aug 2026 12:26:56 +0000

There's a rule someone dropped in a product design session that has lived rent-free in my head ever since:

"Anything digital shouldn't have more than 7 steps."

Seven. That's it. Seven steps to register, seven steps to checkout, seven steps to do the thing your app was built to do.

You're probably reading that and thinking: easy, we only have six steps. And then you count them. And then you remember the email verification. And the "just one more thing" screen. And the tooltip that said, "watch this quick tutorial first." And the confirmation modal. And suddenly you have fourteen steps.

This is a UX problem. This is the UX problem.

What Even Is UX?

UX stands for User Experience. But let's be real about what it actually means in practice:

Good UX is when you open an app, do the thing, and close it. You didn't think about the app. You thought about the thing you wanted to do. The app was just... there. Invisible. Like a good waiter.

Bad UX is when you open an app, spend four minutes looking for the button, accidentally tap the wrong thing, get sent to a page you didn't ask for, hit back, lose your progress, give up, and go tell two people about how bad the app is.

The goal of UX design is to get from bad to good. Simple to say. Apparently very hard to do, given the state of most apps.

The 7-Step Rule and Why It Exists

Your brain has a working memory. It can hold roughly 7 things at once, give or take two, depending on the research you read and how much coffee you've had.

This is called Miller's Law, named after psychologist George Miller, who noticed this in 1956. Every step in a digital process is a thing your brain has to hold. Every decision you make me take is cognitive load I'm burning. And the moment I run out of mental space, I don't just struggle — I quit.

This is why:

Phone numbers are broken into chunks (+263 77 123 4567, not +2637712345677)
Good forms group related fields together
Navigation menus cap out at 7 items
Checkout processes that take more than 5 minutes lose half their users

The seven-step rule isn't about being lazy. It's about respecting how human beings actually work.

The Principles That Separate Good UX from Digital Suffering

1. The User is Never Wrong

This is the hardest one for builders to accept.

When a user can't find a button, the instinct is to think they're not looking hard enough. When they get confused by a flow, the instinct is to think they need better instructions. When they quit, the instinct is to think they just didn't care.

No.

If your users can't find the button, the button is in the wrong place. If they get confused, the flow is confusing. If they quit, something in the experience broke the deal.

The user is not your QA team. They are not your beta tester. They are someone who showed up with a problem they wanted solved, and your job is to solve it before they close the tab.

Good UX assumes the user will do the unexpected — and designs for it anyway.

2. Friction Is a Tax

Every extra click costs something. Every unnecessary form field costs something. Every "are you sure?" confirmation dialog costs something.

Sometimes that cost is worth it; a confirmation before deleting data is a good friction. But most friction is accidental. It's friction because nobody sat down and asked: "Do we actually need this step?"

Here's a brutal test for any feature you're building: If you removed this step, what would break?

If the answer is "nothing," remove the step.

Amazon built an entire empire on the 1-Click Purchase button. They patented it. It sounds silly, saving one click. But that one click was the moment people paused and thought, "Do I actually want this?" And some percentage of them said no. Remove the pause. Remove the doubt. Watch sales go up. That's friction as a tax, in dollar terms.

3. Show, Don't Tell

If your app needs a tutorial before someone can use it, your app needs a redesign.

The best interfaces are self-explanatory. The icon looks like what it does. The button says what happens when you press it. The flow feels like the next obvious step.

When you have to explain how to use a thing, you're admitting the thing doesn't explain itself. Which is fine; sometimes complexity is unavoidable. But the explanation should be context, not prerequisite.

Good: A tooltip that appears when you hover over a feature you've never used before.

Bad: A 5-minute onboarding video before you can access anything.

WhatsApp didn't make you watch a tutorial before chatting to someone. The flows were obvious enough that you just... did it.

4. Consistency Is a Kindness

Users learn your app. They build a mental model of how things work. And every time you break that model- different buttons in different places, different words for the same action, a back button that sometimes goes back and sometimes doesn't you make them rebuild it from scratch.

This is exhausting. And it's entirely preventable.

Consistency means:

The "Save" button is always in the same place
Red always means danger/delete
The same word is used for the same thing throughout the app
If you swipe left to delete on one screen, swipe left to delete on every screen

This sounds obvious. It is obvious. And yet you open most enterprise software and the top navigation changes between sections, the primary action button moves around, and "Submit" sometimes means "submit for review" and sometimes means "submit and it's gone forever."

5. Feedback Is Mandatory

The user did something. They need to know it worked.

This is so basic that it's embarrassing to have to say it. And yet:

Forms that submit with no confirmation
Buttons that you press and nothing visibly happens so you press again and now you've submitted twice
Loading states that don't load
Errors with no explanation

Every action needs a reaction. A spinner. A success toast. A color change. Something that says "yes, I heard you, I'm doing the thing." Even if the thing takes 10 seconds, the user needs to know those 10 seconds are happening on purpose.

The silence between an action and a response is where anxiety lives. And anxious users become former users.

6. Design for the Distracted

Nobody uses your app with their full attention.

They're using it on a bus. In a meeting they should be paying attention to. With one hand while doing something else with the other. They get a notification halfway through. They put the phone down and come back later.

Good UX survives all of this.

This means:

Progress is saved automatically, not lost the moment they switch apps
They can pick up where they left off
The most important action is the most visible thing on the screen
Nothing irreversible happens without a warning

7. Accessibility Is Not Optional

This one lives at the intersection of ethics and UX.

If your app only works for people with perfect vision, steady hands, and a fast internet connection, you have not designed an app — you have designed a filter. You are telling some percentage of your potential users that they are not welcome here.

Good UX works for:

People using screen readers
People with color blindness (don't use red and green alone to convey meaning)
People with slow connections
People with motor impairments who navigate by keyboard
People on older devices

Beyond the ethics: accessible design is almost always better design. Captions help people in noisy environments. High contrast helps people in sunlight. Keyboard navigation helps power users. When you design for the edge case, the average case gets better too.

What Bad UX Looks Like (A Field Guide)

You've seen these. You've suffered these:

The infinite form — 47 fields, many of which are optional but not labelled as such
The forced account — you want to buy one thing, they want your life story first
The dark pattern — the "no thanks, I don't want to save money" button that makes you feel bad for opting out
The modal on modal on modal — you close one popup, another appears; you are now in popup hell
The app that forgets you — you logged in last week, nothing was saved, start over
The error message written by a robot — "Error 403: Forbidden" instead of "You don't have permission to view this, contact your admin"

What Good UX Actually Feels Like

Good UX is invisible.

You don't talk about it. You don't notice it. You just... do the thing. And then you tell your friend about the thing you did, not the app you used to do it.

The best compliment a UX designer can receive is "I didn't even think about it." It means the product got out of the user's way. It means the seven steps felt like one. It means the friction was so low you couldn't feel it.

That's the job. That's the whole job.

The One Question That Fixes Most UX Problems

If you build products and you want to improve them, there is one question that will do more work than any framework, any design sprint, any consultancy:

"What is the user actually trying to do right now?"

Not what you designed them to do. Not what you think they should do. Not what the product brief says they're doing.

What are they actually trying to do, right now, in this moment?

If you can answer that question honestly, and then put the answer to that question one step away from where they're standing, you've done UX.

Everything else is decoration.

Building APIs: Backend API Concepts And When To Use Them

Tawanda Nyahuye — Mon, 10 Aug 2026 06:07:36 +0000

Every few weeks someone posts the same checklist: as a backend engineer, learn System Design, APIs, Databases, Distributed Systems, Caching, Security, DevOps, Performance, Cloud, Monitoring… and the list is correct but can be confusing without specifying when any of it matters.

Lets take one endpoint, POST /transfers, which moves money from one account to another. I picked the scariest endpoint on purpose: when an order endpoint has a bug you ship a duplicate t-shirt; when a transfer endpoint has a bug you move someone's rent twice. Each thing that breaks teaches one concept, in the order you'd actually hit it.

Code is Spring Boot. Lessons aren't (These are applicable in any backend framework of your choice)

Stage 0: It works on my machine

Here's version one. A controller, a repository, done.

@PostMapping("/transfers")
public Transfer create(@RequestBody Transfer transfer) {
    return transferRepository.save(transfer);
}

It compiles, it demos, you feel powerful. It also contains the first mistake almost everyone ships: it accepts and returns the JPA entity directly.

That's a problem on both ends. On input, the client can set fields you never meant to expose (status, id, settledAt). On output, you're serializing a Hibernate-managed object, which lazily loads associations during JSON serialization, giving you surprise queries or a LazyInitializationException outside the transaction.

Fix it before anything else: the wire format is not your database. Use DTOs (records are perfect).

public record CreateTransferRequest(String fromAccount, String toAccount, BigDecimal amount) {}
public record TransferResponse(Long id, String status, BigDecimal amount) {}

@PostMapping("/transfers")
public ResponseEntity<TransferResponse> create(@RequestBody CreateTransferRequest req) {
    Transfer saved = transferService.create(req);
    return ResponseEntity.status(HttpStatus.CREATED).body(toResponse(saved));
}

Now the API has a contract that's independent of your schema. Everything below builds on that.

Stage 1: The user double-clicks (idempotency)

First real customer hits Send, the network stalls, they tap again. You just moved the money twice. This is the nightmare scenario for a payments API, so it's the first thing you harden.

POST is not idempotent, two identical requests legitimately mean two transfers. The standard fix is an idempotency key: the client sends a unique key, and a retry with the same key returns the original result instead of moving money again.

The naive version is an in-memory Map, and it's wrong, because two concurrent requests with the same key both check the map before either writes, a classic time-of-check/time-of-use race. The real guard is the database (a unique constraint) or Redis SETNX:

@PostMapping("/transfers")
public ResponseEntity<TransferResponse> create(
        @RequestHeader("Idempotency-Key") UUID key,
        @RequestBody CreateTransferRequest req) {
    try {
        Transfer saved = transferService.create(key, req);    // INSERT, key column UNIQUE
        return ResponseEntity.status(HttpStatus.CREATED).body(toResponse(saved));
    } catch (DataIntegrityViolationException dup) {           // someone got there first
        Transfer existing = transferService.findByKey(key);
        return ResponseEntity.ok(toResponse(existing));
    }
}

Let the database be the referee. Concurrency is exactly where hand-rolled idempotency falls apart, and with money, "falls apart" means a customer's account is wrong.

Stage 2: The garbage payload (validation + honest errors)

Now requests arrive with amount: -500 (a transfer that pulls money the wrong way) and a missing toAccount. If you don't stop them, that nonsense flows straight into your ledger.

Validate at the edge with Bean Validation, and, this is the part people skip, say what went wrong with the right status code.

public record CreateTransferRequest(
    @NotBlank String fromAccount,
    @NotBlank String toAccount,
    @Positive BigDecimal amount) {}

@PostMapping("/transfers")
public ResponseEntity<TransferResponse> create(@RequestBody @Valid CreateTransferRequest req) { ... }

The status code is the error contract, it tells the client what to do next, before they read a single word of your message:

400 — malformed/missing field. The request is broken.
422 — well-formed but semantically invalid (amount: -500).
409 — conflict (insufficient funds, stale balance, next stage).
401 vs 403 — not authenticated vs authenticated-but-not-allowed. Different problems, different fixes.

Spring 6 gives you RFC 9457 ProblemDetail for free, so every error has the same machine-readable shape:

@RestControllerAdvice
class ApiErrors {
    @ExceptionHandler(MethodArgumentNotValidException.class)
    ProblemDetail onValidation(MethodArgumentNotValidException ex) {
        ProblemDetail pd = ProblemDetail.forStatusAndDetail(
            HttpStatus.UNPROCESSABLE_ENTITY, "Validation failed");
        pd.setProperty("errors", ex.getFieldErrors().stream()
            .collect(toMap(FieldError::getField, FieldError::getDefaultMessage)));
        return pd;
    }
}

A 500 for a bad input is a lie. Don't lie to your clients.

Stage 3: Two debits race on the same account (optimistic locking)

A customer fires two transfers from the same account at the same instant. Both read balance = 100, both subtract 80, both save, last write wins, and now 160 has left an account that only had 100. That's a lost update, and in a payments system it's an overdraft you created yourself.

You don't need to lock rows. Add a version column and let Hibernate detect the stale write:

@Entity
class Account {
    @Id String id;
    BigDecimal balance;
    @Version Long version;     // Hibernate checks this on UPDATE
}

If a transaction tries to update a row whose version has already moved, Hibernate throws OptimisticLockException, which you map to 409 Conflict, telling the client "your view of the balance was stale, refetch and retry." This pairs with knowing your transaction boundaries: keep @Transactional tight, mark pure reads readOnly = true, and never wrap a slow external bank call inside a DB transaction, you'll hold a connection (and a row lock) hostage while the network dawdles.

Stage 4: "Give me all the transfers" (pagination + N+1 + caching)

GET /accounts/{id}/transfers works great with 50 rows and falls over at 5 million. Three separate things bite here, usually at once.

Pagination — never return an unbounded list. Offset paging (Pageable) is built in and fine for admin screens, but the DB still scans and discards every skipped row, so deep pages crawl and new transactions arriving mid-scroll cause dupes. For a transaction history, append-heavy and user-facing — use keyset/cursor paging on an indexed column:

// SELECT * FROM transfers WHERE account_id = :acct AND id < :after ORDER BY id DESC LIMIT :size
@Query("""
    SELECT t FROM Transfer t
    WHERE t.account.id = :acct AND (:after IS NULL OR t.id < :after)
    ORDER BY t.id DESC""")
List<Transfer> page(@Param("acct") String acct, @Param("after") Long after, Pageable pageable);

N+1 — listing transfers and touching transfer.getCounterparty() in a loop fires one query per transfer. The fix is a fetch join or entity graph:

@EntityGraph(attributePaths = "counterparty")
List<Transfer> findByAccountId(String acct);     // one query, not 1 + N

For deeper graphs set hibernate.default_batch_fetch_size so lazy loads batch into a few IN (...) queries instead of hundreds. Watch your SQL logs, N+1 is invisible until the data grows.

Caching — for hot, rarely-changing reads (an already-settled transfer never changes), add HTTP ETag + Cache-Control so unchanged data returns a bodiless 304, and @Cacheable (Redis/Caffeine) so the read never touches the DB:

return ResponseEntity.ok()
    .eTag(Long.toString(transfer.getVersion()))
    .cacheControl(CacheControl.maxAge(60, SECONDS))
    .body(toResponse(transfer));

Stage 5: A stranger finds the endpoint (auth + rate limiting)

You're public now. Two new questions on every request: who are you, and how often are you allowed to ask.

Authentication vs authorization are different jobs. A JWT answers the first, but a JWT is signed, not encrypted, so it proves the token wasn't tampered with while the payload stays readable. Never put secrets in it, always set a short expiry, and authorize separately with scopes/roles. Spring Security as a resource server makes validation declarative:

http.authorizeHttpRequests(a -> a
        .requestMatchers(POST, "/transfers").hasAuthority("SCOPE_transfers:write")
        .anyRequest().authenticated())
    .oauth2ResourceServer(o -> o.jwt(withDefaults()));

A valid token is not a free pass. The single most important check in this whole API: the fromAccount actually belongs to the authenticated user. Skip that ownership check and anyone with a token can drain anyone else's account, this is the #1 class of real-world API breach (broken object-level authorization).

Rate limiting stops one client, malicious or just stuck in a retry loop, from drowning everyone else. Token bucket via Bucket4j, one bucket per API key, returning 429 with a Retry-After so well-behaved clients back off.

Stage 6: The bank rail stops answering (timeouts + circuit breakers)

Your endpoint calls a downstream payment rail to actually settle the money. One day it doesn't respond. With no timeout, your threads pile up waiting, and your healthy service goes down because of someone else's outage. This is the failure the listicles never mention and the one that actually pages you.

Two non-negotiables for every outbound call: a timeout, and a circuit breaker that stops hammering a service that's clearly down (Resilience4j):

@CircuitBreaker(name = "bankRail", fallbackMethod = "queueForLater")
@TimeLimiter(name = "bankRail")
public CompletableFuture<Receipt> settle(Transfer t) { ... }

private CompletableFuture<Receipt> queueForLater(Transfer t, Throwable ex) {
    // degrade gracefully: park it as PENDING and retry, don't take the whole API down
}

Decide now what happens when a dependency dies, not during the incident.

Stage 7: The work is too slow to do inline (queues + async)

Settling a transfer now means: call the bank rail, run a fraud check, write the ledger entry, notify both the sender and the recipient, update analytics. Do all of that inside the request and your endpoint is only as fast as its slowest dependency, and it fails entirely if any one of them hiccups.

The fix is to do the essential part synchronously (record the transfer as PENDING) and offload the rest to a message queue — RabbitMQ, Kafka, SQS, so the API returns immediately and workers handle the slow work on their own time.

@PostMapping("/transfers")
public ResponseEntity<TransferResponse> create(@RequestBody @Valid CreateTransferRequest req) {
    Transfer saved = transferService.create(req);          // record intent, fast
    queue.publish(new TransferInitiated(saved.getId()));   // settle + notify async
    return ResponseEntity.accepted().body(toResponse(saved));   // 202, not 201
}

Three things you must get right the moment a broker enters the picture:

Idempotent consumers. Queues deliver at least once, so the same message will eventually arrive twice. The worker that calls the bank rail has to dedupe (Stage 1's logic, now on the consumer side) — otherwise you settle the same transfer twice and move the money twice, asynchronously, where it's far harder to notice. Dead-letter queues + retries. A message that keeps failing must not loop forever or silently vanish, that's a customer's money stuck in limbo. Retry with backoff, then park it in a DLQ for a human. Spring's @RabbitListener / @KafkaListener have retry and DLQ wiring built in. Backpressure. A queue is a shock absorber: the API keeps accepting transfers at 202 speed during a spike while workers drain the backlog at a sustainable rate. Decoupling accepting work from doing work is the entire point.

This also reshapes the contract. Settlement shouldn't hold a request open, so the pattern becomes 202 Accepted + a status endpoint: return an id now with status PENDING, let the client poll GET /transfers/{id}, or fire a webhook when it settles. If you send webhooks, sign them (HMAC) so the receiver can trust the payload, and retry them, because the receiver's endpoint is exactly as flaky as the bank rail was in Stage 6.

Stage 8: You need to change the response (versioning + consistency)

The transfer shape has to change, and there are clients in the wild you can't redeploy. The rule that saves you: additive changes are free; breaking changes get a new version (/v1/transfers → /v2/transfers, or a media-type header). Adding a field is fine. Renaming or removing one is a v2.

By now you've split work across services and async listeners, which means not every read is instantly up to date, and that's where you have to think hard, because this is money. The discipline is to be deliberate about what gets which guarantee:

Strong consistency for the money itself. The debit, the balance check, the "do we have the funds" decision — these are read-your-writes, inside a transaction, no exceptions. You cannot let a balance be eventually consistent in a way that permits an overdraft.
Eventual consistency for everything derived from the money: the notification, the analytics rollup, the search index, the "transactions this month" widget. These can lag a few seconds and nobody gets hurt.

@TransactionalEventListener     // runs only after the transfer tx commits
public void onSettled(TransferSettled e) { ledger.projectAsync(e); }

Just make those consumers idempotent (Stage 7 again) — at-least-once delivery means the same event will eventually arrive twice.

Stage 9: You can't see what it's doing (observability + docs)

The endpoint is live, fast, and secure, and one morning it's misbehaving and you have no idea why, because you can't see it. An API that moves money and that you can't observe is not an API, it's a liability.

The minimum kit:

Correlation IDs in the logs (a filter that puts a request ID into the MDC) so you can trace one transfer across the API, the queue, and the bank rail instead of grepping blind.
Metrics via Micrometer + Actuator, scraped by Prometheus, drawn in Grafana, latency percentiles (p99, not averages, averages hide the pain), error rates, throughput, and business signals like settlement failure rate.
Health checks — liveness/readiness probes via Actuator (/actuator/health), so your orchestrator knows when to route traffic to a fresh instance and when to restart a sick one.
Docs via springdoc-openapi, so the contract is discoverable and your future self isn't reverse-engineering past you:

@Operation(summary = "Initiate a transfer")
@ApiResponse(responseCode = "202", description = "Transfer accepted and pending settlement")
@PostMapping("/transfers")
public ResponseEntity<TransferResponse> create(@RequestBody @Valid CreateTransferRequest req) { ... }

The endpoint, grown up

Same POST /transfers we started with. Now it returns a DTO, dedupes retries through the database, validates input and answers with honest status codes, refuses to overdraft under concurrent debits, pages and caches its reads, checks not just who is calling but whose account they're touching, degrades gracefully when the bank rail dies, offloads settlement to a queue and answers 202, versions its contract, keeps the money strongly consistent while letting the dashboards lag, and tells you exactly what it's doing.

None of that showed up in the demo. All of it shows up in production, and with money, all of it shows up as a customer complaint if you skip it.

You don't need to learn the whole backend-checklist wall of nouns in one sitting. You need to ship one honest endpoint, then keep asking the next question: what breaks when a thousand strangers hit this at once? The concepts arrive in order, every time. Meet them on a quiet afternoon, not at 2am.

5 Career Lessons I Didn't Expect to Learn in Church

Tawanda Nyahuye — Mon, 03 Aug 2026 09:30:10 +0000

You wouldn't believe what they were preaching about in church this week.

Normally, these days you walk in expecting to be bombarded with Bible verses and the classic "tell your neighbour to tell their neighbour" routine. But guess what, my preacherman was on point. The whole sermon was about how to realise your full potential and grow your career.

And here's the interesting part: it wasn't aimed at the start-your-own-empire crowd. It was for the intrapreneurs, the people who'd rather climb high inside someone else's company than run their own thing. If that's you, this one's for you.

So let me try to break it down in my own words, with a few of the insights I picked up from the preacherman (and a couple of my own).

Let's begin. What is it that we actually need to do to discover ourselves and reach our full career potential?

1. Start Early

There's a popular idea that life comes in four quarters:

0–25 — the learning phase
25–50 — the earning phase
50–75 — the serving / enjoying phase
75+ — the reflecting phase

(You'll see different versions of this floating around, with different age bands; it's a framing, not a law of physics, so take the exact numbers loosely.)

The first quarter is where the magic is supposed to happen. This is your discovery phase. You're meant to learn as much as you can, try different things, fail, get back up, and try again. This is where you find out who you actually are.

If you spend this quarter as a couch potato, there's a good chance you end up miserable and stuck in the wrong career. Your environment matters too. Get born in India, you'll probably force yourself onto a cricket pitch, even if your real gift was on a tennis court; therefore, you have to force yourself into trying quite a number of things.

For the parents reading this: give your kids as much exposure as you possibly can. Let them join different clubs. Let them be around different kinds of people. Someone out there might spot a talent you never even knew your child had. A lot of parents push their kids toward being doctors because it sounds cool, but you have to let a child find their own thing.

Ben White plays for Arsenal today, but he comes from a family with zero interest in football; his dad reportedly can't stand the game. He was basically discovered by accident. One of the people his mum used to cut hair for would come out into the garden, jump in goal, and let a young Ben boot the ball at her. That's it. That's the origin story of a Premier League defender.

Then there's Harry Kane. He started playing at six years old. As a five-year-old, he wrote in a school project, "I want to play football." But here's the part people forget: Arsenal signed him young and then released him at eight for being too small and too slow. He didn't quit. He got back up, kept playing, and became one of the best strikers in the world. Start early, and when you fail early, get up early too.

The other three quarters matter as well: the earning quarter is where all that early discovery gets cashed in, the serving quarter is where you give back (Become a mentor if you can) and enjoy the fruits, and the reflecting quarter is where you look back on the whole game. But everything downstream depends on how seriously you take the first one.

Once you have realised what you would like to do, go for it to gain experience.

2. Give It Your All

My father has always told me: "Whatever you do, Tawanda, do it wholeheartedly, whether you're being paid enough or not paid at all."

I hold onto another belief too: even when people don't reward me properly, the Lord sees, and I'll be rewarded eventually. Colossians 3:23–24 backs this up. Giving your all is simply how you squeeze the maximum out of your talent. When you do what you're good at with your whole heart, you don't just get good, you get exceptional.

Young people often lose sight of this. They start a job and immediately get carried away complaining. My preacherman put it perfectly: when you apply for a job, the pay looks like plenty, but the day you actually start, somehow it's never enough. That mindset will hold you back.

Working hard has a hidden benefit: it builds you allies. People will quietly defend you, even on the days you slip up.

I learned this during my internship. I was saying yes to every single task thrown my way. Then one day something I was handling blew up into a complaint after I got overwhelmed. In the meeting that followed, every senior in the room lined up to blame me. But the CEO — a wise man — cut them off. He looked around and said the young man you are all blaming seems to be doing the very work you are supposed to be doing, carrying the load for you.

That stuck with me. When you're genuinely good at what you do, you'll be surprised how much people are willing to overlook. I've watched top employees get retained after messing up badly, purely because they were that good. I'm not saying being good is a licence to be reckless, but excellence buys you grace.

And remember: when you give it your all, you're not doing your employer a favour. You're helping yourself.

3. Get Certifications

Hard work isn't enough. Being an expert isn't enough. You need something to show for it.

HR does not care about your talk. HR wants to see the qualifications. So certify, certify, certify.

Every field has an accreditation body of some kind. Get accredited for your skills, and I mean every skill you've got. One day it will be asked for, and you'll be glad you have it. Be patient with certifications, too. Some of them sit uselessly in a drawer for ten years until, out of nowhere, the exact one you thought you'd never need becomes the thing that gets you the role.

Think of it like keeping receipts. Nobody looks at a receipt for years, until the one day you desperately need to prove you paid.

4. Network Strategically

Hang around the right people.

Networking sometimes comes at a cost. It might mean moving out of the neighbourhood you're comfortable in and paying double the rent to be somewhere new. Treat that as an investment, not an expense. It might mean buying lunch for influential people, and honestly, you should. You're the one who wants to be in their circle, after all.

And when you network, be consistent. You can't play golf with someone once, dust off your hands, and say "I tried." You do it over and over again until you start speaking their language.

Let's not get distracted, though: we're networking with people in the right field, the field you're in or the one you're trying to break into. Don't be the "I can do it myself" guy. That guy never wins. Nobody lives in isolation. You don't really have to be a bootlicker.

I'd like to believe God himself sends helpers through people. Sure, manna sometimes falls from heaven, but you're not Moses, and you're not in a desert. Go build the relationships.

5. Learn the Business of Your Career

Here's the twist.

Remember, this whole thing started as advice for the "I'd rather work for someone than start my own thing" crowd. But once you become a genuine expert in your area and you learn the business around it, you realise something uncomfortable: to reach the very top of your field, the millionaire or billionaire tier, you eventually have to become the boss anyway.

Look closely at any field, and you'll find the business person standing right next to the talent:

Artists have managers and record labels.
Athletes have agents.
Builders have contractors.
Doctors have private surgeries.

Whatever your career path, there is always a business side of things. That's usually where the real money lives.

But here's the catch, and it ties everything together: to even recognise the business side of your field, you first have to become an expert in it. Which brings us right back to lesson one: start early, give it your all, get certified, network hard. Do the work, and the business will reveal itself.

That's what I took from church this week. Not a single "tell your neighbour" in sight, just a genuinely good roadmap for realising your potential.

Now the real question: which quarter of the game are you in?

What You Can Do With C#

Tawanda Nyahuye — Sun, 26 Jul 2026 09:05:31 +0000

Let's get the joke out of the way, because you're going to hear it within four minutes of telling anyone you're learning C#:

"Oh, C#? Isn't that just Microsoft Java?"

Yes. Kind of. A little. Here's the actual story. Back around 2000, Microsoft wanted a modern, garbage-collected, object-oriented language for their shiny new .NET platform. Java existed and was extremely popular. Microsoft had previously shipped their own version of Java, Sun sued them into the sea, and the whole thing ended in tears and lawyers. So Microsoft did the very sensible, very corporate thing: they hired Anders Hejlsberg, the man who built Turbo Pascal and Delphi, and said: "make us a Java, but ours, and don't get us sued."

He did. And then he kept improving it for twenty-five years while Java spent a decade arguing about whether it should add lambdas. So calling C# "Microsoft Java" today is like calling a smartphone "a Microsoft telegraph." Technically, you can trace the lineage. It is also extremely funny to the person being insulted, which is the only thing that matters.

So, what can you actually do with this thing? More than you'd think. Let's take the tour.

First, the obligatory Hello World

Every language tour is legally required to start here. C#'s has changed a lot, which tells you something about the language's whole vibe.

The old way, circa 2005, was a ceremony:

using System;

namespace MyFirstApp
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello, world!");
        }
    }
}

Eleven lines to say hello. You needed a namespace, a class, a Main method with a specific signature, and the kind of static void incantation that makes beginners quietly close the tab and go learn Python instead.

The modern way (C# 9 and later) is this:

Console.WriteLine("Hello, world!");

That's the whole program. The compiler quietly puts all the ceremony back for you behind the scenes. This is C# in a nutshell: it grew up in a buttoned-up enterprise suit, and over twenty years it has slowly been allowed to loosen its tie.

Thing one: it builds the boring software that runs the world

Here is the unglamorous truth. The single biggest thing C# does is business software — the web APIs, the internal tools, the systems that process your insurance claim and your payroll and your tax return. This is done with ASP.NET Core, and it is genuinely excellent at it.

A whole working web API in modern C# looks like this:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/users/{id}", (int id) => new { Id = id, Name = "Mom" });

app.Run();

Run that and you have a real web server answering real HTTP requests. (And yes — /users/{id} with a sequential integer is the German Tank Problem waiting to happen, but that's a different article, and you've already read it.)

"Boring" is doing a lot of heavy lifting here as a compliment. Boring means it pays the bills. Boring means there are jobs. Nobody puts "enterprise C# developer" on a hoodie, but they do put it on a mortgage application, and the bank, also running C#, approves it.

Thing two: it secretly makes most of your video games

This is the fun one, and it's the reason a lot of people learn C# without even meaning to.

Unity, the engine behind a frankly absurd chunk of the games you've played, especially indie hits and basically everything on mobile, is scripted in C#. Hollow Knight, Cuphead, Among Us, Pokémon GO, and Cities: Skylines. All C#.

When you write game logic in Unity, you're writing things like:

void Update()
{
    if (Input.GetKeyDown(KeyCode.Space))
    {
        rigidbody.AddForce(Vector3.up * jumpHeight);
    }
}

That's "every frame, if the player hits space, launch them upward." That's a jump. You just made a character jump. Congratulations, you are now technically a game developer and contractually obligated to start and never finish three different projects.

There's a beautiful bait-and-switch here: thousands of people who would never sit down to "learn enterprise programming" learned C# because they wanted to make a little platformer where a cube collects coins. The language that runs the world's payroll also runs the world's coin-collecting cubes. Range.

Thing three: desktop apps, phone apps, and everything with a window

C# can build apps with actual graphical interfaces, the windows, buttons, and menus kind:

WinForms / WPF — classic Windows desktop apps. Old, reliable, the COBOL-survivor energy of the GUI world.
.NET MAUI — one codebase that builds apps for Windows, macOS, iOS and Android. Write once, deploy to the phone, the tablet, and the laptop, in theory, when the build gods are merciful.

So the same language does the back-end API and the app talking to it. There's a real, underrated joy in not having to context-switch your entire brain between the front and the back of your own project.

The actual reason C# is nice to learn: it has good taste now

Beyond the "what can it build" list, here's what makes C# pleasant to write in 2026. A few greatest hits.

LINQ lets you query collections like they're a database, in plain, readable lines:

var bigSpenders = customers
    .Where(c => c.TotalSpent > 1000)
    .OrderByDescending(c => c.TotalSpent)
    .Select(c => c.Name);

Read that out loud. "Where the total spent is over 1000, ordered by spent descending, select the name." It reads like English, describing what you want, not a for loop describing how to suffer through getting it. Once LINQ clicks, going back to manual loops feels like being handed a typewriter.

async/await makes "do slow things without freezing everything" almost embarrassingly simple:

async Task<string> GetDataAsync()
{
    var response = await httpClient.GetStringAsync("https://api.example.com");
    return response;
}

The await keyword means "go do this slow network thing, and let the rest of the program keep breathing while we wait." Whole books exist on how hard this used to be. Now it's one word.

Strong typing that doesn't nag you to death. C# knows the types, so your editor autocompletes everything, catches your typos before you run, and tells you you're an idiot at compile time instead of letting you find out from a furious user at 2 am. But thanks to var, you rarely have to type the types out yourself. You get the safety without the paperwork.

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

Because no language is free, and I refuse to write the post that pretends C# is.

It carries some Microsoft baggage. It's enormously more cross-platform than it used to be. .NET runs beautifully on Linux and macOS now; this is no longer 2010, but the cultural centre of gravity is still Windows and Visual Studio, and some tutorials still assume you have a Windows machine and the patience of a saint.

The ecosystem has a lot of old. Search a problem, and you'll get four answers: the 2009 way, the 2014 way, the 2019 way, and the actually-current way, and they will not be labelled. You'll waste an afternoon implementing a pattern that was quietly replaced by one line of syntax three versions ago. (See: the eleven-line Hello World you'd still find in some "beginner" posts today.)

It is a big language. Twenty-five years of "ooh let's add that feature" means there are usually five ways to do anything, and a beginner can drown trying to figure out which one is current. The flip side of a language that never stopped improving is a language with a lot of sediment.

None of these are reasons not to learn it. There are reasons to learn the 2026 version of it, and to be suspicious of any tutorial that opens with a namespace and a sad static void Main.

So what do you actually do tomorrow

You can't learn a whole language in a weekend, but you fully control where you start, so start somewhere real:

Install the .NET SDK (free, cross-platform) and run dotnet new console, then dotnet run. You'll have a running C# program in about ninety seconds, on whatever OS you own.
Pick the lane that excites you, not the "correct" one. Want to build a web thing? ASP.NET Core minimal APIs. Want to make a game? Install Unity and make the cube jump. Motivation beats virtue every time — the person building a silly game finishes more C# than the person dutifully grinding "fundamentals."
Learn LINQ and async/await early. They're the two features that make the language feel modern instead of like Java's stricter cousin, and they're where the "oh, that's why people like this" moment lives.

C# is the language that runs the bank and makes the cube jump. It spent two decades being the responsible one and then quietly got fun when nobody was looking.

Now go make the cube jump, preferably before you make the bank.

And the next time someone calls it "just Microsoft Java", you get to be the insufferable person in the room who explains, at length, exactly why that's both true and completely irrelevant. Anders would be proud.

Automate Spotify and YouTube Playlists - Chapter 6: Deployment

Tawanda Nyahuye — Sat, 25 Jul 2026 08:26:33 +0000

The script works on your computer. But your computer isn't always on, and "remember to run this manually every day" defeats the whole point.

In this chapter, we push the code to GitHub and set up a GitHub Action — a free, scheduled job that runs the script every day automatically, on GitHub's servers, whether your laptop is open or not.

What Is GitHub Actions?

GitHub Actions is GitHub's built-in automation system. You write a small configuration file that says "run this on a schedule," and GitHub takes care of the rest. It spins up a fresh computer, runs your script, and shuts down again. You pay nothing. It just works.

The configuration file is called a workflow and it lives in your repo at .github/workflows/sync.yml. We'll create it in this chapter.

Step 1: Push Your Code to GitHub

GitHub is where we store the code, so GitHub Actions can find and run it. Think of this step as uploading your project folder to the internet — but in a controlled, version-tracked way.

Install Git

Git is the tool that uploads your code to GitHub. Check if you already have it:

git --version

If you see a version number, skip ahead. If not, download it from git-scm.com and install it with all the defaults.

Create the repo on GitHub

Go to github.com and log in. Click the + icon in the top right corner and select New repository.

Fill it in like this:

Repository name: youtube-to-spotify
Description: "Syncs a YouTube playlist to Spotify automatically."
Visibility: Public (so others can follow along from the article) or Private (if you'd rather keep it to yourself — both work fine with GitHub Actions)

Leave everything else as is and click Create repository.

GitHub will show you an empty repo page with some setup instructions. Leave that tab open — we'll need a URL from it in a moment.

Connect your local folder to GitHub

Back in your terminal, make sure you're inside your youtube-to-spotify project folder. Then run these commands one by one:

git init

This turns your folder into a Git repository — it starts tracking changes.

git remote add origin https://github.com/YOUR_GITHUB_USERNAME/youtube-to-spotify.git

Replace YOUR_GITHUB_USERNAME with your actual GitHub username. This tells Git where on the internet to send your code. The URL is also shown on that repo page GitHub gave you.

git add spotify.py youtube.py script.py requirements.txt

This stages the four files — tells Git "these are the ones I want to upload." Notice .env is not in this list. We never add that one.

git commit -m "Initial commit"

A commit is a saved snapshot of your code with a message describing what changed. This is your first one.

git push -u origin main

This sends everything to GitHub. If it asks for your GitHub username and password, use your username and a Personal Access Token as the password — GitHub stopped accepting regular passwords for this. You can generate one at github.com/settings/tokens — click Generate new token (classic), give it a name, check the repo scope, and copy the token it shows you.

Once the push completes, refresh your GitHub repo page. Your four files should be there.

Your repo should now contain these files:

youtube-to-spotify/
├── .github/
│   └── workflows/
│       └── sync.yml        ← we'll create this
├── spotify.py
├── youtube.py
├── script.py
├── requirements.txt
└── .gitignore              ← we'll create this too

Notice that .env is NOT in that list. It must never go to GitHub. We handle that next.

Step 2: Create a .gitignore File

A .gitignore file tells Git which files to ignore — to never upload, no matter what. Create a file called .gitignore in your project root with this content:

.env
venv/
__pycache__/
*.pyc

This ensures your .env file — with all your private credentials — stays on your computer only. Your secrets never leave your machine.

Now commit and push it:

git add .gitignore
git commit -m "Add gitignore"
git push

Step 3: Add Your Secrets to GitHub

Your script needs six credentials to run. Since the .env file isn't on GitHub, we store those values in GitHub Secrets — an encrypted store that GitHub Actions can read at runtime, but that nobody can see, not even you, after saving them.

Go to your repo on GitHub: github.com/Towernter/youtube-to-spotify

Click Settings → Secrets and variables → Actions → New repository secret.

Add each of these one by one:

Secret name	Value
`CLIENT_ID`	Your Spotify Client ID
`CLIENT_SECRET`	Your Spotify Client Secret
`REFRESH_TOKEN`	Your Spotify Refresh Token
`SPOTIFY_PLAYLIST_ID`	Your Spotify playlist ID
`API_KEY`	Your YouTube API key
`YOUTUBE_PLAYLIST_ID`	`PLGBuKfnErZlAkaUUy57-mR97f8SBgMNHh`

The name must match exactly — capital letters, underscores. That's how the workflow file will reference them.

Step 4: Create the Workflow File

Inside your project, create the folder structure .github/workflows/ and inside it create a file called sync.yml.

Here is the complete workflow file:

name: Sync YouTube Playlist to Spotify

on:
  schedule:
    - cron: '0 0 * * *'   # runs every day at midnight UTC
  workflow_dispatch:        # also lets you trigger it manually from GitHub

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - name: Check out the code
        uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: pip install -r requirements.txt

      - name: Run the sync script
        env:
          CLIENT_ID: ${{ secrets.CLIENT_ID }}
          CLIENT_SECRET: ${{ secrets.CLIENT_SECRET }}
          REFRESH_TOKEN: ${{ secrets.REFRESH_TOKEN }}
          SPOTIFY_PLAYLIST_ID: ${{ secrets.SPOTIFY_PLAYLIST_ID }}
          API_KEY: ${{ secrets.API_KEY }}
          YOUTUBE_PLAYLIST_ID: ${{ secrets.YOUTUBE_PLAYLIST_ID }}
        run: python script.py

Let's walk through what this does:

on: schedule — the cron expression 0 0 * * * means "at minute 0 of hour 0, every day." That's midnight UTC. You can adjust this to any time you like using crontab.guru — a free tool that translates cron expressions into plain English.

workflow_dispatch — this adds a "Run workflow" button on GitHub so you can trigger it manually anytime without waiting for the schedule. Very useful for testing.

runs-on: ubuntu-latest — GitHub spins up a fresh Ubuntu Linux machine for each run. It installs Python, installs your dependencies, runs the script, and disappears. Clean every time.

env block — this is where the secrets get injected. ${{ secrets.CLIENT_ID }} pulls the value you stored in GitHub Secrets and makes it available to the script as an environment variable, exactly the same way your .env file did on your local machine.

Now create the .github/workflows/ folder structure inside your project and save the file as sync.yml inside it. Then commit and push:

git add .github/workflows/sync.yml
git commit -m "Add GitHub Actions workflow"
git push

GitHub will detect the workflow file automatically as soon as it's pushed.

Step 5: Trigger Your First Manual Run

Don't wait until midnight to see if it works. Let's test it now.

Go to your repo on GitHub and click the Actions tab. You'll see your workflow listed — "Sync YouTube Playlist to Spotify." Click on it, then click the Run workflow button on the right, then click the green Run workflow button in the dropdown.

GitHub queues the job. After a few seconds, a new run appears in the list with a yellow spinning circle. Click on it to watch it run live.

You'll see each step execute in order:

✅ Check out the code
✅ Set up Python
✅ Install dependencies
✅ Run the sync script

Click on "Run the sync script" to expand it and see the actual output — the same output you saw when running locally in Chapter 5. If all four steps show green checkmarks, it worked.

Open Spotify. Your playlist is updated.

If the Workflow Fails

Red X on "Run the sync script"
Click the step to see the error output. The most common causes are a wrong secret name (check capitalisation) or a missing secret. Cross-reference the secret names in the workflow file against what you added in Step 3.

Red X on "Install dependencies"
Your requirements.txt might be missing or have a typo in a package name. Make sure it was committed and pushed to the repo.

The workflow doesn't appear in the Actions tab
The sync.yml file might be in the wrong location. It must be at exactly .github/workflows/sync.yml — two nested folders from the root of your repo.

The workflow runs but no songs are added
The script ran successfully but found nothing new to add — probably because you already ran it locally in Chapter 5 and the playlist is already up to date. That's not a failure, that's the script doing its job correctly.

What Happens Every Day From Here

At midnight UTC, GitHub wakes up, checks out your code, installs the dependencies, and runs script.py. The script fetches the YouTube playlist, finds any new songs on Spotify, adds them, removes ones that were taken off YouTube, reorders everything, and shuts down.

You do nothing. You just open Spotify and listen.

If the YouTube playlist owner adds a new song, it'll be in your Spotify playlist the next morning. If they remove one, it's gone from Spotify too. The two playlists stay in sync permanently.

The Complete Picture

Here's what you built across this series:

A Spotify developer app with the right permissions
A YouTube API key tied to your Google project
Three Python files that talk to both APIs and sync them intelligently
A .env file for local development and GitHub Secrets for production
A GitHub Actions workflow that runs the whole thing daily on a schedule

That is a real, deployed, automated software project. It has credentials management, API integration, error handling, scheduled execution, and version control. Those are not beginner concepts. You just learned them by building something you'll actually use.

Where to Go From Here

The repo at github.com/Towernter/youtube-to-spotify also contains script_advanced.py — the full version of the script with extra features: auto-updating the playlist description with artist names and genres, filling gaps with tracks from a specific artist, and managing multiple playlists at once. Once you're comfortable with the basics, that's worth exploring.

If you want to sync a different YouTube playlist, just update YOUTUBE_PLAYLIST_ID in your GitHub Secrets and the workflow will pick it up on the next run.

And if you found this series useful, share it. Someone else is out there with a YouTube playlist they wish was on Spotify.

🎵 Final Product

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

🎧 View the completed Spotify Playlist

Thanks for following along. Drop any questions in the comments — I read them all.

Automate Spotify and YouTube Playlists - Chapter 5: Running It Locally

Tawanda Nyahuye — Fri, 24 Jul 2026 04:29:55 +0000

This is the chapter where things get real. We're going to set up Python, create the project folder, put all the pieces together, and run the script for the first time. By the end, you'll have a working Spotify playlist populated with 70s hits.

Let's go step by step.

Step 1: Install Python

Python is the programming language the script is written in. If you already have it installed, skip to Step 2.

On Windows

Go to python.org/downloads and click the big yellow Download Python button. Run the installer.

One thing — and this is important — on the first screen of the installer, before you click anything else, check the box that says "Add Python to PATH". It's at the bottom and it's easy to miss. If you skip this, Python won't work from the command line and you'll spend an hour wondering why.

After that, just click through the defaults and let it install.

On Mac

Mac often comes with Python pre-installed, but it's usually an old version. The cleanest way is to go to python.org/downloads, download the Mac installer, and run it. Follow the defaults.

On Linux

You almost certainly already have Python. Open a terminal and type:

python3 --version

If you see a version number, you're good. If not:

sudo apt install python3

Verify the installation

Open a terminal (on Windows, search for "Command Prompt" or "PowerShell"). Type:

python --version

You should see something like Python 3.12.4. Any version of Python 3 works. If you see Python 2.x.x, try python3 --version instead and use python3 everywhere in this chapter.

Step 2: Set Up the Project Folder

Create a folder somewhere on your computer. Call it youtube-to-spotify. Inside it, you need four files:

youtube-to-spotify/
├── spotify.py
├── youtube.py
├── script.py
└── .env

The first three files are available in the youtube-to-spotify repo on GitHub. Download them and place them in your folder.

For the .env file, create a new text file in your folder, name it .env (just that, no other extension), and fill it in with your credentials from Chapters 2 and 3:

CLIENT_ID=your_spotify_client_id
CLIENT_SECRET=your_spotify_client_secret
REFRESH_TOKEN=your_spotify_refresh_token
SPOTIFY_PLAYLIST_ID=your_spotify_playlist_id
API_KEY=your_youtube_api_key
YOUTUBE_PLAYLIST_ID=PLGBuKfnErZlAkaUUy57-mR97f8SBgMNHh

Save it. Don't share it. Don't commit it to GitHub — we'll handle that in Chapter 6.

Windows users: Windows sometimes adds a .txt extension without telling you, turning .env into .env.txt. To check, open File Explorer, go to the View tab, and enable "File name extensions". If your file shows as .env.txt, rename it and remove the .txt part.

Step 3: Open a Terminal in Your Project Folder

You'll run all the commands in this chapter from inside your youtube-to-spotify folder.

On Windows: Open File Explorer, navigate to your project folder, click the address bar at the top, type cmd, and press Enter. A Command Prompt window opens already pointing at your folder.

On Mac: Open Terminal, then drag your project folder into the Terminal window and press Enter. Or type cd (with a space) and then drag the folder in.

On Linux: Right-click inside the folder and select "Open Terminal here", or use cd to navigate there.

Confirm you're in the right place by typing:

ls

(On Windows, use dir instead.) You should see your four files listed.

Step 4: Create a Virtual Environment

A virtual environment is an isolated box for your project's dependencies. It means the packages you install for this project don't interfere with anything else on your computer, and vice versa.

You only do this once per project.

python -m venv venv

This creates a folder called venv inside your project. Now activate it:

On Windows:

venv\Scripts\activate

On Mac/Linux:

source venv/bin/activate

Your terminal prompt will change to show (venv) at the start. That means the virtual environment is active. Every time you come back to work on this project, you'll need to activate it again before running anything.

Step 5: Install the Dependencies

Our project uses a few external libraries — code that other people wrote so we don't have to. They're listed in a file called requirements.txt (also in the repo).

With your virtual environment active, run:

pip install -r requirements.txt

You'll see a stream of output as pip downloads and installs everything. This takes a minute or two depending on your internet speed. When it's done, the prompt comes back and you're ready.

The key packages being installed are:

google-api-python-client — lets us talk to the YouTube API
requests — lets us make HTTP calls to Spotify's API
python-dotenv — reads our .env file and makes the values available to the script

Step 6: Run the Script

This is the moment. Make sure your virtual environment is still active (you'll see (venv) in the prompt), then run:

python script.py

The script starts running. The first few lines you'll see are it connecting to Spotify and fetching the YouTube playlist:

Fetching YouTube playlist...
Found 150 videos on YouTube.

Then it starts searching, one song at a time:

Searching: Stayin Alive Bee Gees
1. Found: Stayin' Alive by Bee Gees

Searching: Dancing Queen ABBA
2. Found: Dancing Queen by ABBA

Searching: Hotel California Eagles
3. Found: Hotel California - 2013 Remaster by Eagles

Searching: Bohemian Rhapsody Queen Official Music
4. Found: Bohemian Rhapsody by Queen

Searching: Some Obscure B-Side Title
5. Not found: Some Obscure B-Side Title - Artist Name

It will churn through all 150. Most will be found. A few won't — usually because the song isn't on Spotify, or the YouTube title is too unusual for the search to crack. That's normal.

When it's done, you'll see the summary:

Adding 143 new tracks...
Finished adding all 143 tracks.

Reordering playlist to match YouTube order...
Finished reordering 143 tracks.

--- Done ---
YouTube videos:     150
Found on Spotify:   143
Not found:          7
Added:              143
Removed:            0

Open Spotify. Your playlist is there, populated, and in the same order as the YouTube playlist.

That just happened automatically. No clicking. No copy-pasting. You wrote a script that did it for you.

If Something Goes Wrong

ModuleNotFoundError: No module named 'dotenv'
Your virtual environment isn't active. Run the activate command from Step 4 and try again.

Missing required environment variables: CLIENT_ID
Your .env file is either missing, in the wrong folder, or has the wrong name (check for .env.txt on Windows). It must be in the same folder as script.py.

401 Unauthorized from Spotify
Your CLIENT_ID, CLIENT_SECRET, or REFRESH_TOKEN is wrong. Go back to Chapter 2 and double-check the values.

HttpError 403 from YouTube
Your API_KEY is wrong or the API isn't enabled on your Google Cloud project. Go back to Chapter 3 and verify both.

HttpError 404 from YouTube
Your YOUTUBE_PLAYLIST_ID is wrong, or the playlist is set to private. The ID should match exactly what's in the playlist URL.

The script runs but adds 0 tracks
Check that your SPOTIFY_PLAYLIST_ID is correct and that the Spotify app has playlist-modify-public and playlist-modify-private in its scopes (we set this in the authorization URL in Chapter 2).

What's Next?

Running the script manually is great. Running it automatically every day without touching your computer is better.

In Chapter 6, we push the code to GitHub and set up a GitHub Action that runs the script on a schedule — every day, for free, forever.

Automate Spotify and YouTube Playlists - Chapter 4: Writing the Code

Tawanda Nyahuye — Thu, 23 Jul 2026 05:05:21 +0000

We have our keys. Now we write the script.

By the end of this chapter, you'll understand exactly what the code does and why — line by line, in plain English. No assumed knowledge. If something still doesn't make sense after reading, drop a comment, and I'll fix the explanation.

The project has three files:

youtube-to-spotify/
├── spotify.py       ← knows how to talk to Spotify
├── youtube.py       ← knows how to talk to YouTube
├── script.py        ← the brain — runs the sync
└── .env             ← your private credentials (never shared)

We'll go through each one.

The .env File

This isn't code. It's just a text file that holds your six credentials from Chapters 2 and 3. Create a file called .env in your project folder and fill it in:

CLIENT_ID=your_spotify_client_id
CLIENT_SECRET=your_spotify_client_secret
REFRESH_TOKEN=your_spotify_refresh_token
SPOTIFY_PLAYLIST_ID=your_spotify_playlist_id
API_KEY=your_youtube_api_key
YOUTUBE_PLAYLIST_ID=PLGBuKfnErZlAkaUUy57-mR97f8SBgMNHh

That last line is already filled in — that's the 70s playlist we're using. The rest you replace with your own values from the previous chapters.

This file stays on your computer. It never goes to GitHub. We'll make sure of that in Chapter 6.

youtube.py — Reading the YouTube Playlist

This file is responsible for one thing: talking to YouTube. It has three jobs we care about.

Job 1: Fetch the playlist videos

def get_playlist_items(self, playlist_id):
    request = self.youtube.playlistItems().list(
        part='snippet',
        playlistId=playlist_id,
        maxResults=50
    )

    videos = []
    while request:
        response = request.execute()
        for item in response['items']:
            title = item['snippet']['title']
            video_id = item['snippet']['resourceId']['videoId']
            videos.append((title, f"https://www.youtube.com/watch?v={video_id}"))
        request = self.youtube.playlistItems().list_next(request, response)
    return videos

YouTube's API only gives you 50 videos at a time. Our playlist has 150. So the while request loop keeps asking "give me the next 50" until there are no more pages left. By the end, videos is a list of 150 (title, url) pairs.

A typical entry looks like:

("Stayin' Alive - Bee Gees (Official Music Video)", "https://www.youtube.com/watch?v=I_izvAbhExY")

Job 2: Figure out the song and artist from the title

YouTube video titles are a mess. Every creator formats them differently:

Stayin' Alive - Bee Gees (Official Music Video)
Bee Gees - Stayin' Alive | Lyrics
ABBA - Dancing Queen (Official)
Don't Stop Me Now [Queen] HD

There's no rule. So we try to make sense of them:

def extract_song_and_artist(self, title):
    if "-" in title:
        parts = title.split("-")
        if len(parts) == 2:
            artist_first = parts[0].strip()
            song_first = parts[1].strip()

            song_second = parts[0].strip()
            artist_second = parts[1].strip()

            return (song_first, artist_first), (song_second, artist_second)

    return (title, ""), (title, "")

When we see a - in the title, we split on it and return both possible interpretations: "Artist - Song" and "Song - Artist". Later, the main script tries both on Spotify and keeps whichever finds a match.

If there's no -, we treat the whole title as the song name and search with no artist. A broad search often still works.

Job 3: Clean up the noise

Before we search Spotify, we strip all the YouTube clutter — "(Official Music Video)", "[HD]", "ft.", "#lyrics", and about 40 other variations that would confuse the search:

def clean_title(self, title):
    title = re.sub(r'\(.*?\)|\[.*?\]|\{.*?\}|#\S+', '', title)
    # ... removes "Official Video", "Lyrics", "HD", etc.
    title = re.sub(r'\s+', ' ', title).strip()
    return title

So "Stayin' Alive - Bee Gees (Official Music Video)" becomes "Stayin Alive - Bee Gees" before we send it to Spotify. Much cleaner search.

spotify.py — Talking to Spotify

This file handles everything on the Spotify side. Four functions matter most for our sync.

Staying logged in: refresh_access_token

def refresh_access_token(self):
    # Uses your CLIENT_ID, CLIENT_SECRET, and REFRESH_TOKEN
    # to get a fresh access token every time the script runs

Spotify access tokens expire after one hour. The Refresh Token you got in Chapter 2 lets us generate a new one automatically every time the script starts. This is why the script can run unattended on a schedule — it never needs you to log in again.

Searching for a song

def search_song(self, query, limit=10):
    endpoint = f'search?q={query}&type=track&limit=10'
    # ... asks Spotify for the top 10 results
    # ... then runs through three matching passes

This function doesn't just take the first result and hope for the best. It runs three passes:

Pass 1 — Is the full search query a substring of the track name or artist? If yes, that's almost certainly the right song.

Pass 2 — Do two or more artist names from the result appear in our query? A query like "Stayin Alive Bee Gees" matches "Stayin' Alive by Bee Gees" because "Bee Gees" is in both.

Pass 3 — Do at least two words from our query appear in the track title? Last resort, but catches songs where the artist name wasn't in the YouTube title at all.

If all three passes fail, the function returns None and the script logs the song as not found.

Adding and removing tracks

def add_tracks_to_playlist(self, playlist_id, track_uris):
    # Adds tracks in batches of 100 (Spotify's limit per request)

def remove_tracks_from_playlist(self, playlist_id, track_uris):
    # Removes tracks in batches of 100

Spotify's API only accepts 100 tracks per request, so both functions split large lists into batches automatically. You don't have to think about this — it just works.

Reordering to match YouTube

def reorder_playlist_tracks(self, playlist_id, track_uris):
    # Moves tracks one by one until the order matches YouTube

def reorder_playlist_many_tracks(self, playlist_id, track_uris):
    # More efficient version for playlists over 100 tracks

Because our playlist has 150 songs, the script automatically uses reorder_playlist_many_tracks. The order of your Spotify playlist will match the YouTube playlist exactly after every sync.

script.py — The Brain

This is the file you actually run. It loads your credentials, connects to both APIs, and calls the sync function.

def main():
    load_dotenv()  # reads your .env file

    client_id = os.getenv('CLIENT_ID')
    client_secret = os.getenv('CLIENT_SECRET')
    # ... loads all six values

    spotify = SpotifyAPI(client_id, client_secret, refresh_token)
    youtube = YouTubeAPI(api_key)

    sync_playlist(spotify_playlist_id, youtube_playlist_id, spotify, youtube)

load_dotenv() reads the .env file and makes its values available as environment variables. os.getenv('CLIENT_ID') picks them up. The script then checks that none of them are missing — if you forgot to fill in one of the six values, it tells you exactly which one is missing instead of crashing with a confusing error.

The sync function, step by step

def sync_playlist(spotify_playlist_id, youtube_playlist_id, spotify, youtube, remove=True):

Step 1 — Fetch YouTube videos

youtube_videos = youtube.get_playlist_items(youtube_playlist_id)

Gets all 150 videos from our 70s playlist, with their titles.

Step 2 — Search each one on Spotify

for i, (title, url) in enumerate(youtube_videos, start=1):
    (song_a, artist_a), (song_b, artist_b) = youtube.extract_song_and_artist(title)

    query_a = f"{youtube.clean_title(song_a)} {youtube.clean_title(artist_a)}".strip()
    query_b = f"{youtube.clean_title(song_b)} {youtube.clean_title(artist_b)}".strip()

    result = spotify.search_song(query_a) or spotify.search_song(query_b)

For each video, we build two queries (both possible Artist/Song orderings), clean them up, and try them on Spotify. or means: try query_a first, and only try query_b if query_a found nothing.

Step 3 — Try bracket alternatives

for alt in (youtube.extract_bracket_alternatives(song_a) + ...):
    result = spotify.search_song(alt_query)

Some videos hide an alternative song title in brackets: "Stayin' Alive (From Saturday Night Fever Soundtrack)". If the main queries failed, we try searching with the text inside the brackets as a last resort.

Step 4 — Add, remove, reorder

to_add = [uri for uri in found_tracks if uri not in spotify_uris]
spotify.add_tracks_to_playlist(spotify_playlist_id, to_add)

to_remove = [uri for uri in spotify_uris if uri not in found_tracks]
spotify.remove_tracks_from_playlist(spotify_playlist_id, to_remove)

spotify.reorder_playlist_many_tracks(spotify_playlist_id, found_tracks)

Three list comparisons:

Tracks on YouTube but not on Spotify → add them
Tracks on Spotify but not on YouTube → remove them
Reorder what's left to match YouTube's order

Step 5 — Print the summary

print(f"YouTube videos:     {len(youtube_videos)}")
print(f"Found on Spotify:   {len(found_tracks)}")
print(f"Not found:          {len(not_found)}")
print(f"Added:              {len(to_add)}")
print(f"Removed:            {len(to_remove)}")

When the script finishes, you get a clean summary of everything it did. On the first run, expect a big "Added" number. On every run after that, only the changes since the last sync will show.

Why Three Files Instead of One?

You might wonder why we didn't just put everything in one big script.py.

The short answer is separation of concerns — each file knows about one thing. youtube.py knows YouTube. spotify.py knows Spotify. script.py knows the logic. If Spotify changes their API tomorrow, you only edit spotify.py. If you want to swap YouTube for a different music source, you only change youtube.py. The logic in script.py doesn't need to know or care.

This is how real software is structured. You've just done it.

What's Next?

In Chapter 5, we install Python, set up the project on your computer, and run the script for the first time. You'll watch it pull all 150 songs from the 70s playlist and build your Spotify playlist live.

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

Tawanda Nyahuye — Wed, 22 Jul 2026 05:05:40 +0000

Spotify is sorted. Now we go to YouTube's side.

The goal of this chapter is simple: get a YouTube API key and find the ID of the YouTube playlist we want to mirror. Two things. That's it.

A Quick Word on the YouTube API

YouTube is owned by Google, so the YouTube API lives inside Google's developer platform. Don't let that intimidate you — you're logging in with the same Google account you use for Gmail or Google Drive. Nothing new to create.

The YouTube Data API has a free tier that gives you 10,000 units per day. Reading a playlist of 100 songs costs about 200 units. So unless you're syncing 50 playlists a day, you'll never hit the limit. We're well within free territory.

Step 1: Go to Google Cloud Console

Open your browser and go to console.cloud.google.com. Log in with your Google account.

If this is your first time here, Google will ask you to agree to their Terms of Service. Accept and continue.

Step 2: Create a Project

Google organises everything into "projects." Think of a project as a folder for your app. We need to create one.

At the very top of the page, you'll see a dropdown that probably says "Select a project." Click it, then click New Project in the top right of the popup.

Give it a name — something like youtube-to-spotify works fine. Leave the organisation field as is and click Create.

Google will take a few seconds to create it. Once done, make sure your new project is selected in that top dropdown before continuing.

Step 3: Enable the YouTube Data API

With your project selected, use the search bar at the top of the page and type "YouTube Data API v3". Click on the result that says exactly that.

You'll land on an API overview page. Click the blue Enable button.

After a moment, the page will refresh and show you the API is now enabled. You should see a dashboard with some quota charts — all zeros for now, which is correct.

Step 4: Create an API Key

Now we need an actual key. In the left sidebar, click Credentials. Then click + Create Credentials at the top and choose API key.

Google will generate a key immediately and show it to you in a popup. It looks something like this:

AIzaSyD3x8Kv2mNpQr7wLtYhJfUcX9vBsE1oRk

Copy it. This is your API_KEY.

Restrict the Key (Recommended)

After copying it, click Edit API key in that same popup. Under "API restrictions," select Restrict key, then choose YouTube Data API v3 from the dropdown. Click Save.

This means your key only works for YouTube — if someone somehow got hold of it, they couldn't use it anywhere else. It takes 30 seconds and it's good practice.

Step 5: Find Your YouTube Playlist ID

Go to youtube.com and open the playlist you want to mirror on Spotify.

Look at the URL in your browser's address bar. It will look something like this:

https://www.youtube.com/playlist?list=PLGBuKfnErZlAkaUUy57-mR97f8SBgMNHh

The part after list= is your Playlist ID. In this example, that's PLGBuKfnErZlAkaUUy57-mR97f8SBgMNHh. That's the 70's Music Hits Playlist - Best of 70s Music Classics by Redlist Decades — the one we'll be using throughout this series.

Copy that. That's all you need from YouTube.

One thing to note: the playlist needs to be public or unlisted for the API to read it. If it's set to private, the script won't be able to see it. You can change the visibility in YouTube Studio under your playlist settings.

What You Have Now

Between Chapters 2 and 3, you've collected everything the script needs to run. Here's the full list:

Variable	What it is	Where you got it
`CLIENT_ID`	Spotify app ID	Spotify Developer Dashboard
`CLIENT_SECRET`	Spotify app secret	Spotify Developer Dashboard
`REFRESH_TOKEN`	Long-lived Spotify login token	curl/PowerShell command in Chapter 2
`SPOTIFY_PLAYLIST_ID`	Your Spotify playlist to write to	Spotify share link
`API_KEY`	YouTube Data API key	Google Cloud Console
`YOUTUBE_PLAYLIST_ID`	`PLGBuKfnErZlAkaUUy57-mR97f8SBgMNHh`	YouTube playlist URL

Six values. That's the whole configuration. No more accounts, no more dashboards. From Chapter 4 onward, it's all code.

What's Next?

In Chapter 4, we write the script. We'll walk through each file — what it does, how it works, and why — in plain English. No assumed knowledge.

See you there.

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.