Good Engineers Are Often Great Project Managers
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 ~22 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
Good Engineers Are Often Great Project Managers
Every role in engineering, regardless of seniority, demands organization. Whether managing a feature rollout or resolving production incidents, a structured approach ensures success and minimizes chaos.
Here's how I try to approach driving long and complex projects (like DiceDB). You can leverage pointers and apply them at your workplace. Every project must be estimated and weighted against returns. Always pick the most impactful ones requiring minimal effort.
A key to getting a project delivered
well-defined scope - what and why
well-defined outcome - clear metrics and deliverables
clarity in the schedule of delivery - timeline, and accountability
seamless communication - overcommunication >> silence
ownership of critical sections - clarity
A good engineer doesn't just write great code, they
manage their work like a project is maintained
works across the T shape to put it to completion.
follows timelines, breaks down tasks well
proactively identifies blockers and finds creative solutions
So, do not run away from project or management responsibilities, rather take them head-on. It is a great opportunity to make a bigger impact. This dual capability sets apart good engineers from great ones.
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 - What happens when ID column reaches its max value - Dissecting GitHub Outage
What happens when our ID column in databases hits its max value?
Does it throw an error? or will it circle back to negative? or will the database crash? Also, what if this happens in the production of a multi-billion dollar company?
Some time back, I dissected a GitHub outage where their ID column hit the maximum value in production. I have compiled my learnings and explained the inner workings in the video.
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 am 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.
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.