Author Archives: anairdoduri

Sprint Retrospect Blog 1

When you have been in college for about 5 years, you start to think that there can’t be any more surprises and that you have been through pretty much everything, boy was I wrong on that one. This semester started in a way that I was at the same time familiar and a stranger to. Being divided into groups was nothing new to me, but sharing a long-term goal with a group of people was something that I was unaccustomed with.

We started this project together without any of us having any idea how to proceed, and I doubt anyone knew what they were doing the first week, but what we missed in knowledge we found in supporting each other. We have been part of groups before, but I can wholeheartedly say that this is the first time I’ve felt myself being part of a team. Through friendship and communication, we started to lay out a plan that helped us give form to a project we started from scratch. The best thing we might have done is to divide ourselves in sub-groups, each focusing on specific tasks that they felt comfortable working on. Be it by coincidence or instinct, I have always found myself to be the odd one out, being the only one working independently but this was very short lived in this setting as after the first week of actually working on the project I quickly found myself asking and finding a great deal of help and opinions from my teammates. We all ask and give help without even noticing it, learning new things along the way even though after years of being a CS student.

This leads me to one of the Apprenticeship Patterns called “The Long Road”. This pattern reminds us that becoming a true software craftsman isn’t about reaching a final destination. Instead, it’s an ongoing process where every project, challenge, and mistake is an opportunity to learn and rather than expecting immediate expertise, the long road emphasizes small, consistent improvements over time with each step building on the previous one. Reflecting on both successes and failures evolves or changes our goals and teaches us that on the long run we should not only value coding proficiency but also soft skills such as communication, teamwork and the ability to collaborate with mentors and peers. I was too fixated on the end-goals, finishing the project, and reading this pattern before starting to work would have saved me some good hours of unnecessary headaches.

This pattern became even more evident to me when I reviewed the first commits I did in this project. Working on the guest-info system the past semester, I thought it would be a breeze adding on to it and giving it shape to help our end-goals, which ended up in failure. I tried to do too much in a short amount of time, add new endpoints to the API, add the script to update our existing database with new objects with extra attributes. My whole work ended up failing at the end as my lack of knowledge caused irreparable errors in the code.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/newAPI?ref_type=heads – My initial branch where 85% of the added code went wrong.

Thankfully, I learned from these mistakes, and having great teammates helps a lot. Michael and Prince worked on shaping our schemas and API to match the attributes from the objects we were fetching from an external dataset, by adding a few tweaks and a quick script, I managed to fetch the correct object and lay the groundwork for our next sprint, which is combining all of our work together.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/guestinfobackend/-/tree/main/src?ref_type=heads – The current folder containing the script and tweaks to the guest-info API.

I am happy to have communicative and capable teammates to help me and each other during this project. Being able to ask for help and share opinions without being judged is working wonders on our team and helping us understand each other’s work more efficently.

What I’m not happy with is myself and how I more than often take a bigger bite than what I can chew, working on small increments is something that I would improve for myself in the future.

I know that the upcoming spring will be challenging, but with a great team and gradual self-improvement, I’m confident that we will be proud of the end result.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 – Intro

I just finished reading the first chapter of Apprenticeship Patterns, and I’ve got to say it’s a refreshing take on how we should think about our careers in software development. As a CS student who’s been mostly caught up in the whirlwind of lectures, coding assignments, and the occasional leet code exercise, reading this really made me think “Why did no one show me this when I first started?”.It made me rethink what it means to truly “learn” and grow in this field.

One of the coolest ideas I encountered was the emphasis on the apprenticeship mindset. Up until now, I always imagined career growth as a ladder where each step was a new certification or a harder project. But Hoover and Oshineye argue that learning isn’t about reaching a final destination; it’s more like being in a constant state of evolution, much like a traditional apprenticeship. This concept hit hard for me because it suggests that every coding bug, every failed project, and every line of messy code is just another step in the journey. It’s about continuous improvement rather than a rush to perfection.

What I found particularly intriguing was how the authors challenge the “lone genius” narrative. I used to believe that if I just buckled down and put in my ten thousand hours, I’d eventually figure it all out on my own. Now, I see the value in mentorship and community even though I’m pretty sure I’ll continue to be a bit shy about reaching out for help. It made me realize that collaboration and learning from experienced developers can be just as crucial as independent study. This chapter nudged me to consider joining more coding communities where I can both learn and share knowledge. Having the commit numbers on my GitHub page go up is starting to look like a good idea.

There were a few points I didn’t fully agree with, though. The idea that traditional schooling is almost insufficient for real growth struck me as a bit harsh. While I do see the limitations of classroom learning, I believe formal education lays an essential foundation that apprenticeships and self-directed learning can build upon. They both deserve merit and finding the right balance between both worlds can be very beneficial.

Looking ahead, I’m most excited about the chapters that dive into practical patterns for tackling everyday challenges in software development. I think those will be directly relevant as I navigate internships and open-source projects. Overall, this first chapter wasn’t just a reading assignment for me. It was a call to embrace a more holistic, reflective approach to learning. This is a mindset that I’m eager to adopt as I continue my journey in computer science.

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

API Endpoints, just so you know.

If you’re studying or working with Rest APIs, the chances of you running into endpoints are extremely high. I struggled a bit to wrap my head around them, so here’s a casual breakdown. It’s not as scary as it sounds.

What Are API Endpoints?

Let’s start with the basics. An API (Application Programming Interface) is like a menu at a restaurant(HOW MANY TIMES MUST I SAY THIS?). It tells you what’s available (services or data) and how to ask for it (requests). Endpoints are specific URLs on that menu where you go to get what you need.

Imagine you’re at a pizza place. You want to order a pizza with extra cheese and pepperoni. The endpoint is like the part of the menu that says, “Build Your Own Pizza.” It’s where your request (extra cheese, pepperoni) is processed and sent to the kitchen (server), and then your pizza (data) comes back to you.

In tech terms, an endpoint is a specific location on a server where an app interacts with the API to get or send information. For example:

https://api.pizzaplace.com/orders

Here, /orders is the endpoint where you place or check your pizza order.

How Do They Work?

Endpoints use URLs and HTTP methods to define what action you’re taking. These methods are the “verbs” of APIs:

  • GET: Asking, “What’s on the menu?” You’re retrieving information.
  • POST: Placing your pizza order. You’re creating something new.
  • PUT or PATCH: Updating your order, like adding mushrooms.
  • DELETE: Canceling your order. Sad day.

When your request hits the endpoint, the server processes it and sends back a response, often in JSON (an easy-to-read data format).

Why Do They Matter?

Endpoints make modern apps and websites possible. For instance, when you check Instagram, there’s an API endpoint fetching your posts. When you order on Amazon, there’s an endpoint processing your purchase. They’re everywhere!

Endpoints keep things organized. Instead of exposing a server’s entire functionality, APIs provide specific endpoints for specific actions. It’s like keeping the kitchen off-limits in a restaurant—you just see the front counter.

Real-World Example

Let’s say you’re building a library app. You might have API endpoints like these:

  • GET /books: Retrieve a list of all books.
  • GET /books/42: Get details about book #42.
  • POST /books: Add a new book.
  • DELETE /books/42: Remove book #42.

Each endpoint serves a purpose, and together they make the app functional.

Wrapping It Up

API endpoints are the way apps and servers talk to each other. They’re like doorways leading to the data and services you need. Understanding endpoints is crucial because they’re the foundation of so much of what we build. Whether you’re connecting a frontend to a backend or building your own API, endpoints are the unsung heroes of the digital world.

Next time someone mentions an “endpoint,” you’ll know it’s just a fancy name for a digital doorway.

References
https://www.geeksforgeeks.org/what-is-an-api-endpoint/
https://www.ibm.com/topics/api-endpoint

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

How the Frontend and Backend Connect in an API: A CS Student’s Guide

Since we’re diving deeper into web development, understanding how the frontend and backend work together is a must. It might sound like a techy tug-of-war, but it’s actually a smooth partnership—thanks to APIs (Application Programming Interfaces). Here’s how the magic happens, dumbing down.

The Frontend: The Face of Your App

The frontend is what users see and interact with. It’s all about the visuals and user experience. Imagine buttons, forms, and animations—that’s the frontend at work. Developers usually use HTML, CSS, and JavaScript frameworks like React or Angular to build this.

But here’s the kicker: the frontend is mostly clueless. It can show pretty pages, but it needs help to fetch or save data. That’s where the backend steps in.

The Backend: The Brain of Your App

The backend is like the brain. It’s where the logic, data processing, and database interaction happen. Built with tools like Node.js, Python, or Java, the backend handles all the “boring” stuff the user doesn’t see, like authenticating a login or storing a comment.

The frontend and backend don’t just shout at each other directly—they use an API to chat.

The API: Their Translator

The API is the middleman that helps the frontend and backend understand each other. Think of it as a menu at a restaurant(you would know if you read my previous entries). The frontend (the customer) picks something from the menu and places an order. The backend (the kitchen) cooks it up and sends it back. The API defines the rules of this exchange, so everyone’s on the same page.

Here’s how this plays out in real life:

  1. Frontend Sends a Request: The user clicks a button to log in. The frontend sends an HTTP request (usually via POST) with the user’s credentials to the backend API at something like /api/login.
  2. Backend Does Its Thing: The backend gets the request, checks if the credentials are valid, and prepares a response—like a token if the login is successful.
  3. Backend Responds: The backend sends the token (or an error message) back to the frontend in JSON format.
  4. Frontend Updates the UI: If the login worked, the frontend can now display the user’s dashboard. If not, it’ll show an error message like, “Try again, champ.”

Why This Connection Matters

APIs keep the frontend and backend loosely connected, so they can evolve separately. For example, you can upgrade your UI (frontend) without messing with your database logic (backend). Plus, APIs make your app’s backend reusable, other apps can connect to it too.

TL;DR

The frontend is the face, the backend is the brain, and the API is their translator. Together, they create the seamless apps we use daily. So next time you log in, search, or post, know that there’s a whole tech orchestra working behind the scenes. And now, you kind of know how it plays its tune!

References
https://www.geeksforgeeks.org/frontend-vs-backend/
https://medium.com/@adityagaba1322/streamlining-backend-frontend-integration-a-quick-guide-145eca3cca05

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

What’s an API? A Casual Guide for Noobs

Have you seen those memes about junior developers pushing the API key as a comment but never understood why it is such a big deal? Well, have no fear because if you have no idea what an API is, you’re at the right place.

So, What Even Is an API?

API stands for Application Programming Interface. It sounds super technical, but it’s not that bad. Basically, an API is like a menu at a restaurant. The menu tells you what dishes (functions) the kitchen (the system) can make for you. You don’t need to know how they’re cooking your pasta in the back; you just order, and it shows up at your table.

In the tech world, an API does the same thing. It lets one app talk to another without knowing all the inner details of how the other app works. Cool, right?

Why Do We Need APIs?

Imagine you’re building an app that needs weather data. You could go out, set up weather stations, and measure the weather yourself (good luck with that). OR you could just use a weather API that already collects and shares this data for you. APIs save you a ton of time by letting you use existing tools and data instead of building everything from scratch.

How Does It Work?

Here’s a quick breakdown:

  1. You Make a Request: Your app sends a request to the API. Think of it like sending a text message that says, “Hey, can I get today’s weather for [city name]?”
  2. The API Responds: The API sends back the info you need, usually in a format like JSON (basically a fancy way of organizing data).

That’s it. It’s like texting a really reliable friend who always gives you the answers you need.

Real-Life Examples of APIs

  • Google Maps API: Used by apps to show maps and directions.
  • Twitter API: Lets developers pull tweets or post updates automatically.
  • Spotify API: Allows you to add music to your app or create custom playlists.

Even when you’re signing into a website with Google or Facebook, there’s an API making that happen behind the scenes.

Why Should You Care?

If you’re a CS student like me (or thinking about becoming one), learning to use APIs is a game-changer. It’s how you get your apps to do cool things without reinventing the wheel. Plus, if you ever want to work in software development, knowing how to interact with APIs is a must.

So, next time you hear someone drop “API” in a convo, you can confidently nod and say, “Oh yeah, I’ve used APIs before.” (Fake it ‘til you make it, kings.)

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

6 Common Design Smells and Why They Matter

Ever work with code that feels like it’s about to fall apart? That’s often due to design smells, which are signs of poor design that make code harder to work with. Here’s a quick rundown of six big ones: Rigidity, Fragility, Immobility, Viscosity, Needless Complexity, Needless Repetition, and Opacity

1. Rigidity

Rigidity is when code is hard to change. You try to update a small feature, and suddenly you’re changing ten other things just to make it work. This makes the code stiff, leading to slow updates and frustration.

2. Fragility

Fragility means that the code breaks easily. A small change in one part of the codebase suddenly causes errors all over. Fragile code is typically too tightly coupled, meaning different parts rely too much on each other, making even minor updates risky.

3. Immobility

Immobility happens when you can’t easily reuse code in other projects. Maybe you’ve written a method that could be helpful elsewhere, but it relies on so many project-specific details that you can’t transfer it without dragging a ton of dependencies. Immobile code wastes potential and limits flexibility.

4. Viscosity

Viscosity means the code is easier to “quick-fix” than fix the right way. The messy design makes doing things properly so difficult that developers often take shortcuts, creating even more technical debt. Viscous code tempts us to compromise, resulting in even messier code over time.

5. Needless Complexity

Needless complexity is adding extra, unneeded elements to the code. This could be because someone thought, “We might need this someday,” or because they’re solving non-existent problems. Extra complexity doesn’t just add confusion; it makes the code harder to read, test, and debug. Simple solutions are usually best.

6. Needless Repetition

Needless repetition is when you see similar code blocks everywhere instead of consolidating them. When you repeat code instead of centralizing it, it violates the DRY (Don’t Repeat Yourself) principle. This makes code harder to maintain, as changes need to be made in multiple places instead of just one.

7. Opacity

Opacity is when code is confusing and hard to read. Maybe variable names don’t make sense, logic is overly complex, or comments are missing. Opaque code is like a puzzle, requiring extra time to understand, and slowing down productivity.

Why It Matters

Design smells don’t stop your code from working, but they make it harder to understand, change, and maintain. Ignoring them means the code gets more frustrating to deal with over time. By refactoring to remove these smells, you make the code cleaner, easier to work with, and more enjoyable for everyone on your team. Next time you’re reviewing code, look out for these design smells, your future self will thank you!

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Decoding Software Technical Reviews: A Practical Guide for Developers

Hello again and welcome back to this week’s update. Today, I want to discuss something very critical in software development but perhaps many find it quite intimidating (me included) – Software Technical Review. For any developer, whether they are a professional coder or just a beginner, getting familiar with this process will completely change the game. So, grab your coffee or another favorite brew, and let’s break STR down.

Firstly, what is it?

To describe it in simple terms, a Software Technical Review is a sort of code brainstorming. This procedure requires a team of developers – sometimes, other stakeholders, too, – to meet and look through the code and design of the project, as well as any other technical part. It is a kind of peer review of your code, where every team member, checks each other’s homework to make sure everything is on course before proceeding further.

Secondly, why is it important?

Well, STR helps identify bugs immediately, ensures software complies with quality requirements, and helps consultants stay up-to-date with a project’s aims. All in all, it’s like double-checking an essay before sending it: it would be quite irritating to receive a failing grade for a paper due to small mistakes that could have been rectified. Imagine the irritation when even small details can have a severe aftermath.

What actually happens in the review?

The team analyzes the code to detect blunders, potential security risks, and quality as a whole.
They examine the design document to see if the planned architecture makes sense, and if it is achievable.
The team also looks at the performance of the development and its ability to satisfy the requirements of the proposed user.
The members always come up with their ideas of what to upgrade or alter.
Who is involved, and not just developers?

Finally, here is the STR’s cast:

Project managers, who ensure the project is on the right path to its goals and timeline.
Quality assurance engineers are responsible for the quality and ensuring that no rough edges of under-functionality come out.
Other developers may see an error that was made in the code-reviewing phase by the coder.

Some review suggestions?

You should know what you have done without stammering, have an open mind to revision, know it is for everyone’s best, and try to avoid subjective opinions – stick to points on making your code better, not yourself worse.

As they say, two minds are better than one so try to take advantage of the other minds worrying about the same project as you in order to better yourself and your programming skills.

Till next time,

Ano out.

References

https://www.geeksforgeeks.org/software-technical-reviews-in-software-testing

https://www.softwaretestinggenius.com/understanding-software-technical-reviews-strs/

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Coding Katas: Grinding for a sharp mind.

Hello, and welcome back to your least favorite corner of the internet. I want to talk about something that I found to be pretty cool, Programming Katas. To all my OG Karate Kid fans out there, programing katas are basically the “Wax-on, wax-off”‘s of the programing field.

Translating this to our world, programming katas are small, manageable coding exercises that challenge you to solve problems repeatedly, often in different ways. Each kata is designed to be tackled in one coding session, making them the perfect daily workout for your brain.

Just like playing scales can make you a better musician, regularly working through katas can make you a sharper coder. They force you to wrestle with new problems, reminding you of syntax you might have forgotten or introducing you to new methods and functions. Katas aren’t just about finding any solution; they’re about finding the best solution and then making it better. This iterative process of refining your code teaches you about the art of clean, efficient programming. It’s all about writing code that not only works but works beautifully. As you progress through different katas, you’ll find yourself picking up new programming concepts and deepening your understanding of the languages you use. Many katas come from community platforms like CodeWars, HackerRank, or LeetCode, where coders from around the world share their solutions and insights. Imagine solving a puzzle and then seeing a dozen different ways others have solved it. Boom, you’ve just struck learning gold.

Starting with programming katas is as easy as signing up for a platform that hosts them. Pick one that suits your taste and start with challenges that match your skill level. Personally I like the katas from CodeWars, the community problems and challenges push me forward to try and be better than what I was yesterday, or I just solve some problems just for bragging rights with my fellow programmer friends. Sites like CodeKata.com have good starting exercises for people who just got in Kata’s so you might find that to be your particular cup of tea. Either way if you just find an exercise you fancy and work on that, it’s enough.
Don’t be afraid to struggle—that’s part of the learning process.

Incorporating katas into your daily or weekly routine can transform the way you code. They keep your skills fresh, introduce you to new ideas, and deepen your problem-solving abilities. Plus, they’re a lot of fun! Whether you’re a newbie looking to get better or an experienced dev wanting to stay on top of your game, give katas a try. You might just find yourself hooked, coding better, faster, and more creatively than ever before. Just remember that while Kata’s are fun and have several profits, do not fall behind on your school work or personal portfolio projects. The reason why you’re even grinding Katas in the first place is to become a better programmer for your main line of work.

Till next time,

Ano out.

References

http://codekata.com/kata/codekata-how-it-started/
https://docs.codewars.com/concepts/kata/
https://www.soapui.org/testing-dojo/testing-katas/what-are-testing-katas/

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Workstations: The best setup for CS Students

Here’s the thing, having the right workstation isn’t just about keeping up with the cool kids anymore, it’s about finding the right blend of power, ergonomics, and style to run through coding marathons, debug sessions, and endless project nights. Let me guide you through what, in my opinion, is the best (somewhat cheap?) setup you could have as a CS student.

First off, the centerpiece of your digital dominion: the Laptop. You know that for CS students the laptop is not just some tool you use, it’s your best friend, your main weapon, your Excalibur and as such It needs to be powerful enough to compile the code faster than you can say “runtime error”. Try to find a laptop that has:

  • Powerful CPU: Intel Core i7 or i9, or AMD Ryzen 7 or 9. If you’re into Macs, Apple’s Silicon chips have proven their efficiency these past years so if you can afford it, go for it.
  • Plenty of RAM: 16GB should be your starting point. If you’re into machine learning or running multiple Virtual Machines, 32GB should be your sweet spot.
  • SSD Storage: Waiting for your IDE to load is so, 2010’s. Most laptops now come with 256GB SSD, if you juggle multiple projects you can upgrade to 1TB.
  • Graphics Card: Look into a graphics card that is affordable but also new, It will be useful not only for GPU programming and A.I. work but also for winding down by running some of your favorite AAA studio games.

Some people might be content with only a laptop as their workstation and I can’t say they are wrong as some of you living in dorms might not have the space for your workstation, but trust me when I say that setting up peripherals is a game changer.

  • Hi-Res Monitors: A single 27-inch, 4K monitor can drastically change your coding experience by reducing eye strain and improving readability. It works great for having your code on one screen and your reference material on your laptop. I’m running a 34-inch ultra-wide + 15.6-inch laptop on the side. Maximum real estate.
  • Mechanical Keyboard: Once you go clack, you never go back. The tactile feedback is not only satisfying but also reduces typing fatigue. Plus, it makes you feel like a hacker from a 90s movie.
  • Ergonomic Mouse: Your wrist will thank you if you get a mouse that is fit for your hand, try to find something that feels right for you.
  • Quality Headphones with Noise Cancellation: For when you need to zone out and focus, or just vibe to some tunes while debugging.

Don’t be afraid to express yourselves whether it’s with LED lights, action figures, or posters of your favorite GitHub repos, make it yours. You’ll be spending a lot of time here, so make sure it’s a place that inspires you.

By now you should have what is essentially a perfect workstation. You have your laptop around campus, your station to hook it up and unleash its potential.

This is my personal working space,I hope it inspires you. Till next time,

Ano out.

References

https://www.techradar.com/pro/best-laptops-for-computer-science-students

https://simpleprogrammer.com/best-laptops-for-computer-science-students/

https://medium.com/technonerds/desk-setup-2020-peek-into-the-gear-i-use-daily-as-a-student-f88ea8be16f5

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.

Test-Driven Development: Because Debugging is Overrated.

You know that heartbeat you skip when you press ‘run’ and pray everything works? Well, today I shall exhibit a certain method that has been around for some time that will have you save those skipped heartbeats for when your favorite TV show character nearly dies. Enter Test-Driven Development (TDD) – it’s kind of like having a buddy checking your work as you go, making sure you’re on track

Imagine you start cooking a new recipe you found. Would you start cooking without checking if you’ve got all the ingredients? You write a small test for a feature you’re about to whip up, see it fail (because it doesn’t exist yet), and then write just enough code to pass the test. It’s a cycle: write a test, code a bit, make it pass, and clean up your code without changing how it works. Rinse and repeat.

Yes, I’m not a telepath but I know what you are thinking right now, why even bother?

One benefit of TDD is that it nearly eradicates most of the bugs in your code, making you less likely to spend hours hunting down bugs. You’re checking your steps as you go, so you know exactly where things might have gone sideways.
Your code design is going to be more professional because when you write your tests first you can make your code more modular and easier to read, kind of like organizing your closet so that you can find your favorite shirt even in the dark.
Once you have a couple of tests, guess what? You can go update or refactor your code however you like, your tests will let you know if you broke something.
Apparently, the word online is that after getting used to it you’re actually going to code faster. The backtracking time to fix bugs adds a lot to your programming timer even if it doesn’t feel like it.

Okay, It’s not all Sunshine and Rainbows. I personally feel like Test-Driven Development feels like a drag at most times, especially for people who are not used to writing tests before you code, and from what I have experienced so far, writing good tests is an art form on its own. Still, once you start, you might just want to stick with it. The payoff in reducing headaches (I promise I’ll stop using this word in the future) and quality code will be worth it.

I really want to think of TDD as my coding companion, helping to keep my code clean and bug-free. It is somewhat of a mindset shift, more frontloaded work for sure but I feel like it will result in fewer late-night coding sessions and better-quality projects. Whether you are a solo developer or a team player, giving TDD a shot could be a game-changer. So try leading the way with tests next time you sit down to code and see how that goes.

Till next time,

Ano out.

References

https://testdriven.io/test-driven-development

https://www.browserstack.com/guide/what-is-test-driven-development

From the blog CS@Worcester – Anairdo's WSU Computer Science Blog by anairdoduri and used with permission of the author. All other rights reserved by the author.