Monthly Archives: February 2022

White Belt Pattern

For my first Apprenticeship pattern, I chose to write about “The White Belt”. In this pattern, you’ve created a good understanding of the first language you’ve learned, and others have recognized and have often called you for help when they have problems. Even though this is great, you feel that you’re have a little difficulty trying to learn new materials and find that things are slowing down and you’re not learning as quick as before and fear you have hit a peak of your personal development.

When I first read about this pattern, I did in fact felt like I hit a plateau in obtaining new skills and in self learning. I could relate to the description of the white belt very much. I really loved how they quoted Yoda from Star Wars with “You must unlearn what you have learned”, regarding approaching new situations. Another quote that I liked while reading about this pattern is “In order to climb, you must leave the sure footing, letting go of what you already do well and possibly slipping downward into a ravine. If you never let go of what you already do well, you may continue to make steady progress, but you’ll never get off the plateau” by Jerry Weinberg. Both quotes are quite similar and suggest that in order to learn and make a steady progress, you must leave your comfort zone and tackle the problem with a different method. This helped me come to the realization that I’m constantly trying to incorporate another programming language that I was comfortable with the new language I’m trying to learn. Which results in me having a hard time learning new things for both languages. After I took a step back to analyze what was going on, I went back and tackle each language in a separate way. I then was able to learn and get past the plateau I was on.

There isn’t anything I would disagree with what was said for this pattern. Everything that was said was great and would really help others who have also hit a plateau. The story of Dave was a quick and simple way of relating the quotes I said earlier and applying them. Overall reading about this pattern has helped me come to the realization that there are some problems that should be handled differently, for instance when learning a new problem or a technique of how to do something.

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

Emptying the Cup

Apprenticeship Patterns by Dave Hoover, Adewale Oshineye

Taking a Different Approach to Coach. If there is a way to learn, adapt to change, or see yourself in a different perspective, the book of  Apprenticeship Patterns chapter 2, “Empty the cup.” is your guidance. 

To sum up the idea from the introduction of that chapter, let’s paraphrase it like this: “Empty cup, new tea,” a buddy once said, perhaps borrowing the phrase from a great, ancient philosopher. The friend was attempting to persuade a group of change-seekers that if they truly desired “fresh tea” in their life, they needed to “empty their cups” to make way for it. This is a straightforward but deep idea. Yet, how many of us attempt to start something new—whether it’s a new activity, a new goal, a new relationship, or a larger version of something we already have in our lives—without first asking ourselves, “What do I need to let go of to create a way for this?” 

There are a lot of great concepts in this chapter, but I would like to focus on two paragraphs here: Your first language and concrete skills. Why do those concepts matter in programming? I would like to share a brief description of my experience with my first programming language. As well known, programming languages are not different from any other languages. All are required to afford passion, dedication, consistency. Of course, we are always excited about learning a new language. We will put all the effort into it until we have a good sense of it. I remember working days and nights to improve my skill in my new language. However, as the book stated, we learned things one way, and we made a custom of it. I am still having trouble changing my comfort zone. Reading through this book, it’s the best wishes I can think of as a programmer to change my way to a new perspective or new approach about how to look at myself when it comes to programming. 

Concrete Skills

Why is it essential in today’s world? Technology gives us a new reality in this world. Working in collaboration is becoming the new norm. Cloud computing and the level of competition have brought a territory that requires many different sets of skills. Adaptation, teamwork, problem-solving, critical thinking, and more became a demand for the work environment. 

As it says it all here in this paragraph; Constructive talents must be acquired and maintained. Even though one of the benefits of being an apprentice is the capacity to learn rapidly, having discrete and demonstrable proficiency with specific tools and technologies enhances the possibility that you will be trusted to contribute indirectly until you attain status.

References:

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#concrete_skills

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

Apprenticeship Pattern: Your First Language

For my first blog post on these patterns, I wanted to start with Your First Language. I have only been exposed to a handful of languages since starting my computer science journey. And though I have honed my skills somewhat in those languages, I am by no means a master at them. I can relate to the problem in the pattern, so I was interested in what it had to say. This pattern addresses those who are looking to start learning a programming language or those who feel their skills are not up to par with what a job is looking for. Selecting your first language could influence your future career, so it is important to choose a language wisely. The solution suggests choosing a language based on those around you, for example, an expert in the subject that can mentor you. Becoming proficient in a language involves building up knowledge through reading specifications and solving problems.

One of my main takeaways was to choose a language based on the people you know, specifically an expert. The other takeaway was to look at the community built around a language and see if you want to belong to that community. I found those two points to be the largest deciding factors when it comes to picking up a new language. For me, I would consider my first language to be Java since that was the first language that I learned at school. There were plenty of professors that aided in my learning process and the community surrounding Java is extensive. It would only make sense for me to continue learning about java and solving sample solutions until I consider myself fluent. I think starting a professional career is a bit daunting, but what the pattern explains makes a lot of sense. The only way to become proficient at a language is to do a lot of reading and try out problems myself. A work environment where you can call on a more experienced team member is also beneficial when it comes to learning a language. That being said, I don’t think there is anything I disagree with anything mentioned in the pattern, it more so emphasizes what it means to be a good learner.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Expose your Ignorance Pattern

This learning pattern is very important it exposes us to a very delicate issue. Although the Software Development community is built around everchanging technologies, and we are all shooting at a moving target, the fear of letting others know what you do not know is constantly present. Particularly to me, another analogous fear that I think is related to this learning pattern is the fear of you believing you know something and being shown the opposite. I think that at this level in our learning careers, so close to graduating, this pattern is extremely important. This period of entering the field officially, is the period in which we feel the need to show what we know, coupled with doubts and the lack of experience which rob us the confidence we need.

I hope that once we internalize this pattern regardless of the fear of using it, the field, out in the wild will become gradually more amenable. Perhaps this is why I think that a job with a grounded company with tradition in technology is the best steppingstone to a software developer. Every company small or large today relies on technologies that we must understand. This is the reason I fear the non-tech companies that need tech people. The fear that they will expect the newbie to know it all, or worst, not understand what it really takes to get what they want. I think that this fear will probably gradually disappear maybe at about 2 years in the field.      

To sum up I must say that this pattern served me well in my career as a student and I think it will serve me just as well as a developer. I feel lucky to know that I can relate and count on people that are either having the same problem as me or have surpass it to help me. Reaching out to ask people for help is not only better than staying ignorant but help build confidence in the person whom you asked. Even when you ask someone who does not understand the field, their out of the box answer may guide you to a better understanding. I found that I discovered a lot of the answers I needed just by formulating the question and dissecting it to a non tech aficionado.  

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

Apprenticeship Pattern: Concrete Skills

The pattern I decided to read is titled “Concrete Skills” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts off by discussing how hiring managers have no incentive to hire someone who can not directly contribute to a team’s workload. Hoover and Oshineye ask the following rhetorical question from a recruiters point of view: “If we hire you today, what can you do on Monday morning that will benefit us?”. In short, the solution to this problem is to develop and maintain some concrete skills. We learn that with time we will become less dependent on our concrete skills and get hired through the reputation we have garnered from notable projects. This pattern ends by giving the reader a recommendation on how they can begin developing some concrete skills.

The thing I found most interesting from the reading is that at some point in my journey I will become less dependent on my concrete skills. My portfolio and “deeper qualities” will be what matter more. This was interesting to me because in a section that stresses the importance of learning concrete skills in the beginning of my professional journey, I am still getting a message that soft skills are important. This shows me how there is an important balance of maintaining the hard skills I’ve learned in addition to being a team player, having good communication, being empathetic and having many other traits that fall under the soft skills category.

Overall, there isn’t anything that stands out that I strongly disagree with in the reading. As far as how this pattern has caused me to change the way I think, I would say that it has emphasized the importance of regularly updating my resume with technical skills since this is something many hiring managers focus on. Since there are plenty of skills I’ve been developing in school this past year, I took the advice from this pattern to heart and almost immediately started jotting down the skills I have started developing. I also started looking into CVs online for inspiration of concrete skills I want to develop and to add to my own resume.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Exposing Your Ignorance

When previously looking at ‘Apprenticeship Patterns’ we discussed the importance of the pattern ‘The White belt'(You can read more about that here: https://georgechyoghlycs343.wordpress.com/2022/01/26/apprenticeship-patterns-wearing-your-white-belt/). That pattern focused on the importance of being able to set aside past experiences to learn something new. To build upon this we will be looking at the pattern titled ‘Exposing Your Ignorance’.

As we previously saw, it is important to always be learning, especially for software craftsmen who must always be prepared to learn a new language or technology stack for their current job. However, this ever-evolving profession presents a common risk that many fall victim to. It is far too often that we feel pressure to appear competent in front of our peers and our managers. People depend on us to be confident and deliver on whatever job is put in front of us.

You may feel pressured to give your manager reassurance that you know what they want, how to give it to them and when it will be done. But to do so will only be detrimental to your reputation in the long run if you cannot deliver. Instead, it is important to set aside your pride and be truthful with both yourself and your peers regarding your capabilities. If you want to reassure anyone on anything, do so on your ability to learn.

Dave Hoover, an author of this book worked as a family therapist previously and often took the “not knowing” stance when dealing with every new family. This feeling of not knowing would eventually become something that he grew attached to, as a reminder that he was in the right place, that he was learning something new and growing as a person.

To “Expose your Ignorance” you must embrace the learning process, you must have the courage to “Wear your White Belt” and commit to the learning process. Some don’t and fall back on what they are already familiar with. Those people generally become experts but this is not the goal of an apprentice. An apprentice will, by the end of their apprenticeship, have a solid grasp on a few different technologies they can use to create robust software applications. A master craftsman will have a handle on a myriad of different technologies and be able to create large, complex software.

One thing that is discussed in the book you can do now is take a sheet of paper, write down a list of 5 different software tools you do not understand. Post this paper in an area that you and anyone else can see it and update it as you learn more and your work changes. Setting aside your pride to do this can help prevent future pressure from causing you to act in ways that may be detrimental to you in the future.

Bibliography:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Reflection on the Breakable Toys Apprenticeship Pattern

The Breakable Toys pattern is about creating your own projects that allow you a safe place to experiment with new ideas and become more comfortable with your toolset. A project where you can try unconventional things to improve your skill, but where it doesn’t matter if they fail. The project they recommend for this is creating a wiki for yourself, to help learn multiple facets of design techniques.

I really liked this pattern and the idea that it promotes. Working on a rigid system that many people use, or whose functionality is necessary for the operation of your job, there isn’t really any room to try new things and grow. So having your own little workspace to try new things seems like a great way to build your knowledge in an environment that is completely your own. Like a chemist having a chemistry lab to experiment, it is important for software developers to have a place to experiment themselves. I also really enjoyed the idea of maintaining a project like this across different jobs, always having a place to try new things and to try new techniques when you are stuck on something. I think that implementing this into my own life will allow me to grow as a developer and gain new skills and insights that I would never have the freedom to do in a work environment.

The recommended “action” for this pattern is to build a wiki, and while I think this is a good example, I don’t think that that would work for everyone. So I think that if anything, I disagree with that specific recommendation, as I feel that depending on what is necessary for your work, a wiki might not need the tools that you need to work with or work on. So while I think it is a good example, I think that the individual has to come up with a project of similar scope that better matches what they need.

Overall, I think that this pattern is a very good piece of advice. Any profession can have difficulties and expectations that cause you to stagnate in your learning, but in the ever-shifting landscape of the software development field, this stagnation can leave you behind very quickly. So having your own personal project to experiment with things in will keep your skills sharp and keep you constantly learning and developing solutions to problems that can later be implemented in a work environment.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week I am writing about concrete skills. The apprentice pattern here is somewhat self explanatory. Concrete skills are what an apprentice can do for a company day one on the job. Some examples of conrete skills are basic web development, popular frameworks, and the standard library of the programmer’s language of choice. The problem is that an apprentice that has not proven himself may not be able to find a job. The hiring manager needs a reason to take a risk on this prospective employee. The solution is aquiring concrete skills. The author recommends that apprentices seek out guidance from developers they admire. And pursue 5 concrete skills on that developer’s resume. And build a toy project that demonstrates these concrete skills. I really like this idea. The author also mentions that a recruiter is more focused on the skills at this point in the journey, than the experience. Because the work experience is not software related.

I think that his is a very useful apprentice pattern. And I like that it starts before an apprentice starts getting paid to code. One thing I think could be improved is finding the important concrete skills from another developers resume. I think the more practical approach is to look at job postings to find what concrete skills are in demand right now. It is possible that a developer I admire has skills on their resume that are no longer in demand. One way that employers quantify an apprentice’s concrete skills is through a technical interview. This interview would involve basic data structures and algorithms. As well as the standard library of whichever language the candidate is interviewing with.

I have done a version of this apprentice pattern already. I have noticed that many companies hiring Full Stack Engineers are using React.js, so I decided to complete a React tutorial and a simple project over the Christmas break. I was able to but something new on my GitHub, and my resume. This process is a win-win because I am learning a concrete skill, and improving my public GitHub profile at the same time.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and 2-6 introductions Summary

I found interesting that a lot of the practices mentioned in the book are probably day to day patterns that we practice involuntarily. Some patterns are surprisingly new and offer a good way to cope with the workflow of continuous learning. The comparison with medieval ways of artisanship in which the learning takes a practicum meaning and the theoretical is stripped out in favor of physical interaction which is very interesting. I am an enthusiast of the theoretical realm, but I must agree that expertise which people wrongly associate with the illusion of talent only comes with continuous long-term repetitions of small actions on limited theoretical content.     

The book showed me that there is more than one way to navigate through a lifelong learning journey. It is comforting to know that in the Software Development work environment the continuous improvement presented by the authors is not only present but encouraged. The idea of sharing these patterns and improving on them is very open source like. It shows the developer understanding of the need for each other and that there is no downside to help the general improvement of the community.  

The chapter that talks about perpetual learning is enlightening. It absolutely homes in on the greatest obstacle to learning which is distraction.  I agree to it but have my reservations because it also mentions that if you love learning you get over these distractions. What I think is truer is that focus is also the most important skill to be practiced. It involves more than a set of actions and habits; it also involves chemical reactions and sensorial exposure as well as countless parameters out of our control. I confess that as I navigate through my undergrad incursion, I came across supplements to improve focus and used them even if just for placebo effect. I have set controls such as continuous study times, set brakes, meditating 20 minutes for every hour, sleeping a minimum of 8 hours, balancing topics by due date and importance, not consuming alcohol even in social events, ignoring people and everything that is not study. Which is why I have a pile of mail and bills after every semester. But even after all the controls I still must continuously adjust and adapt to optimize focus. Without focus there can be no real learning.        

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

Apprenticeship Pattern

The Apprenticeship Pattern: Guidance for the Aspiring Software Craftsman book of Adewale Oshineye and Dave Hoover is the book that I recently have the opportunity to read and explore. What I like about this book, unlike typical software development books, this book’s focus is on how to develop and maintain a solid mindset as a software developer.

Apprenticeship is the state of evolving and looking for better ways and seeking out people, companies colleagues that force us to learn better and smarter. It’s the first step on the road toward becoming a different kind of software professional and to learn is the most skilled software developer. That includes looking out for good teachers and taking opportunities to learn by practicing and working with them.

This chapter showed me that to be a better developer, we need to seek out bits of help from others, learn from others, and grow together. Therefore, the ability to express ideas and to communicate are two essential skills that every developer needs to have and maintain.

People say you cannot judge a book by its cover. However, in my opinion, a good book would have good first few pages to attract readers. This book is one of them. The first chapter showed me different approaches and mentalities to be a successful developer. It taught me that efforts make successful developers and failure is just a way to try on a different approach. Also, another lesson I have learned was a belief that you can be better, and everything can be improved if you’re willing to put the work in. A good developer needs to maintain an inward focus to cultivate their skills. It means that a willingness to learn new technology and a humble attitude will help us go further in this industry as in the story about “Emptying the cup”.

Although, I’m just at the beginning of this book but I’m really looking forward to read the rest of this book to learn more about apprenticeship pattern for me to become a good and a better developer.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.