Category Archives: Week 10

Blog Post

The piece “Draw Your Own Map” encourages individuals to take control of their career paths rather than relying solely on their employers or societal expectations. It addresses the common notion that programming and career advancement in the field are limited, especially for those who may not fit the stereotype of fresh graduates. It emphasizes the importance of identifying one’s own career goals and taking proactive steps to achieve them.

The solution proposed involves identifying logical yet ambitious career steps and visualizing the incremental actions needed to reach those goals. It advocates for taking the first step, even if seemingly insignificant, as it generates momentum towards larger aspirations. Rather than setting only high-level goals, the article suggests defining small, achievable steps that provide feedback and aid in obtaining assistance from like-minded individuals.

The narrative includes personal stories illustrating individuals’ struggles to pursue programming despite organizational constraints. It highlights the importance of prioritizing personal aspirations over organizational expectations and seeking opportunities that align with one’s goals.

The actionable advice includes listing potential career paths, extending the list to explore additional options, and challenging preconceived constraints to open up new possibilities. It also encourages seeking mentors and kindred spirits who can provide guidance and support along the way.

Overall, the piece advocates for a proactive and flexible approach to career planning, empowering individuals to chart their own paths and overcome obstacles to achieve their desired destinations. What I thought was the most important of this piece is the career planning aspect of it especially since this semester I am finishing up my degree and starting on looking for a career, this also like points me in the write direction on a professional work future.

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

blog post 3 – 443

The article “Pairwise Testing” by Ryan Craven explores into the concept and application of pairwise testing, a powerful technique used in software testing to enhance efficiency and effectiveness. Pairwise testing, also known as all-pairs testing, aims to analytically reduce the number of test cases required to test a system while still maintaining thorough coverage.

This blog begins by introducing the problem of combinatorial explosion in testing. Traditional thorough testing, where every possible combination of inputs is tested, quickly becomes impractical as the number of variables or parameters increases. Pairwise testing offers a solution to this problem by focusing on testing pairs of input values. The key insight is that many faults in software are caused by interactions between pairs of inputs rather than individual inputs themselves.

The author explains the core principles behind pairwise testing, emphasizing its ability to efficiently cover many combinations by selecting a representative subset. This approach significantly reduces the number of test cases needed compared to exhaustive testing while still providing effective coverage.

This blog also shares the concept of pairwise testing with a simple example involving a fictional coffee shop application. By identifying the parameters and their respective values (e.g., coffee size, type, extras), he demonstrates how pairwise testing can be applied to generate a minimal set of test cases that cover all possible pairs of values.

Also, the article discusses the benefits and limitations of pairwise testing. While it offers substantial reductions in test case count and provides good coverage, it may not detect faults involving interactions between more than two inputs. Craven advises on when pairwise testing is most suitable, such as in situations with limited time and resources or when dealing with complex systems with numerous input parameters.

This was a good blog post to read because it covered somethings we talked about in class during the group work. Through clear explanations and examples, the article serves as a helpful guide for understanding and applying pairwise testing in real-world scenarios. This is definitely something that will be very useful in the feature as my professional career expanded

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

Nurturing Software Craftsmanship

Hey everyone! In “Apprenticeship Patterns,” the authors present the pattern “Nurture Your Passion.” This defines preserving and growing one’s passion for software craftsmanship, even in unique work environments.
The authors acknowledge that as a software developer, your true passion lies in the craft itself. Unfortunately, the daily grind can decrease this passion, with factors like crushing hierarchies, “death marches,” abusive managers, and colleagues ruining your enthusiasm. The pattern suggests strategies to protect and add on to your passion. One is to focus on aspects you genuinely enjoy and dedicate time, even outside work, to pursuing these interests. The authors cite Paul Graham’s advice to “work on what you like.”
Another strategy is to seek out “kindred spirits” – joining user groups, participating in forums, and starting a blog to connect with others who share your passion. These interactions can renovate your thought process and provide a supportive community. The pattern also encourages studying the “classics” of software development literature, as you involve yourself in the great works can open your eyes to a more inspiring world.
Finally, the authors emphasize the importance of drawing your own map – being willing to move to an organization that better aligns with your goals, even if it means leaving a comfortable job. They warn about going against the “hero mentality” that leads to “death marches.”
As an aspiring software developer, I found this pattern insightful. The idea of caring one’s passion, even among adversity, resonates deeply. I appreciate the authors’ acknowledgment of the challenges and their suggestions for proactively addressing them. The priority on seeking kindred spirits and studying the classics is crucial. These activities can help renew my enthusiasm and provide a sense of purpose, even for future career challenges.
Additionally, the authors’ caution against the “hero mentality” and the importance of setting boundaries to protect one’s passion is a valuable lesson. I will be thinking of maintaining a sustainable pace and refusing to compromise my standards.
Overall, the “Nurture Your Passion” pattern provides a compelling framework for approaching my future career as a software developer. By actively protecting and growing my love for the craft, I believe I can navigate the profession’s ups and downs and maintain a granting, fulfilling, and consistent career. Thanks for tuning in!

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.

CS-448: Week 10

Expose Your Ignorance

In the world of software development, everyone is under a great amount of pressure to meet deadlines and deliver software. Because the entire team is under the pressure of meeting deadlines, the managers look for confidence when asking how long a feature will take to finish. Due to the new developer’s inexperience, they are unsure how to answer because they are not familiar enough with the technologies to be able to quantify how long the process will take. This pattern is called “Expose Your Ignorance.” In this pattern, it discusses the situation of a new developer who is unfamiliar with some of the required technologies their team uses, and is afraid to look incompetent.

Software developers tend to build their reputations through strong relationships with their clients and colleagues. Building strong relationships require honesty, and not just telling the client what they want to hear. Rather than pretending to know something, it is better to reassure the client by emphasizing the ability to learn new technologies and being able to apply them. Reassuring in this manner allows relationships to be built based on the ability to learn and adapt rather than based on what is already known.

The most obvious way to expose ignorance is to ask questions. The hardest part about asking questions is the fear of appearing incompetent. However asking questions and being direct is the easiest and most straightforward path down the software craftsman’s journey. Becoming comfortable with this process of learning, by asking questions to mentors, helps to prevent us from being locked into one domain of software development. An action that can be done to help with this process is to keep a list of what is unknown. Keep this list in a place that is public to the rest of the team to hold accountability and/or to help with understanding. Being in the habit of updating this list is also important to ensure continuous learning. Ultimately, possessing the ability to learn is one of the most important traits of a craftsman.

I found this pattern to be helpful because it provides a way with confronting feelings that may be uncomfortable when becoming a craftsman. I found the solution of making a list of what is unknown, and keeping that list public was interesting and changed the way I view the pattern because that is something I would not do. I would rather keep this to myself and work on it separately, but keeping this list public allows the team to hold accountability. This is because if the list has not been updated for a while, then that means the learning process has halted. I do not disagree with anything in this pattern.

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.

Be the Worst

For this week’s blog I decided to talk about the pattern from chapter 4 called “Be the Worst”. This pattern describes the situation where you have taken every opportunity to learn and eventually have outgrown your team. In this situation, it is important that you find developers that are better than you. When you take this route you will need to put in a lot of work because your aim is not to stay at the bottom but work your way up. You will be able to use multiple methods like mimicking other developers until you are on the same level and them. 

I agree with the solution for this scenario. I have found that I learn a lot when I am the weakest on a team. I am able to study the code written by the stronger members of my team and get insight on their choices. I found that learning from another person also speeds the process along. During this process, its important to avoid bothering your other team members too much. Although it can be convenient to just ask others, you need to establish a way to learn on your own so you can avoid prohibiting thew progress of others.

As one can guess, this method has risks like dragging the team down and running the risk of being fired because your productivity is not as expected. I have experienced pressure to avoid bringing the team down along with a lack of confidence in my own abilities. The first steps to follow this pattern is to develop confidence in yourself and focus on learning. Second, I think it is important to have open conversations with your team members and speak up when you may be falling behind. As mentioned in my other blogs, I have worked on past teams where I had to learned from other members. During this process, we all kept each other updated on our progress and it was crucial for us to work together to finish by our deadline.

 I think this pattern aligns well with the way I’ve been developing my professional skills and I cant say that I disagree with anything. Following this path will definitely help with self-assessment because the more you know, the more you know what you don’t know. 

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 Mentors

This section really emphasizes the importance a mentor can have on someone’s apprenticeship. Guidance from someone who has already experienced the same or similar issues that you are going through is invaluable. On top of that, it establishes what realistic expectations one should have for a mentor. With computer science being such a vast field that is only getting larger, it’s unrealistic to expect one person to know everything about every topic. The last major point the section covers is that the flow of knowledge does not stop at you. An apprentice must be willing and able to pass on knowledge to other apprentices. 

Thinking back to my most impactful teachers and professors, it’s clear to see that their impact comes from their ability to mentor their students.  Having those impactful mentors throughout my education is what inspired me to seek a career in computer science. The best example I can come up with to relate the impact a mentor can have on an apprentice is this: Imagine trying to solve a hidden picture puzzle or “Where’s Waldo” and you can’t seem to figure it out. Having a mentor is like having a magnifying glass to help narrow down where you should be looking. This sense of direction is great to focus your efforts into researching helpful information. Considering how large the computer science field has grown.

When it comes to choosing a mentor in the computer science field, it is important to realize how large the field is. I have said it three times now, and I still don’t think that is enough to emphasize it. It is best to try and find a mentor that specializes in the field you want to learn about. Although, from my experiences, a mentor that does not specialize in the same field as you is still worth having. A mentor that specializes in any field can still give you tips on how they got to where they are. With the same mentality of teaching a person to fish over giving them a fish, learning how to learn is better than being taught something directly. With information so readily at our fingertips, the ability to research and find solutions is crucial in our world and especially the computer science field.

Bringing everything full circle is the idea that what separates an apprentice from a journeyman is the responsibility to help teach and mentor other apprentices. It makes sense that as I continue down the long path that there will be others behind me. I, personally, have always loved the spark that my mentors have ignited in me and it would be great to be able to pass that sling to others in the future.

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

Recording the Journey

Pattern Summary:
“Record What You Learn” from the book “Apprenticeship Patterns” emphasizes the importance of documenting and organizing your learning experiences as a software craftsman. It encourages apprentices to maintain a journal or log of their progress, insights, challenges, and solutions throughout their journey of learning and mastering software development.

Reaction to the Pattern:
This pattern resonated deeply with me as it highlights a crucial aspect of professional growth: continuous learning and reflection. What I found most interesting and useful about this pattern is its emphasis on active engagement with one’s learning process. By recording what we learn, whether it’s new programming techniques, problem-solving strategies, or insights from failures, we create a valuable resource for future reference and self-improvement. This pattern has significantly influenced my approach to learning and working in the software development field.

Impact on Professional Perspective:
“Record What You Learn” has caused a notable shift in how I perceive my intended profession and my approach to work. Previously, I often relied on memory or scattered notes to capture my learning experiences. However, this pattern has taught me the immense value of structured documentation. I now see my journal as a treasure trove of lessons learned, growth milestones, and areas for improvement. It has become a tool for self-assessment, goal-setting, and tracking progress, ultimately enhancing my effectiveness as a software craftsman.

Disagreements and Critiques:
While I wholeheartedly agree with the importance of recording what we learn, one potential challenge is maintaining consistency and discipline in documenting every learning experience. Balancing work responsibilities, learning endeavors, and documentation efforts can be demanding. However, I’ve found that integrating journaling into my daily or weekly routine has helped mitigate this challenge.

Overall Reflection:
Incorporating the “Record What You Learn” pattern into my professional journey has been transformative. It has instilled in me a sense of accountability and mindfulness in my learning process. I now approach challenges with a more structured mindset, knowing that each solution, mistake, or insight contributes to my growth. This pattern has reinforced the idea that true mastery in software development comes not just from technical skills but also from continuous learning, reflection, and adaptation.

“Record What You Learn” serves as a guiding principle for aspiring software craftsmen, reminding us that our learning journey is as valuable as the destination. By embracing the discipline of documenting our experiences, we pave the way for continuous improvement, innovation, and success 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.

CS448 Software Development Capstone – Apprenticeship Patterns: “Be The Worst”

This week, I wanted to reflect on my habit of self-comparison in relation to my ability as a software developer. I’ve recently found myself preoccupied with how much I don’t know as compared to others in the computing world, both at and above my perceived level of competence. It feels awfully paralyzing comparing my present knowledge with the unfathomable set of things that I’m not even aware that I don’t know about. It’s becoming difficult to even take a break from ruminating about how far behind I feel, because Youtube and Instagram’s content generation algorithms keep delivering me videos with sensational titles like “5 Sorting Algorithms You NEED To Know”, or “Learn THIS Framework NOW”, or “Build THESE Projects To Establish Your Software Career”. It’s exhausting! Before I’ve even started, the amount and complexity of the work that I believe lies ahead of me makes me feel hopeless. How am I supposed to learn anything or get anything done if I think that my best is so far from acceptable, and to do better sounds so exhausting as to be impossible?

Spending so much time and energy spinning my wheels over this issue has me considering a counterintuitive approach. I can’t stay here in this weird superposition of feeling like I’ve been spending all my available energy on becoming the best programmer I can be, yet also feeling like I’m not working nearly hard enough to produce results that anybody would pay me for. That’s why the title of this pattern from chapter 4 of “Apprenticeship Patterns” caught my eye. I knew before that striving to be the best would be a fruitless and frustrating endeavor, but I didn’t foresee that striving to be my best could still lead to as much paralysis and burnout.

I’ve held myself back from contributing to open-source projects or joining online programming groups partly because I’ve been afraid that even if I try really hard, my best won’t be good enough. My rate of output will sputter, and my code will be full of mistakes, then I’ll lose the respect and patience of my team, and soon I’ll be drowning with no hope of rescue. That’s what my imagination says, anyway – it’s annoyingly silent about what my life would be like if I put some confidence into the skills I’ve learned and started believing that people wanted me on their team. This pattern, “Be The Worst”, asks the apprentice to embrace their role as the worst member of a team they are considering joining. From this place as the weakest member of the team, the apprentice can soak up knowledge and experience from their more capable team members and work their way up.

This pattern is one of those in this book that I think goes back to learning to let go of your own ego and presumed sense of competence. I need to be getting more programming experience outside of school, but because I am so petrified of people thinking that I’m incompetent, I never actually get anything done. It’s kind of terrifying to imagine myself as the weakest member of a team working on an important project, because then I imagine the situation where my being on the team has become a burden on the project despite my best efforts and intentions, and now everyone is mad at me when I’m trying so hard! I should have known better than to bite off more than I can chew! Extremely unproductive and exhausting attitude, I know. Maybe I’ll be able to wade my way out of this strange emotional swamp surrounding my sense of industry someday, but maybe more likely is that I’ll end up living that situation where I’m the worst on the team and I just cannot find it within me to do any better than I already am, and I’ll have to learn that regardless of all that, I’m still valuable.

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.

Week 11

Deciding on a topic this week I decided to delve into Test Driven Development (TDD). I found an article with an engaging title “Test-Driven Development (TDD): A Time-Tested Recipe for Quality Software” by Ferdinando Santacroce. This would be very useful for me and the whole class because it’s fresh in our minds and we will continue to work with this concept. Getting a firmer grasp on this topic will help me with future assignments and homework. It’s always great to get an insider view with experience inside the field connecting it to what we learn in class.

This article begins with the history of TDD giving credit to Kent Beck one of the first “extreme programmers”. At the time nobody had ever reversed the idea of testing starting with a test instead of the actual code. The purpose of writing a test before the code would help programmers put them in the perspective of the maker making it easier to create the software. This would make more tunnel-focused code with much more simplicity because of just focusing on the test. Plus the codes get rapid feedback because all the tests have been made. TDD has the fastest feedback loop only surpassed by pair programing. Currently, TDD is widespread inside the field and several teams utilize it day to day. It’s hard to adapt to this type of coding scheme but with time it is proven to be a key to success. Minor grievances may also come up because this type of process can be too rigid or the lack of tools.  

After reading this article getting a glimpse into the history of how this came to be. It didn’t specifically specify when it started but I assume it was around the 90s because it mentions how common it is now. Understanding the benefits of doing this test answers my question why would you decide to do your coding process in reverse? What we have been learning is that it will be conventional to have code and then write the test connected to the already processed code. The benefits of cutting down time because of the faster feedback times and leading to less complicated code, I now understand its purpose. That is a recurring theme with code the simpler the better because you are never working alone. Maybe it is a self-contained project but your future self may not understand your complex code and updates to the code should be easy to do not a headache.

From the blog cs-wsu – DCO by dcastillo360 and used with permission of the author. All other rights reserved by the author.

Week 10 Blog Post

Searching for an article this week I looked for something relating to mocking. Considering last week I did the negatives on mocking I think it’s valuable to have various perspectives. Seeing multiple ideas with mocking can give us an idea of how to implement them in the future. The writer of this article is a reliable source being a Java script developer. Getting information from someone in the industry can give a perspective inside the workforce and how people inside see different ideas. Not everyone may agree with using the same coding language but seeing how developers see different concepts can give an idea of the drawbacks to stuff and where in our own experiences can we improve. Overall this article is a great way to see how mocking is seen inside the workforce by an experienced professional.   

In this article, Eric Elliot focuses on the drawbacks of excessive mocking. He points out how brittle tests and how they can be easily broken. There broken simply just from the change of implementation even though the behavior stays the same. Another point is a false sense of security because of there lack of accuracy that occurs from not using accurate real behavior. This is a fault in the test because the test will pass even if it isn’t supposed to. Third, he focuses on complexity overload which is just adding too much complexity can make the code harder to understand and maintain. Elliot still believes in mocking but a more balanced approach can overall help the program. Mocking should be used sparingly and when there actual weight for its use. All together Elliott wants the audience to create a strategy that will have confidence in their code correctness while also minimizing any negatives of excessive mocking. 

Reading this article at first I thought it would be more of a pro mocking but it’s more in between. It says its flaws while still sharing the positives. After reading this article I understand that mocking can cut time but it can bring flaws to testing. The best time to utilize mocking is when time is scarce and later it can updated with time. It still isn’t the ultimate be-all to testing but with a balance, it will work. Understanding these flaws can foresee issues that may come up when mocking. Mocking should never bring up complexities that can complicate the code and should always have a priority in simple to understand and easy maintenance.

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