Removing a single line of code slashed database CPU usage by 66% 🤘

Swizec reveals the hidden pitfalls of overusing the DRY principle in coding, leading to bad abstractions. Discover how to write adaptable, efficient code that avoids these common traps.

This talk from C3Fest summarizes the key lessons I've learned in the past ~15 years of working in tech startups. It's a high level overview of a new book I'm writing (60% done).

Here's a trap that talented engineers fall into all the time. It creates frustration, burnout, and the genre of tweets that read like "Why don't people care about the amazing work I'm doing".

Here are 6 books I'd buy every engineer who joins my team, if I ran a team. You might like 'em too.

Discover the potential pitfalls of spurious automation and learn a foolproof three-step process to automate any task effectively. Don't miss out on understanding when automation is truly beneficial and when it can become a hindrance.

Not everything needs to work forever. Start by solving the problem

Decided to publish my notes because they look pretty useful on their own. Although I hope my stage presence adds a little something something. Enjoy :)

All the hard lessons learned using feature flags in production. Skips the why and gets to the how.

here's war story from last summer. I've talked about it in workshops but haven't written it down before. It's for a book I'm working on.

Many engineering challenges start with your roadmap

effective engineering teams should work *with* their product owner/manager, not *for* them

When working: sync first *then* async

A shift in your code review process can boost your team's productivity. Empower authors to make the call.

The best engineering books aren't those you read at the start of your career. It's the ones you appreciate 5 years in.

Don't get stuck being a critical member of the team.

Team dysfunction where everyone's a soloist? Try this fix: Force the team to work on ONE story at a time.

Ever felt like your software team is just soloists in a trench coat? You may be right!

No amount of growth hacking, investor money, or a/b testing will save you, if people don't want what you have.

Agile is something you are, not something you do.

Talk about today, not yesterday

Books start with a detailed outline that's easy to change. That's when they're easy to change and where you can help.

People are starting to cheat in interviews using ChatGPT. It's obvious, doesn't work, and wouldn't even be cheating if you did it right!

Swizec is writing "Scaling Fast", a book about his journey in a 20x hyper-growth startup. Questions?

Do Hard Things is a recent book from an author of my favorite book about burnout (Peak Performance). It talks about why our traditional view of toughness is wrong.

Realizing I'm statistically halfway through life at 36. Time is the one thing you can't get more of

You can't escape Conway's Law. Might as well use it for good.

everything people say is bad about modern tech interviews is actually good 🤯

Staff Engineer was one of the more impactful books I've read in recent months. Went through the audiobook soon after becoming tech lead so the timing was perfect.

burnout doesn't work the way you think

When I first picked up Software Engineering at Google I thought it was another one of those FAANG books full of lessons that make no sense at human scale. I was surprised, lessons apply to teams as small as 5.

In his book, The Art of Science and Engineering, Richard Hamming says the key to a great career is vision. What does that really look like?

Serverless is the future. New book coming out Mar 31st and it's looking bomb

Ever wondered what it's like to make a physical book? It ain't as easy as shipping code lemme tell ya 😅