Premature Abstractions

This edition of the newsletter contains two quick write-ups about

• Quantify and show impact, whenever and wherever possible
• Premature Abstractions

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 August cohort are open, only 8 seats are left, and the course starts next weekend. 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

Quantify and show impact, whenever and wherever possible

One of the most common lines I find in resumes is "Implemented features and bugfixes", but this line adds zero value because it is vague and it tells the hiring manager absolutely nothing about the impact of your work; literally any engineer could have added this line to their resume and it still would have made sense.

It is important to showcase real-world outputs and outcomes in your resume and this is best done by quantifying the outcome of your work. Two simple templates that you can leverage -

• improved X by Y%
• improved X by doing Z

Instead of writing "worked on recent searches", I write "improved CTR by 42% by implementing recent search feature". This is where I have shown the needle-moving impact of my work.

Even in the case of fixing a bug, you should quantify against the error it was causing, maybe the number of errors, the number of users impacted, or anything usecase specific - eg: reduced transaction failures by 80% by resolving issue X.

By the way, you should know your numbers, and if you don't ask your manager, or product manager, or refer to the monitoring tool.

Remember, the goal of quantification is not to inflate the achievements, but to accurately represent the value you bring to a table. By quantifying your impact, you're not only showing what you can do but why it matters. Thinking in numbers shifts your mindset and makes you think and focus on outcomes instead of outputs.

You can find this post on my LinkedIn and Twitter; do leave a like.

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.

?? Video I posted this week

This week I posted Why DragonflyDB uses B+ Trees to implement Sorted Set instead of Skiplist like Redis.

Redis uses a skip list to implement Sorted Set, but DragonflyDB switched their implementation to B+ Trees. I spent some time this week to understand the real reason behind this decision. Going into depth just changed the way I looked at Data structures and their implementations.

If you love DSA, you will absolutely love the video, and this is the real reason why DSA is such a practical and the most important subject for any engineer. Give it a watch

Premature Abstractions

Abstraction is a fundamental principle in software engineering, but premature abstraction does more harm than good.

Premature abstraction occurs when we create generalized solutions before fully understanding the specific problems we're solving. For example, starting to write the first implementation in a completely abstract way without even needing to write the second one, ever.

It's a trap to fall into, especially for those who take pride in writing "clean" and "elegant" code. They see patterns emerging in our early development stages and think, "Ahhh, I can abstract this into a reusable component!". But in most cases, you would never need to have the second implementation of the functionality.

The problem isn't that abstraction is bad. The issue arises when we abstract too early. Such implementation would lead to leaky abstraction that fails to encapsulate the complexity it was meant to hide. Four key problems with premature abstraction

1. makes code harder to understand
2. adds layers of indirection that make the code harder to navigate
3. makes you not trust your own subsequent changes to the codebase
4. adding a generic handler requires accounting for all possible cases, leading to unnecessary checks and operations.

It is important to resist the urge to abstract too early and here's what I do; I follow the principle of "Rule of Three" - the core idea is to wait until there are at least three concrete implementations before attempting to abstract.

This ensures that I have abstracted the implementation only after having a deeper understanding of the commonalities and differences between various use cases. Here are the four things I stick to while building large applications,

1. implement solutions for specific use cases first
2. don't try to solve problems you don't have yet
3. look for patterns that emerge naturally
4. refactor your existing code incrementally

Again, not saying to not use abstractions. They are great at hiding out complexities and making code extensible, but just nudging to create systems that can evolve and adapt over time rather than being overly complicated on day 0.

Remember, the goal of abstraction is to manage complexity, not to showcase our ability to write clever code.

You can find this post on my LinkedIn and Twitter; do leave a like.

?? 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.

• Revealing the Inner Structure of AWS Session Tokens
• Counting Bytes Faster Than You'd Think Possible
• Beyond Clean Code

Thank you so much for reading this edition of the newsletter ?? If you found it interesting, you will also love my courses

1. System Design Course for Beginners
2. System Design Course for SDE-2, SDE-3, and above
3. Redis Internals Course

I keep sharing no fluff stuff across my socials, so, if you resonate do give me a follow on Twitter, LinkedIn, YouTube, and GitHub.