It's Not Enough to be Right; Learn to be Heard
Once you're in the system and thinking deeply, you'll start to notice inefficiencies and gaps. You might see decisions being made that feel wrong. But instead of putting your point across bluntly, it'
This edition of the newsletter contains
Btw, enrollments are open for my Systems Design October cohort (sessions start 11th Oct). If you'd like to dig deeper into systems, their implementation, and how to design them the way they actually run in production, check out:
The course is completely no-fluff and packed with brainstorming and discussions that will shape your thought process and intuition. You'll feel like you're part of a real technical discussion happening at your workplace.
It's Not Enough to be Right; Learn to be Heard
Once you're in the system and thinking deeply, you'll start to notice inefficiencies and gaps. You might see decisions being made that feel wrong. But instead of putting your point across bluntly, it's important to raise it thoughtfully.
What I've learned over the last decade is that tone often matters more than the content, at least at first. Challenge decisions, yes, but do it with kindness and clarity.
Don't assume others missed something; assume they had different inputs. Frame your suggestions as additions, not corrections. It changes how they're received.
When offering feedback or questioning a choice, be mild in tone but sharp in your reasoning. That sharpness must come from preparation; your suggestions should rest on data, not vibes. Here’s what “doing your homework” looks like:
understand the context and constraints
explore alternatives and their trade-offs
anticipate counter-arguments and prepare responses
cite metrics, issues, or past incidents
keep it brief but loaded with substance
state assumptions and ask clarifying questions
tie your suggestion back to team or product goals
This detailing builds trust. Over time, your feedback won't just be heard, it'll be sought. You'll be known as someone who elevates discussions, not derails them.
The goal isn't to "win" arguments; it's to move the team forward, together.
By the way,
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.
Here's a video from me
I published a video - How to Implement Vertical Sharding
Vertical sharding is feasible, but how can it be effectively implemented?
In vertical sharding, we distribute the tables across multiple database servers. For example, keeping all the payment-related tables in one database server, and all the auth-related tables in another.
In this video, we take an in-depth look, not at the theoretical side of vertical sharding, but at the implementation side of it. We will see how Vertical Sharding is implemented with minimal downtime and what the exact steps are to do it.
Here's a paper I recently read
I spent some time reading Web-scale extraction of structured data
The web is unstructured, and the value lies in extracting the implicit structure, indexing it, and making it a web-scale knowledge base.
Some time back, I read a 2008 paper from Google talking about how they extracted structured data from this unstructured mess, as free text, HTML tables, and deep-web (not dark) databases hidden behind forms.
The paper talks about multiple systems - TextRunner, WebTables, and the Deep-Web surfacing engine.
TextRunner processes and extracts information from unstructured text. It doesn't start with schemas; it discovers relations on the fly, purely from frequency patterns. WebTables processes HTML tables and makes them indexable.
The deep-web surfacer learns minimal sets of useful form submissions to process and fetch large hidden databases without consuming too much of the crawler resources.
If you like information extraction or large-scale search infrastructure, this paper will ground you in what it takes to operate at the full scale of the Web.
You can download this and other papers I recommend from my papershelf.
Three interesting articles I read
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.
Hi Arpit, I'm not able to access your website.