Engineer or Manager? How to Decide Your Path
Why are managers even needed if they are not coding? are they supposed to code? why are they paid so much? And more importantly, should you become a manager or not? This is pretty common to wonder, es
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. 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
Engineer or Manager? How to Decide Your Path
Why are managers even needed if they are not coding? are they supposed to code? why are they paid so much? And more importantly, should you become a manager or not? This is pretty common to wonder, especially as early engineers. Here are a few pointers from my experience
The bulk of the work a manager puts in is abstract and super difficult to quantify. This gives an illusion that the manager is "not doing anything". To ensure a significant impact and the outcome of the team, a manager needs to do at least three things really well
prioritize the right projects,
track the right metrics, and
reward the right people
Given that managers hold the authority on the execution and are accountable to the team, they need to be right a lot. This sounds easy, but it is not.
Managers need to have the right technical acumen, some technical know-how, and the right gut feeling to make the right decisions across design, engineering, product, and business.
When I was a manager, I was under constant pressure to deliver things, to make sure the right projects were picked up, and to ensure all engineers (and managers) had enough impactful work on their plate and were getting recognized and rewarded.
I could not cut some slack because the career growth of my team was my responsibility, and making sure it happened was all on me. So, if you are in a dilemma, you should become a manager if
you prefer mentoring people
you want to make sure people grow
you are patient, observant, and a good listener
you can get people excited to chase a goal
you communicate well
you are organized and have an urge to keep things in check
Let me get this straight: whether managers should code or not is either a personal or organizational preference. In the end, what matters is the impact and outcome the person is making.
But one thing I can tell is that if you choose to become a manager, be ready to spend a ton of time with others. :)
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 do indexes make databases read faster?
We all want our databases to operate efficiently, and having the right set of indexes is one of the first things we do. But how do these indexes make the query execution faster?
Here's the video about how the data is stored on the disk, how indexes are structured, serialized, and stored, and how required data is quickly read using the indexes.
Paper I read and would highly recommend
I spent some time reading Web Search for a Planet: The Google Cluster Architecture
This weekend, I would recommend you to read a 2003 paper from Google, where they discussed their early cluster architecture and how it laid the foundation for large-scale, cost-effective search infrastructure.
The paper is quite short, and the best way to read this paper is to do a DFS when you find something new. Most concepts that were new are kind of normal today, but still, it is a good weekend read.
It covers what it takes to build distributed systems at scale, like aggressive parallelization, replication for fault tolerance, and a focus on price-performance trade-offs.
But more than that, the paper offers insights into the architectural intuition behind those choices, and this will help you understand why a system is built a certain way.
Some key design decisions that were taken back in 2003 were around
prioritizing throughput, fault tolerance, and cost-effectiveness
utilizing commodity hardware
ensuring software-level reliability and achieving scalability
parallelization of queries through sharding
how to keep latency predictable
when and how to focus on price performance over peak performance
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.
Well said and written