For this week’s blog post, I covered the design pattern “Sustainable Motivations” from chapter three of “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. I chose “Sustainable Motivations” for this week’s pattern because I think that maintaining your motivations for your career is one of the most important things you can do for your mental health regarding software development. This chapter discusses why sustainable motivations are essential.

A section of this chapter that stuck with me was when the author says that there will be days when you are surprised that you are paid to write software and how happy you are with what you are working on. The author then mentions that those days are few and far between. “There will be days, weeks, and months when you love your job. You’ll chuckle to yourself, in awe that you actually get paid to develop software. The software you write will flow effortlessly from your mind through your fingertips, beautiful to behold in function and design. These are good and extraordinary days. In other words, they are not your ordinary days.” This was not a massive revelation for me, and I am well aware that most of my time working will be just that, working. I am not necessarily working somewhere because I love what I am developing, though I hope I do love what I am working on. That is the goal, after all.

The authors also go into some detail about what challenges a developer would face in the field. “As Paul Graham so rightly says, the typical programming job will put you face-to-face with tedious, vaguely defined, and needlessly complex problems. Nasty, wicked problems. What’s more, you may also be faced with bureaucracy, difficult personalities, and spotty leadership. There will be days, weeks, and months when you question your commitment to the craft. When you are confronted with such problems, it is crucial that your motivations to program are aligned with walking The Long Road.” Thankfully, with my experiences so far through my education, I feel prepared for the challenges that come from the work itself. From living life, I think that I can navigate bureaucratic and interpersonal issues reasonably well.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The pattern I chose to write about from Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is in chapter 3: Sustainable Motivations. I chose this as my first pattern to touch on because I find that motivation is something that I struggle with constantly. I already face days where I question my commitment. I did it today. Imposter syndrome got to me and I questioned whether I was cut out for this field. 

I agree with the argument that “it is crucial that your motivations to program are aligned with walking The Long Road”. Two of the examples of unsustainable motivations were money and thinking of programming as fun. Initially, my primary motivation for getting into this field was money; I did think it was somewhat fun to write code and think of solutions but I was thinking about a career path that would pay decently well. My line of thinking was impacted by how expensive it is to live and enjoy life. I figured that it’s best to just become a software developer because “It’s not like I hate it and it pays well”. After reading, I want to try figuring out what motivates me to stay in this field. I’m motivated by something that isn’t money or how fun it is because I’m still studying software development despite my struggles. 

I couldn’t find something in this pattern that I disagreed with but I don’t exactly understand the task from the action part. It instructed to “Write down at least 15 things that motivate you. Wait a little while, then write down another five. How many of your motivations are about what other people think rather than what you feel? Are the percentages different between your first 15 and the final 5? How many of the motivating factors can you do without? Now write down a list of the five most important things that motivate you”. I don’t understand the practice of writing down an initial 15 and then another 5 when you can keep the questions in mind as you write the last important 5. Maybe I’ll try it and figure it out.

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 ‘Unleash your enthusiasm’ apprenticeship pattern is one which I would consider very important. The basis of this pattern is that you should not feel the need to suppress your own excitement over crafting software when you are part of a team but you should be mindful of the team’s dynamic and attitude before blindly acting on your own enthusiasm. Essentially it is completely normal for a newcomer in software development to be excited to learn or even to be working within a professional team but the newcomer should always keep in mind that their enthusiasm may be warranted but depending on your colleagues you may want to keep your enthusiasm to yourself in order to not make any negative impression which is important in many different fields not only software development. But even if you judge that your enthusiasm should be kept to yourself based on a team or individual’s dynamic you can still ask questions in order to better yourself.

  I found this pattern particularly useful as I myself along with some fellow computer science majors I know are hesitant to show excitement over software development at times as I do not know if it would be considered as unprofessional. This pattern explained to me that while you do not want to overly express your excitement throughout the learning process it can be helpful to question things and give your ideas even as a beginner when working in a team as the perspective you offer the team is fresh and can lead to helpful solutions or enhance your own learning process and the more you know about what you are developing with your team the more useful you will be when trying to work together on productive and time effective solutions. Being aware that it is for the most part encouraged to share your thoughts, question or ideas when you can at the very least so that you can get an explanation on why an idea would or would not work is something that will help me to be more open to sharing my thoughts with others whether it be colleagues, other students professors etc.

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.

Summary: 

The white belt pattern focuses on the idea that new situations should be approached with all previous knowledge set aside. The white belt signifies an entry level of knowledge and understanding of a subject, and is only achievable if all preconceptions and past experiences are removed during the learning process. This mental clean slate prevents old habits or patterns from getting in the way of exploring new possibilities when it comes to solving problems.

Reflection:

The more I reflect on this pattern the more I agree with it. However, my opinion felt like it went from agreeing to disagreeing back to agreeing. When in reality, it went from agreeing with some parts, and disagreeing with parts I didn’t fully understand. To eventually gaining an understanding of the pattern that I fully agree with.

Originally agreeing with the overall idea that you should have the mentality of a white belt when learning something new, I disagreed with the notion that all previous knowledge was bad. I, as do many others, learn by being able to take previous knowledge and experiences and relating them to the new situations. This however is the trap that this pattern is actually trying to avoid. The interesting part in this section that made me realize my mistake in my in initial interpretation was the “problem of ‘writing Fortran in any language.’” Not knowing what FORTRAN was, I researched it and found out that I was in fact making this same mistake. Learning a new language doesn’t mean just being able to recreate a simple program. It involves learning all the small nuances and limitations each language has. The only way to explore those is to approach each situation independently and with a clean slate.

My first language was java, and when it comes to learning a new language it is helpful for me to be able to relate things in the new language to elements in java. This turns out to be a trap if you are only looking for 1 to 1 relationships, or you let your old knowledge prevent you from learning something specific to the new language. The more I think back to all my older projects that involved learning in a language that was not java, all I actually learned was the syntax of how to rewrite my code in another language. My understanding of the language or coding in general did not get deeper. Having my previous knowledge acted more as blinders than guidelines, showing me the one way I already knew, but preventing me from seeing other possibilities I didn’t know even existed.

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

When working with a project that has already been built up to a certain point, one can find themselves lost in where to look first, how to accomplish their job within that project, how the program even works as a whole. I’ve had firsthand experience with this already working with the Thea’s Pantry system. Ultimately, the only way to really learn what is going on in the system is by looking at the code and trying to make sense of it.

This pattern is very important within the context of working in the Software Development field. The quote at the end is a synopsis of it: if a programmer can learn a codebase quickly after being hired, then they can more quickly be productive and add value to the project for the employer they are writing code for. Otherwise, you’re spending a lot of time just trying to get an understanding of things while you have deadlines coming soon.

The one thing is that obviously getting an understanding of a codebase is incredibly difficult depending on your level of knowledge in various languages and programming as a whole. Of course, this is one of the later patterns (chapter 5), but regardless if I don’t have much experience with JavaScript, trying to read a project that operates on JavaScript at a high level will be a bit more difficult than reading a project that uses C given that I have worked with C for a year, let’s say.

There’s also the consideration of documentation. Documentation can be very helpful, but there will always be cases where the code was changed and the documentation was forgotten about. This leads to additional confusion, and it only compounds when there are comments in the actual code that are misleading, or functions that weren’t written with clean code principles in mind. Everyone makes mistakes, and sometimes those mistakes lead to tech debt that has been compounded upon to the point where that bit of code that’s hard to understand cannot be changed without a whole refactor.

Of course, this is dependent on the project. I’m sure that projects like version control systems that were mentioned in the reading are fairly consistent because they need to be, and having the experience of learning a codebase like that is definitely useful and builds on adaptation skills that are somewhat of a necessity in the tech field. It’s an interesting thought, and I can see how it can lead to better code.

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.

“Confront Your Ignorance” urges us to face our lack of knowledge head-on. Instead of shying away from what we don’t know, this pattern encourages us to acknowledge our ignorance and embrace it as a stepping stone to growth.

Key points of the pattern include:

1. Recognizing Blind Spots: We all have blind spots – areas where our knowledge is lacking or incomplete. The first step is acknowledging these blind spots and accepting that there’s always more to learn.
2. Seeking Learning Opportunities: Actively seek out opportunities to expand your knowledge and skills. Whether it’s through reading books, attending workshops, or collaborating with peers, every experience is a chance to confront your ignorance.
3. Embracing Humility: Embrace humility and be open to learning from others. Recognize that expertise comes from a continuous process of confronting and overcoming ignorance, rather than pretending to know it all.
4. Asking Questions: Don’t be afraid to ask questions, even if they seem basic or obvious. Asking questions is a sign of curiosity and a willingness to learn.

My Reaction:

“Confront Your Ignorance” resonated deeply with me, especially as someone navigating the complex landscape of software development. It’s easy to feel overwhelmed by the vastness of the field, but this pattern reminded me that it’s okay not to have all the answers.

One aspect of the pattern that particularly struck me is the emphasis on humility. In a culture that often values expertise and confidence above all else, it can be daunting to admit when we don’t know something. However, this pattern taught me that true growth comes from embracing our ignorance and using it as fuel for learning.

I’ve also realized the importance of seeking out learning opportunities proactively. Instead of waiting for knowledge to come to me, I now actively seek out books, courses, and conversations that challenge my existing understanding.

One point of contention I have with the pattern is the suggestion to ask questions, even if they seem basic. While I agree with the sentiment, I sometimes struggle with feeling like I’m bothering others with my questions. However, I’m working on overcoming this hesitation and embracing the value of curiosity.

In conclusion, “Confront Your Ignorance” has shifted my perspective on learning and growth. By embracing the unknown and confronting my ignorance, I’m committed to embarking on a journey of continuous improvement and discovery.

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 “Find Mentors” pattern emphasizes the importance of seeking guidance and mentorship from experienced individuals in the field of software craftsmanship. It acknowledges the challenges faced by apprentices in navigating their professional journeys and advocates for actively seeking out mentors who can provide valuable insights and guidance. The pattern highlights the rarity of finding a master craftsman but encourages apprentices to engage with a series of mentors, recognizing that mentorship can come in various forms and may not always be face-to-face.

Reaction: This pattern resonates deeply with me as it underscores the significance of mentorship in personal and professional development. It acknowledges the inherent challenges in finding suitable mentors but emphasizes the transformative impact that mentorship can have on one’s journey towards mastery. I appreciate the practical advice offered in the pattern, such as lurking in online communities to identify potential mentors and taking the initiative to reach out to them for informal advice.

Interest: What I find particularly interesting and useful about this pattern is its emphasis on the reciprocal nature of mentorship. While apprentices seek guidance from experienced practitioners, they are also encouraged to pay it forward by mentoring others who are earlier in their journey. This aspect highlights the collaborative and communal nature of the software craftsmanship community, where knowledge sharing and mentorship play vital roles in fostering growth and development.

Reflection: The “Find Mentors” pattern has prompted me to reflect on my own approach to mentorship and how I can leverage it to enhance my professional growth. As I navigate my career in software development, I recognize the importance of seeking out mentors who can provide guidance, feedback, and support. Additionally, I am inspired to contribute to the community by offering mentorship to others who may benefit from my experiences and insights.

Disagreement: While I wholeheartedly agree with the principles outlined in the pattern, I believe that it could provide more nuanced guidance on navigating the complexities of mentorship relationships. For example, it could delve into strategies for building meaningful connections with mentors and managing expectations within the mentorship dynamic. Additionally, the pattern could explore potential challenges or pitfalls that apprentices may encounter in their quest to find suitable mentors.

Conclusion: In conclusion, the “Find Mentors” pattern serves as a valuable reminder of the importance of mentorship in the journey towards software craftsmanship. By actively seeking out mentors and engaging in reciprocal mentorship relationships, apprentices can accelerate their learning, navigate challenges more effectively, and contribute to the growth of the software craftsmanship community. As I continue on my own journey, I am committed to embracing mentorship as a cornerstone of my professional development and to paying it forward by supporting others along the way.

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