It's not about what you know, but about how you think
This edition of the newsletter contains two quick write-ups about
I have also shared 3 super-interesting articles I read this week along with a paper that I am reading 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 and only 67 seats are left. So, if you are SDE-2, SDE-3, and above and looking to build a rock-solid intuition to design any and every system, you will find my course super interesting.
Instead of drawing boxes, we go into 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. So, if you are looking for some real engineering discussions, or brainstorming, do check out my course.
Course curriculum and other key details - https://arpitbhayani.me/course
It's not about what you know, but about how you think
I speak with many engineers (both senior and junior) daily and one question I get asked a lot is "How do I retain the things I am learning". My answer to that is simple ... I do not.
I have seen people while reading a book, complete a few pages and then try to recollect what they read. If you are one of them then by doing this, you are testing your recall and not understanding. To me, this is not the right metric to chase.
Whenever you are reading a new concept, focus on understanding the underlying pattern and the core concept instead of remembering the bullet points. But what if someone asked you something, shouldn't you thoroughly answer it?
Yes, you should. but thorough answers need not be bookish. If you have built an understanding, then there are three possible cases
Thus, even in the worst case, you are looking in the right direction and not being a headless chicken. Also, with the availability of note-taking apps, search engines, and even LLMs, we can offload the task of remembering to our devices; and we then are free to focus on understanding concepts, connecting the dots, and solving problems creatively.
In my experience, prioritizing understanding over memorization has the following benefits.
By the way, this doesn't mean that memory isn't important at all. There is a massive value in having a sharp memory but the point is to shift your focus from rote memorization to deep understanding. So, the next time you're learning ask yourself the following questions
Remember, It's not about what you know, but about how you think.
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.
?? Video I posted this week
This week I posted Everything about HTTP Streaming and how Airbnb leverages it in production
领英推荐
It is typically memory-intensive to send large responses over HTTP, but this can be optimized by using HTTP streaming. I just published a video covering everything about it and how Airbnb leverages it in production.
I have also covered the implementation nuances in the video, go give it a watch. By the way, you can also use this to build and implement LLM chat interfaces, where your backend server generates tokens and streams them to the client. Give it a watch.
?? Paper I read this week
This week I spent reading NanoLog: A Nanosecond Scale Logging System
7 nanoseconds is the median latency of NanoLog and it can write 80 million log messages every second ??
This week I am reading a paper NanoLog, from folks at Stanford, that talks about reduced logging latencies to mere nanoseconds. The best thing about the approach they took is instead of doing everything at runtime, they moved some aspects to compile time and some post-application execution.
The core insight that the NanoLog is based on is how fully formatted human-readable messages are not required in application code. This is so true and they leveraged this to build the fastest logging utility. By the way, the code is available on GitHub in case you want to take a look.
You can download this and other papers I recommend from my papershelf.
C in ACID is different from C in CAP
Most early engineers (in some cases even seniors) get confused with the word "consistency", but remember, Consistency in ACID is different from Consistency in CAP, here's a quick write-up to understand the difference.
ACID consistency is about the logical correctness of data within a single database and is enforced at transaction boundaries. CAP consistency is about the agreement of data across distributed nodes is about how real-time is the agreement across nodes.
So, ensuring that there are no blogs in the database whose author does not exist is ACID consistency; while ensuring that all the blogs are present across all the database nodes across all regions is CAP consistency.
You use NOT NULL, UNIQUE, and CHECK constraints to implement ACID consistency. On the other hand, you use replication, gossip, locks, and consensus protocols to achieve strong or eventual consistency across nodes.
So, given that the same word is used to describe both, it is important to understand the context in which the word is used.
?? Interesting articles I read this week
I read a few engineering blogs almost every single day, and here are the three articles I would recommend you to read.
Thank you so much for reading this edition of the newsletter ?? If you found it interesting, you will also love my courses
Tackling code complexity (Optimize CODE for NFRs) before layoffs can save 50-100% of jobs. The most brilliant cost-cutting measure you're not considering.
6 个月How it is applied is the real skill, as knowledge is too much out there..