Category Archives: CS@Worcester

Pattern: Sweep the Floor

This pattern underscores the value of humility and the readiness to tackle any task, regardless of its perceived significance, as a means to learn and contribute meaningfully to a team. The concept is that by beginning with basic responsibilities and executing them proficiently, you develop a comprehensive comprehension of the work environment, the tools, and the processes at play. This establishes a groundwork for advancement and enables you to establish credibility within your team.

Reaction: This pattern indeed serves as a valuable reminder that professional growth often hinges on our willingness to embrace all tasks, regardless of their perceived glamour or complexity. It’s a testament to the fact that success often starts with mastering the basics and being adaptable to the team’s needs, ultimately contributing to a more robust and effective team dynamic.

Interesting Points: This pattern really highlights the importance of having a humble and open mindset, especially at the beginning of one’s career. By showing a willingness to tackle any task, you not only acquire new skills but also showcase your dedication and team spirit, which can be incredibly valuable in establishing yourself within a team or organization.

Impact on Thinking: This pattern has caused me to rethink how I approach new opportunities. Instead of focusing only on the tasks that I find most appealing, I now see the value in taking on a variety of tasks, even if they seem mundane at first. I realize that by doing so, I can gain a better understanding of the overall work environment and make a more meaningful contribution to my team.

Disagreements: I don’t disagree with anything in this pattern. The principles of humility and a learning mindset are universally valuable, no matter where you are in your career journey. They can be particularly impactful at the outset, setting a strong foundation for growth and development. Embracing these principles can lead to more enriching experiences and better relationships with colleagues and mentors, which are essential for long-term success.

In summary, “Sweep the Floor” underscores the significance of humility and a readiness to tackle any task, regardless of size, to foster professional development. This mindset will remain a guiding principle as I progress in my chosen career path.

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

Activity on Gitlab (from oldest to youngest)

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend

  • Worked on verifying correct linters are present/used, pushed branch and was merged later

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend

  • Helped team by commenting details in regards to issue worked on as a group

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend

  • Deleted branch to do some clean up at the end of the sprint

In the dynamic realm of sprint cycles, our team of five individuals embarked on a journey of collaboration, growth, and shared accomplishments throughout Sprint Three. As the semester progressed, we evolved into a more cohesive and efficient unit, leveraging our collective strengths to overcome challenges and achieve our objectives with confidence.

From the beginning of this sprint, our experience was characterized by seamless workflow, effective time management, and a strong emphasis on teamwork dynamics. Through a combination of collaborative efforts, individual contributions, and paired work, we navigated our sprint objectives with precision and determination, exceeding expectations within the designated timeframe.

Reflecting on our previous sprints, we collectively identified areas for improvement and implemented strategies to enhance our performance. One notable shift in our approach for Sprint Three was the refinement of our task allocation process and the adoption of a more strategic approach to problem-solving. Recognizing the importance of leveraging diverse perspectives and skill sets, we allocated tasks based on complexity and urgency, ensuring optimal resource utilization and productivity.

Furthermore, we continued to prioritize inclusive code reviews, fostering a culture of knowledge sharing and continuous improvement within the team. By conducting comprehensive reviews as a team, we not only enhanced the quality of our work but also reinforced our commitment to collective success. Paired work remained instrumental in our strategy, facilitating better communication, collaboration, and task completion efficiency.

Despite the inherent challenges of a five-person team, we maintained a cohesive and supportive environment throughout Sprint Three. Each team member actively contributed to discussions, shared insights, and collaborated with others to overcome obstacles. Our shared dedication to excellence and mutual respect for one another’s contributions fostered a positive team dynamic, elevating our overall productivity and morale.

Moreover, we remained focused on maximizing our time and resources by prioritizing tasks based on importance and feasibility. Setting ambitious yet attainable goals, we remained committed to completing at least 75 percent of our sprint backlog, ensuring progress towards our objectives while allowing flexibility for unforeseen challenges or revisions.

As we look towards future sprints, we are confident in our ability to build upon the successes of Sprint Three while addressing any identified areas for improvement. By continuing to prioritize collaboration, effective communication, and adaptive problem-solving, we are poised to further enhance our team’s performance and achieve even greater success in the upcoming iterations.

In conclusion, Sprint Three was a testament to our team’s resilience, growth, and unwavering commitment to excellence. Through strategic task allocation, inclusive code reviews, and increased paired work, we navigated our sprint backlog with confidence and cohesion, emerging stronger and more united than ever before. As we continue to iterate and refine our processes, we remain dedicated to driving innovation, fostering teamwork, and delivering exceptional results in all our endeavors.

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

Security Testing

Security Testing (A Complete Guide)

Security testing is a form of testing which is rapidly growing with consumers’ needs for security on the internet. As the article states, cybersecurity is becoming very important when you are online not only for personal reasons but also for business purposes. Many companies now use multiple online resources just to run their business day to day which may include payment systems, payroll, database management or any other range of services which are offered to companies through different platforms in order to help business owners run their business as efficiently as possible. These platforms have to be trusted so that consumers continue to use them and recommend them to friends, family, etc. Some examples provided of security issues within an  application are a student management system being insecure if the admission branch of the system can edit the exam branch, online shopping malls or any online storefront is not secure if the details from users credit cards or other payment methods is not encrypted as this opens up the users to credit card fraud, and even custom software can have security issues which is highlighted by the articles example of an SQL query retrieving the actual passwords associated with users accounts. Two tools recommended in this article for security testing are Invicti which is a web application that is used to scan both legacy and modern applications and Indusface which includes scanners for web, mobile and API applications. There are also different techniques involved with security testing some of these being access to application which involves going through the different roles in a system one by one ensuring they all only have access to what they should, data protection which similarly to access to application is meant to ensure that a specific user/role cannot see an aspect or menu of the application they are not supposed to and error handling which ensures detailed error messages cannot be used to aid in hacking.

Security testing while not being something we directly worked on during the semester it would have been interesting to work with as the many different types of security testing and the many different risks associated with application security. This type of testing seems to be much more manual in many aspects versus directly writing test cases as we did in most cases but being able to test for access or test the permissions of a role in a system would be very interesting to work with.

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.

Performace Testing

https://www.opentext.com/what-is/performance-testing#:~:text=Performance%20testing%20is%20a%20non,up%20under%20a%20given%20workload.

Performance testing is a form of testing in software development which is called non functional testing. Non functional testing means that the software’s function is not directly tested during this type of testing and in turn this makes a large majority of people view performance testing to be an afterthought or unimportant compared to other types of testing. Performance testing is specifically responsible for testing how a system or software may perform under a heavy amount of traffic or stress provided by many requests or users concurrently using the system. Some of the reasons that an organization may choose to undertake performance testing are to ensure a specific amount of users can be handles (for example 1000 concurrent users), to locate bottlenecks within an application which hinder performance or result in errors, to ensure that software is performing up to the standard that was given by the softwares vendor and to measure general stability as traffic goes up and down. Performance testing can require many different steps depending on the type of application being tested, the tester must make sure to look at the environment they wish to use for testing as well reading documentation on the environment or systems hardware in order to ensure the proper environment is used as performance testing may or may not involve testing within the production environment. The tester must also decide what is deemed acceptable performance wise which may involve meetings with the product owner or production team in order to set the correct standards for your tests and then you must also plan and design your original tests for performance. These tests may be all that you need, but if you require further testing due to necessary changes in a system if the system is originally unable to meet the requirements you will have to redesign and re-run your tests.

I feel as though performance testing is a lot more important than some people may think, especially to very large companies or social media platforms as they need to be able to accommodate a certain number of users not only everyday but also a certain number of users concurrently. Companies like amazon, microsoft, facebook, etc have to deal with thousands of customers or users at once and they can even reach millions of concurrent users which means they must do thorough performance testing in order to maintain the stability of their platforms and keep consumers happy.

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.

‘Breakable Toys’ Pattern

The “breakable toys” pattern from chapter 5 is one of if not the most important pattern contained in this book in my opinion. This pattern specifically talks about the necessity of learning from failure even if your work environment does not allow you to do so. A situation like this is common within industries such as software engineering and the example the book gives of a juggler and how someone who can juggle three balls would not attempt to juggle five while actually performing which relates to software engineering as this pattern encourages you to make mistake and learn from your failures on your own time if your workplace does not allow it. “Breakable Toys” also suggests constructing a similar system to the one you may work on at work in order to be able to experiment on your own time and learn from your mistakes in an environment that directly resembles the one you are in at work. You should push yourself to find learning opportunities for yourself through the use of this pattern as if you do not have those opportunities at work then you must make your own in order to continue learning and get better at your craft. It is also stated that your “breakable toys” should be things that you find fun or have interest in so that even though they are meant to provide learning experiences for you, you are still engaged enough to where you look forward to working with them.

I think that this pattern is very important especially to a software engineer. No matter what company you work at there will eventually be a job where you are expected to make nearly no mistakes and you will not be able to try different solutions due to this expectation. But if you are able to experiment with different solutions on your own and see why they may not work or why they do work you can not only learn for yourself but you can also help the team you are working on evolve from using one standardized solution to using one that could be more efficient or faster.

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.

Capitilzing on your Title

This week, I chose to read the “Use Your Title” apprenticeship pattern under the “Walking the Long Road” chapter. I found “Use Your Title” interesting as it points out that titles like “senior,” “architect,” or “lead” aren’t accurate reflections of one’s personal skill level. Titles like these won’t alone mean an apprentice has become a journeyman, and due to the lack of craftsmen, apprentices still receive these titles, which can potentially cause feelings of inadequacy or overconfidence. This pattern emphasizes maintaining focus on continual learning and self-assessment, viewing titles as indications of company workflow patterns rather than reflecting a craftsman’s advancement along their journey.

This pattern spins a new perspective on the traditional view of titles, suggesting that titles can provide insight into a company’s structure and values. For example, if a title feels inflated or undeserved, it might indicate a lack of rigorous standards within an organization. On the other hand, a lack of recognition might point to an environment where contributions are undervalued.

It’s interesting how the pattern also brings up formal titles such as “senior” while also acknowledging the existence of informal titles. Informal titles are team- or company-wide accepted roles being fulfilled by certain employees without having a title to reflect such. It seems that both have sway in the perception of the validity of one’s work, but informal titles, in my opinion, seem more applicable to one’s skills rather than workflow.

Looking at Dave Hoover’s testimony solidifies things my mentors have told me in the past as well. If you move up the totem pole, it doesn’t always correlate with your development and is more a reflection of a company’s need for more craftsmen. I’ve been told that as a rule of thumb, gauge your progress at your current position every three years. If you feel like your work is underappreciated or your title is inflated or undeserved, then it might be time to move on to better fulfill your personal development. A position at a company may work at first, but over time it is important to also take an objective look and figure out if that position still suits your development or hinders it.

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.

Learning How We Fail Until We Hit Growth

Hey Everyone! In the nonstop pursuit of excellence, the “Learn How You Fail” pattern reminds us of a old forsaken truth: failure is not a curse but a catalyst for growth. It challenges us to confront our weaknesses head-on, to seek out the patterns and behaviors that lead to our missteps, and to use that self-knowledge as a powerful tool for transformation.

The whole point of this pattern means a lot to me deeply, as it recognizes that true creativity and work ethic are not born from a quest for perfection but actually a willingness to form somewhat of a imperfection. As Atul Gawande states, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.”

Personally, I find this pattern both humbling and it gave me a sense of confidence. After reading it a couple of times, it forces us to confront the uncomfortable reality that our successes are often counterbalanced by our failures and weaknesses. I’ve always related to the fact that you have to get out of the comfort zone otherwise you’ll stay there forever. Reason is, in that discomfort is the seed of growth – by consciously acknowledging our limitations, we open ourselves to the possibility of going past them.

This pattern has profoundly influenced my perspective on the intended profession. It has reinforced the idea that your craft is not a destination but a continuous journey of self-discovery and self-improvement. By embracing the idea of “learning how we fail,” we create a mindset of resilience and adaptability, qualities that are essential in the ever-evolving landscape of software development, especially after reading about these patterns.

One aspect of the pattern that resonates particularly is the hard point on making conscious choices. By gaining self-knowledge about our patterns of failure, we empower ourselves to make informed decisions, sort of how some work better under pressure– whether to work on fixing those weaknesses or to acknowledge our limitations and focus our efforts elsewhere.

Lastly, the “Learn How You Fail” pattern is a powerful reminder that failure is not an enemy to be feared but a guide to be embraced. It is a call to take in vulnerability, to find the illusion of perfection, and to strive as more self-aware, adaptable, and the best version of ourselves we can be in and out of software development.

andicuni
May 15, 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.

Embracing the Cycle of Growth

Hey Everyone! The “Create Feedback Loops” pattern shines a light on this predicament, reminding us of the fundamental importance of going outside the box, objective feedback to fuel our growth and development.

At its core, this pattern challenges the idea that self-assessment alone is enough for recognizing our strengths and weaknesses. It acknowledges the built in biases and limitations of our own perspectives, which can be hooked by the very teams we work with or the environments we are around. The solution is in actively creating methods that provide us with a mirror, reflecting our true selves through the eyes of others.

What resonates with me about this pattern is its emphasis on the nature of growth. I’ve always been one to say how we never stop learning in this field and by requesting feedback early, often, and effectively, we can create a clean cycle – one where we become conscious of times where we lack understanding, take action to improve, and then seek further feedback to validate our progress. We need to understand there is nothing wrong with taking criticism. This continuous loop not only fuels our personal development but also helps search for a mindset of success and openness to learning.

Personally, I find the pattern’s recognition of the difference between useful and ineffective feedback is definitely a new way I would’ve originally thought about it. It highlights the importance of constructive criticism from distractions, separating obtainable data from well-meaning but misguided advice. This judgment supports us to focus our efforts on the feedback that truly matters, giving us a new way to make targeted improvements and avoid the mindset of false confidence or unnecessary self-doubt.

So to speak on how this impacted me, I like when the patterns give me a different influence on my perspective on the intended field in a positive way. It has strengthened the concept that true mastery is not a isolated push but rather a collaborative journey, where we actively seek out and embrace the perspectives of others. By creating feedback loops, we not only improve our own skills but also contribute to the growth of those around us, fostering a culture of mutual support and shared learning.

In conclusion, the “Create Feedback Loops” pattern is a powerful reminder of the importance of seeking objective, actionable feedback in our quest for growth and mastery. It challenges us to be open to the idea of okay to listen, okay to fail, and okay to continue trying. By cultivating this cycle, we encourage our own development but also add to the supportive growth of our peers and technical community.

andicuni
May 15, 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.

Chapter 1 of “Apprenticeship Patterns” delves into the concept of the “Long Road” pattern.

The “Long Road” pattern underscores the importance of embracing the journey to mastery in software development rather than seeking quick fixes. It begins by emphasizing the complexity and depth of software development, stating that mastery is not achieved overnight. The pattern suggests committing to a lifelong journey of learning and improvement, recognizing that expertise requires time, effort, and dedication.

The chapter delves into the analogy of software development as a craft, comparing it to traditional crafts like woodworking or blacksmithing. It highlights the importance of embracing the iterative process of skill development, viewing each project as a chance to enhance abilities and deepen understanding. Additionally, it promotes a mindset of humility among practitioners, acknowledging that there is always more to learn and room for improvement.

One particularly intriguing and beneficial aspect is the focus on deliberate practice and intentional learning. The chapter highlights the importance of seeking challenges that expand one’s skills and actively soliciting feedback from experienced practitioners. It encourages the development of a personalized learning plan aligned with individual goals, promoting a proactive approach to skill enhancement.

Moreover, the chapter introduces the concept of “Kindling Your Enthusiasm,” which underscores the significance of retaining passion and curiosity in one’s profession. It proposes that nurturing a sense of wonder and excitement can bolster motivation and help individuals persevere through the challenges and setbacks they may face.

This chapter hasn’t fundamentally altered my perspective on my intended profession, as I already held the belief in continuous learning and growth. However, it serves as a reaffirmation of the significance of embracing the journey and dedicating oneself to lifelong improvement. It reinforces the understanding that expertise isn’t attained overnight but is rather the outcome of consistent effort and commitment.

Overall, Chapter One of “Apprenticeship Patterns” offers valuable insights into the mindset and approach crucial for success in software development. It highlights the significance of embracing the journey of mastery, engaging in deliberate practice, actively seeking feedback, and sustaining passion and enthusiasm. These principles are not limited to software development but can be applied to any profession or pursuit that demands continuous skill development and growth.

From the blog CS@Worcester – THE SOLID by isaacstephencs and used with permission of the author. All other rights reserved by the author.

Teaching to Learn: Understanding Through Sharing

Hey Everyone! As apprentices in the making , we spend countless hours absorbing knowledge, honing our skills, and making our craft as efficient as possible. However, the “Share What You Learn” pattern reminds us that true growth lies not just in getting knowledge but also in generously sharing it with others.
The essence of this pattern is fairly captured in the quote from Twyla Tharp: “Look at the luckiest people around you, the ones you envy, the ones who seem to have destiny falling habitually into their laps… they involve their friends in their work, and they tend to make others feel lucky to be around them.” This resonates deeply, as it highlights the equal relationship between sharing knowledge and creating a fulfilling, comfortable community.
Personally, I find this pattern both thought-provoking and inspiring. It goes against the idea of knowledge is a finite resource to be put aside, instead advocating for its free exchange and somewhat of distribution. By sharing what we learn, we not only empower others but also solidify our own understanding. As the saying goes, “When one person teaches, two people learn.” I’ve never resonated with a quote as much as that one. Teaching forces us to organize our thoughts, anticipate questions, and articulate concepts in a clear manner – a process that always deepens our understanding.
Moreover, this pattern has influenced my thoughts on our field. I now recognize that true mastery extends beyond individual expertise; it follows the ability to communicate effectively and uplift others. The pattern explains how a skilled craftsman who fails to share their knowledge ultimately limits their impact, while one who embraces this pattern becomes a trigger for collective growth, leaving a lasting legacy that goes past their individual contributions.
One aspect of the pattern that I agree with a lot is the perspective of knowledge sharing. It serves as a reminder that not all lessons are ours to share, particularly those that may harm others or breach confidentiality. This way highlights the importance of wisdom and care when sharing knowledge, ensuring that our actions contribute to a positive, trustworthy environment.
Overall, the “Share What You Learn” pattern has inspired me to embrace the joy of knowledge sharing and to view it as an important part of my professional journey. By defining what I’ve learned, I can make stronger connections within my community, validate my own understanding, and help to the collective improvement of our craft as we say how we never stop learning. It’s a upright cycle that benefits all involved, to continue to make an environment of continuous growth and mutual support.

andicuni
May 15, 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.