Derrick Wippler
@thrawn01.bsky.social
Engineer, Optimist, Open Source enthusiast, https://mailgun.com alumni, Efficiency Evangelist, Project: http://querator.io, blog: https://wippler.dev
“Whenever a theory appears to you as the only possible one, take this as a sign that you have neither understood the theory nor the problem which it was intended to solve.” -- Karl Popper
October 21, 2025 at 2:06 PM
“Whenever a theory appears to you as the only possible one, take this as a sign that you have neither understood the theory nor the problem which it was intended to solve.” -- Karl Popper
A man asked a gardener why his plants grew so beautifully. The gardener said: “I don’t force them to grow. I remove what stops them.”
October 19, 2025 at 3:02 PM
A man asked a gardener why his plants grew so beautifully. The gardener said: “I don’t force them to grow. I remove what stops them.”
Your development velocity should match your business velocity. If you're in a fast-changing market, optimize for flexibility and change. If you're in a stable market, optimize for reliability and efficiency. The best architecture is the one that matches your business reality.
October 18, 2025 at 3:03 PM
Your development velocity should match your business velocity. If you're in a fast-changing market, optimize for flexibility and change. If you're in a stable market, optimize for reliability and efficiency. The best architecture is the one that matches your business reality.
The secret to managing technical debt: If you focus on what truly matters first—the critical functionality, the operational issues—you'll have time to pay down tech debt later. When you're not constantly firefighting, you can actually refactor. Focus creates space for quality.
October 17, 2025 at 3:05 PM
The secret to managing technical debt: If you focus on what truly matters first—the critical functionality, the operational issues—you'll have time to pay down tech debt later. When you're not constantly firefighting, you can actually refactor. Focus creates space for quality.
Perfect code is a myth that kills velocity. I've never seen perfect code, it doesn't exist. I've seen code that is resilient and code that's easy to change. Optimize for change and resiliency, not perfection.
October 15, 2025 at 3:04 PM
Perfect code is a myth that kills velocity. I've never seen perfect code, it doesn't exist. I've seen code that is resilient and code that's easy to change. Optimize for change and resiliency, not perfection.
Customers don't pay you for your code. They pay you for the value your code provides. Every technical decision should connect back to customer outcomes. If you can't draw a line between what you are doing and the customer, you might be working on the wrong thing.
October 14, 2025 at 3:02 PM
Customers don't pay you for your code. They pay you for the value your code provides. Every technical decision should connect back to customer outcomes. If you can't draw a line between what you are doing and the customer, you might be working on the wrong thing.
Followed a link to a Facebook post, got this.
Not really sure what the blue guy is doing with the wrench.
Not really sure what the blue guy is doing with the wrench.
October 13, 2025 at 3:02 PM
Followed a link to a Facebook post, got this.
Not really sure what the blue guy is doing with the wrench.
Not really sure what the blue guy is doing with the wrench.
Asked Claude to research the 2026 economic outlook based on current data. Took 10 minutes and referenced 500+ sources. ✨
October 12, 2025 at 2:02 PM
Asked Claude to research the 2026 economic outlook based on current data. Took 10 minutes and referenced 500+ sources. ✨
This was taken from the backseat of a jeep, facing forward through the windshield, driving in Washington.
Every time I see it, I can't believe it came out this good.
Every time I see it, I can't believe it came out this good.
October 11, 2025 at 4:59 PM
This was taken from the backseat of a jeep, facing forward through the windshield, driving in Washington.
Every time I see it, I can't believe it came out this good.
Every time I see it, I can't believe it came out this good.
True story, we mostly test in production, rarely ever pushed to staging before production.
Because our testing focused on what was important. Which gave us a high level of confidence our change didn't break anything.
Also, it was common to deploy 3-5 times a day even Fridays.
Because our testing focused on what was important. Which gave us a high level of confidence our change didn't break anything.
Also, it was common to deploy 3-5 times a day even Fridays.
October 10, 2025 at 2:05 PM
True story, we mostly test in production, rarely ever pushed to staging before production.
Because our testing focused on what was important. Which gave us a high level of confidence our change didn't break anything.
Also, it was common to deploy 3-5 times a day even Fridays.
Because our testing focused on what was important. Which gave us a high level of confidence our change didn't break anything.
Also, it was common to deploy 3-5 times a day even Fridays.
Code style exists to help teams work together faster, not to make code pretty.
Style can speed you up, as familiar patterns are easier to follow. If your style guide is slowing you down, throw it away. If your spending hours a day in PR arguing or fixing idioms and style. You're missing the point.
Style can speed you up, as familiar patterns are easier to follow. If your style guide is slowing you down, throw it away. If your spending hours a day in PR arguing or fixing idioms and style. You're missing the point.
October 9, 2025 at 2:04 PM
Code style exists to help teams work together faster, not to make code pretty.
Style can speed you up, as familiar patterns are easier to follow. If your style guide is slowing you down, throw it away. If your spending hours a day in PR arguing or fixing idioms and style. You're missing the point.
Style can speed you up, as familiar patterns are easier to follow. If your style guide is slowing you down, throw it away. If your spending hours a day in PR arguing or fixing idioms and style. You're missing the point.
I've seen teams spend weeks debating whether to use TABS or SPACES while their customers are churning because of bugs. Code formatting doesn't make good code. Your code is Good Code because it's easy to change. Easy to change code is more about architecture, and far less about style.
October 8, 2025 at 2:11 PM
I've seen teams spend weeks debating whether to use TABS or SPACES while their customers are churning because of bugs. Code formatting doesn't make good code. Your code is Good Code because it's easy to change. Easy to change code is more about architecture, and far less about style.
October 7, 2025 at 4:59 PM
I've been using Sonnet 4.5 in Claude Code for a few days now, and, it's REALLY good.
Like, keeps track of multiple thought paths, THAT I WAS SURE I would need to reset context to solve, Good.
Like, keeps track of multiple thought paths, THAT I WAS SURE I would need to reset context to solve, Good.
Introducing Claude Sonnet 4.5
Claude Sonnet 4.5 is the best coding model in the world, strongest model for building complex agents, and best model at using computers.
www.anthropic.com
October 3, 2025 at 2:05 PM
I've been using Sonnet 4.5 in Claude Code for a few days now, and, it's REALLY good.
Like, keeps track of multiple thought paths, THAT I WAS SURE I would need to reset context to solve, Good.
Like, keeps track of multiple thought paths, THAT I WAS SURE I would need to reset context to solve, Good.
Stop yolo-ing code to production. Deploy like you're sneaking into Smaug's cave. Move slowly, carefully, deliberately. Monitor every step. Roll out gradually. The difference between shipping features and causing incidents is never waking the dragon.
October 1, 2025 at 1:03 PM
Stop yolo-ing code to production. Deploy like you're sneaking into Smaug's cave. Move slowly, carefully, deliberately. Monitor every step. Roll out gradually. The difference between shipping features and causing incidents is never waking the dragon.
The key to 10x productivity with Claud Code is to spin up multiple Claude Code instances. Let one handle implementation while another plans your next feature. Learn to parallelize your entire workflow, and it changes everything.
September 30, 2025 at 2:06 PM
The key to 10x productivity with Claud Code is to spin up multiple Claude Code instances. Let one handle implementation while another plans your next feature. Learn to parallelize your entire workflow, and it changes everything.
Quite probably the most important essay anyone could read right now, especially if you have kids.
open.substack.com/pub/jmarriot...
open.substack.com/pub/jmarriot...
September 28, 2025 at 11:05 PM
Quite probably the most important essay anyone could read right now, especially if you have kids.
open.substack.com/pub/jmarriot...
open.substack.com/pub/jmarriot...
Product Managers: When writing product requirements, ask claude to look for gaps in error states, ask it to find gaps in the current write up. Use the magic phrase in the prompt "ask follow up questions".
Works like magic.
Works like magic.
September 22, 2025 at 8:44 PM
Product Managers: When writing product requirements, ask claude to look for gaps in error states, ask it to find gaps in the current write up. Use the magic phrase in the prompt "ask follow up questions".
Works like magic.
Works like magic.
AI can 2X or even 10X developers, but It's not going to fix your broken SDLC. Companies struggle because they don't know how to build software, not because their developers aren't typing fast enough
September 20, 2025 at 8:08 PM
AI can 2X or even 10X developers, but It's not going to fix your broken SDLC. Companies struggle because they don't know how to build software, not because their developers aren't typing fast enough
Deep dive into KeyDB's architecture revealed SO_REUSEPORT's power:
✅ Eliminates accept() bottlenecks - kernel distributes connections directly to threads
✅ Zero coordination overhead - no locks needed
✅ Same thread accepts & processes
The kernel does the heavy lifting while your threads stay focused
✅ Eliminates accept() bottlenecks - kernel distributes connections directly to threads
✅ Zero coordination overhead - no locks needed
✅ Same thread accepts & processes
The kernel does the heavy lifting while your threads stay focused
August 22, 2025 at 4:59 PM
Deep dive into KeyDB's architecture revealed SO_REUSEPORT's power:
✅ Eliminates accept() bottlenecks - kernel distributes connections directly to threads
✅ Zero coordination overhead - no locks needed
✅ Same thread accepts & processes
The kernel does the heavy lifting while your threads stay focused
✅ Eliminates accept() bottlenecks - kernel distributes connections directly to threads
✅ Zero coordination overhead - no locks needed
✅ Same thread accepts & processes
The kernel does the heavy lifting while your threads stay focused
Reposted by Derrick Wippler
new blogpost about protobuf perf (work related!)
mcyoung.xyz/2025/07/16/h...
mcyoung.xyz/2025/07/16/h...
Parsing Protobuf Like Never Before · mcyoung
mcyoung.xyz
July 16, 2025 at 6:59 PM
new blogpost about protobuf perf (work related!)
mcyoung.xyz/2025/07/16/h...
mcyoung.xyz/2025/07/16/h...
> The person who communicates best, becomes the programmer.
Senior devs get more from AI because they know how to explain complex ideas clearly.
They have years of experience communicating to teams of developers. THAT, translates well to working with AI.
youtu.be/8rABwKRsec4?...
Senior devs get more from AI because they know how to explain complex ideas clearly.
They have years of experience communicating to teams of developers. THAT, translates well to working with AI.
youtu.be/8rABwKRsec4?...
July 12, 2025 at 4:59 PM
> The person who communicates best, becomes the programmer.
Senior devs get more from AI because they know how to explain complex ideas clearly.
They have years of experience communicating to teams of developers. THAT, translates well to working with AI.
youtu.be/8rABwKRsec4?...
Senior devs get more from AI because they know how to explain complex ideas clearly.
They have years of experience communicating to teams of developers. THAT, translates well to working with AI.
youtu.be/8rABwKRsec4?...
- Working in a mono repo
- Linters and Generators take 15 minutes to complete
Do not do this
The amount of developer time wasted is not greater or equal to the convenience gained from the generated code.
- Linters and Generators take 15 minutes to complete
Do not do this
The amount of developer time wasted is not greater or equal to the convenience gained from the generated code.
July 11, 2025 at 1:21 AM
- Working in a mono repo
- Linters and Generators take 15 minutes to complete
Do not do this
The amount of developer time wasted is not greater or equal to the convenience gained from the generated code.
- Linters and Generators take 15 minutes to complete
Do not do this
The amount of developer time wasted is not greater or equal to the convenience gained from the generated code.