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.

When you first get placed on a team, it’s sometimes hard to get your bearings if you aren’t given an explicit task to work on to begin with. We sort of experienced this at the start of the semester, where we weren’t all too familiar with the Thea’s Pantry project even after working with forks of it for assignments in prior courses. Part of this is just the nature of working with something new, and having the expectation of providing value to it in a practical sense.

In this way, it makes sense the way we approached the issues that we took for the first sprint. For the most part, these issues were fairly simple and mostly plumbing, which can also be classified as sweeping the floor. The idea for sweeping the floor is that you take simple tasks that, while necessary, aren’t all that interesting, in order to build confidence in yourself with the project and build rapport with the team.

The authors make a good point in that it might not feel great to do as someone with a Computer Science degree that you worked hard for, but the reality is that the degree is really just a way to get your foot in the door. Same with any other way that you gained the qualifications to get accepted for a job or project that you’re working on. The real work is the work you do when you’re placed into a project, where you really get to apply the basics that you learned in college while also learning more practical skills.

I really think this is a good approach to take when you feel out of your element in a new environment. Maybe you just got hired for your first internship or even first full-time job, and while you are excited, you don’t really know how to actually provide value to the project, because you haven’t necessarily had that sort of experience before. This seems really helpful to get your bearings in a new project. The authors do mention a couple drawbacks to this approach, with the most notable one being the feeling of being stuck doing the small tasks without branching out due to anxiety, but there are ways out of this mindset too.

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.

This week I decided to discuss the pattern called “Stay in the Trenches”. In this section, the problem presented is where you are offered a promotion into a role that will pull you away from programming. It mentions that this offer is an illusion of accomplishment that will test your sustainable motivation and determination to walk the long road.  I decided to pick this pattern because it involves the idea of sustainable motivations which is a pattern I wrote about previously. I am unsure about what is motivating me to stay in the field so I like thinking about these kinds of topics. I don’t think this section has really changed my mind about the way I think about my profession though.

Many people equate a promotion with success but in the problem presented (a promotion that would pull you away from programming), you will be trading the programming skills that you have worked to develop for said promotion. The tet calls for you to stay on your path and work with your manager to find other mechanisms to reward you for your excellent work. This means if your company refuses to be flexible, you should find opportunities somewhere else. 

I agree that it would be best to continue on the path of software engineering since you’ve dedicated a lot of time in an attempt to become a master but simply saying that if your organization is inflexible then you should find opportunities elsewhere is a bit easier said than done. I think you can love this path but if life knocks you down it may be a bit difficult to stay on the path. If you are able to find other opportunities, that’s great; you can continue on the path. If you have trouble finding other opportunities and you need the resources that the promotion can provide, then you may just have to take that promotion. I’m not saying that you have to give up software engineering forever, but you might have to take a little detour and stray from the path a little at least until you can find other opportunities elsewhere. You can still love software engineering and pick up projects in your free time but sometimes you have to be realistic in this society career wise. 

Lastly, I do think the list of possible alternate rewards for your excellence was great. It suggested to “consider whether there are standard constraints that could be loosened in your case” and to  “prepare a list of these alternative rewards so that when you reject that promotion, you’re in a position to negotiate based on a clear understanding of your own motivations”. I think those are very helpful suggestions.

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.