Traits of a 10x engineer

Build your own Interpreter

CodeCrafters launched a super interesting challenge on building your own interpreter. Give it a shot, it is free in beta. There are some other interesting challenges as well that you can explore like building your own SQLite, BitTorrent, and even Redis.

Sign up, get 40% off, and become a better engineer.

Three rules that helped me communicate better with engineers, leaders, and peers

We engineers are great at coding, but things get shaky when it comes to collaboration. Here are three simple rules I followed that helped me build trust with other engineers and teams

When I was leading horizontal teams - SRE and Data Engineering - at Unacademy, me and my team were known for Ownership, Execution, and Collaboration. This happened because of the three rules we followed

1. Always close the loop

The core of this is never to leave any discussion or thread open-ended. For example, if there was some bug to fix from our side, we made sure to follow up with the individual and confirm the resolution after the fix was pushed.

Even when some task was done on other platforms (say Github) and that auto notifies the user, we still ensured to close the Slack thread by putting the final message on it. This way, even if some leader was going through the Slack messages or threads, he/she needs to wonder about the current state.

2. Be humble, no matter what.

In a collaborative environment, it's essential to listen to others to understand their perspective. It is possible that we do not have all the answers or could extrapolate our understanding. So instead of being aggressive in defending our approach, we listened to what others had to say, discussed with them to understand their pain points, and then came up with an approach that worked for both of us.

We always patiently listened to them, and this led to us having a higher chance that they would take the approach we suggested, or at least be a relatively easier and minimal change on our end.

3. Do not make others follow up, ever

If someone is waiting for your input or action, it can make them anxious. So we ensured to be proactive in communicating the progress, the completion, the delays, and the blockers.

This kept everybody in the loop, made us operate with high ownership, and made the entire collaboration transparent and pleasant. The best thing, after seeing us operate this way, other teams reciprocated whenever they were working with us :)

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

Admissions for my August cohort are open

Admissions for my System Design August 2024 cohort are open, if you are SDE-2, SDE-3, and above and looking to build a rock-solid intuition to design any and every system, check out

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

?? Video I posted this week

This week I posted Internals, architecture, and interesting trade-offs of Blacksmith that runs GitHub Actions jobs 2x faster

This week I spent some time understanding and dissecting the architecture and internals of Blacksmith, which optimizes, almost any, CICD jobs and makes them 2x faster by changing the underlying hardware on which the job runs.

I compiled my learnings in a quick video and going through the video will make you understand the importance of picking the right hardware and choosing the right trade-off.

ps: Nodejs build times reduced from 180m to 90m ??

?? Paper I read this week

This week I spent reading Intelligent Scaling in Amazon Redshift

This week I am reading a research paper by Amazon about how they scale Redshift. Here's a quick gist from my first skim ?

The paper is all about a system they built called RAIS – which utilizes machine learning to optimally provision the resources and automate the scaling up and down of Redshit's underlying infrastructure.

By the way, the paper also has some maths in it. I am skipping that, for obvious reasons. But other than that the first skim was pretty awesome. One thing I loved about this paper is the time it spends in making us understand the problem and the constraints to play with.

Give it a read if the topic seems interesting or if the database and data system domain amuse you. The paper will definitely make you think deeply about the systems you work with.

You can download this and other papers I recommend from my papershelf.

Traits of 10x engineers

10x engineers are not 10x because they built a complex system; they are 10x because they almost always tend to find simple, stable, and manageable solutions to complex problems. To become one,

1. operate with extreme ownership
2. be curious with a high bias for action
3. be a problem solver and not a complainer
4. do not remain confined to some syllabus or curriculum
5. have an innate passion for the domain you are operating in
6. and most importantly understand business >> product >> engineering

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.

• PostgreSQL and UUID as primary key
• Do Grayscale Images Take Less Space?
• A write-ahead log is not a universal part of durability

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.