Category Archives: CS-448

The Power (and Curse) of Retreating into Competence

This week, I chose to read the “Retreat into Competence” pattern and found its overall message quite interesting since I see it as a helpful but potentially harmful one. It suggests that when faced with challenges that can leave me feeling overwhelmed or upon realization of my limitations, I should temporarily retreat into known territory to prepare myself to confront the unknown. Doing so will enable me to rebuild my confidence and be able to prepare myself to tackle any challenges that may lie waiting in my future career. While retreating can be helpful, it may end up being harmful and the pattern also highlights the importance of setting time limits for retreat to avoid it from becoming an issue. Setting time limits and asking for help from mentors will ensure if I feel that I must retreat into competence in the short term, it won’t lead to the stagnation of my development in the long term.

I believe that setting time limits for a retreat into competence is vastly important in keeping one’s journey into evolving from an apprentice on the proper path. It works toward preventing people from becoming complacent or stagnant when returning to their competencies. Placing limits encourages an environment where one can gather thoughts and pool together any necessary resources before returning to the thick of it promptly. Asking for help from mentors is also important in aiding to overcome obstacles. Even if something may seem overwhelming at first approach, with the guidance of others, such may appear a lot more manageable than it had before.

I think the pattern provides a good framework on how to deal with my limited knowledge due to my lack of practical experience. It’s common for anyone to feel overwhelmed by new things, especially in the early stages of learning or taking on new challenges upon transitioning from a learning environment into a professional environment.

I have to also mention that the notion of retreating into competence can be helpful but it also may be harmful if not done correctly. It may be helpful, but making a habit out of retreating may result in taking fewer risks even when establishing time limits. I feel as time goes on, the necessity of retreating may fade away, but if a habit of retreat is developed and relied upon too much, it may do more harm than good in the long run.

Overall, I think the “Retreat into Competence” pattern sets a solid framework for new apprentices to follow by destigmatizing the fear of the unknown. It shows retreating when faced with a challenge can be beneficial if used correctly.

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.

sprint 3 retrospective

This sprint, the bulk of my time was spent looking into ESLint and keeping up with the team to ensure that we are meeting our goals. I also made a tentative branch for how the pipeline should look like after the linters are added, as these changes were never pushed by the team that was in charge of actually putting the linters in the ReportingAPI repository. I also participated in a clean-up of previous issues that were completed, and reviewed some merge requests from team members.

ESLint Research and Configuration: I checked to see if ESLint could theoretically fulfill the needs for an active linter that shows JavaScript syntax errors in the editor, and it seems like with proper configuration it does fit that role. I found that the ESLint version we currently use is out of date, and the old style of configuration file (.eslintrc) was hard to get working properly. With the new format for ESLint configuration, I found that ESLint needs to probably be installed locally in order to have this take effect properly, and that we should update the ESLint version we use in LibreFoodPantry to adopt the new configuration standard.

Pipeline Configuration: I configured the pipeline based on the GuestInfoBackend repository, and it currently fails because there are no linters actually installed in the repository. The idea is that when the linters are merged into the main branch, this pipeline branch should fetch those changes, push them to the branch on GitLab, then check to see if the pipeline does work correctly with that. Theoretically it should.

Cleanup ReportingIntegration: I checked over the work I did in this repository and it looked fine. I also adjusted Hieu’s branch where he cleaned up some of the documentation.

Cleanup ReportingBackend: I checked over the work I did in this repository and it looked fine.

We had some logistical issues again this sprint, but ended up completing nearly all of the work that we set out to do, thankfully. The problem was that there was a kind of rush during the last few days leading up to the sprint review, which led to me having to take charge as scrum master and keep up with each group member actively in the days leading up to the review to make sure everything was completed. That being said, our communication was the best that it has been this semester during this sprint, the one issue I was consistently having is that we should be sharing communication with each other, but team members were direct messaging me personally for issues they were having.

On my part, I do think I could’ve spent more time with the ESLint issue and also looked into other solutions, but I definitely was feeling crunch from other courses and ended up putting the work for this course on the backlog while other courses were piling work on me. I’m happy I got to a relatively satisfying conclusion with the issue, but I feel like I could’ve done more. On the part of being scrum master, I performed much better at keeping everyone on task by checking in every week, though I could’ve been a little more strict so there was less crunch at the end of the sprint.

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

Sprint-3 Retrospective Blog Post

Tasks/Issues that I worked on in Sprint-3:

1. Cleanup and Enhancement (Reporting Backend) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/79):

Assigned alongside Isaac, Victor, and Andi, I undertook the task of consolidating enhancements made to the reporting backend during earlier sprints. My role involved conducting a thorough review to ensure clarity and accessibility for future developers. While I completed the task successfully, I acknowledged the need for additional time to refine code cleanliness further.

2. Documentation Review (Documentation Repository under Reporting System) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/documentation/-/issues/11):

Independently assigned, I reviewed the reportingsystem documentation repository to identify any inaccuracies. After a comprehensive review, I found the repository to be accurate and well-structured, requiring no immediate changes. However, I recognized the importance of ongoing documentation maintenance to keep information up-to-date.

3. ReportingIntegration Documentation Update (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/merge_requests/10/diffs?commit_id=c972ae9723af3eefcf3d2f09b4827c9c942b368c):

In another individual task, I updated the reportingintegration documentation to reflect recent changes. This included updating the lint.sh file to ensure proper linting functionality and modifying file paths for improved readability. Despite encountering an issue with dead links, which I consulted with our professor about, the documentation updates were otherwise successful.

4. Code Cleanup and Refactoring (Reporting Integration) (https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingintegration/-/commit/ece7535bbd6e9c5901083e541fb450dcbb9466b8):

Collaborating with Victor, I worked on cleaning up and refactoring code within the Reporting Integration module. This involved rewording, rephrasing, and highlighting phrases in documentation files to enhance readability. While completing this task without issues, I acknowledged the need to dedicate more time to code cleanliness for improved team collaboration and understanding.

Reflection on what worked well:

Improved Docker Pipeline Configuration: We successfully configured Docker pipelines, addressing path issues and ensuring smooth file copying into containers, enhancing our development workflow.
Effective Scripting: Our development efforts were streamlined with the implementation of scripts like bin build and push.sh, contributing to efficient Docker operations and backend development processes.
Communication and Task Management: Clear communication through GitLab issues and effective task management ensured that team members were aligned, contributing to productivity and progress tracking.

Reflection on what didn’t work well:

Linter Configuration Challenges: We faced difficulties in setting up linters, particularly with es.lint configuration files and syntax checking, impacting code quality validation.
Docker-compose Issues: Challenges arose in creating Docker Compose files that adequately handled starting MongoDB, RabbitMQ, and backend services, causing complexities in deployment.
Dependency Management: Struggles with dependency management led to inconsistencies in development environments across team members, hindering collaboration and code compatibility.

Reflection on changes to improve as a team:

Enhanced Teamwork and Collaboration: We aim to foster a stronger collaborative environment where team members assist each other with tasks and share knowledge effectively, improving productivity and problem-solving capabilities.
Improved Documentation and Knowledge Sharing: Documenting processes, configurations, and troubleshooting steps will facilitate smoother workflows, onboarding for new team members, and better understanding of project intricacies.
Streamlined Development Processes: Automating repetitive tasks like linting and formatting will reduce manual effort, enhance code quality, and ensure consistent development standards across the team.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

448 Last Sprint

Last Sprint Retrospect.

This sprint introduced something different then out  usual approach, as we embraced a more flexible and independent way of working but still in a team setting. Allowed to choose our own tasks, each team member assumed ownership of their respective assignments, encouraging a sense of accountability and purpose within the team. This new self-sufficiency was complemented by a sense of collaboration, where team members voluntarily offered assistance and support whenever needed, ensuring that our group efforts flowed seamlessly towards our common goals.

Throughout this sprint, my role primarily centered around the essential task of tidying up loose ends from previous iterations. From closing redundant branches to resolving trial-and-error issues, I found myself assuming the role of the team’s cleanup crew, diligently organizing and optimizing our GitLab repository. While the task was undeniably lengthy, the satisfaction of viewing our codebase evolve into a leaner and more simplified object made the effort worthwhile.

However, amidst our collective productivity, a significant challenge surfaced: the shortage of possible epics to reach our sprint points . For several weeks, we faced with the search of new task of identifying new projects and enhancements to strengthen our workload. We look high and low, in other groups past epics to search for anything tat we thought could make this project ran more efficient. It took a couple of days until we finally had enough points to reach our goal. Despite the challenges we encountered, the sprint unfolded with remarkable smoothness. The organized cooperation within our team, coupled with our solid dedication to excellence, pushed us forward.  While the cleanup work demanded meticulous attention to detail and patience, it served as a evidence to our team’s commitment to maintaining high requirements.

Reflecting on the semester as a whole, I am struck by the profound educational value of our experiences. Beyond the mere acquisition of knowledge, this class has equipped me with valuable skills and insights that go beyond the limits of academic world. From mastering the art of collaboration, every aspect of our semester has left an indelible mark on my professional development.

As I board on my future career, I am grateful for the transformative impact of this class, which has not only enriched my skill set but also shaped my outlook and approach towards work and collaboration. The lessons learned and experiences gained during this sprint, in particular, have reinforced the importance of adaptability, resilience, and the pursuit of excellence in the face of challenges. Prepared with these invaluable lessons, I am confident in my ability to navigate the complexities of the professional world with confidence and competence.

Evaluate current state of CheckInventoryFrontend (#41) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / CheckInventoryFrontend · GitLab

Clean up GuestInfoFrontend (#100) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoFrontend · GitLab

Check documentation for GuestInfoFrontEnd (#99) · Issues · LibreFoodPantry / Client Solutions / Theas Pantry / GuestInfoSystem / GuestInfoFrontend · GitLab

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

CS-448 Week 13 Nurture Your Passion

The pattern “Nurture Your Passion” is compelling to me as a software developer who is learning the importance of maintaining enthusiasm and dedication in a challenging work environment. It acknowledges the common struggle many developers face when their passion for the craft is interrupted by factors such as corporate hierarchies, project pressures, or negative workplace dynamics.

What I find compelling about this pattern is its emphasis on taking the right steps to protect and grow one’s passion for software craftsmanship despite adversity getting in the way. It also addresses that while external factors may be discouraging, there are still actions individuals can take to sustain their enthusiasm and commitment to their craft.

I have personally experienced times when my passion for software development wavered due to demanding project deadlines, different obstacles, and lack of recognition. However, this pattern reminds me that while it may seem tough at times, my passion is worth preserving and that I have the tools to nurture it.

One of the aspects this pattern provides that resonates with me is the importance of setting boundaries between work and personal life. Prioritizing self-care and making time for out-of-work activities that help rejuvenate my passion allows me to maintain a healthy balance and prevent burnout.

The pattern also underscores the significance of continuous learning and seeking out like-minded peers for support. Professional development opportunities as well as connecting with colleagues who share my enthusiasm for software development can provide me with valuable inspiration and encouragement.

Reflecting on this pattern has reinforced my belief in the adaptability and resilience of software developers. It has reminded me that while external factors can influence the work environment, I have the power to carve my own experience and continue my passion for the craft.

If anything, this pattern has confirmed my intended profession and pursuing a career in software development. There have been times that I considered trying a different career path, but reflecting on this pattern has showed me that my belief and dedication are essential qualities for success in this field, and that overcoming challenges can lead to personal growth and fulfillment.

Overall, I agree with the principles outlined in this pattern. It serves as a reminder that passion is not something that is given, but rather it is something that should be nurtured and protected, especially when facing adversity. By embracing this mindset and taking the right steps to maintain my passion, I am confident that I can thrive as a software developer despite any obstacles I may encounter.

3. Walking the Long Road | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows: Shortcutting the Path to Software Mastery

The “Rubbing Elbows” pattern advocates for software developers to actively seek out opportunities to work hands-on, side-by-side with other skilled programmers. The core premise is that certain techniques and micro-habits can only be absorbed through close collaboration on shared coding tasks. Practices like pair programming try this kind of knowledge transfer, but the pattern applies to any endeavor that allows you to observe the workflow and decision-making of an experienced developer.
I found this pattern incredibly insightful and motivating. As a software engineering student, I’ve already experienced how much more I can learn by watching lecturers code and explain their thought process in real-time, versus just reading examples. The “Rubbing Elbows” pattern highlights how that same example of accelerated learning through consistency well beyond the classroom.
The authors make an good point that there are “thousand little everyday moves” that skilled developers have pressed through years of experience. These small refinements may seem minor on their own, but include into real improvements in productivity, code quality, and problem-solving prowess. However, these micro-habits are nearly impossible to fully carry through written documentation or formal teaching. Rubbing elbows allows an apprentice to organically absorb them through repeated, intimate observation.
I’m reminded of when I pair-programmed on a school project with a talented classmate. While daunting at first to have my code exposed, I soon realized I was gaining insight into his mental models, techniques for juggling complexity, and little shortcuts that markedly lifted his coding flow. Rubbing physical and mental elbows enabled knowledge transfer that couldn’t have occurred through solo learning.
This pattern has inspired me to be a go getter about joining open source projects, participating in local meetups, and seeking out internships that enable close collaboration with experienced mentors. Identifying and creating these “rubbing elbows” opportunities will be important for go beyond my current peak and speeding my progression as a capable, well-rounded software crafter.
While the unusual feeling of being the “newbie” amongst experts is unavoidable, I’m excited by the authors’ advice: embrace feeling lost at times, ask questions, rotate pair partners if stuck, and record learnings to cement them. Absorbing the tacit knowledge of those further along the path is key to rapidly elevating my own skills.

andicuni
April 28, 2024

From the blog CS@Worcester – A Day in the Life as a CS Blogger by andicuni and used with permission of the author. All other rights reserved by the author.

Pattern: Expose Your Ignorance

Summary: “Expose Your Ignorance” advocates for honesty and humility in software development by encouraging developers to openly admit what they don’t know and actively seek learning opportunities. The pattern emphasizes that expertise is a result of the learning journey, not the end goal, and that building trust within teams is essential for growth.

Reflection: I really resonate with the idea of embracing ignorance as a natural part of learning, especially in an industry where it feels like you need to know everything. Admitting what we don’t know can be tough, but I’ve learned that it actually creates a better environment for learning.

Embracing Vulnerability: Admitting that we don’t know something can make us feel vulnerable, but it’s also a powerful way to build trust within our teams. Being humble and honest about our knowledge gaps encourages others to do the same. It creates an atmosphere where asking questions and seeking help are seen as strengths rather than weaknesses.

Shift in Mindset: It’s a real game-changer to shift our mindset away from always needing to appear competent. Instead, focusing on showing our ability to learn and adapt makes us more resilient. It takes away the fear of failing and makes us more willing to take on challenges. Plus, it encourages us to keep improving, which is crucial in such a fast-paced field.

Craftsmanship Analogy: Comparing software development to craftsmanship really speaks to me. Like a craftsman honing their skills, we need to keep expanding our knowledge base. It’s not about being an expert right away, but about constantly growing and learning. Expertise comes with time and practice.

Personal Experience: I’ve seen firsthand how embracing ignorance has helped me grow both personally and professionally. Being open about what I don’t know and actively seeking to learn has boosted my confidence and strengthened my relationships at work. Asking questions and being open to feedback have been key in my development as a developer.

Conclusion: “Expose Your Ignorance” is a great reminder that it’s okay not to have all the answers. By embracing our ignorance and actively seeking knowledge, we create opportunities for growth and improvement. It’s a lesson I’ll definitely keep in mind as I continue on my career path.

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.

CS-448: Week 12

The Deep End

“The Deep End” pattern is about feeling unsatisfied with the path taken when learning new skills. The path taken has been small, safe steps that has made the learning process plateau. A way to jump start the learning process is by challenging yourself with bigger things such as bigger projects, working with larger teams, more complex projects, etc.

A solution to this pattern is to jump into the deep end, rather than waiting until you are ready. This is because the latter can lead to never starting anything, or challenging yourself to learn new skills. When a difficult problem occurs, rather than shying away, diving into the deep end and facing the problem head on is what will help in the long run. However there are some risks that are involved with going straight into the deep end. A risk is that you may get overwhelmed and fail. Although you may fail, failing is not necessarily a bad thing. Being prepared to fail, and recovering is what drives growth and provides opportunities that would be lost if the risk was never taken in the first place.

As mentioned before, in order to grow, bigger projects need to be made as a way to challenge yourself. Previous project’s size can be quantified by looking into those previous projects and marking down how many lines of code was written with how many developers. After reviewing all previous work, a chart can be made to see where how the next project compares.

Conclusion

I enjoyed reading about this pattern. I found the action to the pattern to be interesting because creating a chart, representing the size of your previous work, is something I would not have thought to do. However that process can be useful when determining if a project is at a large enough scale that can challenge previous projects. The pattern has changed the way I think about failure and taking risk. I like how the pattern paints the potential of failure as something that should be invited because I feel that failure is something that is not normally deemed acceptable. The pattern has ultimately changed the way I think about taking risks because risks and recovering from failures are what key to growth.

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.

The Strength in In-Depth Exploration

Pattern Summary:

The “Dig Deeper” pattern from “Apprenticeship Patterns” advises aspiring software craftsmen to explore their craft beyond surface-level understanding. It emphasizes the importance of curiosity, continuous learning, and seeking deeper insights into software development concepts, tools, and techniques.

Reaction to the Pattern:

Upon reading about the “Dig Deeper” pattern, I was immediately struck by its relevance and applicability to my journey as a software enthusiast. What stood out to me as particularly intriguing and valuable was the idea of embracing curiosity as a driving force for growth. This pattern encourages us to go beyond mere familiarity with programming languages or frameworks and delve into the underlying principles, design patterns, and best practices that shape our craft. It has sparked a renewed sense of curiosity and passion for exploring the depths of software development.

Impact on Professional Perspective:

The “Dig Deeper” pattern has had a profound impact on how I view my intended profession and approach learning. It has shifted my focus from superficial knowledge acquisition to a more profound understanding of core concepts and foundational principles. By digging deeper into software development topics, I’ve gained a deeper appreciation for the intricacies and complexities of the craft. This pattern has reshaped my learning strategies, prompting me to prioritize depth over breadth and invest time in mastering fundamental concepts.

Disagreements and Critiques:

While I wholeheartedly embrace the essence of “Dig Deeper,” one potential challenge I’ve encountered is the overwhelming volume of information available in the software development realm. It can be daunting to decide which areas to delve deeper into and how to manage the depth of exploration effectively. However, I’ve found that setting specific learning goals, leveraging resources like documentation, tutorials, and mentorship, and focusing on practical application have helped overcome this challenge.

Overall Reflection:

Embracing the “Dig Deeper” pattern has been a transformative experience in my professional development journey. It has fueled my curiosity, expanded my knowledge horizon, and enriched my problem-solving capabilities. By diving deeper into software development concepts, I’ve gained confidence, resilience, and a deeper sense of fulfillment in my craft. This pattern has instilled in me a lifelong commitment to continuous learning and mastery, shaping the way I approach challenges, collaborate with peers, and contribute meaningfully to the software development community.

“Dig Deeper” serves as a guiding principle for aspiring software craftsmen, urging us to move beyond surface-level understanding and embrace the depths of our craft. By cultivating curiosity, seeking deeper insights, and mastering fundamental concepts, we pave the way for growth, innovation, and excellence in our profession.

From the blog CS@Worcester – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

Nurture Your Passion

The Nurture Your Passion pattern is about how important it is to protect and grow your passion for software craftsmanship even in some environments where it might not be supported. This pattern also talks about the challenges that people as software developers face in certain environments where their passion for the craft isn’t supported. Not only does it acknowledge the challenges faced by software developers in environments that may not fully support their passion but also provide strategies to navigate and thrive in those situations. Use certain strategies to protect and nurture your passion by working on what you like and drawing your own career path. The pattern shows that the real challenges that software developers face are when their passion for coding isn’t given its due, so they use a strategy to make their work more passionate. I felt like this pattern emphasizes preserving passion when a challenge comes around and finding a nurturing environment for that passion in software development. It’s great advice to work on tasks that interest you and also make sure to look for supportive people who like your ideas to motivate your success. It’s changed the way I think about my career path and how I should go about challenges in that journey, it’s important to be passionate about work but if it doesn’t give you a purpose or challenge you it’s important to find something that does.

 This pattern wants to encourage people to make sure that their career path has a purpose and that they’re passionate about it. It makes me want to be part of an environment that fits my values even if challenging. It’s not just about writing code; it’s about making sure every step in your career journey feels meaningful. seeking out a workplace that aligns with your values, even if it means tackling some tough challenges along the way. This pattern is a reminder that staying driven and having a clear sense of purpose in your career is everything, even when the going gets tough. This pattern wants to remind people of the importance of maintaining enthusiasm and purpose in one’s career path,  even though it comes with some challenges. It encourages self-care, learning, and engagement that can help in long-term success and satisfaction in software craftsmanship.

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.