How to Find and Ride the Next Tech Wave

This edition of the newsletter contains

• one quick write-up that will help you grow faster in your career
• a video I posted
• a paper I read

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 April cohort are open, and about 52 seats left. 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 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. 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

How to Find and Ride the Next Tech Wave

Whenever there is a new wave in tech, you will find two camps.

1. optimists - seeing it as a profound change
2. pessimists - seeing it would collapse or prefer the old way

You will often face a key dilemma - exploration vs exploitation, implying to either leverage your existing expertise to go deeper or start afresh and embrace the new.

This is currently happening with LLMs, where a bunch of engineers are trying to switch the domains to ML. But, should you do it?

Both paths come with risks. Constantly changing domains prevents you from building the momentum needed to make a meaningful impact. On the other hand, staying too long in one area without evolving can lead to stagnation, eventually diminishing your relevance.

The answer lies, like almost always, in balancing exploration and exploitation - understanding when to dig deeper into your strengths and when to pivot toward new opportunities.

Here's a practical mindset - be aware of everything happening around you, but watch for substantial shifts. When it's clear that things have meaningfully evolved, do not hesitate to jump on the bandwagon.

When you see some stability in the new, clinging to legacy approaches does not make sense, and that is where you should try to jump to the new and see how it pans out.

As engineers, our curiosity and willingness to learn are some of our greatest assets. So, be adaptable to stay ahead and prolong your career.

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 the video I posted

I published a video - How to safely and gracefully handle timeouts in a microservices

Handling timeouts well is extremely critical as it makes your distributed system robust and ensures you provide a consistent user experience by adhering to SLA guarantees.

In this video, I have covered how a synchronous dependency on a microservice leads to long delays becoming a big problem, understand how timeout addresses the concern, and discuss 5 approaches to handle service timeouts.

Paper I read and would highly recommend

I spent some time reading How to Break Software

Breaking software is fun! and to understand this better, this weekend, I would recommend reading a super simple paper from Google titled "How to Break Software".

The paper documents systematic testing techniques that make it easy to find bugs in software. This paper is a crash course, literally a checklist, of the kind of things you should test while building a product. The paper covers three main categories of "attacks" -

• input/output: boundary conditions and unusual input
• data - corrupting stored values, overflowing buffers, etc
• computation - operand mismatches, feature interactions, etc.

To get the most out of this paper, absorb the patterns, make a list (in your context), and share it with your team at the workplace. The patterns shared in the paper are still relevant today :) things haven't changed much.

The paper is a pretty short one, but highly relevant to every single engineer out there, and it is definitely an easy weekend read.

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 would recommend you to read.

• You can make Postgres scale
• In S3 simplicity is table stakes
• Were multiple return values Go's biggest mistake?

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.