Working for the last few years has been quite an experience. And by experience, I mean “how did I survive this?”

Growing up and learning how to build a routine around an 8-hour job, finding time for hobbies, and maintaining a social life is like trying to juggle while riding a unicycle. Blindfolded. But hey, if you genuinely enjoy where you spend the main 8 hours of your day, it gets a little easier.

My time at college had been pretty fast and hectic. Having done multiple open source work with GSoC and MLH, I had gotten used to the rhythm. I could not wait to ride the wave out and start working as soon as possible. But as it usually goes with life, COVID was right around the corner and the entire world was about to shut down for a while. Lucky for me, by this time I had already found an opportunity to work at a fully remote startup, and I practically sprang to take a shot at it.

Looking back, it’s nice to see how much ground I’ve covered - from someone who had never touched anything platform related to building complex frontend architectures, the journey has been filled with a lot of “oh no” moments, and countless “aha” moments.

Here’s everything I learnt in my 3.5 years at Phaidra:

Working in a big vs small company

Before Phaidra, I worked at Oracle - think well-oiled machine with clear structures and hierarchies.

Going from structure to a startup was an amazing experience.

First off, working for a startup teaches you a LOT in very little time, you learn about how architectural decisions are made, just how important documentation is, how smaller components are all delicate pieces of a functional larger picture, and the importance of logging - especially for debugging. A lot of these skills transfer to larger companies, but the major plus side of a startup is that when you’re one of the first few, you genuinely build a top level understanding for how everything works.

I joined Phaidra as an engineer for the product team, but spent the first six months learning python and its relevant coding practices. I had never actually known the platform side of tech, and everything seemed daunting. It’s crazy to think that I’d never thought of this before, but now that the browser is out of the picture - how does one service talk to another? Oh, that’s where remote procedure calls come into the picture.

And so, the six months passed learning how the world outside browsers work.

My 3 big(ger) lessons

In 2022, I finally joined the product team, all excited to finally work on something that has a user interface. This was pretty much my first step into the world of React, one that I am grateful to be a part of. From there on, the next two years have only been more learning -

  • The importance of making design decisions when you build something from scratch is crucial when you’re planning to make things functional long-term.
  • Decisions need to be made in a way that it would stay easier to overhaul or change legacy code in the future. As much as one can wish for this, there’s only so much that stays relevant as time passes on (doesn’t mean you don’t try).
  • Every few months, you’d have a dependency upgrade, and ignoring it is a short lived bliss till they slap you with breaking changes and now the entire code across 5 apps need to be updated ASAP.

While all this sounds hard to keep track of, luckily, I was always surrounded with very helpful seniors.

One of the most useful things I learnt was building a proper design library to leverage usage of smaller components across multiple apps and have the visuals stay consistent. Not only does it ensure correct branding, it also adds miles for testing because you don’t need to test the component across all multiple app usages. Oh, and not to forget the magic that Redux brings to a large app that needs to share state across different components, the seamless deployment of a Next.js app using Vercel and how easy it is to use a CMS for a blog platform.

Recent changes

In the last few months, some of the best discussions I’ve had have been about testing strategies and code maintainability.

When you work in a fast paced environment, it’s easy to prioritize some things over another - often deadlines over long discussions. But the one thing this has taught me is that while everything is a balance - pace and velocity can never come above code maintainability.

As a company grows and scales, not only should your work be easy to debug, but it should also be easy to understand, a newcomer should be able to read it and intuitively understand the logic behind it.

And that’s something I have only now started thinking about before submitting my PRs, the slow process of making intentional decisions on how to structure and place each part of the code.

It’s been wonderful to finally adopt a strategy where you think before writing up a solution, something that we often forget to unlearn.

Finally

These lessons have shaped my approach to development - from rushing to implement features to thoughtfully architecting solutions, I’ve learned to value clean and intuitive code that others can easily understand and maintain (KISS - Keep it simple, stupid as they say).

The last three years have been a lot of trial and error, and experimentation and learning, till I finally hit the jackpot. I can only hope that I’ll continue to use these lessons in my own personal growth.