I am Gaurav.

If you have read the `Alamanack of Naval Ravikant`, then you must have come across this famous quote ``` It doesn't take money to make money, it takes leverage to make money. ``` Retaining something after reading something is just as important and somehow, this quote along with few other quotes of his, has stuck with me. I have found real life examples of this playing out so many times that it's astounding that most people don't use this often. In this blog, I will try to show how building leverage can help you in your career. We will do that by going through a few real life examples with details changed and then we will regroup to collect our thoughts. Here we go. ## Example 1 - Amy Amy, 19 yo, is studying humanities in Delhi University, one of the best colleges of Delhi University, India. She feels something is missing and she has always liked programming, so she decides to pursue programming again. She fiddles around with some tools and then she discovers WebAssembly(WA). For some reason, she loves the idea of WA and decides to build something on top of it. She learns Rust, builds a few examples and decides that the ecosystem is still too unstable. Instead of setting it aside, she decides that she can fix those issues and she starts contributing regularly to the WA source code. She is 22 now and has been regularly pushing patches to the WA source code. Mozilla takes note of her contributions as they are also building in the same space and decides to hire her. They offer her a job and she accepts the offer since it means that she will be getting paid to do the same work, but from inside the company, and maybe also help the company out. She joins as a SDE-1 and based on her continuous contributions, she is able to become an important member of the team and she is promoted to SDE-2 within 6 months. At the age of 24, she becomes one of the maintainers of the project. Google takes note of her and offers to hire her. She notices that the pay and position are both better than the current one at Mozilla. She decides to leave, but Mozilla can't afford to let her resign. They immediately give her a Senior Software Engineer equivalent role. At the age of 25, she is promoted to Staff Engineer and is one of the youngest engineers to become a Staff Engineer at one of the reputed companies. For reference, Staff Engineers at reputed companies usually have a pay ranging between Rs 1.5-2.3 crores. ## Example 2 - Barry Barry, 29 is working as a Senior Software Engineer in Coinbase on crypto payments. Elon wants people to buy Teslas using DOGE coin and everybody starts going crazy in buying cryptocurrencies. Coinbase's database, Postgres is unable to handle the tremendous load and things start failing. Barry, along with a team of few other folks, offers to help fix these issues as he has some experience with a database. He, along with his team of just 3 engineers, are able to partition and scale the entire Postgres database in a year to handle Coinbase's growing popularity. Barry is immediately promoted to the position of Staff Engineer. New teams come up with less experience in database systems, so Barry offers to help them build a data layer for the product teams to use so that they don't have to deal with the database directly. This helps Coinbase in building products faster and with more resiliency. The database team, which was almost non-existent 1.5 years back, has now grown to a team of 20 engineers. Barry is promoted to Senior Staff Engineer at the age of 31. ## Example 3 - Dhruv Dhruv joins a small startup right out of his tier-3 college. Dhruv is the 11th person to join the company. Dhruv, since he is just out of college, doesn't know a lot of things, but is willing to work on almost everything. He learns backend, frontend and everything under the Sun, wherever help is required. As his breadth of experience grows and he becomes accustomed to working with senior folks, he is able to now make decisions since he has more breadth than the original founding engineers. The company grows to 50 engineers and Dhruv is promoted to be the team lead for his vertical at the age of 25. His vertical becomes a scale bottleneck, but also the money earner. He spends time in understanding how to scale both the team and the code, and with much experimentation, he is able to achieve it. In the meantime, he is now the lead for a 40 member team and is promoted to Director of Engineering. The company raises multiple rounds of investment during his tenure and his stock portfolio has grown above 30 crores. The next few years, he spends time in building his social media community and promotes the company in his channels. The company is acquired and he gets a Rs 70 crore payout and a huge social media following, which he leverages to build new products in his own company now. ## Let's regroup All the folks listed in the above examples have had different backgrounds, different goals and different starting points when their career started to fly. What's the common point between all of their stories? Let's change a few minor things in their stories and see how it would turned out otherwise. If Amy, after getting the offer from Mozilla, had decided to stop working on WebAssembly, Google wouldn't have made her the offer and she would not have been promoted within Mozilla to Staff Engineer. Her persistence with WebAssembly, a growing area of interest in multiple companies helped her gain leverage over her company allowing her to get promoted much earlier compared to many of her colleagues and seniors. If Barry wouldn't have offered to help build the database layer, even though he was a Web3 engineer, he would have had a similar trajectory as his peers and wouldn't have become the Senior Staff Engineer, which many people don't achieve in their entire careers as well. If Dhruv had decided to stop learning and not increase his breadth of experience and would have relied on his seniors to just do what he was told, he wouldn't have been able to gather the experience required to run his team and wouldn't have been promoted to Director of Engineering. ## What if it didn't work out? All the above examples are positive cases, or the happy path as we call it. It also had the potential of turning out to be a negative scenario. For example, if the company decided that they no longer want to improve WebAssembly and Amy still kept working on it, then she wouldn't have gotten the double promotion in a short time. If the tool she was focussing on didn't have takers outside Mozilla, then Google wouldn't have hired her as well. If Barry had scaled the Postgres layer but the company decided to leverage a cloud database instead of managing it in-house, then the entire year would have gone to waste for Barry without much leverage. If the startup Dhruv was working in didn't do well and didn't find funding, then there would have been a salary cut or firing and Dhruv wouldn't have had the exponential rise as well. ## What to look out for? ### Industry Norms When Barry was scaling the database layer, there were not a lot of options apart from AWS RDS and they too didn't have that big of a customer base that could immediately solve the problem. So what Barry built was definitely a niche use case that you wouldn't find generally and was tailor made for Coinbase, which meant that Coinbase wouldn't be able to just swap the data layer out. ### Funding This is similar to what companies face as well. But if the problem that you are solving is not a money maker for the company resulting in significant earnings either directly or indirectly, then it may not be a problem worth solving. For example, if the database layer wasn't resulting in customer churn for Coinbase, then it wouldn't have recognised Barry's efforts and rewarded him. ``` To fix something, identifying it is broken is paramount. ``` ### Direction Does this align with the company's long term vision? Dhruv could try to increase his breadth in a bigger company all he wants, but it would not be rewarded in the same manner. The bigger company already has the ability to hire more people for specific tasks and having a generalist may not be that big of a win most of the times. On the other hand, a startup cannot afford to hire so many people and the more breadth you build, the faster you can leverage it. The common point behind all these stories is Leverage. Leverage comes in different shapes and sizes. Identifying them is the main path to win in your career. The power to force uncommon events because that event is more important than the routine flow of nature. Different people have different points of strength. It just takes time and effort to build on this. Take the time to invest in yourself, and build leverage in your life.

So it's been a week since I have been trying to use and compare AI code editors and tools extensively to integrate into my coding routine. Claude Code has been the most successful, but it's way too expensive compared to Cursor or Windsurf. So Cursor is the winner here. The judgement was based on the ability to convert my markdown based blog to a NextJS application with search and firebase functionality. It was able to provide elaborate steps on converting markdown to HTML, creating the right routes, changing the theme of the website, and so much more. One major complaint that I have with this type of development is that you don't own any part of the app. It's all owned by the tool. So even if you have worked on the app for sometime, chances are that you would still not know a lot of things about the codebase. So the incremental pace and value that you pick up as you grow with a codebase is going to decrease even further since changes are going to come way faster than you can absorb it. In so many places, the AI tends to take shortcuts to reach the end goal. One major flaw was the most of the tools tried to disable type checks completely for the app since it was unable to fix the problem. In other cases, for few problems, it tends to make the problem even worse by getting into a loopy state.