Hello community!
I’ve been challenged to start the #100DayCodeChallenge, and guess what?! Challenge Accepted!! 
So, for the next 100 days, I’ll be sharing my knowledge, learning, and experiences.
Below is my progress from previous days, and I’ll now be updating regularly from today. If you’re up for it, join me on this adventure! 
Day 1 of #100DaysOfCode: Kicking Off with a To-Do List Web App! 
I’m thrilled to embark on this 100-day coding journey, starting with a project that’s close to my heart—an advanced To-Do List Web Application! 
This isn’t just any to-do list—it’s packed with features designed to enhance productivity while keeping things visually appealing:
Dynamic Task Management: Add, edit, delete, and mark tasks as complete.
Customizable Backgrounds: Switch between stunning background images, with automatic updates every minute.
Real-Time Progress Tracking: Visual stats and a progress bar to keep track of task completion.
Persistent Data: All tasks are saved locally, so you never lose your progress.
Day 2 of #100DaysOfCode:
Excited to share my latest project: Data Structures Quiz Master! 
As part of my ongoing coding journey, I created a quiz game designed to test and improve knowledge of essential data structures. This game is more than just a fun challenge—it’s a learning tool for anyone looking to sharpen their skills in computer science.
Tech Stack:
Key Features:
Whether you’re a student, a seasoned developer, or just someone curious about data structures, I hope this game provides both fun and valuable learning.
Feel free to give it a try and share your feedback. Let’s continue to learn and grow together! 
Day 3 of #100DaysOfCode:
Today, I deepened my understanding of GitHub, and I’m excited to share a key lesson: The Power of Branch Management!
In a collaborative project, effective branch management is essential for maintaining clean and efficient workflows. I’ve learned how to create, manage, and merge branches, allowing my team to work on different features simultaneously without conflicts. Here’s how it works:
Create a Branch: Each feature or fix gets its branch, keeping the main codebase stable.
Pull Requests: Merging changes through pull requests ensures that every contribution is reviewed and integrated smoothly.
Conflict Resolution: Handling merge conflicts has taught me the importance of frequent commits and communication within the team.
GitHub is more than just a code repository; it’s a powerful tool for collaboration and version control. Understanding these concepts has made me a more efficient developer, and I’m excited to continue building on these skills! 
To help others on their journey, I’ll leave you with some of the cheat sheets that I’ve used along the way. They’ve been invaluable in making GitHub feel more manageable and intuitive!
Day 4 of #100DaysOfCode: Embracing the Challenge of Imposter Syndrome
Today, I’m taking a moment to reflect on something many of us in the tech field experience—Imposter Syndrome. Even with years of experience and countless projects, there are days when self-doubt creeps in. But I’ve learned that these moments are an opportunity for growth. 
How I’m Tackling It:
Project Spotlight: Today, I tackled some complex issues in our KutubHub team website project—from refining the UI design to troubleshooting functionality across different pages. Working through these challenges reminded me of the power of persistence and teamwork. It’s inspiring to see how our collective effort is bringing this project to life.
Takeaway: Imposter Syndrome is a sign that you’re pushing your limits, and that’s something to be proud of. I’m embracing the journey, challenges and all, and I’m excited to see where it leads.
Day 5 of #100DaysOfCode: Unlocking the Potential of JavaScript Proxies
Today, I explored the fascinating world of JavaScript Proxies—a powerful feature that allows you to intercept and customize operations on objects. Proxies offer a unique way to handle dynamic behaviors, validation, and even debugging, all while keeping your code clean and maintainable.
One practical use case I experimented with is input validation. By using a Proxy, I was able to enforce data types and constraints directly at the object level, catching errors early and preventing invalid data from propagating through the system.
Another exciting application is creating virtual objects that simulate properties or methods, which can be incredibly useful in mock testing or implementing lazy loading.
JavaScript Proxies open up a whole new realm of possibilities for developers looking to write more flexible and dynamic code. Have you experimented with Proxies in your projects? Share your thoughts and experiences!
Day 6 of #100DaysOfCode: Reflecting on Leadership and Mentorship
Today, I had the privilege of leading and supporting a dedicated team. Leadership isn’t just about giving directions; it’s about empowering others, listening to their ideas, and helping them grow.
One of the most fulfilling aspects of this journey has been watching the team embrace challenges and achieve their goals.
The gratitude expressed by one of our team members reminded me of the importance of creating an environment where everyone feels valued and heard.
By fostering open communication and collaboration, we were able to tackle complex problems together, leading to innovative solutions. As a leader, I focused on providing guidance while giving team members the autonomy to explore and develop their own approaches.
This experience reaffirmed that leadership is a continuous journey of learning and growth. It’s about being adaptable, empathetic, and always striving to bring out the best in others.
I’m excited to carry these insights forward as we continue this journey together!
Day 7 of #100DaysOfCode: Deep Dive into CryptoJS and SHA-256 Hashing 
Today’s challenge led me to explore the CryptoJS library and its widely-used SHA-256 hashing function, a critical tool in modern web security.
What is CryptoJS?
CryptoJS is a JavaScript library that provides simple yet powerful cryptographic algorithms, including encryption, decryption, and hashing. It’s widely used to secure web applications by protecting sensitive data like passwords, API tokens, and digital signatures.
Given the growing concerns over data breaches and privacy, understanding and implementing strong cryptographic techniques is essential for every developer.
Why SHA-256?
SHA-256 is part of the SHA-2 (Secure Hash Algorithm 2) family, developed by the NSA. It’s one of the most commonly used hashing algorithms, trusted for its balance of speed and security. The function takes an input of any length and produces a unique, fixed-size 256-bit hash.
Hashing is a one-way function, meaning once data is hashed, it cannot be converted back to its original form, ensuring its integrity.
Key Learning:
Even the smallest change in the input creates a completely different hash, making it nearly impossible to reverse-engineer or manipulate the data.
With CryptoJS, you can hash strings, secure data in transit, and ensure that your application’s sensitive information remains protected.
Why It Matters:
Data security is non-negotiable. Whether it’s securing passwords or verifying data integrity, learning how to properly implement cryptographic techniques like SHA-256 can make your application significantly more robust.
Use Case in CryptoJS: One of the easiest ways to hash a message in JavaScript is through the CryptoJS library. Here’s a quick example using SHA-256:
Day 8 of #100DaysOfCode:
Today, I dove into JavaScript Modules – a game changer for organizing code into reusable components!
What I learned: Modules allow us to split code into manageable parts, making our projects more scalable and maintainable. By using export and import, we can easily share functionality between files.
Key takeaway: Modules help avoid clutter and keep our code DRY (Don’t Repeat Yourself). The result? Clean, maintainable code!
How are you organizing your JavaScript code? Let’s share best practices! 
Day 9/100 of 100daysofcode - Tackling Underfitting and Overfitting
Today, I dove deep into two critical pitfalls of machine learning: underfitting and overfitting.
Underfitting happens when a model is too simplistic—it can’t capture the underlying patterns in the data, leading to poor performance both on the training set and unseen data. It’s like trying to fit a square peg into a round hole—the model just doesn’t have the capacity to represent the complexity.
Overfitting, on the other hand, is when a model becomes too attuned to the training data, even learning the noise and outliers. This model performs great on the training set but struggles to generalize to new data—like memorizing practice questions for an exam but faltering when the real test changes slightly.
Balancing these two requires careful tuning of model complexity, regularization techniques, and validating on diverse datasets. The sweet spot is where the model is flexible enough to capture the right patterns without clinging to irrelevant details.
What’s your favorite technique for managing this trade-off?
Day 10/100 of 100daysofcode - Scaling Systems: Vertical vs. Horizontal Scaling
Today, I deepened my understanding of system scaling, which plays a crucial role in building efficient, scalable architectures.
Vertical Scaling (Scaling Up): Involves adding more power (CPU, RAM, etc.) to an existing server. It’s simple but has limitations:
Easier to implement initially
No changes in the codebase
But it’s constrained by the hardware limit—once you’ve maxed out, that’s it!
Horizontal Scaling (Scaling Out): Involves adding more machines (servers) to distribute the load. It’s more flexible but requires more planning:
You can theoretically scale indefinitely
Better fault tolerance as the system doesn’t rely on a single machine
But requires changes in architecture and how systems handle data distribution (e.g., load balancers, sharding, etc.)
Key Learning: Starting with vertical scaling is common, but as systems grow, horizontal scaling is often the sustainable solution for long-term performance and stability.
Day 11/100 of 100daysofcode : Exploring MVC Architecture 
Today, I dove into the MVC (Model-View-Controller) architecture, a fundamental design pattern for building scalable web applications. Breaking down responsibilities into three interconnected components—Model, View, and Controller—really changes how I think about structuring projects.
Model: The brain of the application, handling data and business logic. It’s the core that stays independent of the user interface.
View: Responsible for the user interface and what the user sees. A clean separation from the logic ensures easier updates and redesigns.
Controller: The middleman, handling user inputs and determining which view to present, allowing for smooth interaction between the Model and the View.
What really stood out to me was how this architecture not only improves code organization but also allows for flexibility when scaling an app or adjusting components independently. It’s like giving your code room to breathe and evolve.
Have you had experience with MVC? How has it impacted the way you code?
Day 12/100 of 100daysofcode : Mastering Server-Side Rendering (SSR) vs. Client-Side Rendering (CSR)! 
Today, I not only explored Server-Side Rendering (SSR) but also dove into how it compares to Client-Side Rendering (CSR) and when to use each in web development.
Here’s what I learned:
SSR is perfect for improving initial load times and boosting SEO. Since the server renders the content, users can see meaningful content right away—super important for content-heavy and public-facing websites.
CSR, on the other hand, shines for highly interactive apps. It allows for faster subsequent loads and works great in apps where user interaction is the focus, like dashboards or single-page applications.
When to use SSR vs. CSR?
SSR is ideal for SEO-friendly pages or static sites, and is commonly used in frameworks like Node.js, Next.js, ASP.NET and PHP(Laravel).
CSR fits apps with heavy front-end interactions and is often seen in frameworks like React, Angular and Vue.
Learning how to balance SSR and CSR in different scenarios has opened up new possibilities for optimizing performance in my future projects. The trick is knowing when to apply each rendering method for the best user experience!
How do you approach SSR vs CSR in your projects?
Day 13/100 of #100DaysOfCode: Pre-hooks in MongoDB
Today I dove into pre-hooks in MongoDB, specifically with Mongoose, and it’s fascinating how much control we can have over database operations!
Pre-hooks (or pre-middleware) allow you to run specific logic before certain database actions like saving, updating, or deleting documents.
I learned how to use them to automatically hash passwords before saving user information—ensuring security is handled at the database level without repetitive code.
For example, here’s a simple use case:
This runs right before a document is saved, ensuring user passwords are always hashed before hitting the database.
Day 14/100 of #100DaysOfCode: Mastering Serverless Applications
Today I took a deep dive into serverless applications, and it’s incredible how they redefine modern software development! Here are some insights I gained:
What is Serverless?
Serverless doesn’t mean “no servers”; instead, it refers to an architecture where the cloud provider manages the infrastructure. Developers focus on writing functions and services without worrying about provisioning, scaling, or maintaining servers.
Key Benefits:
Pay-as-you-go: Traditional infrastructure often involves paying for idle resources. With serverless, costs are optimized—you only pay when your code runs, making it highly efficient, especially for applications with unpredictable traffic.
Automatic Scaling: Serverless platforms like AWS Lambda, Azure Functions, and Google Cloud Functions handle scaling automatically. Whether you have 10 or 10,000 users, your application adjusts seamlessly.
Faster Development & Deployment: By eliminating infrastructure management, you can focus purely on coding and quickly deploy new features or updates. This agility makes serverless a perfect fit for agile development and startups.
Event-Driven Architecture: Serverless apps are designed to respond to events (like API calls, file uploads, or database changes). This event-driven model aligns well with microservices and dynamic workloads.
Use Cases:
Challenges:
While serverless offers significant advantages, it’s important to be mindful of cold starts (which can cause latency), vendor lock-in, and debugging complexities. Balancing these trade-offs is key when adopting serverless for critical applications.
Overall, learning about serverless has expanded my understanding of modern cloud architecture and opened up new ways to approach efficient, scalable development. I’m excited to implement these concepts in future projects!
Has anyone else worked on serverless solutions? I’d love to hear about your experiences and tips!
Day 15/100 of #100DaysOfCode: Understanding Software Dependencies
Today’s learning focus was on dependencies in software development.
Dependencies are crucial, and understanding them can make or break your project’s stability. Here’s a quick breakdown of what I explored:
Build Dependencies: Tools needed to compile or build your project.
Runtime Dependencies: Libraries required for the software to function post-build.
Development Dependencies: Only needed during development (e.g., testing frameworks).
Direct vs. Indirect Dependencies: What you use directly vs. what your dependencies rely on.
Version Dependencies: Specifying versions to avoid conflicts.
Optional & Peer Dependencies: Enhance functionality but may not be necessary for core functions.
Being mindful of how these dependencies interact can prevent a lot of issues down the road, such as version mismatches or bloated projects.
What’s your biggest challenge with managing dependencies? Let’s discuss!
Day 16/100 of #100DaysOfCode: Nodemon Dependency
Yesterday, I explored the different types of dependencies, learning how each serves a specific purpose in project development.
Today, I dived deeper into Nodemon, a powerful dev dependency that significantly boosts productivity by automatically restarting your server whenever file changes are detected. Instead of manually stopping and starting the server during development, Nodemon does it for you—seamlessly.
What I’ve Learned:
Installing Nodemon as a dev dependency (npm install nodemon --save-dev) allows you to streamline your development workflow and focus on writing code rather than managing your server.
The power of automation at its best! 
What tools have you used to automate your workflow?
Day 17/100 of #100DaysOfCode: Security Insights
Today I learned why login systems often return a generic “invalid credentials” message instead of specifying whether it’s the username or password that’s wrong.
The reason? Security. 
By keeping error messages vague, developers reduce the risk of brute-force attacks where bad actors could systematically guess usernames or passwords. If the system revealed which field was incorrect, it could make their job easier.
It’s a reminder that sometimes user experience is intentionally sacrificed for a higher goal: protecting sensitive data. Balancing convenience and security is always a challenge in software design!
