This week I decided to write about the pattern called “Retreat into Competence”. This pattern discusses the common occurrence of feeling out of your depth and what you should do about it. In the past couple of months,  I have been confronted with the depths of my lack of knowledge and realized just how overwhelming it can be. It is for this reason that I chose to read about the suggested solutions for this pattern.

The solution provided for this issue is to retreat into your knowledge to regain composure and then “then launch forward like a stone from a catapult”. This method will allow you to realize how far you’ve come and recognize what you are capable of. You need to overcome your fear of incompetence to grow. I agree with the statement that “sometimes you need to take one step back in order to take two steps forward” and how it is important to focus on moving forward as quickly as possible. It took me some time to reflect on this solution but I think this is because if you don’t force yourself to focus on moving forward you can get stuck by being too comfortable. 

For the most part, I agree with the text. It is definitely a risky solution because it is important that you recognize that it is only a temporary fix. You need to be honest with yourself and have discipline to stick to a time limit as suggested in the last paragraph. Although this is a good solution for certain situations and/or certain types of people, sometimes I think you just need to throw yourself into learning the new material. In the recent projects I worked on where I realized the extent of my ignorance, I decided to dive right into some resources to help me learn. I was working with tight deadlines and had to learn as much as I could to be a useful team member. Regardless of this fact, the core of this section gets one thing right, to do anything you must first tackle your fear of incompetence and inadequacy. Although my first solution is to dive into new material, I may come across a situation where it will be more helpful to take 2 steps back. This solution was definitely interesting to read about because it is very different from my usual approach.

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.

The ‘sweeping the floor’ pattern in chapter four pertains directly to the beginnings of an apprenticeship or just work in software in general. This pattern explains that when you first begin the process of working in software while you will not be nearly as knowledgeable or efficient as the other members of your team with more experience you will still be able to contribute in smaller or more simple ways in order to still provide assistance and work with your team as you learn how to do more technical tasks. This strategy can be applied in every field as when you start your career or even when you start a part time job in high school you first have to be taught how to do certain tasks in the correct way but while you learn how to do the more complicated tasks correctly you will still be able to put effort into making tasks easier for others who are already able to do the more complicated tasks that come with your job.

This pattern stood out to me as I believe that this is especially important to remember when you are entering any job or looking to start your career after college as the thought of ‘not knowing’ how to do the more technical tasks can be daunting for people at times as they see it as a massive obstacle you must overcome when in reality you are not expected to be able to do every task that more experienced team members are able to do. You are expected to contribute in any way you can to help your team work and provide insight while also remembering to continuously learn along the way in order to enable yourself to do these tasks in the future so that one day you are the ‘more experienced team member’ that someone looks to for guidance. Advice like this is important for college graduates that are just starting their careers as in most cases our first jobs will be learning experiences that we need to embrace and make the best of in order to further our understanding of both the field and our colleagues. 

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.

After my week of spring break, I’m looking to get back to building constructive habits and reinforcing my software development fundamentals. I was inspired to return to this chapter of the “Apprenticeship Patterns” textbook because I recently learned about a computer science problem called the Circle-Ellipse problem.

This hypothetical problem is meant to highlight the limitations of the object-oriented programming paradigm, specifically when using subtype polymorphism in your class design. In the Circle-Ellipse problem, two classes are defined, Circle and Ellipse, with the Circle class inheriting from the Ellipse class. The Ellipse class includes two member methods, stretchX() and stretchY() which can modify, or mutate, two private member variables of Ellipse each representing an X and Y coordinate. The programming language understands all instances of the Circle class as also being instances of the Ellipse class with this inheritance relation. The problem arises when considering the requirements of a subclass. A subclass needs to implement all the member variables and methods of its parent. The Circle class needs to implement stretchX() and stretchY() as a subclass of Ellipse. Using either of these methods to change the dimensions of the Circle would consequently make that object no longer represent a mathematically correct circle.

As this problem was explained to me, the Liskov Substitution Principle was mentioned. I remember reading about this principle as one of the 5 SOLID software design patterns. The Liskov Substitution Principle essentially states that in a program using subtype polymorphism, an object ought to be able to be substituted by one of its subclasses without breaking the program. The Circle-Ellipse problem represents a violation of this principle because an Ellipse cannot be substituted for a Circle except in one very specific case.

I hadn’t considered the limitations of inheritance relationships in software design before learning about this problem. I decided that after the lecture where I learned about the Circle-Ellipse problem, and after seeing so many titles and authors name dropped in “Apprenticeship Patterns”, that I should start compiling a reading list and start more intentionally defining my daily schedule, including time for reading about software design and computer science. I started with a summary of the Circle-Ellipse problem, and then went through the appendix in “Apprenticeship Patterns” to choose a few books that the authors cited the most often.

The pattern introduces the possibilities of making your reading list public on the internet or using an existing list to source further reading material. The reader is also prompted to look ahead to the future and maintain the reading list to use for reflection on their learning journey.

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.

The pattern of “The Long Road” highlights a common dilemma faced by aspiring software developers in today’s fast-paced industry. It contrasts the culture of instant gratification and superficial success with the desire to pursue mastery and craftsmanship in software development.

What intrigues me about this pattern is the disconnect between the long-term goals of becoming a proficient software developer and the short-term pressures to prioritize immediate financial gain and career advancement. Especially early in their careers, developers find themselves torn between these conflicting expectations while navigating through the complexities of the industry and trying to establish themselves.

This pattern resonates with me personally because it highlights the internal struggle I have faced in my own journey as a software developer. While I have not had any significant offers in the field of work yet, I know that true fulfillment in this line of work comes from the pursuit of excellence, continuous learning, and honing one’s craft over time. With my focus on excellence in my personal craft, it will pay off for me in the future later down the road.

The notion that the lessons and wisdom of seasoned software developers often goes unheeded in an industry that is constantly chasing the next big thing I found thought-provoking. The lack of knowledge transfer between generations of developers leads to the repetition of past mistakes and the reinvention of the wheel.

This pattern has caused me to reconsider my approach to my intended profession and how I want to work. Rather than falling into the external pressures and expectations, I am more committed to stay true to my passion for software development and prioritizing personal growth and mastery over short-term gains.

While I understand the advice to prioritize financial stability and career advancement, I do not completely agree with the notion that slow and steady skill-building is somehow less valuable or important. I believe that the pursuit of mastery is what ultimately sets exceptional developers apart and leads to long-term success and fulfillment in this field. I remain steadfast in my commitment to honing my skills, embracing lifelong learning, and striving for excellence in my craft, regardless of the trends or societal expectations.

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.

Summary

In the world of software development, the mantra of “Practice, Practice, Practice” resonates deeply with aspiring craftsmen. This pattern from the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye emphasizes the critical role of deliberate practice in mastering any skill, especially in the realm of programming.

My Reaction

The essence of this pattern is simple yet profound: improvement comes through consistent and focused practice. As I delved into this pattern, I couldn’t help but reflect on my own journey as a budding software developer. Often, I find myself oscillating between bouts of intense coding sessions and periods of procrastination. This pattern serves as a wake-up call, reminding me that true growth stems from disciplined and purposeful practice.

What struck me as particularly insightful about this pattern is its emphasis on deliberate practice. It’s not just about clocking in hours mindlessly; rather, it’s about setting specific goals, pushing oneself out of comfort zones, and seeking feedback to refine one’s skills. This approach resonates with the concept of “deep work” championed by Cal Newport, where undistracted focus on challenging tasks leads to substantial progress.

This pattern challenged my perception of talent and innate ability. The authors stress that talent is overrated and that mastery is achievable through dedicated practice. This perspective is empowering as it shifts the focus from fixed traits to actionable steps that anyone can take to improve.

However, I do have a slight disagreement with the notion that “talent doesn’t matter.” While I agree that hard work and practice are paramount, acknowledging individual differences in aptitude can also be valuable. Some may grasp concepts more quickly or possess a natural affinity for certain aspects of programming. Nonetheless, the core message of this pattern remains invaluable: consistent practice is the cornerstone of excellence.

As I reflect on how this pattern has influenced my approach to software development, I am inspired to adopt a more structured practice regimen. Setting aside dedicated time each day for deliberate practice, tackling challenging problems, seeking constructive feedback, and tracking progress are strategies I plan to implement rigorously.

The “Practice, Practice, Practice” pattern serves as a powerful reminder of the transformative impact of focused practice. It has reshaped my mindset, emphasizing the journey of improvement over notions of inherent talent. Through disciplined practice, I aim to embark on a path of continuous growth and mastery in software craftsmanship.

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.

Summary:
The “Rubbing Elbows” pattern emphasizes the value of collaborative learning in software development. It acknowledges the limitations of solo work and advocates for the benefits of working alongside another developer. The pattern suggests that certain skills and insights can only be gained through direct collaboration with peers, leading to enhanced productivity and continuous learning.

Reaction:
The concept of “Rubbing Elbows” resonates deeply with many developers, including myself. While autonomy is cherished, there’s a unique energy that arises from collaborating with others. The ability to bounce ideas off one another, share insights, and tackle challenges together fosters a rich learning environment that is hard to replicate solo.

Interesting Insights:
What’s particularly interesting about this pattern is its emphasis on the micro-techniques and personal knowledge exchanged during collaboration. It underscores the idea that true mastery in software development extends beyond technical proficiency to encompass the subtle habits and practices observed in seasoned developers. The notion of absorbing such knowledge through proximity and shared experience is compelling.

Impact on Professional Outlook:
This pattern has certainly influenced my perspective on professional growth within the software industry. It reinforces the importance of seeking out opportunities for collaboration, whether through pair programming, open-source contributions, or project partnerships. It has shifted my focus from purely technical skills to include the creation of collaborative abilities and interpersonal dynamics.

Disagreements and Considerations:
While the benefits of collaborative learning are evident, the pattern acknowledges that it’s not always a seamless experience. Instances of feeling lost or outpaced by a partner are common, requiring perseverance and effective communication to overcome. Additionally, the pattern raises awareness of the need to evaluate the effectiveness of collaborative practices like pair programming and make adjustments when necessary.

In conclusion, “Rubbing Elbows” serves as a reminder of the invaluable growth opportunities that arise from collaborative attempts in software development. By embracing this pattern and actively seeking out opportunities to work alongside peers, developers can enrich their skill sets, broaden their perspectives, and ultimately thrive in their professional journeys.

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

In the realm of software development, testing is an integral part of the development cycle. It ensures that the code behaves as expected under various conditions and scenarios. Test doubles are a crucial concept in testing, especially in unit testing, where dependencies need to be isolated to ensure focused and reliable tests.

Test doubles are objects used in place of real dependencies during testing. They help in simulating the behavior of real objects and controlling the environment of the test, making it easier to isolate the component being tested. There are several types of test doubles, each serving a specific purpose in testing. Let’s delve into some of the most common ones:

1. Dummy Objects: Dummy objects are the simplest form of test doubles. They are typically used when an object is required as a parameter but is not actually used within the test. Dummy objects do nothing and are only present to fulfill the method signature or parameter requirements.
2. Stub Objects: Stub objects provide predetermined responses to method calls during testing. They are used to simulate specific behavior of dependencies, returning fixed values or predefined responses to method calls. Stubs are useful when testing code that relies on external services or complex dependencies that are not easily controllable.
3. Mock Objects: Mock objects are more sophisticated than stubs. They record and verify interactions with the test subject, allowing expectations to be set on method calls. Mocks are useful for verifying that certain methods are called with specific parameters or in a certain sequence. They help in ensuring that the code under test behaves as expected in terms of interactions with its dependencies.
4. Fake Objects: Fake objects are implementations that mimic the behavior of real objects but are simpler and faster. They are often used to replace complex or slow dependencies with lightweight alternatives during testing. Fakes are particularly useful when dealing with external systems or resources that are difficult to control or reproduce in a testing environment.
5. Spy Objects: Spy objects are similar to mocks but with additional functionality. They record the interactions with the test subject like mocks, but they also allow access to the recorded data for verification or further processing. Spies are beneficial when you need to inspect the behavior of the code under test along with its interactions with dependencies.

Understanding the different types of test doubles empowers developers to write effective and efficient tests. By leveraging test doubles appropriately, developers can isolate components, control dependencies, and ensure reliable and maintainable tests.

For more in-depth information on test doubles and their usage, you can visit Martin Fowler’s article on Test Doubles. Martin Fowler is a renowned software developer and author known for his expertise in software design and development practices. His article provides comprehensive insights into various aspects of test doubles and their role in software testing.

In conclusion, mastering the use of test doubles is essential for writing robust and reliable tests, ultimately leading to higher-quality software products. Whether you’re dealing with simple dummy objects or complex mock objects, understanding when and how to employ each type of test double is key to effective testing practices in programming.

From the blog Discoveries in CS world by mgl1990 and used with permission of the author. All other rights reserved by the author.

Breakable Toys is a pattern that shows the importance of learning through failure and trail and error in software development. It teaches that failure is inevitable in the learning process and encourages developers to create small,  projects where they can make mistakes without breaking something permanently . By building a toy systems with similar toolsets to their professional projects but on a smaller scale developers can push their abilities to the limit and gain experience. The pattern suggests building simple projects like wikis, calendars, or address books. These projects serve as opportunities to try out new ideas and techniques without the pressure of real-world consequences in a job scenario . They allow developers to learn from their mistakes, iterate, and grow as professionals. Examples of Breakable Toys include personal wikis, games like Tetris or Tic-Tac-Toe, blogging software, and IRC clients. The idea is to choose projects that are relevant and useful to the developer’s life, allowing them to invest time and effort into exploring different aspects of software development. The pattern also emphasizes the importance of enjoying the process of building these toys. If the projects become stressful, they are less likely to be learning experiences that are successful.Also , developers should be open to the possibility that their toys may evolve into something more significant or even gain other users over time. A classic example cited is Linus Torvalds’s creation of Linux, initially announced as a hobby project to build a small operating system similar to Minix. This shows how even the most significant projects can start as personal experiments or Breakable Toys. Overall, Breakable Toys encourage developers to embrace failure, take risks, and continuously seek opportunities for learning and growth in their craft. By building and iterating on these small projects, developers can expand their skill sets, deepen their understanding of tools and technologies, and ultimately become more proficient practitioners of software development. I have used breakable toys for a school setting but never for just for fun, after diving more to the pattern I will be deepening during my free time. 

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