Sponsored by

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had a great week.

Quick reminder!

I made a very short feedback form for the newsletter where you can share what you like, what you don’t, and what you’d like to see more of:

I’ll start implementing some of the feedback next week!

Receive Honest News Today

Join over 4 million Americans who start their day with 1440 – your daily digest for unbiased, fact-centric news. From politics to sports, we cover it all by analyzing over 100 sources. Our concise, 5-minute read lands in your inbox each morning at no cost. Experience news without the noise; let 1440 help you make up your own mind. Sign up now and invite your friends and family to be part of the informed.

Sign up today!

SDK For Dummies

I always pictured an SDK as some magical black box.

In reality, an SDK is just the stuff you’d build yourself anyway. It’s just bundled, documented, and (ideally) battle-tested.

What Is an SDK?

An SDK (Software Development Kit) is basically a toolbox for developers.

They make the development process easier.

What type of tools are in a SDK?

An SDK usually comes with this:

• API bindings - Functions/methods that wrap HTTP endpoints.

• Libraries - Helpers (auth, retries, pagination, signing requests, JSON models).

• Docs + examples - Copy/pasteable snippets in your language.

• CLIs / dev tools - Scaffolding, emulators/simulators, local testing.

• Types/Models - TypeScript/Java/Kotlin/Swift definitions so your IDE can catch mistakes.

• Project templates - “Create app → it actually runs” vibes.

A nice way to think of it is like a “starter kit” for a platform/tool.

How is an SDK different from an API, a framework, or a library??

That’s uh… that’s a good question. Here’s how I like to think of them:

SDK vs API vs Library vs Framework

• API: The contract (usually HTTP). Like a restaurant menu.

• SDK: Tools to use that API. Like the kitchen with recipe cards and utensils.

• Library: A reusable set of functions. Like a specialized tool (sharp knife).

• Framework: Structure you build inside. Like a full kitchen layout dictating your flow.

Programming example: API vs SDK

Let’s raw dog a stripe request… (I hope you don’t have to do this).

API

// Raw API via fetch
await fetch("https://api.stripe.com/v1/payment_intents", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.STRIPE_SECRET}`,
    "Content-Type": "application/x-www-form-urlencoded",
  },
  body: new URLSearchParams({
    amount: "2000",
    currency: "usd",
    "automatic_payment_methods[enabled]": "true",
  }),
})
  .then(r => r.json())
  .then(console.log);

SDK

// Using Stripe’s official SDK
import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_SECRET);

const pi = await stripe.paymentIntents.create({
  amount: 2000,
  currency: "usd",
  automatic_payment_methods: { enabled: true },
});
console.log(pi);

What’s the difference?

Now the flow and structure looks similar, but the SDK is doing a lot more behind the scenes:

• Auth header formatting

• URL building

• Encoding

• Error parsing

• Retries

• Knowing every query string quirk.

If you only used the API, you would have to handle all that yourself.

Why SDKs are (usually) worth it

• Speed: Less boilerplate, faster to first success.

• Safety: Built-in auth, retries, backoff, idempotency, pagination.

• Developer Experience (DX): Types, autocompletion, better error messages.

• Parity: Official SDKs stay aligned with new API features.

When not to use an SDK

You’re probably thinking:

Why doesn’t every API have an SDK? It sounds like an upgraded version.

Oh my sweet innocent developer… If only it were that simple.

• Bundle size / cold starts: Some SDKs are big and chonky (bad for front-end or serverless cold starts).

• Environment mismatch: Might not support your runtime (Edge/Workers/Deno/Electron).

• Lock-in / opinionated flows: SDK dictates patterns you don’t want.

• Security & audit: You need ultra-tight control over requests, logging, or compliance.

• Missing features: API supports a new thing the SDK hasn’t shipped yet.

“Should I use the SDK or just the API?”

Use the SDK if:

• You want speed to first prototype.

• You’re in a supported language/runtime and care about solid DX.

• You need built-in best practices (auth, retries, pagination) without reinventing them.

• The company/project actually MAINTAINS IT.

Use the API directly if:

• You need ultra-slim dependencies or edge runtimes.

• You require custom signing/telemetry/auditing.

• The SDK lags features you need now.

• It hasn’t been updated in years…

Thanks to everyone who submitted!

grcc492, Melvis-07, Yeshua235, JunKaiPhang, raresh2306, 190-785, MihajloMilojevic, gcavelier, cre-w, Pardeshi-Aditya, MWANZO-MPYA, Yeshua235, geethsai0507, Neverever1705, AspenTheRoyal, WopheAkinlade, SanjnaSukirti, jsjasee, NeoScripter, and Suji-droid.

Wow… that’s a lot again. Let’s do a harder one:

Trace the Path of the Word

Given a grid of letters, check if a word can be traced by moving up, down, left, or right from one letter to the next.

Write a function that returns the path as a list of [row, col] positions, or "Not present" if the word is not found/can’t be created.

Examples

trace_word_path("BISCUIT", [
  ["B", "I", "T", "R"],
  ["I", "U", "A", "S"],
  ["S", "C", "V", "W"],
  ["D", "O", "N", "E"]
])
output = [[0, 0], [1, 0], [2, 0], [2, 1], [1, 1], [0, 1], [0, 2]]

trace_word_path("HELPFUL", [
  ["L","I","T","R"],
  ["U","U","A","S"],
  ["L","U","P","O"],
  ["E","F","E","H"]
])
output = "Not present"

trace_word_path("UKULELE", [
  ["N", "H", "B", "W"],
  ["E", "X", "A", "D"],
  ["L", "A", "U", "U"],
  ["E", "L", "U", "K"]
])
output = [[2, 3], [3, 3], [3, 2], [3, 1], [3, 0], [2, 0], [1, 0]]

trace_word_path("SURVIVAL", [
  ["V", "L", "R", "L"],
  ["V", "A", "I", "V"],
  ["I", "O", "S", "C"],
  ["V", "R", "U", "F"]
])
output = [[2, 2], [3, 2], [3, 1], [3, 0], [2, 0], [1, 0], [1, 1], [0, 1]]

Notes

• The target word will never be longer than the grid of letters.

• Target word and the letters grid will be in upper case.

How To Submit Answers

Reply with

• A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

• or if you’re on the web version leave a comment!

• If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

New video! (I forgot to mention it here)

You like the thumbnail?

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.