Category Archives: CS-448

Sprint Retrospective #3

Overall, I believe the second sprint went well. Like the previous sprint, we had meetings in person or over discord. All in all, I believe we all did a fantastic job of keeping each other updated and asking each other questions when we got stuck. I noticed that once we finished one issue, nobody hesitated to start another issue which really helped us with moving the project along. During this sprint, we worked on several of the issues as a group. We kept up the open-mindedness, accountability, honesty, and respect that were originally described as the culture we hoped to establish in the working agreement. Like in the previous sprints, we determined the maximum amount of work that each person should attempt to finish in order to split the work fairly and equally in regards to the issues we had, and we mostly adhered to it.

I worked on multiple issues that involved verifying that the pantry projects had the correct extensions, linters, and pipeline stages. Like the last sprint, I looked over the project’s file types, created a list of required linters based on the files, added any new linters, verified that the new linters passed, verified which stages were required, and adjusted the stages as necessary. For this type of issue, I worked on “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – InventorySystem General” by myself and then worked on “Verifying that InventoryAPI has the correct extensions, linters, and pipeline stages” and “Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – Inventory Backend” with the group. When working on the issue for InventorySystem General, I realized that the build and test scripts weren’t needed so I also removed those files. I also worked on “Determine what needs to be done on GuestInfoFrontend” with the group. For this issue, we reviewed comments left in the code, wireframe, and documentation. Then if any work worthy of note needed to be done, we created new issues for them. We created these issues (“Moving “Other Assistance” attribute” and “Moving Receiving Unemployment Attribute to Assistance”) and linked them to the initial issue. 

I think we did really well as a team for this sprint. We did not get around to establishing a method that will guarantee that particular individuals are not examining the majority of issues, as we had originally intended when drafting our working agreement. For this sprint, we did not discuss how we would make sure to stay on top of issues that needed to be reviewed because many of the issues included us working together and we stayed on top of a lot of the issues. The time frame between finishing an issue, reviewing, and merging was a lot shorter than the last sprint. We made sure to constantly communicate with each other and the first one that could review an issue took the task. As a group, I can see that we improved a lot in that regard but I still think we could establish a method to make sure that reviewing code is not done mainly by a few individuals in the group. As an Individual, I showed a lot of improvement by checking on what needs to be done compared to the previous sprints but I think I can still improve when it comes to merging my issues as quickly as possible after they’ve been reviewed.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Finding Your Different Road in Career

Introduction

In the journey of our careers, it’s not uncommon to reach a point where the road we’ve been traveling no longer feels right. Maybe it’s the urge for more time with family, the pursuit of a new passion, or simply a desire for change. Whatever the reason, it’s important to recognize that diverging from the familiar path doesn’t mean getting lost.

Sometimes, after diligently following the path laid out before us, we realize that it’s not leading where we want to go. The “Different Road” pattern acknowledges this pivotal moment, encouraging us to reflect on what truly matters to us.

Letting Go of the Long Road:

Embracing change often means bidding farewell to the familiar. Whether it’s stepping away from a successful career in software development or leaving behind a role we’ve invested years into, it can be daunting. However, the pattern reminds us that this departure doesn’t have to be permanent. Instead, it’s an opportunity to explore new horizons and grow in unexpected ways.

One of the most valuable aspects of taking a different road is recognizing that the journey doesn’t erase the experiences we’ve accumulated. Like Dave, who transitioned from family therapy back to technology, our skills and insights remain with us. Whether we’re teaching, parenting, or pursuing other passions, the problem-solving mindset and analytical skills we honed as software developers enrich our new endeavors.

Navigating Challenges

Leaving the Long Road might come with its own set of challenges. Some may fear judgment or difficulty reentering the software development field after a hiatus. However, as Larry’s journey illustrates, the skills acquired in one domain are often highly transferable. Additionally, the experiences gained from pursuing other interests can bring fresh perspectives and creativity to our work when we return.

If you find yourself considering a different road, start by exploring what else you might enjoy doing. List potential jobs or pursuits that intrigue you and speak to people who are already on those paths. Hearing about their experiences and comparing them with what you love about software development can provide valuable insights.

Conclusion

Embracing change in our careers can be both exhilarating and challenging. However, by recognizing when the Long Road is no longer the right path for us and bravely venturing onto a different road, we open ourselves up to new possibilities and opportunities for growth. So, if you’re feeling the pull of a different road, remember, it’s okay to take that leap. Your journey is yours to define, and the experiences you gain along the way will shape you in ways you never imagined possible.

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Drawing Your Own Career Map

Have you ever felt like your career path doesn’t quite fit the mold provided by your employer or the traditional trajectory laid out by society? You’re not alone. In fact, many professionals find themselves in this position, yearning for something more but unsure of how to break free from the constraints imposed by their current roles.

Enter the concept of “Drawing Your Own Map.” This pattern, inspired by real-life stories and experiences, encourages individuals to take the reins of their career paths and chart a course that aligns with their aspirations, interests, and values.

Imagine this: you’re at a crossroads in your career, feeling dissatisfied with the options presented to you. You realize that your employer’s idea of your career path doesn’t quite match your own vision. What do you do? You draw your own map.

This concept urges you to identify an ambitious yet logical next step for your career, irrespective of what your employer or career counselor may suggest. It’s about taking ownership of your professional journey and understanding that you have the power to shape it.

But how do you go about it? Start by visualizing the smaller, interim steps needed to move forward. These steps may seem insignificant at first, but they generate the momentum necessary to propel you toward your goals. It’s about taking that first terrifying step, even without a perfect plan, and trusting that you’ll figure it out along the way.

One of the most thought-provoking aspects of this pattern is its emphasis on defining small, achievable goals. By breaking down your aspirations into manageable tasks, you not only make progress but also gain valuable feedback that informs your journey.

Perhaps what’s most inspiring about this approach is its recognition that there’s no one-size-fits-all path to success. Each individual’s career map is unique, shaped by personal values, interests, and circumstances. It’s about finding your own route through the wilderness, even if it means deviating from the norm.

Now, you might be thinking, “But what about external constraints? What if economic conditions or family responsibilities limit my options?” Valid concerns indeed. The pattern acknowledges these challenges but encourages you to find creative solutions and challenge accepted norms.

In conclusion, drawing your own career map is about embracing personal agency, taking calculated risks, and continuously adapting to change. It’s about recognizing that your professional journey is yours and yours alone, and you have the power to redefine it at any time. So, grab a pen and start drawing your map. Who knows where it might take you?

From the blog CS@Worcester – CS: Start to Finish by mrjfatal and used with permission of the author. All other rights reserved by the author.

Retreat into Competence

Retreat into competence is a pattern that involves taking a break from a challenging task to work on something you are more comfortable or confident in. This helps a developer reflect on how far they have come and can keep them motivated to move forward. Patterns may emerge that show how you got proficient in that task. These patterns can then be used to advance your current tasks. Motivation can also be a problem if someone is constantly getting stuck on a task, or just not being able to progress a project forward. Being able to step back and complete a more familiar task can help keep up the drive during the long road.

This pattern really popped out at me originally for the “Context” and “Problem” sections, as I have felt very overwhelmed many times finishing up my college degree. There have been countless times that I have questioned if I have learned enough for my degree. Each semester felt like it only introduced me to a whole new branch of computer science that I didn’t know. Even the classes that had focused on more advanced topics still felt like it was only just the tip of the iceberg.

There have been a few times this semester that I have been stuck on an issue and just could not figure out where to start looking for a solution. It can be really demotivating when you are unable to complete a task that other people are relying on you to complete. Taking the time to work on another issue helped me in both ways mentioned above. Solving an issue that I was confident I could do made me realize what steps I needed to follow to work on the other issue. Not only this, but being able to actually complete an issue kept my motivation up as I felt like I was contributing to the team.

When I first read through this pattern I originally thought mostly about the motivation and satisfaction aspects of being able to complete a task that is familiar to you. However, as I read through it and began to understand more about what you could learn from working on more approachable projects. Paying attention to and understanding the patterns and steps one takes to solve familiar problems can be used to solve new or challenging issues.

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

Stay in the Trenches

The “Stay in the Trenches” pattern is a reflection of the temptation to prioritize promotions and managerial roles over staying engaged in programming, which is usually a developer’s passion. This pattern draws attention to the societal pressure to achieve success with upward mobility, highlighting the importance of sustainable motivations and the long-term commitment required for mastering software development. The pattern begins by addressing the common idea of being offered a promotion away from programming due to someone’s proven track record of delivering amazing work. While promotions are usually seen as signs of success this pattern challenges that notion. It emphasizes the risk of losing touch with the craft and the journey toward mastering when you step away from programming roles. The solution is to resist the given promotions that take you away from programming. Instead, it encourages people to negotiate with their employers for alternative forms of recognition and rewards that allow them to stay in programming. These alternatives may include increased pay or non-traditional technical leadership roles that still involve hands-on coding.

The main message of the “Stay in the Trenches” pattern is about keeping the passion for software development. Its about staying true to one’s love for coding and finding ways to balance career growth with meaningful work in programming. By rejecting promotions that lead away from programming, individuals can maintain their passion and commitment to the craft. This pattern challenges the usual idea of success and encourages to rethink of what truly motivates us in our careers. It helps remind us that staying connected to our passion and purpose is important for long-term fulfillment and excellence in software development. This pattern has made me rethink the usual idea of career advancement and success. It shows the importance of staying grounded in what I love to do and finding ways to align my career growth with my passion for programming even though the idea of the promotion maybe. This pattern has changes the idea that true success lies in finding joy and fulfillment in the work we do, even if it means resisting the loads of promotions that might take us away from our passion. The “Stay in the Trenches” pattern is a important pattern that reminds us to nurture our passion for software development by staying engaged in programming roles. It challenges us to focus on meaningful work over success and encourages us to negotiate for rewards that relate with our motivations and values.

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.

CS-448: Week 14

Retreat into Competence

This pattern is about how it is easy to get caught up in constantly learning new technologies due to the fast pace of software development, and how to manage the intense pace of learning. The pattern highlights the importance of taking a step back from the fast paced learning and to focus on honing existing skills. Trying to learn the latest tools, frameworks, and methodologies can be overwhelming. Along with the overwhelming feeling of trying to learn many skills at once, there is also a risk of never fully mastering the fundamentals. Therefore it is important to take a step back, and take time to practice fundamental skills.

According to the pattern, being an apprentice is a rollercoaster ride. This is because there is the thrill using newly learned skills to deliver value to the customer, but there is also the terror of realizing how little is known compared to more experienced craftsman and experts. However both are normal and inevitable experiences.

Although the pattern encourages developers to take a break from learning new skills, it also emphasizes how retreating back to competence is to not get stuck in the realm of competence. It is important to be intentional when retreating, as this pattern is only a short term fix. Spending too much time on this pattern can lead to halted learning. Being able to learn something new is a skill in itself; therefore, learning should be practiced unlike any other skill.

In order to prevent the pattern being used, setting a time limit for honing new skills is useful. This is so one does not focus too much on retreating, and helps them stay in the habit of learning new skills. A strategy the pattern suggests is to pick a well understood topic that is self contained, and to reimplement it. This can help regain confidence to propel learning.

Conclusion

I found this pattern to be interesting as constantly learning new technologies can be tiring, so having a strategy to regain confidence is helpful for the future. I particularly enjoyed the analogy of a catapult to represent this pattern. The analogy being that the skill of learning new topics can be launched forward by taking a step back. The pattern has changed the way I view learning new skills, and maintaining old ones.

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

CS448 Software Development Capstone – Apprenticeship Patterns – “Confront Your Ignorance”

For my final Apprenticeship Patterns reflection, I want to talk about the “Confront Your Ignorance” pattern in the second chapter, “Emptying the Cup”. In the last sprint of our software development capstone course, I felt that I wasn’t able to deliver my best work – partly because of how undeveloped my unit testing design skills are, and partly because I caught a mild cold partway into the sprint that zapped my energy levels. If I want to be honest though, the former problem was the more severe of the two, and it will stick around far longer than the sniffles I had. I’ve realized how much more I need to study the technologies I’ve been working with. In combination with the “Reading List” and “Record What You Learn” patterns, I want to put this pattern into action over the summer break and establish a disciplined reading and studying habit for software development topics.

In addition to the unit test design, there were other parts of the work I took part in over the semester that I didn’t completely understand before it came time to implement them. Docker is one subject I want to take the time to research in further detail, since it was an essential component of our work. I first encountered Docker last semester, but it wasn’t until this semester that I’ve understood what the purpose and benefits of virtualized containers are. I know now that Docker allows development teams to create applications within a common virtual operating system. What I want to learn more about is how to write docker-compose files to initialize a functional HTTP backend server. One of my tasks this sprint was to do just that for one of the backend microservices in Thea’s Pantry, and I wouldn’t have been able to do that if there wasn’t a complete docker-compose file in another backend that I could adapt for the repository I was working in.

The largest gap that in my knowledge that I’ve been wanting to address is my technical skill with Java. Java has been the language that I’ve accomplished the most with, next to Python, but I haven’t taken the time to write any Java this semester besides the foundations of my MonsterFactory project, which I realize now could qualify as an example of the “Breakable Toys” pattern from the textbook. Over the summer I think I would like to implement my studying of unit test design into the MonsterFactory and create some tests for the abstract factory classes.

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

Walking the Long Road

The “Walking the Long Road” pattern goes into the journey of mastering software development, by tracing a new pathway to a summit rather than just conquering the same peak. This pattern reflects the challenges and rewards of pursuing excellence in software craftsmanship over a lifetime. The pattern begins by talking about the common practice of displaying training and achievement certificates as a sign of expertise. It shares the story of a developer named Dave, who relied on such certificates to validate his skills. However, through interactions with amazing developers, Dave realized the depth of knowledge and continuous learning required to become better in software development. One main idea of this pattern is the recognition of software development as a lifelong learning journey. The idea of mastering it highlights the dedication, discipline, and ongoing commitment needed to reach the highest levels of skill and understanding.

The pattern emphasizes the importance of embracing challenges, staying focused on long-term growth, and valuing learning opportunities over rewards or promotions. The impact of this pattern has me want to keep taking the approach of embracing any challenges and enjoy learning more about software development. It changes the idea that mastering software development is not a destination but a continuous process of improvement and exploration. It encourages so many people including me to prioritize learning, experimentation, and embracing the face of challenges. While the pattern talks about a focus on software development mastery, it also shows that different career paths in the industry are valid and beneficial in the long run. It encourages individuals to find a career path that works with their values, passions, and long-term goals, even if it means navigating tough challenges along the way. This pattern has changed my perspective on career development in software development. It has taught me the value of patience, perseverance, and a growth-oriented mindset. It has also inspired me to keep embracing the journey of mastering software craftsmanship with dedication, knowing that every step along the road contributes to a deeper understanding and appreciation of the craft. The “Walking the Long Road” pattern is a reminder of the nature of software development mastery, the importance of learning, and the rewards of staying committed to a path of continuous growth and improvement in software development.

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.

Unlocking Success Through Understanding Failure

Throughout the long road of lifes, we always strive to find success, but sometimes we may hit roadblocks and fail. Some of us choose to accept those failures and learn from them, but others may neglect those failures and choose to take an alternative route. The Learn How You Fail pattern, emphasizes the importance of embracing failure. Embracing failure is a crucial aspect of not only personal growth but also professional growth. This pattern encourages us to look for our weaknesses and patterns of failure, and instead of avoiding them, accepting and learning from them. If we can gain knowledge on how, why, and what led to our previous failures, we can learn from them, make adjustments, and pave a path to success in the future.

When we think of the word failure, we often think that it carries a negative connotation, referencing setbacks or disappointments. Yet, in our journey as aspiring craftsmen, failure is not just part of our professional learning, it is possibly one of our greatest teachers. We’ve all experienced some sort of failure at some point in our lives. But the most important part of dealing with failure is pinpointing why we failed, fixing it, and taking those issues head on.

I found this pattern to be extremely interesting considering many people give up after they fail. Failure isn’t something that should be feared or avoided. Instead it should be embraced as a catalyst for learning and self development. It underscores the idea that true growth comes from a willingness to confront our failures and adapt. What I find particularly interesting about this pattern though, is its emphasis on self-awareness and introspection. By actively seeking to understand our patterns of failure, we can empower ourselves to make better decisions about our personal and professional development.

After reading more, I was able to connect the pattern to the software development field. In the field, we cannot just expect to find success. Through lots of learning, practice, and trial and error, we can eventually find success. Instead of viewing failure as a setback or embarrassment, I view it more as an opportunity for reflection and growth. I now realize the importance of acknowledging my successes but also embracing my failures as learning experiences. In the future, I plan on having a more proactive approach towards identifying and addressing any of my weaknesses, rather than just ignoring them.

With this being said, the Learn How You Fail pattern, offers valuable insights into the importance of embracing failure as a means of personal and professional development. By learning from our failures, we can ultimately find success in our chosen fields.

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 #3 Retrospective

What Worked Well:

Sprint #3 was our last sprint as a team and appeared to be one of our easier sprints since we were all familiar with our team workflow, who was doing what, and reviewing processes. In Sprint #3, we were tasked with completing seven different issues for a total weight of 25 points. As a whole, we completed six out of our seven issues for a total weight of 24 out of 25 points. We managed to complete many issues as a team, which was extremely helpful. By combining five minds, we could work in an efficient manner. Something worth noting was our communication this sprint. In all three Sprints, we conducted weekly meetings either in person or over Discord. Additionally, we had weekly standup meetings informing the group with what everyone was currently working on, doing next, or needs help with. I noticed that once we finished one issue, nobody hesitated to start another issue. This helped propel the project forward. Connecting all three sprints, Sprint #1 was a learning process, Sprint #2 was learning how to efficiently work with each other and complete tasks in an effective manner, and Sprint #3 was combining everything we have learned and putting it together. Sprint #3, whether it was our workflow, completing issue process, review process, or communication, we were able to combine everything and find success. One thing I particularly enjoyed was the comments we made on issues. Everyone on the team wrote comments informing the team what was going on within an issue, what the issue needed for completion, and any changes made to contribute.

Improvements As A Team:

We made some drastic improvements from the previous sprints in regards to how we took on work, the time we worked on it, our review process, and much more. Considering this is our final sprint as a team, I believe we are more than capable of bringing what we have learned into the workforce. To continue growing individually on our own teams, I believe it would be important to continuously build on communication. Regardless of the group or team we are on, it’s important to always provide updates, feedback, and details upon what we are working on, completing, any problems, any help needed, and so on. By continuously building on communication, asking questions, and continuing to refine and develop our skillset, we can set ourselves up for success in the future regardless of the team we are on. 

Improvements As An Individual:

During Sprint #3, I was able to work on four different issues. My first issue I completed individually and it was Update and Review InventorySystem/Documentation. This issue required me to go through the different files and add any files, comments, or updates, so that everything was corrected for future sprints. My other three issues I completed with my team included, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryAPI, Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages in the InventorySystem/InventoryBackend, and Determine what needs to be done for GuestInfoFrontend. For the Verifying issues, these involved adding and enabling the different linters in our system and testing their respective pipelines to ensure they passed. If they didn’t pass, we needed to go into their specific files to make changes to correct them. For the Determine what needs to be done for GuestInfoFrontend, involved the team building the frontend to view its contents and code. Here we created new issues for future sprints in regards to what needs to be completed, what can be changed or implemented better, and how we can improve the GuestInfoFrontend. For individual improvements, I’d like to continue being more of a team player where I’m open to help and support anyone on my team and voice my thoughts and opinions. Even if it’s just reviewing work and mentioning some tips or ideas, it can be extremely valuable. Additionally, when writing code or fixing documents, I’d like to add more comments. By doing so can allow anyone to understand my thought process while I’m working on issues. It would also allow other people to understand my work and not get lost or confused, allowing for anyone to contribute, add on, or provide feedback on what I’ve completed. Keeping that in mind, I believe it’ll help me grow as an individual and a teammate, and help me in numerous ways with my 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.