Author Archives: anairdoduri

Sprint 3 Retrospect Blog

At a certain point in life, you start to notice a pattern. Older individuals often tell you, “Don’t worry, it will be over before you notice, so try to enjoy it.” People told this to me when I started High School, and I was complaining about its hardships, and they said the same phrase again when they caught me complaining about College. I always seem to learn my lesson a little too late, but luckily this time I caught it at the right moment. This last sprint on one of my last college classes was nothing short of enjoying my time surrounded by good teammates and working on a field that I became familiar with.

In the earlier sprints, we were caught off guard by what we had to do. This sprint, however, we had a clear vision of what needed to happen. All that was left was a little push.

Our inventory system was almost done by the end of the second sprint. We needed to add some final touches. We also had to clean up the code so that it would be presentable for future teams. After taking some opinions into consideration, we decided to add a few more features to it so that it would be overall complete for use, even for certain items that were not part of the Food Data Central Database. Playing around with adding new items to the back end and creating the necessary front-end infrastructure to do so the past sprints had me equipped with enough skills and knowledge to implement this feature seamlessly and tirelessly. Adding a few new modals after the scanned UPC was not found on the FDC database was not an issue as it would be the same procedure I used in the last sprint to populate the back end with new items. What was tiring at the time was having to manually input every attribute of the new item each time it was scanned. The temporary workaround for that issue was to cache the data to the local machine memory the first time an unidentified item was scanned. By doing so, every other instance that particular UPC code would be scanned again the attribute sections would already be populated with the previous input. This, however, was a temporary solution to the problem, as it could be an issue when the Web App is used in the future. If the same application is run on a different machine, it would not recognize those items as the cached memory for that machine would be null, and if by some means the cached memory were to be cleared using developer tools we would still find ourselves with items whose attributes would need to be scanned again.

Another feature added to the project this sprint was the sorting of different attributes. A simple sorting function which sorts a populated list based on their values and letters was added to the database file. Appointing this function as an “onClick” to the attribute table could sort the population of the table in a descending or ascending order of values for integers, and prioritizes the first letter of the category and sorts them alphabetically for strings.

Last commit done to the project side branch before merging to main:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/9ecee33738a922be4f200ba106064a1aad6f40a6

In Apprenticeship Patterns, the “Familiar Tools” pattern emphasizes the importance of mastering your environment—whether it’s your editor, command-line interface, or even your IDE. These tools are your instruments, and just like a musician, your fluency with them can either make your job seamless or frustrating. My tool for this sprint was my familiarity with the system that we had created previously, and the basic functions I had learned on my earlier classes. As I was searching for libraries to create the sorting and this pattern reminded me to stop jumping from tool to tool but instead double down on the ones I have used the most. The end result was nothing glamorous, but it does speak for itself. Less friction and more flow.

In the end, we reached our goals, but the feeling of satisfaction continues to be bittersweet because for some of us, it was the last project before graduation. As we now go on different paths, this project will link us to the good times we had working together, and to remind us to not be sad because its over, but to be happy because it happened.

With that, I conclude this journey.

Ano, over and out.

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.

Sprint 2 Retrospect Blog 2

If I were to put our journey so far in simpler terms, that gamers like myself would have an easier time understanding, I would say that this whole project has felt like an MMORPG game. During the first sprint, we all had nearly no idea what we were doing, trying to do easy tasks just so we could get a few levels and understand the mechanics behind the game so we could maybe get a glimpse of the bigger picture. After that was said and done, coming into the second sprint of this project, we all felt more comfortable with the project and its continuity. By now, we all have a clear image of our roles and what we bring to the table. We no longer run around aimlessly trying to defeat a minor boss, but now each of us has developed specific skills that make “fighting challenges” feel like a walk in the park, and everything goes smoothly like clockwork.

The one apprenticeship pattern that I would choose for this sprint would be “Concrete Skills – Making your abilities tangible and demonstrable”. We are entering into a more advanced phase in our journey as CS students, with most of us graduating in a month, so now is the time to let go of the abstract knowledge and hone tangible and demonstrable skills. This pattern really pushes you to refine your skills with specific and marketable abilities. The division into subgroups pushed us to learn more about particular skills. Working on the backend and connecting it to the frontend pushed me to learn or better yet, refine some skills that I thought I had a pretty good understanding of until I had to put them in practice. My teammates had already done a great job setting up the front end and adhering to visual identity guidelines, which meant I had to do as good of a job as they did, making everything functional and smooth.

After creating a functional backend last sprint, now I had to connect it to the frontend and make it actually “do something”.
I started by copying the front-end files my teammates had worked on so far to our main branch and started editing their scanner and database files. A simple JS script to fetch the information from the FDC database and add it to our own backend was all that it took to give life to our project. It took me a while to figure out the correct pathing for each API call, but once that was set up, everything was a breeze. My teammates had also created a “Database” page in which we would store our scanned products. I populated the page with items stored in our backend from the previous scanner page. After that, adding two buttons that were connected to simple API calls made the page more interactive. Now we can easily store, edit, and delete products, which is way more than what was asked of us initially.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem-culling/inventorybackend/-/commit/b57e1ea44a8113bac4075769da0b25336c975c8f – my latest commit with all the functionalities.

I guess if I had prior knowledge of the above-mentioned pattern, I would have had an easier time working on the project, as I would have “honed” my knowledge of backend-to-frontend connections beforehand, which would make my work even more efficient.

My teammates continue to be a great force in this project, and we are able to communicate clearly between us and solve issues in a short and manageable time without putting a lot of strain on ourselves. In fact, our communication might even backfire in a sense because we solve the issues so efficiently that we don’t even put them up on the issue board, a simple “hey, we have to fix this” is all that it takes to “clear” an issue, so we might want to work on that a little bit for the upcoming sprint.

Going back to my analogy, I guess that by now we have reached “level 40” with the cap being at 60. I hope that as we reach the “end-game,” we continue to have the great teamwork that we have had so far and that has helped us so much. We all have our roles and work cut out by now, so tackling this last sprint should be easy, with the end result being a successful project that we will leave behind but take with us valuable, tangible skills to help us take on future projects and challenges.

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.

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.