Uncle Ben once told Peter Parker, “With great power comes great responsibility”. This quote applies to fellow programmers who are involved in building projects. Being in the industry for over 5 years has made me reflect on my experiences so far, and it is time I give back to the community.

The Beginning

I started my career in a multi-national corporation, but I soon realized I wanted to work on more challenging roles with bigger responsibilities. And so, after a year, I joined a startup.

It was only a five-member dev team. It changed my outlook on development. I luckily found a great mentor and awesome teammates who helped me grow. But then again, we were a fast-paced company. To ensure delivery on time we often compromised on our code quality. We often assumed we would fix it in the end. So as we built the ship, we left loopholes. This led to tech debt, which was not a bad thing.

Never compromise on code quality

After some time, we gradually realized, that we won’t be able to scale anymore. So we decided to rewrite the whole codebase, which in turn took more time. But this eventually led to a good codebase, which was scalable and fun to work upon. I still remember we used to have a ‘shame folder in case any developer decided to write code they knew would create additional work later on.

This way we made ourselves accountable to maintain quality. But the lesson I learned was this:

Even if it takes a little more time to complete, we should take that time and write quality code for the future. Because of that extra effort we put in, we saved a lot of time and money.

We solved the architectural problem, but then came the fun part: performance. When we built our project, we used a lot of libraries for speedy development. We felt our project had put on some weight. It needed a lot of exercises. To shed those extra pounds, we did some analysis and realized that we had a lot of unnecessary libraries. We could have built these libraries ourselves. And so we scraped those libraries and built our own. Great!! Our page was faster due to a smaller bundle size.

But the hunger for performance was not over. When you have built a project from scratch, that feeling of being a spartan slowly consumes you. The story can’t be over yet. We could be faster. Then it dawned upon us, we were still using libraries. What if we didn’t use any? The thrill of writing our own consumed us, so we did it. We built a project successfully with almost no libraries.

Always document and write code comments

Then came a twist to our story: the startup was eventually acquired. I was moved to a new team. The new members were more acquainted with libraries that exist in the market. Suddenly our codebase was alien to them. We indeed wrote our libraries, but we didn’t have enough time to document them. It created a huge gap. I learned the important lesson of documentation and code comments.

I realised code is not just about yourself. As an author, it is your duty to write for the masses.

So the moral is, it is not wrong to write your own libraries. But if you do, then documentation and code comments are a must. Anyone should be easily able to comprehend your library just by reading your docs. I can’t emphasize enough, don’t write for yourself! As a code reviewer and maintainer, it is your responsibility to ensure this.

Don’t reinvent the wheel, unless you ensure it is maintainable

As time passed by, I realized there was no point in reinventing the whole wheel. Unless we have a lot of time to develop and document the same so that it can be understood by all. If there is a library that exists and solves your problem, then it is a great idea to contribute to that specific project! There is a catch, and I would like to quote from Phil Walton’s blog:

Reinventing the wheel is bad for business, but it’s great for learning. You may be tempted to grab that typeahead widget or event delegation library from npm, but imagine how much more you’d learn by trying to build those things yourself.

So make your choice wisely ^_-

Always test your codebase

I can’t emphasize enough how important this is. Thanks to libraries like Jest and React testing library, and many others, testing code has never been easier. Often when the codebase becomes large, even a single line of change can cause the application to break. If our testing is automated, we can be confident about the changes we push.

Keep learning

I wanted my frontend development to be fast and performant. I finally decided to learn React, mostly because of the background I came from. I found it to be unopinionated, and writing it was very close to writing plain JavaScript. It changed my life for the better.

Libraries like React, Vue, Angular and various others (especially Redux) don’t just tell you how to build a fast UI. They also open doors to other concepts like functional programming, immutability, and many others, which actually helps you become better at your craft. Learning React and Redux enhanced what I already knew.

Conclusion

As I gained experience, I eventually joined another startup, where I was tasked to build products from scratch and eventually lay the foundation. But this time I was armed with all my experiences and mistakes. I am happy to say, I am proud of what I have built so far and I am sure I have a long way to go. The pursuit for perfection is a never-ending path, but we can always strive to walk the right path.

All the experiences I have mentioned are not meant to be the word of law. They are very specific to my journey in the industry. But I hope this will help you become a better developer, and I am always thankful to the community, who has helped me grow.

Follow me on twitter to get more updates regarding new articles and to stay updated in the latest frontend developments. Also, share this article on twitter to help others know about it. Sharing is caring ^_^.

Some helpful resources

  1. https://philipwalton.com/articles/how-to-become-a-great-front-end-engineer/
  2. https://jestjs.io/
  3. https://blog.kentcdodds.com/introducing-the-react-testing-library-e3a274307e65
  4. https://en.wikipedia.org/wiki/Technical_debt
  5. https://en.wikipedia.org/wiki/Software_entropy

My previous articles

  1. https://medium.freecodecamp.org/the-best-way-to-architect-your-redux-app-ad9bd16c8e2d
  2. https://medium.freecodecamp.org/how-to-use-redux-persist-when-migrating-your-states-a5dee16b5ead
  3. https://codeburst.io/redux-observable-to-the-rescue-b27f07406cf2
  4. https://codeburst.io/building-webapp-for-the-future-68d69054cbbd
  5. https://codeburst.io/cors-story-of-requesting-twice-85219da7172d
  6. https://blog.usejournal.com/what-i-learnt-from-reactfoo-2018-e4e1a4c6a705