Explore with Aadi

Explore with Aadi

Lessons from my first software engineering job.

Lessons from my first software engineering job.

My name is Aditya and I am a College dropout currently building the future of commerce at Plaza with some really smart and driven people. I got my first job amidst the pandemic in 2020. Link to my full story.

Now moving on, I will share some rules that I developed during my first job to accelerate my growth. I will also share some of the screw-ups that I did which led me to develop these rules.

Rule #1: Minimize the work of your seniors

I decided to follow my tech lead around on each of his tasks. Whenever he had a bug or a small feature for which he needed to do some digging, I used to take that up and ask him to continue with more important tasks. This constant need to save his time made me better at googling and coming up with solutions faster, which was exactly what I wanted.

Rule #2: Learn from others code

Every morning, I'd go through each of the JIRA tickets and then the PRs raised and understand the code. If there were too many, I'd go through the rest of them in the evening. This helped me understand the mistakes I was making in my code (since everyone else was more experienced than me) and also helped me understand the entire flow of the app in a much better way. Later on, I became so good that often I could guess the exact piece of code that caused a particular bug among 30+ components and many sub-components.

Rule #3: A framework to save time

My tech lead gave me this very good framework. He asked me to reach out to him if I was working on a bug and couldn't fix it in < 2 hours or working on a feature and couldn't figure out how to go about it within an hour. Since it was a startup, we couldn't afford to lose any more time than that but even in such a constrained environment, he gave me enough freedom to tinker on my own and come up with solutions faster.

Rule #4: Have your own north star

The team and especially my tech lead started relying more on me and let me wrap up many of the small features by myself end-to-end hence I had to come up with this rule so that I don't screw up the chances I was given. I had to start thinking about the overall app and how my changes would affect the end-user experience instead of just worrying about the code quality. As a Front-end Developer, I made the UX my north star instead of obsessing over best practices because making the correct trade-offs would've been very difficult if I didn't. Yes, I was still writing quality code (because any PR with a below A-rating would fail) but that was not my top priority.

These were the four rules that I developed with the help of my seniors and after a lot of trials and error. One day while resolving code conflicts, I almost reverted the code for an entire feature pushed by my senior but somehow survived. On some days, I'd even push the console log and debugger in my PRs and my tech lead would just laugh at these silly mistakes. I still remember when I got my first feature request after ~2 months of hard-ass effort and I just went ahead and copy-pasted most of the code for that feature from google without understanding it much and somehow it worked but I was lucky to have a kind and helpful tech lead who helped me get better and never got angry even once despite me blowing up the code left and right many times. There is a lesson too in this story that if you are early in your career then look for companies that have helpful seniors instead of just a fat package (luckily enough, most companies with good devs have good packages but not always).

Hope you got something out of this article, may your day be bug-free :)

Share this