Together with
Hello friends!
Welcome to this week’s Sloth Bytes. I hope you had an amazing week!
One editor for writers, developers, and agents
Your docs have more contributors than ever. Engineers, PMs, support, marketing, and now AI agents. But most documentation tools force a choice: an accessible editor for the whole team, or the rigor of git-based version control for developers. That tradeoff slows everyone down.
Mintlify's editor removes the tradeoff. Writers get a visual WYSIWYG experience with slash commands and editable navigation. Developers keep their git-native workflow. Every visual edit is a clean commit, every commit appears in the editor. Changes flow both ways.
The editor also brings live collaboration and AI agents as first-class contributors:
WYSIWYG editing with no markdown syntax required
Real-time multiplayer for war room-style doc sessions
MCP support so your AI can edit alongside your team
Two-way git sync that preserves a single source of truth
The best documentation is written by everyone who has context. That's your whole team. And now, your agents. Try it at mintlify.com.
Stop re-prompting. Say it right the first time.
Voice-first prompts preserve the nuance you cut when typing. Speak once, paste into any AI tool, get results that don't need a follow-up. 89% of messages sent with zero edits.
There's a phase every programmer hits.
You're finally building projects and you start writing code every single day, yet somehow it feels like you're not actually getting better.
It feels like you're running on a treadmill. Lots of effort, but going nowhere.
I hit this wall and I thought the answer was just... write more code.
Do more projects, watch more tutorials, rise and grind, if I’m not coding I’m wasting my life. So I kept building things and was wondering I wasn’t making as much progress as when I first started.
Well… it was because I was always reading MY garbage code everyday.
Turns out you can get better without even writing code. Here’s my 5 favorite ways of doing that.
1. Read code you didn't write
Yes. Just read code. It sounds really simple, but when you first start it actually feels pretty uncomfortable. If it does, that’s a good sign.
Most developers only ever read their own code. Especially when they’re first getting started.
Which is terrible because it’s the same as trying to become a better writer by only reading your own writing.
You'll just reinforce your existing habits forever. Good and bad. Mainly bad…
That’s why it’s good to read code.
“But, but I read tutorial code Sloth…”
Hey, I’ll give you credit, that’s a start.
The issue is most tutorials are documentation examples dressed up nicely. They're designed to work for any project, which means they solve nothing specific and teach you very little about real decisions.
It’s better to find a real codebase. Something people actually use if possible.
GitHub is free and one of the best ways to do that.
Pick a project in a language you know
Find a file that does something interesting
Read it like a book.
The goal here is NOT to understand everything. There’s no way you’re doing that in a big codebase. Ideally you should be looking for decisions that surprise you.
A function that's structured differently than you'd write it.
A pattern you've never seen.
A comment that explains why something was done a specific way (my favorite since that’s when a programmer is most honest.)
The first time I had to read someone else’s code was so humbling, but also the fastest I’ve ever learned.
Because while I could technically understand the syntax, I didn’t understand why they used it THAT way. Which led to me asking questions and then playing around with it.
2. Read company engineering blogs
From Uber’s blog
A surprising amount of developers don’t know that the biggest tech companies in the world are constantly publishing exactly how they build things.
Netflix writes about how they handle streaming for 300 million people. Uber publishes how they rebuilt their architecture from scratch. Discord documented why they switched from Go to Rust. Shopify writes about scaling Flash Sales that do millions of requests per minute.
This is the stuff that used to be completely locked behind NDAs and internal wikis. Now it's just... sitting on the internet. Waiting.
The difference between reading a tutorial and reading an engineering blog is massive. Tutorials teach you how a tool works in theory. Engineering blogs show you how a real team used that tool to solve a real problem at a scale you've never thought about.
To be fair, it’s rare you’ll use this knowledge in personal projects, but if you’re working professionally or want to learn more about system design, they’re a great resource.
You get to see the decisions they made, the tradeoffs they accepted, and sometimes the mistakes they made along the way.
Some good ones to start with:
Just pick a company whose product you use and start there. You'll finish one post and immediately have five new things to Google.
3. Give feedback on other people's code
If you ever get the opportunity to review someone else's code do it.
Even if you're junior or you feel underqualified.
Giving a code review forces you to read carefully, articulate your reasoning, and defend your perspective. You can't just vaguely feel like something is wrong. You have to explain why.
It also exposes you to problems you didn't know existed. Someone else's bug is a lesson you get for free (unless you’re their manager)
If you end up being wrong, well guess what? You just learned something new.
Now if you don't have access to real code reviews, you can just use open source pull requests. Go read the comments on a merged PR in any major project. You'll see senior engineers explaining their reasoning in real time.
4. Actually read the documentation and books…
Diagram from the book Design Data Intensive Applications
I know. Revolutionary. Hear me out.
Most developers Google the specific thing they need, copy the answer, and move on. Which is fine for shipping fast. It's terrible for actually understanding anything.
The moment you start reading real codebases and sitting in on code reviews, you're going to hear words you've never encountered in your life. Terms people throw around like everyone just knows them.
In my experience, a lot of programmers don't simplify their vocabulary for you.
They use the term, expect you to keep up, and move on.
"Oh we just need to debounce that." Cool. What?
"This looks like a classic race condition." Ah yes, I was thinking the same.
"We should probably hoist this up." Absolutely. On it. Just need to google what hoisting is…
That experience is either going to make you feel stupid and shut down, or it's going to make you do intense research. I recommend the second option.
I’ve come to learn that this is another reason why documentation and books matter.
Sure you’ll learn some interesting things, but you also build the vocabulary/concepts that lets you actually participate in real conversations with engineers.
When a dev says "this violates single responsibility" they learned that somewhere.
You just have to figure out where.
5. Talk about code out loud
I think this one is going to become more important because of AI.
Explaining something you know is one of the fastest ways to discover how much you don't actually know.
Find someone or something to talk to. Explain your thought process when your working on a new feature or fixing a big. Try to walk them through how something works and why you’re doing it this way.
Usually, you'll get three sentences in and hit a wall.
"And then... uh… actually, wait, why does it do that?"
That’s exactly where you need to start studying/researching.
Hope these tips will help you out so you can write less trash code.
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.
What'd you think of today's email?
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.
