This edition of the newsletter contains
I have also shared 3 super-interesting articles to read over the weekend. Thank you once again for reading this edition of my Newsletter. Now, without further ado, let’s jump right in.
By the way, the admissions for my System Design October cohort are open. If you are an SDE-2, SDE-3, or above, and looking to build a rock-solid intuition for designing any and every system, you will find my course extremely interesting.
Instead of drawing boxes, we go into the intricate details of every single system and build an end-to-end understanding. The learnings from the course can be applied at your workplace from day 1. If you're looking for genuine engineering discussions or brainstorming, be sure to check out my course.
Course curriculum and other key details: https://arpitbhayani.me/course
Not every mistake needs a correction.
Some folks take a little too much joy in proving others wrong. Sure, it can feel satisfying - especially when you're right. And yes, sometimes stepping in is the responsible thing to do.
But if you're constantly scanning for flaws and calling them out, you're not being helpful - you're just being exhausting. People remember how you made them feel far more than whether you were technically right.
Give others the benefit of the doubt. Maybe they missed something. Maybe they're just having a rough day. If it's not mission-critical, let it go. Kindness doesn’t mean staying silent - it means being intentional about how you speak.
If someone misses a small detail in a PR, nudge gently
If someone shares an idea that’s slightly off, don’t tear it down
If someone gets something wrong, help them understand without making a scene
If you're in a group setting, choose private correction over public shaming - always
When this nitpicking behavior becomes normalized, it starts shaping team culture - and not in a good way. In some orgs, it's even unintentionally incentivized.
People start optimizing for not being wrong instead of moving fast and learning. Everyone gets a little more defensive, a little more hesitant. Progress slows down - not because people aren’t smart, but because they’re too busy being careful.
Engineering is not a zero-sum game. You don’t win by pulling others down. You build influence by being the person others want to work with.
Be kind. You're not here to win arguments - you're here to build.
Being hands-on is the best way for you to learn. Practice interesting programming challenges like building your own BitTorrent client, Redis, DNS server, and even SQLite from scratch on CodeCrafters.
Sign up, and become a better engineer.
I published a video - Introduction to RPC - Remote Procedure Calls
What are RPCs, and why do they even exist?
Here is my detailed explainer video about Remote Procedure Calls, how and why they were conceptualized, where they fit in the architecture, and the steps you need to take to integrate them.
I also highlighted the significance of standardizing communication between services, irrespective of languages used, through RPCs, while also touching upon the concept of stubs gives us a seamless way to handle remote calls.
I spent some time reading Segcache: a memory-efficient and scalable in-memory key-value cache for small objects
In-memory caches are supposed to be memory-efficient and scalable under high-throughput workloads, and to leverage the learning as I continue to build DiceDB ...
Some time back, I revisited a 2021 paper from CMU and Twitter titled Segcache, which talks about what it takes to handle billions of small objects efficiently, while keeping latency low. The paper asks one question that challenges the absolute core: Do we really need to manage objects individually?
The entire paper revolves around sharing metadata, expiring keys in bulk, and reducing contention without losing fidelity. After my initial skim, a few details that stood out:
ttl-indexed segments allow bulk expiration without scans or lazy deletes
aggressively sharing metadata does not affect in any way
If you are interested in in-memory databases or data structures & optimizations in general, this paper will push your thinking. It's highly practical and backed by real production traces; a must-read.
You can download this and other papers I recommend from my papershelf.
I read a few engineering blogs almost every day, and here are the three articles I read and would recommend you read.
Thank you so much for reading this edition of the newsletter 🔮 If you found it interesting, you will also love my courses
I keep sharing no-fluff stuff across my socials, so if you resonate, do give me a follow on Twitter, LinkedIn, YouTube, and GitHub.
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.