Swizec Teller

For the first time in my career we completed a design system migration. The new math on big rewrites tickles my soul. As I like to say: at scale you are always mid-migration, mid-rewrite, mid-wowthiscodeisbad. Your company changes every few months and the systems you built 2 years ago are no longer fit for purpose. How you handle these migrations is everything. Continue reading →

That was my wake up call: This company is different. Shipping fast is not just something we say, we ship fast. Every day, multiple times per day, even Fridays at 5pm. You might think that's cute but for a 21-person engineering org we ship with a velocity I wouldn't think possible 2 years ago when my young whippersnapper boss told me off for writing code the old fashioned way. We now auto-approve and merge 16% of all pull requests, perform big-bang migrations, ship a few hundred PRs every week,…

Check this out – how fast Jev vs Claude find a product recommendation. Both make an API call based on your query, both are just prompt engineering on our end. No training, no piles of evals, no months of collecting data, huge difference in speed and cost. Jev is even fast enough that it can [poorly] play a game in real time. Each key press here is an API call with the observation of current game state and a choice for what key to press. Continue reading →

I've been on a quest lately to reclaim my sanity at work. The latest advancement is a bot that auto-approves and merges low risk PRs with no oversight 😈 https://twitter.com/Swizec/status/2093478262639046864 Back in July I wrote that code review is the bottleneck to your velocity. If you can't get your code verified and deployed, you're just building a large backlog of work-in-progress, which slows you down further as you keep all that context in mind for every new feature. Continue reading →

I've been a dad for 3 months now so obviously I have it all figured out and there's nothing new to learn. My theories are rock solid and definitely apply to everyone. Here's what B2B software taught me about having kids. Most startups fail for a very basic reason: The money runs out. Continue reading →

The points are fake and the score is made up but we always finish 70% of our sprint and get around 30 points done per person. Hey waitaminute that almost sounds useful 🤨 I've said before that working in a high growth startup is like spinning plates – you do a bit here a bit there and kick the can to survive another day. There's always more work than people and spaceship-first development makes this worse because starting is easy and finishing is hard. On my team we add ~50 new ideas to triage…

I've been experimenting with different approaches to build a system where humans and agents can ship fast safely. Think I've found something that works – custom linters. Engineering teams produce more code than ever. I'm sure you've noticed. But you can't ship faster than you can validate and keeping the slop cannons safe is the architect or principal engineer's job. Or whatever you call the designated adult in the room :) Here's what you need: Guardrails and feedback loops. They should be fast…

I'm in the middle of migrating our design system and it's fun to see how much AI can do. Just last night I stayed up until 1am to ship another big portion. Wait why am I coding at 1am if AI's doing all the work? 🤨 It's the spaceship problem. You start with the ending then work your way back to something useful. This kinda sucks. Continue reading →

At scale you're always mid-migration but you never do a big-bang rewrite, right? I think that's changing 🤨 You see the secret of our industry is that "you never rewrite your software" but we're all always rewriting our software. When the business changes every 6 months, what else are you gonna do? https://twitter.com/Swizec/status/1924875257669943383 Continue reading →

Ever worked with a useful software architect? Yeah me neither. But I sure have tried to be one. Software architects have a weird role: Think about the code tomorrow. Today's code is what it is, how do we make it good tomorrow? Without slowing down, losing business, or falling off a cliff. The worst architects write lots of docs nobody reads, make proclamations of The One True Way, and fall out of touch. Many effective architects put on the Software Janitor hat and burn out in 2 years. Continue…

Can you believe I've been writing on swizec.com for 20 years? The blog started back when "have a website" was social media 🤯 Before that it was a webcomic site. Those posts do not survive but I recently found the sketches in my mom's basement and brought them to San Francisco. Little memento of a different path :) I got swizec.com in 2005 and started hosting websites on the linux machine in my bedroom, which was also my only computer and everyone's web router. Fun times. Gentoo was my distro of…

In the last few months every engineer I hired stumbled in exactly the same way: Project management. They learned quickly, but that first big project has become a right of passage.

Feedback from an expert is how you learn taste. Your code doesn't matter until it's shipped.

The death of engineering has been greatly exaggerated. You still need to know what you're doing.

Hiring engineers is like deciding what kind of system you'll have. This seems obvious but surprised me to see first-hand.

This is a classic startup war story: Someone had built a leaky rowboat. It worked! Then we started flying the rowboat as a Cessna. What we needed was an aircraft carrier.

Explore the art of invisible software and user-centric workflow design with Swizec and Kent C Dodds. Uncover what separates a good engineer from a great one in this insightful dialogue.

AI makes it easy to focus inwards and feel impressed with all the churn and motion and output you're producing. But your users don't care.

Traditional engineering levels were about skill progression. I think this has changed. Everyone now is a mini staff engineer.

You know what's better than a code review comment? A fix.

On AI, mental load, and delegation

I've been digging into agents for internal tooling and processes. Looking for how to scale without drowning in manual work. Here's what I found

When candidates put AI on their resume, the key thing I try to find out is whether they used evals. How did you measure making improvements?

Forget the bullshit tips and tricks, just talk to it.

Read more papers. You can learn the latest and greatest in your field in one chill afternoon.

We talk a lot about outcomes over outputs and how engineers are supposed to get us over the water, not blindly build a bridge because someone asked for a bridge. But how do you do that in practice?

Maybe AI will replace engineers, I don't know. Self-driving cars were just around the corner for 50 years. Until then we've got shit to do and engineers to hire.

The best engineers I know never talk about their AI setup. The worst engineers I know only talk about their AI setup.