For this week’s blog, I decided to write about the pattern called “The Long Road” from Chapter 3. My previous blogs touched a bit on the contents of this pattern so I decided to discuss what the authors suggest for this pattern. In this pattern, the situation that is presented relates to how your aspirations to become a master software developer conflict with the expectations of others and how “Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills”. 

The solution that is presented is to first accept the judgments you may receive from others to go against the status quo and then to stay focused on the long term. During the journey you will gain quite a bit of skills and knowledge; it is a long one so you need to prepare for it by drawing your own map. The text mentions “ you should keep in mind the expectation that you will be a working software developer even when you are middle-aged. Let this influence the jobs you take and the scope of your ambitions. If you’re still going to be working in 20 years’ time, then you can do anything”. You will be able to catch up to anyone in terms of skills in the decades that you will work and you may just pass them. Before reading this pattern I never really thought about just how long I will be working in the field. As I have discussed in many of my blogs for this class, I have been working on developing myself professionally and learning from other developers; as I have progressed, I have thought about the possibility of not being the weakest on the team so I agree that it is realistic to surpass people during your long journey.

The pattern really stresses the idea that instead of counting the days to retirement, a craftsman will willingly work until their final decades. You should thoughtfully work on developing your craft over many years. The idea of taking the long road is the foundation for a successful apprenticeship along with self-assessment. I couldn’t find anything in this section that I could disagree with. It definitely made me think of what I want to get out of this long journey because I didn’t take the time to think about it in-depth before.

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.

Confront Your Ignorance

This pattern is about confronting your ignorance. After going through the “Expose your ignorance” pattern, where you identify gaps in your skillset, the next step is to confront those gaps. The main problem that comes from this pattern is that there are techniques and tools that need to be learned, but the process of actually learning these techniques in unclear. Some of these may be techniques that everyone already knows, so there is an expectation that everyone be competent in that area.

The solution to this pattern, with the list generated from “Expose your ignorance”, is to pick an item from that list and actively fill the gaps for that item. How this can be done is a matter of preference. Some prefer to research everything they can about a topic, such as introductory articles and forums. Others prefer a more hands on approach by going straight into the topic by building a simple project. Although confronting your ignorance is mostly an individual task, asking mentors and experienced people is important to learn what information they can share with you. Asking mentors can also be beneficial as they may have learned tricks that they found themselves that may not be discoverable through documentation.

As mentioned before, this pattern is do be done after exposing your ignorance. Exposing your ignorance is a critical step because it makes the gaps in your knowledge public, which makes your team aware of those gaps and your learning ability. Having your gaps be on display for your team encourages an environment where failure and learning are acceptable as they both play a large role in an apprentice transitioning to become a journeyman and so on.

Conclusion

This pattern is helpful to me because confronting my ignorance is something I struggle with at times. The pattern states that exposing your ignorance without confronting can lead to excessive humility and helplessness which are feelings I have had in the past, so this pattern helps to give some encouragement to start confronting that gaps in my knowledge. After reading the patterns “Expose your ignorance” and “Confront your ignorance”, I feel much more confident in the future on how I can improve my skills in a methodical manner.

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.

In this blog post, I want to talk about the “Record What You Learn” pattern from the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye. The premise presented in the pattern’s introduction,

“You learn the same lessons again and again. They never seem to stick… You remember doing very similar things in the past, but the exact details escape you.”

, captures some of the feelings that I’ve been having as our development group continues our work on Thea’s Pantry. I remember doing so much backend HTTP server work last semester, but I haven’t retained the lessons as well as I wanted to, and I feel like I’m repeatedly reviewing old material.

Lately, I’ve been reflecting on how well I’ve been nourishing my writing abilities – I stopped keeping a daily journal some time ago, and I’ve noticed that I haven’t been taking as many handwritten notes in my classes as I used to. The first reason I can think of for not wanting to stick to the habit is that I haven’t been exactly clicking with the record-keeping tools that I’ve been using. At first, I wanted to keep digital personal journals with tools like Microsoft Word or a journaling app on my Android device because I liked the idea of having as much space to write as much I wanted, without having to think about reaching a physical “end of the book”. However, I’ve realized over time that there are parts of the electronic writing process, like the glow of the monitor and the distractions of other applications, that can make it harder to concentrate on personal writing as opposed to pen and paper.

I’ve also been reflecting on my writing practices in addition to the tools I’ve been using. I’ve known for some time that I would be helped by keeping records of the things I’ve learned about computers, networking, and software development in my own writing, but I just haven’t known how to start or structure a collection of notes that I want to return to and reference in the future. One solution offered by the “Record What You Learn” pattern is to utilize a personal wiki to organize and store your notes. While I’ve been thinking I want to return to pen and paper for more personal writing, I think that a digital tool like a wiki would be a great choice to organize knowledge-based writing and references to further learning resources. The review process is also an essential part of using the “Record What You Learn” pattern. The authors emphasize the importance of rereading your material: “Your notebook, blog, or wiki should be a nursery, not a graveyard—lessons should be born from this record, rather than going there to die.”

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.

Summary:

This pattern describes growing your skills by challenging yourself with any opportunity that is given to you. Whether it’s done through taking on bigger or more complex problems or working with larger teams, there is always something to learn by trying something new. This also means seeking out projects to work on to build a portfolio and expand your skills.

Reflection:

For someone who started programming java in 2007, my portfolio is pretty barren. This comes down to two factors. Lost old files, and failing to start new projects. This pattern is one that I can definitely relate to the problem of feeling like I have plateaued. My eyes are opened to the truth as I get more exposure to the world of software development. If I am going to gain new skills I need to actively seek projects that push the boundaries of what I already know. I have always wanted to develop an application, but without any clear idea of what kind of application I wanted to make. This has always paralyzed me from actually learning how to develop an application. There are two clear solutions I can think of right now based off of two other patterns I have written about in the past. Following the pattern of “Find Mentors,” I could have sought out the guidance of a mentor and asked for ideas for projects that would develop my skills. The second pattern of “Breakable Toys,” gives me the option of just making an application for the sake of having a tool I can use. Making a breakable toy for an application would be a great way for me to jump into the deep end as far as pushing my knowledge of software development.

The other part of challenging myself is working with larger teams. Up until last year all of the projects I have worked on have been solo. Last semester, where I was partnered with another classmate, was one of my first exposures to developing large projects with someone else, and the challenges that come with it. Teamwork is crucial as anywhere I go in my career I will be working on a team, so being able to work together and communicate are important skills to develop. And just like learning from actually developing code, these skills will be built by actually working in larger teams.

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

As my final Apprenticeship Pattern blog post for my capstone course, I found it fitting to write about the “Share What You Learn” pattern. The idea is fairly simple, if you are gaining knowledge on a topic, you should be able to share that knowledge with others effectively to foster mutual growth, which results in everyone building on their ‘craftsmanship,’ which further results in better products from everyone involved.

We don’t work in a vacuum by ourselves, and so communication is incredibly important. We will always be working on teams of software developers, and even in our personal projects, we are working with information that we are informed about from the entirety of the software development ‘community.’ As such, learning to communicate your ideas and share your knowledge is always great for your team.

Different people have different specializations, and in software development, we have our own specializations and interests within this field, and it is beneficial to not only contribute your expertise to the project you are working on with your team, but also share things about that expertise to get everyone on the same board with what you are doing, and perhaps foster growth in them as people and the project as a whole.

The intersting thing is that you can also learn from others’ specializations and expertise when you are sharing your own, and you can also build on your knowledge from ideas and suggestions that others may make when hearing your ideas. It’s a bounce back and forth.

I think everyone has probably experienced this to some extent, even in small circumstances. As the authors mention, simply knowing one small thing more than another person allows you the opportunity to inform that person about your piece of knowledge, and that fosters growth, no matter how small. I know that, for me, I’ve had multiple people ask me about how to do things when they need reminders or help with assignments or issues that they run into at work, and in that situation, it is beneficial to know how to communicate solutions, suggestions and feedback in a way where everyone stands to gain.

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.

Summary of the Pattern: “Expose Your Ignorance” is a pattern that challenges the common fear of appearing unknowledgeable in professional settings. It encourages individuals to openly acknowledge the areas in which they lack understanding or skill, rather than concealing their ignorance. This approach is presented as a method for accelerating learning and building genuine connections with colleagues who can provide support and knowledge. The pattern emphasizes that admitting ignorance is a step towards expertise, as it directly confronts what one needs to learn.

My Reaction: Encountering “Expose Your Ignorance” was both a relief and a revelation. It addresses a deep-seated fear many of us have: the fear of being judged for what we don’t know. This pattern not only normalizes but celebrates the act of admitting ignorance as a courageous step towards personal and professional growth. It has made me reconsider how I approach learning and collaboration, highlighting the value of vulnerability as a tool for building trust and fostering an environment where knowledge sharing is encouraged.

Insights and Changes in Perspective: This pattern has significantly shifted my perspective on learning and growth within professional contexts. Rather than viewing ignorance as a weakness, I now see it as an opportunity—an invitation to learn and to invite others into my learning journey. This change in mindset has encouraged me to be more proactive in asking questions and seeking out resources, knowing that each act of vulnerability brings me closer to the expertise I aspire to.

Disagreements and Critiques: While the ethos of “Expose Your Ignorance” is powerful, it’s important to acknowledge the varying degrees of safety within different workplace cultures for such vulnerability. In environments where admitting ignorance is not valued or might even be penalized, applying this pattern requires careful navigation. Thus, while I agree with the principle, its application must be adapted to the specific dynamics and culture of one’s workplace.

Conclusion: “Expose Your Ignorance” has profoundly influenced my approach to learning and professional development. It has taught me the strength in vulnerability and the importance of creating a culture that supports growth through openness and curiosity. I think that it is a very strong tool to learn new skills and to master old ones. I have used it many times in the past when feeling overwhelmed about a large task or a new topic. As I continue in my career, I am committed to living this pattern, fostering environments where ignorance is not a stigma but a starting point for collective learning and innovation.

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.

Software testing != doing homework bt rather, Software testing == checking homework to make sure it’s done right. In this blog we’ll explore the basics: what testing is, how it’s done, and why it’s important. We’ll cover different ways to test, how deep we go into testing, some smart ways to test, and why testing is worth it. Let’s dive in!

What is Software Testing?

Software testing is the process of verifying and validating whether a software or application is bug-free, meets technical requirements, and satisfies user needs. It ensures that the software functions as expected, identifying errors, faults, or missing requirements in contrast to actual specifications. This process aims to enhance efficiency, accuracy, and usability.

Verification and Validation

1. Verification: Ensures that the software correctly implements specific functions, answering the question, “Are we building the product right?”
2. Validation: Confirms that the built software aligns with customer requirements, answering the question, “Are we building the right product?”

Different Types of Software Testing

1. Functional Testing: Validates whether the software functions according to functional requirements.
2. Non-functional Testing: Assesses non-functional aspects like performance, scalability, and usability.
3. Maintenance Testing: Involves modifying and updating software to meet evolving customer needs.

Further, testing can be performed manually or through automation, each with its own set of advantages and applications.

Different Types of Software Testing Techniques

1. Black Box Testing: Conducted without accessing the source code, focusing on software interface.
2. White Box Testing: Involves knowledge of internal workings and access to source code.
3. Grey Box Testing: Blends aspects of both black and white box testing, providing testers with partial knowledge of the internal workings. This approach offers a balanced perspective, allowing for effective testing while maintaining a degree of independence from the code’s intricacies.

Additionally, Grey Box Testing combines elements of both approaches.

Different Levels of Software Testing

1. Unit Testing: Evaluates individual units or components of the software.
2. Integration Testing: Tests the interaction between integrated units.
3. System Testing: Assesses the complete, integrated system or software.
4. Acceptance Testing: Determines system acceptability based on business requirements.

Each level serves a distinct purpose in ensuring software reliability.

Best Practices for Software Testing

• Continuous Testing: Test each build as it becomes available to reduce risks and improve functionality.
• User Involvement: Engage users to understand their needs and perspectives during testing.
• Test Segmentation: Divide tests into smaller parts for efficient analysis and resource utilization.
• Metrics and Reporting: Track project metrics and share test results for improved collaboration and decision-making.
• Regression Testing: Continuously validate the application to maintain its integrity.
• Avoid Programmer Bias: Programmers should refrain from writing tests to maintain objectivity.
• Service Virtualization: Simulate systems and services to reduce dependencies and start testing sooner.

Benefits of Software Testing

• Product Quality: Ensures delivery of high-quality software by detecting and fixing errors early.
• Customer Satisfaction: Identifies and resolves issues before delivery, enhancing user experience.
• Cost-effectiveness: Saves time and money by detecting and fixing bugs in early stages.
• Security: Protects software from internal and external security vulnerabilities.

Sources – https://www.geeksforgeeks.org/software-testing-basics/

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.

In another of my classes I am beginning to learn android mobile app development. This gave me a lot of interesting thoughts about how testing might look for mobile app development. As the applications are full-stack applications, and require testing of the back and front ends. I had questions like: “What would testing a front end look like? Simply applying it and clicking around?” and “How might we test back-end functions if they are intrinsically tied to the front-end?”. To find out more I looked on stickyminds, where I find most of my articles. I found an article about Testing Usability in Mobile app Development The title struck me as answering the first of my questions, so I chose to delve into it. The article’s title is Testing Usability for Mobile Applications by Mukesh Sharma.

The article provides an in-depth analysis of the pivotal role of usability in mobile applications. Usability has a profound impact on user engagement and app longevity, and this is something I can corroborate, as I have chosen apps with higher usability over similar apps with better quality and functions, but lesser usability. The article highlights specific usability characteristics: app simplicity to facilitate navigation effectively, helpful error handling mechanisms to guide users through troubleshooting and make it less of a hassle, optimizing efficiency to speed up tasks, and prioritizing user satisfaction to keep the app functional and supported by users. The article also delves into the nuanced focus areas for usability testing, including functionality assessments to verify feature completeness, contextual evaluations to tailor experiences to user preferences and test them against other preferences, rigorous device compatibility testing to ensure seamless performance across diverse models of mobile device and OS, examining in detail and scrutinizing data entry methods, and comprehensive examination of multimodality, to avoid user uncomfortability. The article uses an example of the Skype app to explain these potential problems. When moving the phone away from your ear, it would switch the speaker in your phone from the call speaker, to the loud back speaker. This is similar to the function in my Samsung Galaxybuds. When you take them out of your ear, it stops what’s playing or disconnects entirely. These are examples of uncomfortable features that have not been tested fairly. By adhering to the best practices for testing, developers can fix these issues in the testing phase, and assure no issues come from the software.

This applied extensively to several of my classes. I had been wondering how to think about tailoring mobile applications to the user, since learning about their development in one of my classes. This article has given extensive explanations into some poor features, and how to test to avoid these issues in the creation of the app. This will be very useful not only for mobile applications, but for testing full-stack applications as a whole, as the article covers mainly abstract ideas for testing full-stack applications.

Source:
https://www.stickyminds.com/article/testing-usability-mobile-applications

From the blog CS@Worcester – WSU CS Blog: Ben Gelineau by Ben Gelineau and used with permission of the author. All other rights reserved by the author.

Test driven development is an important method of developing which is based on first writing a test for what you want your program to do, this test will fail as you do not have any code written in orde for the test to pass but you then write the code which is necessary for the test to pass and then you continue repeating this process of writing a test then writing the code for said test to pass. You are encouraged to write the simplest possible code in order to make your test pass before moving on to the next test but you may need to do some refactoring between tests in order to ensure you do not have unused code, confusing methods or variables, etc. Test driven development is very helpful when it comes to testing the specifications of a system as you can write simple unit tests which would pass if a specification was met and when it fails you know that you still must add or change your code in order to make sure the specification was met for the end product. Other types of testing are also important to perform but test driven development can help you steer away from over complicated code and make sure that you do not have recurring duplication present when you regularly refactor between cycles.

I found this article to be particularly helpful when researching test driven development as it clearly breaks down the steps of test driven development in order for the reader to fully understand the process you must go through in order to follow this development method. Along with the thoroughly explained process this article also compares and shows how both acceptance test driven development and developer test driven development work together. As we just started working with test driven development in class I found this article to provide valuable insight into the definition and process of this testing/development model as it is something rather different compared to what we have worked on previously regarding testing as we usually have worked with code that needed tests written and not with tests that needed code to be written. Being new to TDD made it seem very confusing at first as it did not feel right to be writing the tests for code which did not even exist yet but the benefits of TDD are much easier to understand once you put this method into practice.

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.