I joined Underdog Protocol as a developer in October 2023, after attending the Solana HackerHouses in Bangalore and Mumbai. Before that, I had worked on a contract basis and as a mentee under the LFX Mentorship throughout the year.

This blog is about how my thought process changed in the 3 months of starting my job. It's an unstructured outpour of my thoughts.

Build for Enterprises

I've built projects aimed at general users and developers. My approach to any problem would initiate a thought process with "How can this benefit/work for me?" in an individual capacity, for example, billing, I'd prefer project-based billing. My thought process would be "I'll pay for the specific projects I want and that's it". Supabase switched to org-based billing this year and I was annoyed at it because again, I'll pay for the projects I want. Underdog had org-based billing when I joined.

There was a bigger picture to this that I had yet to see. Org-based billing is preferred by enterprise and institutional users where there's more than one developer. It helps them have a single abstraction on their usage and billing I assume there are more things as well. The service provider can also structure their offered services to allow n number of projects under a plan for an org, team usage, and much more.

Rather than catering to individual devs, build for enterprises. Think of what you'd prefer if you were at an enterprise level looking to use a service. If you cannot/fall short, talk to someone who has already built, is building, or at an enterprise user.

Learn Testing

I cannot stress how important testing is. Not giving it enough emphasis during my college days is a regret. At Underdog, every function, service, and module has a test. The code is thoroughly unit-tested, reviewed, and then deployed. When I started working on the codebase initially, it was challenging for me to navigate the codebase and find and work on things. I opened the code and rammed my head straight through trying to understand it and work on it, expecting comments/docs to understand what the code does. I didn't bother looking at the tests.

But hey, there are unit tests to test what the code does. So, I could've just looked at the tests to figure out what the code did. I started by looking at what gets triggered when an API call happens to our services and working my way downward to find its core logic and work on it.

I managed to implement the first functionality assigned to me this way and made a PR. I was happy and confident my code worked and it'll get merged easily. The first question asked during my PR review was "Where's the test?". I had to write a test for the functionality I had added.

I had never written tests for my projects in the past, guilty as charged, it had bit me back. I opened the tests, understood them, worked my way through, and wrote tests for my work.

Had I focused on tests earlier, it'd have been easier for me to work and my colleagues to review. If you're reading this, as painful as it might be, write those damm tests.

Don't Reinvent UX, Study Others

While working on Passport, which is a service to facilitate wallet-less NFTs, we were working on adding email UI/UX to it. I had the liberty to design the UI, so as a dev, I did what was easy and fast at the beginning. As things progressed, I realized that the intended users for this service are primarily non-devs, with a mental model of email services.

The UX I had in place did the job, however, it didn't quite fit the mental model of an email UX the users will have in mind. I took some feedback from the non-dev friends to confirm this. Now I had to re-engineer the UX. This time, I opened popular email services studied their UX, and implemented a UX that'll maintain the mental model users have when they hear email.

Understand the Problem at Hand

Understand the problem at hand before jumping into solutions. I'm guilty of this, and it's a habit of mine where I partially understand a problem, jump into writing code, take a step back when a roadblock is hit, and understand the actual problem at then solve it.

While understanding the problem, I simultaneously start thinking about possible solutions and get the excitement to start implementing, however, lately, this dopamine rush has been trouble causing.

A simple strategy I've devised to tackle this is to:
- write the problem
- try to explain it to a 5-year-old

This has helped me calm my nerves and focus better.

Don't Overengineer

In the past, for my projects, I've designed to handle a scale of millions but failed to get even 50 users for my app. This repetitive pattern, when implemented in a complex codebase, causes complex overengineering with multiple levels of abstraction.

I'm not saying building for scale is bad, I love thinking about how systems and code are built & maintained at a big scale. But complex doesn't mean scalable and maintainable.

The solution I found to this was:
- Learning about clean code principles
- Discussing my thoughts and solutions with peers and getting feedback

Don't Overdocument, Rewrite

This AVL Tree code I wrote in 2020, has comment explanations for everything. I religiously comment and document all of my code till date and expect a similar level of documentation. It frustrates me when code doesn't have comments for everything to spoonfed me. This has also been a barrier for me to work on open-source codebases.

Why is the code overdocumented? Because it's not readable.
Why is it not readable? Because I'm not aware of the practices toward it.
What's the solution to this? Learn how to write clean code

So now I'm reading a book on how to write clean code. The book hit me like a truck. I make all of the rookie mistakes mentioned in it. Comments are great wherever they're helpful, but they're not compensation for bad code.

I now try to write code that follows a good set of clean code practices and refactor until I'm satisfied with the code or frustrated enough to not give a damm about it.

Conclusion

The year has been full of learning. These are the most recent and I feel will be impactful. I'm grateful for the team at Underdog Protocol for my immense growth in the past 3 months.

This blog aims to be a checkpoint as I learn, upskill, and progress ahead. When will the next version be out you wonder? When I have enough points to span in a blog.

Hit me up on Twitter/X to talk about anything tech.