Learn the differences between TAM, SAM, and SOM, and why they are essential for defining your market size. A must-read guide for entrepreneurs and startups crafting a winning business strategy.

Learn why avoiding deeply nested code is a key clean code practice in Coding. Discover simple tips like returning early and using guard clauses to make your code easier to read, maintain, and debug. Clean up your code with this easy-to-follow guide!

Explore the power of TypeScript's type assertion to ensure robust type safety within your projects. Enhance code readability and maintainability effortlessly.

I know you are always confused with any VS uknown in typescript.

Naming conventions, also known as code nomenclature or coding conventions, are important in software development for several reasons: Readability, Maintainability, Code Reusability, Consistency, Documentations, and Scalability. Here we shall discuss some naming conventions I follow and recommend so that the next time you are writing new types it’s easier for you to name them.

Ordinal suffix number format is a way of writing numbers that indicates their position in a sequence, such as first, second, third, etc. This format is commonly used in writing dates, ranks, and other similar contexts.

How to prefetch React Lazy components or pages so that your page transitions are as smooth and fast as possible. This blog is in continuation of my earlier blog about Energetic React Lazy, where I discussed about code splitting and how you can use React Lazy to make your app lighter and faster.

You might have heard about React lazy and suspense before, but might never have felt the energies ⚡️ it has, I don’t know why is it called lazy why not energy or maybe flash, I guess it’s called as lazy since it lazily loads something 🤔.

Code Reviews have been an integral part of Software Development Lifecycle, but lately this topic has been missing from our engineering books. This document covers some aspects of why we review code, how we should review code etc.

Component structures are very unopinionated in terms of how they receive data - is it via props, or do they handle their own data/business logic? How your components are designed largely decide the fate of our application, onto how people are going to reuse the components, are they actually reusable or not, how much of a refactor does a component require before plugging in, how easier is it to plug the component and just use it.