Monthly Archives: March 2024

Retrospective – Sprint #1

During the course of our first sprint, I contributed to 3 issues:

  1. Gitpod Dev Environments – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/69 (Created new files to support the use of settings and extensions in Gitpod instead of Docker).
  2. Move from commands to bin – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryintegration/-/issues/6 (Changed commands file to bin and altered any mentions or uses of prior commands files).
  3. Add AlexJS linter to the pipeline – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryintegration/-/issues/7 (Assisted in adding Alexjs to the Inventory Integration pipeline).

I also reviewed a majority of our issues at the end of our sprint and collaborated with teammates to fix any errors with issues, mainly regarding merging.

What worked well during our sprint was that we were all able to help each other and work towards achieving our goal of at least 75% completion of our planned issues. We were all able to reach out and have any questions clarified in a timely manner if anyone was stuck on a particular step or concept. We efficiently used our time for standups and were able to seamlessly transition between our virtual and in-person meetings without any issues. Regardless of our meeting location, we were able to meaningfully collaborate on issues, and when working individually, we were still able to bounce off each other if needed.

What didn’t work well is that we could have planned more properly in splitting the workload evenly per person. As a team, we could have done a better job in communicating what needs to be worked on and/or reviewed to allow for everyone to participate in our sprints. We didn’t communicate much over what we each planned to complete and just went with the flow as we went along. This did not hinder our progress, but it did, however, hinder our overall planning efficacy and the spread of participation.

As a team, we could work towards communicating better when discussing what needs to be done and what is yet to be done. By improving our communication, we would be able to reach our goals as we had in the past while also allowing for all members to have a substantial impact on our overall sprint. By better separating our work, it would also help even the spread of workload and stress to each member instead of having some members dealing with more to do than others when other members are available and willing to contribute/collaborate.

As an individual, I felt as if I could have also communicated better to facilitate more work being spread instead of taking it upon myself to make sure all work was reviewed and ready for merging. While it helped to ensure we were prepared for our review session, it still left others in our team unable to participate as much since, while I did take the initiative to get our things done, it left little room for others to contribute to our tickets if they had not already participated.

Overall, I’m happy with how our first sprint turned out, it went pretty smoothly, and I’m looking forward to our next sprint.

From the blog CS@Worcester – Eli's Corner of the Internet by Eli and used with permission of the author. All other rights reserved by the author.

The Importance of Finding Mentors

Beginning a journey in the Software Development field is like walking through a maze. Every turn presents different challenges, different opportunities, and different outcomes. Having a mentor can be the guiding light that we need through our journeys. The Finding Mentors pattern underscores the importance of seeking out help and assistance from experienced individuals who can provide both support and guidance while navigating the complexities of the field.

Reflecting on my own experiences, having a mentor can have quite a profound impact on shaping skills, gaining knowledge, and viewing things from different perspectives. I’m yet to experience this within my software development journey, but experienced it on numerous occasions with my athletic career where I was coached by a number of professional athletes. This in turn enhanced my skills and knowledge and resulted in me becoming a better overall player and athlete. I would assume the same would happen within the development field. Having a mentor would overall increase our knowledge and skillset, allowing us to further walk down our professional journeys.

What I found particularly interesting about this pattern was the emphasis on the give and take nature of mentorship. While apprentices seek guidance from experienced individuals, they then also have the opportunity to mentor others. This creates a culture of continuous learning and collaboration within the software development community as a whole. Additionally, the pattern has reinforced the notion that mastery can be achieved through the guidance and mentorship of individuals who have already walked the path we are trying to take. This allows us to take a step further in our learning journey. Therefore, this has prompted me to actively seek out mentors and engage more proactively within the development community to accelerate my personal learning and growth.

Additionally, while having a mentor can be an extreme plus in our own personal development, we should acknowledge that finding mentors can be challenging. This is due to the fact that some individuals may lack access to established networks or communities. In this case, we can look into alternative approaches to finding a mentor through online platforms or peer-to-peer mentorship programs.

Therefore, the Finding Mentors pattern can serve as a guiding light for us as aspiring craftsman, utilizing the power of mentorship in our professional development. By embracing the core message outlined within the pattern and seeking out mentorship opportunities, apprentices can then navigate through the complexities of software development with purpose and confidence, while also growing and learning for their professional career.

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

With this being our first sprint it went well and we still have plenty to learn about. Our team did a great job of communicating, time management, and ensuring everyone’s ideas were heard. In our working agreement, we talked about not being afraid to ask questions or for help, which made it easier for us to make sure were on the right track and nobody was falling behind. Having in-person and discord meetings was helpful for us since everyone has a busy schedule and made it easier for us to show our work and any problems we were having. As a group of 5, we needed 13 different issues for a weight total of 25, we managed to do 12 out of the 13 so we had more than 75% of the sprint done. Most of us are used to using GitLab but we did have some trouble finding our work and navigating GitLab, it’s just how GitLab was set up and we just need some getting used to it. GitPod is something new we started using this semester. It works well and it’s similar to Visual Studio so we were able to use it with ease the only different thing was the commit message and merge request. We were just used to committing our work a different way, so it took a little getting used to. For the next sprint, we will make sure to keep communicating with each other, manage our time, and deal with any issues we are having. 

As a team an improvement that we can make is our time management, we didn’t get a go on our sprint until toward the end of our sprint. I think that’s what gave us a lot of issues because we were rushing to make sure we got most of our work done on time but would end up with errors like with our commit messages. If we start tackling the sprint as soon as our stuff is weighed and assigned to someone we can deal with these errors earlier rather than later and still have plenty of time to help and review work.

As an Individual some things that I can improve on is making sure that I’m not holding my team back and leaving them with a lot of work.  Also teach myself more about GitLab, so I can find my work with ease. The issue I worked on was moving from commands to bins in the inventory system in general. I made sure to rename commands to bin and that all the script paths were set to bin. The only problem I ended up having was my build and test pipeline because they were asking for specific files. I just ended up disabling those pipelines and everything ran smoothly. Next sprint I plan on assigning more issues to myself so my team members don’t have to do more work than they need to and make sure that I’m contributing as well. I also plan on making sure I get started on my work earlier in the week instead of waiting until the last minute, so if I have any issues or problems I can make sure to ask my team head-on to get it figured out and solved sooner rather than later.

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

With this being our first sprint of the semester it went well but we had our fair share of issues that we had to work through as a team which will help us make better decisions on our workflow and our team dynamic in the future. I personally worked on five issues throughout the sprint, one of these issues being a team issue and three of the issues being assigned to myself while we still worked as a team while going through our individual issues. These issues included adding the alex js linter to a pipeline and resolving alex js issues, adding a git pod dev environment setup to a repo in the project and moving from commands to bin for a specific repo within the project. Our group issue that we completed included researching frontend development and using our research to create issues for our second sprint regarding the wireframe for the add inventory frontend.

Overall I did not have much trouble with my individual issues within this sprint. My first issue I worked on with the alex js linter was straightforward and I was able to complete it without much delay as there were not a lot of terms flagged by the linter after its implementation to the pipeline. My second issue regarding git pod dev environments took a bit more time which was simply just due to the time it took to fully test the pipeline after a commit but I did not have trouble with implementing the git pod dev environment within the repository. My last individual issue involved moving from commands to bin, this was my most simple individual issue as it mainly consisted of renaming a folder and checking for commands which used the commands folder and changing it to use the bin folder. Our team wide issue of researching frontend and making issues also went well as we all attended the meeting and went over frontend basics together. Links to my individual issues are listed below.

Although we did not have a large amount of problems within this sprint I still feel as though there are things we could work on to improve as a team. One thing we can improve on is our timeline when it comes to reviewing, during the sprint we didn’t review our code until near the end of the sprint which just ended up being inefficient and experiencing this has led to us deciding to review code as soon as possible during this sprint instead of waiting until the end of the sprint in order to notify each other of any issues with our work with ample time to fix mistakes. Another thing I feel as though we all need to work on during sprint two is our use of gitlab as there were points where we got lost in gitlab when making merge requests, branches etc so being more careful when using gitlab will help us all remain more organized in order to ensure we get our code properly reviewed and merged within a timely manner. In my opinion we worked well together given it was our first time working in a team like this and hopefully we can continue to develop our abilities to work as a team throughout the next two sprints.

Alex JS Linter issue: 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/33

Gitpod Dev Environments Issue: 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/32

Move from commands to bin issue: 

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/31

From the blog CS@Worcester – Dylan Brown Computer Science by dylanbrowncs and used with permission of the author. All other rights reserved by the author.

WEEK 8

PATH TESTING.

Path testing is an approach to testing where you can ensure that every path through a program has been executed at least once. However, testing all paths does not mean that you will find all bugs in a program. There are some steps involved in path coverage testing. Step one is code interpretation. It is important to carefully understand the code you want to test. The next step is constructing a control flow graph. It shows the nodes representing code blocks and edges for the movement of control between them. The third step is determining the paths. This entails following the control’s path from its point of entry to its point of exit while considering all potential branch outcomes. While determining paths, you’ll also consider loops, nested conditions, and recursive calls. It is important to list every route like giving each path a special name or label so you can keep track of which paths have been tested. The next step is testing case design. Create test plans for each path that has been determined, make inputs that will make the program take each path in turn. Make sure the test cases are thorough and cover all potential paths. Examine the test results to confirm all possible paths have been taken. It is important to make sure the code responds as anticipated.

Some advantages of path testing is it helps reduce redundant tests, it focuses on the logic of the programs and it is used in test case design. Some cons of using path testing is the test case increases when the code complexity is increased, it will be difficult to create a test path if the application has a high complexity of code and some test paths may skip some of the conditions in the code. There are three path testing techniques which are Control Flow Graph (CFG) – The Program is converted into Flow graphs by representing the code into nodes, regions, and edges. Decision to Decision path (D-D) – The CFG can be broken into various Decision to Decision paths and then collapsed into individual nodes. Independent (basis) paths- Independent path is a path through a DD-path graph which cannot be reproduced from other paths by other methods. I chose these two resources because they go more in depth about path testing and help explain it well. One of the sources talks about the pros and cons of using path testing, the types of path testing which I didn’t know before this.

References.

https://www.geeksforgeeks.org/path-testing-in-software-engineering

https://www.tutorialspoint.com/software_testing_dictionary/path_testing.htm

From the blog CS@Worcester – Site Title by lynnnsubuga and used with permission of the author. All other rights reserved by the author.

Unlocking the Power of Stubs in Software Testing

In the realm of software development, testing is a critical phase that ensures the quality and reliability of the product. This week, my exploration led me to a compelling resource that sheds light on an integral part of testing methodologies: the use of stubs. Stubs are simplified, replaceable components that mimic the behavior of real software modules, allowing testers to isolate and test individual parts of a program. The resource, an insightful article titled “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” provided a comprehensive overview and practical advice that I found particularly enlightening.

The reason I selected this resource was its direct relevance to our current course material on software testing methodologies. As we delve into the complexities of ensuring software reliability, understanding the role of stubs becomes indispensable. This article not only introduces the concept but also illustrates its application with clarity and precision, making it an invaluable tool for beginners and seasoned developers alike.

Upon reading, I was struck by the depth of information presented. The article begins by defining stubs and differentiating them from other testing techniques such as mocks and drivers. It then delves into practical scenarios where stubs can significantly enhance the testing process, such as in unit testing and integration testing. The step-by-step guide on implementing stubs, complete with examples in popular programming languages, was particularly useful.

Reflecting on the content, I realized the importance of stubs in creating a controlled test environment. By simulating specific components, stubs enable testers to pinpoint errors more efficiently and focus on testing the functionality of individual units without the complexity of the entire system. This not only streamlines the testing process but also improves the accuracy of test results.

The application of what I learned from this article to my future practice is clear. I anticipate using stubs to conduct more effective and efficient testing, particularly in complex software systems where isolating components can be challenging. The hands-on examples provided will serve as a reference guide as I implement stubs in my projects.

For those interested in diving deeper into the subject, I highly recommend reading “A Comprehensive Guide to Stub and Mock Testing: Unveiling the Essence of Effective Software Testing” This resource has significantly enhanced my understanding of stubs in software testing and equipped me with practical skills that I look forward to applying in my future endeavors.

Resource Link: https://medium.com/@fideraphael/a-comprehensive-guide-to-stub-and-mock-testing-unveiling-the-essence-of-effective-software-testing-7f7817e3eab4

As we continue to explore the vast landscape of software testing, I am excited to share more discoveries and insights. Stay tuned for more reflections and learning experiences.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

Sprint 1

During this sprint it was very much of a learning process there was a lot of things that we had to do to first get used to working with teamsters and also with figuring out the scrum since it was the officially first time we were working on it as a “professional “ setting. As we worked together, we learned what we could do better in the next sprint. One of the things that we changed how we reviewed and worked on things. During some of the issues, we would assign a review and then have the review, review it, mark it as done and then have the original person that worked on it merge. That we learned took more time and there was more margins for error, therefore we decided that the reviewer would review and then they would just merge it and mark the issue as done. Another thing that we talked about improving on the team is communication, over all we had good communication but here and there we would forgot to say something about what we did and we had someone work on it doubled. Another thing we decided to do during this spring is when issues arise about during something we are working on to send it in the group or keep it in writing so that when it is time to come up with issues we have those to go back too. Since this time around when we were done with the sprint and it was time to write new issues we spent a lot of time going back and refreshing especially for the things that were in the initial part of the sprint. As an individual, I am trying to work on your review the issues as soon as it gets tagged. Sometimes it is hard because of my work schedule but I am trying my best so that if something does need to get fixed, that can be done as soon as possible so that we do not get behind. I think that this sprint even though we have more issues it will run more smoothly since we now know how the structure is and how it is supposed to go. A lot of last spring was figuring if the structure was right and if what we were doing was right. But now I feel more comfortable.

This was the issue that was used to plan out the test to make sure that the front end is compatible with and user friendly for this I had to do some research.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/28

Like the one above this was our non program ones, where we researched and came up with ways to enchance the checkInverotryfrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/27

This issue was to move commands and make it bins, we had a few of these and we separated it to team mates, mine was the ReportingAPI

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/21

This issue was set up to work with VSCode in Gitpod, since before we used devContainers, this was to switch it to gitpod

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/32

This was one we worked as in a group and thought that it was going be easier ended up being harder than we thought there for it carried on to the second sprint

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/26

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

Going into our first sprint, not only as a team together but as each of our first sprints individually, we were all on the same page with similar expectations. Those being that we would equally know just as little as each other. This mentality was good to have when we ran into issues that we knew ahead of time would take working as a team to solve. We had no idea what those issues would be, just that there were going to be plenty as this was a learning opportunity for each one of us.

Our team was tasked with setting up AlexJS linter and Gitpod extensions in select repositories in Thea’s Pantry. We tackled these tasks by dividing the work between us so that we would work primarily in one repository, with mine being the GuestInfoSytems/GuestInfoFrontend. This only worked for 3 of our members with the 4th having to work in a different repository for each issue. Looking back on this, only working in one repository makes working individually more organized but, as we found out later, would lead to less cross referencing and things being missed.

Other issues our team tackled during the sprint involved frontend testing. First we worked together to do research on open source frontend testing software that could be used in our project. This led us to understand how frontend testing works and what tests should be expected. With this knowledge, we investigated the frontends that were available to design the test that would need to be built in a later sprint.

What Worked Well:

Our team collaboration was by far our strongest feature. With all of us willing to work together and communicate, we were able to make sure that we all stayed on the same page throughout the sprint. Our team stayed in constant communication throughout, even in between meetings. This meant we could communicate times for meetings well ahead of when we wanted to have them, while still being flexible if something came up. When we were working together in a meeting it was either in person or over a discord call. These calls sometimes went on for hours. However, no one let that bother them when it came to getting the work done and sticking around to make sure we all understood what was going on.

What Didn’t Work Well:

The most notable issue we ran into was the weights of our issues. While on paper the issues seemed trivial, what we didn’t account for was the complexities of learning Gitpod and Gitlab. Navigating gitlab and handling pipeline commit message issues lead to the majority of the long nights and ultimately meant that none of our weights should have been a 0.

Team Improvements:

We were all working on the same or similar issues in different repositories meant we could do them together simultaneously. This led to all of our work this sprint being done during the calls with only minor issues being handled individually. While this made the work way more digestible at the start, it is important that we are able to handle issues individually in the future when we have to work on issues that don’t all align with each other’s. 

Person Improvements:

I noticed that a lot of, if not all, of my questions were answered in the documentation provided in the repository I was working in. Moving forward I am going to do better at fully looking through the documentation and files to get a better understanding of the project and how to approach issues.

Gitpod Issues:

Setup Gitpod environment and settings for GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/85

Issue to change commands to bin in GuestInfoFrontend was fixed prior to the sprint:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/82 

Worked on adding the AlexJS linter to the pipeline for GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/81 

Researched open source frontend testing software:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/86

Designed tests for GuestInfoSytems/GuestInfoFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/issues/87

Designed tests for InventorySystem/CheckOutGuestFrontend:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/36 

From the blog CS@Worcester – CS Learning by kbourassa18 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog

As the first sprint EVER, it went very well, and it provided significant learning opportunities.

Our team exhibited strong collaboration throughout this initial phase. Effective communication was a cornerstone of our approach, enabling us to schedule both online and face-to-face meetings efficiently. A testament to our collaborative spirit was achieving our target of completing more than 75% of the tasks by the sprint’s end. This success largely stemmed from our commitment to weekly in-person meetings, fostering a united team environment crucial for addressing new challenges and workflows.

Despite these positive aspects, our journey was not devoid of hurdles. We encountered several setbacks, primarily due to our collective inexperience with GitLab and its workflow processes. Initially, we struggled with navigation, issue postings, and branch creations, leading to confusion and delays. Our approach to merge requests and the subsequent review process also proved problematic, culminating in merge conflicts and pipeline failures due to our wait-until-the-end strategy.

In light of these challenges, we aim to refine our approach in the upcoming sprint. We plan to create a “Workflow tips” document, compiling our experiences and solutions from this sprint to circumvent similar obstacles in the future. We intend to adopt a more proactive review process for issues and streamline our approach to merge requests, ensuring they align with workflow requirements.

Reflecting on the obstacles I encountered this sprint, there are several areas for personal improvement:

Enhancing GitLab Skills: I recognize the importance of becoming more proficient with GitLab. I intend to invest effort into understanding its intricacies, especially concerning branch management, handling merge requests, and connecting issues. I plan to utilize online resources, seek guidance from tutorials, and lean on my peers for support to enhance my competency.

Strengthening Communication: Acknowledging the need for improvement, I aim to enhance my approach to communication. I will take initiative to seek out feedback more actively and clarify doubts promptly with team members and mentors, aiming to resolve issues before they escalate.

Boosting Organizational Capabilities: I understand that better organization is key to avoiding past mistakes. Therefore, I am committed to honing my organizational skills, particularly in keeping track of my tasks, associated merge requests, and issues. Employing project management tools or maintaining a personal task tracker will be instrumental in keeping me in sync with the team’s goals and deadlines.

Links to the issues covered in this sprint:

Create Integration and Pipeline

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/integration/-/issues/1

Settings and extensions previously located in the dev container should now be transferred to .vscode/settings.json and .vscode/extensions.json within the Gitpod environment, as outlined in the .gitpod.yml documentation. Furthermore, developer commands should be moved from the commands directory to bin to align with standard Linux conventions, necessitating updates in script paths and .gitlab-ci.yaml environment variables. Additionally, integrate the AlexJS linter into each project’s pipeline and the bin/lint.sh script, ensuring all documentation is checked and updated accordingly.

Familiarize ourselves with guestInfoFrontend to understand what goes into CheckoutGuestFrontend

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/37

This activity served as an introduction to the primary objectives of sprint 2. During this phase, we collectively reviewed the current wireframe for the checkout guest front end to familiarize ourselves with the anticipated design layout.

Refactor commands folder to bin

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/gitlab-profile/-/issues/69

This process entailed establishing a bin directory within the project and transferring three scripts from the template project into this new folder. Following this, I conducted tests on each of the three scripts to verify their functionality.

From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.

Building Skills with “Breakable Toys” Week-6

Cultivating Skills in a Safe Space:

“Breakable Toys,” a pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, advocates for the creation of personal projects or ‘toys’ that can endure failures. These projects offer a sandbox for experimentation, where learning and mistakes occur without the high stakes of a professional environment. This pattern underlines the significance of having a personal space to apply and test new skills and knowledge in a tangible, yet forgiving, setting.

A Concept That Inspires:

While I am yet to embark on a professional career in software development, the idea of “Breakable Toys” strikes a chord with me. It appeals to the part of me that believes in the power of hands-on experience and learning through doing. The notion of constructing a personal project where the risk of failure is not only permissible but encouraged, is both liberating and exciting, especially for someone preparing to enter the tech industry.

The Freedom to Experiment:

What I find most intriguing about this pattern is the emphasis on the freedom to experiment, innovate, and yes, even fail. In the realm of these personal projects, the usual barriers and fears associated with failure are reduced, paving the way for creativity and exploration. This approach makes “Breakable Toys” not just a learning exercise, but a crucible for innovation and self-discovery.

Anticipating Its Impact on Learning:

The concept of “Breakable Toys” has already begun to shape how I envisage my approach to learning and development in software engineering. It reinforces my belief in the importance of engaging in personal projects as a fundamental part of my learning journey. This hands-on practice will be key to transforming theoretical knowledge into practical expertise.

A Balance Between Play and Purpose:

While I am enthusiastic about the potential of “Breakable Toys,” I also recognize the importance of balancing these personal explorations with goal-oriented learning. It’s essential that these projects are not just about exploration but also about advancing specific learning objectives or developing particular skills.

In conclusion, the “Breakable Toys” pattern presents a compelling approach for anyone aspiring to grow in software development. It highlights that mastering this field involves not just structured learning but also unstructured, creative experimentation. By building and experimenting with personal projects, one can cultivate a deeper understanding and a more versatile skill set, all within a context where failure becomes a stepping stone to innovation and mastery. This pattern celebrates the idea that sometimes, the most valuable learning experiences come from the freedom to break things and learn in the process.

From the blog CS@Worcester – Kadriu's Blog by Arber Kadriu and used with permission of the author. All other rights reserved by the author.