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.

Apprenticeship Patterns, Chapter 1 & 2-6 Introducions

From the beginning of chapter 1, it does not surprise me that Google lists 61,800 references to the phrase “software craftsmanship”, with only a few of those being usable definitions. So many times when trying to look something up we have to parse through the search results and try to find what we actually want, because what comes up first and the rest might not exactly be what we are looking for. I also agree with the sections about being an apprentice, journeyman, and master, as to show that there is progress from where you started, and what it might look like as you continue to learn and grow throughout your software practices.

An apprenticeship pattern, as we learn, is an attempt to offer guidance to someone working with a model in ways in which they are trying to improve progress in their career. I like this definition, as it describes a pattern that we use to learn and grow throughout our software careers.

In the beginning of chapter 2 we read a story about an apprentice learning from a master, and how whenever the master would try to teach the apprentice something, the apprentice would cut off the master saying what he already knows about the subject. The master later tells the apprentice after overfilling his tea cup saying “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”. This is an analogy to how when learning from someone with greater experience than yourself, it is best to just learn from the master, and not try to interject with what you already know.

In the beginning of chapter 3 we learn about someone named Dave, who has certificates certifying that he knows what he was doing in various programming languages. We then learn about how Dave found some hackers online, and learned about their expertise in the field. Despite having certificates showing that he knew a lot, he felt his knowledge paled to the hackers’ knowledge. This shows, similar to the previous chapter, that there is always something to learn, not to get discouraged by feeling like you know so little, and always be inspired to learn more from others.

In chapter 4 we learn about having accurate self assessments. It is important to not become self satisfied with your success, as it is easy to feel like you are slightly better than most others in the field, and become discouraged from continuing to improve and get better. I like this, as I can easily see how most people can get absorbed in self satisfaction, and not want to continue to grow and improve.

In chapter 5 we learn about how in software development, there should be two activities, learning and communication. In this, it is important to always continue learning, and to always communicate with others in the field, as they can often see things you cannot. This allows you to be familiar with your weaknesses, which allows you to improve more and more.

Lastly, in chapter 6, we learn about how you yourself should be constructing your own curriculum through the vast, ever expanding resource of the internet. One must always be learning and practicing. It should not be up to others to assign what you must read and learn about, it should be up to you to continue on your path to always continue to learn and improve.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

A Constant State of “Update”(ing): Using Apprenticeship Patterns to Become a Master Programmer

“Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been considered to be an acclaimed read by many of my fellow students. After giving the book a try, I can also see why it is such a big hit. In essence, this book speaks to programmers on a “relatable, spiritual” level on how to turn their passion for software development into a lifelong process of constant improvement.

To be honest, the most interesting part of the reading for me was found in Chapter 4: Accurate Self-Assessment. This is because it is instrumental to my learning style that I am “the worst of a group”, or that I am always in a zone that I need to focus on improvement. Throughout my college career, I have been the type of person to rant and rave about how “I’d rather get a ‘C’ and master two programming languages, than receive an ‘A’ and still show evidence of struggling with one.”

Considering my own views on how I work with software, I feel as though this book has been mainly a “rehash”, or a reinforcement of my beliefs. This is due to several factors, including the “Be the Worst” philosophy as mentioned in “Accurate Self-Assessment”; this can also be seen in “Chapter Two: Emptying the Cup”, where they state the importance of becoming extremely proficient with your first programming language.

Unfortunately, as amazing as this book is, I cannot say that I agree with every last line of its code. One spot where a “warning of disagreement” occurs is when “Chapter 6: Construct Your Curriculum” does just that – it tells me how to create my own study plan (outside of college classrooms and office hours). Perhaps this makes me contradict myself with my own “unorthodox schedule”, but I learn best when I don’t feel like it’s forced. Instead, my most efficient learning is recreational; it seems as though material sticks with me the best when I ingest it in the same way that one would ingest a juicy diary or a football roster.

For me, I found the chapter “Walking the Long Road” to be the most useful for continuing my career as a software engineer. This is due to the fact that it acts as a reason for using the philosophies found in “Accurate Self-Assessment”. By this, I mean that people (including myself) need to understand that becoming a master craftsman, and especially a master programmer, does not “just happen” overnight. it takes years upon years of grinding, of constantly “being wrong” and being challenged to find alternative solutions to problems.

Overall, “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been a fun, yet informative read. As mentioned before, I agree with most of the book; even in times of disagreement, I can see where the authors are coming from. I am looking forward to the applications of this book in my career as an aspiring software developer.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6

My favorite chapter in this week’s reading was chapter 4 “Accurate self assessment”. When you are a studying computer science in college you are introduced to new topics each semester and by the end, you have developed a good understanding of the material. Once that happens, a new semester starts and you are back to being a beginner in a topic. What we don’t think about often is in the workplace, there will be a large amount of learning initially however over time that can level off. Software engineering is a field that is constantly growing and changing, and I like the advice of always aiming to be the weakest member of your team to start off and work your way up. This is great advice because it keeps you in a place where you are always learning new things as the industry changes.

The topics of chapter six ties in really well with chapter four, almost as a way to teach the reader how to accomplish the goals of chapter four. Computer science is a growing field, but it’s also one of the fields with the most free available information on it’s topics shared online amongst other computer scientists. When you leave school it’s your responsibility to keep learning and decide how much you want to do. Read constantly is one of the pieces of advice I think is great, whether it’s books, blogs, articles, etc. A good goal to aim for when you are outside of school and start your job is to try and spend a half hour every reading different materials in CS.

This chapter also brings up a good point about learning to code in programming tutorials and how limiting that can be at times. It’s definitely a great starting point, however it shouldn’t be the long term way to learn. A software engineer should have the skills to approach any kind of debugging problem and develop their own solution. That’s why it’s so important to have good logical thinking and algorithm skills and work on solving a variety of different programming problems rather than follow many full project programming tutorials.

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

Apprenticeship Patterns Book review

I really enjoyed reading the introduction and the outlines of the Apprenticeship Patterns Book; it sparked my interest because I could identify myself with a lot of the concept and habits addressed in the book. As I started reading chapter one, there was already so much to learn in the ten values of software craftsmanship they listed and so much that I could start applying to my day-to-day life as of right now. Below are the biggest takeaways I got from each of the intros from chapter 2-6

The patterns in the second chapter are all about getting rid of preconceived ideas and not letting previously acquired knowledge get in the way of your learning. It’s all about how to maintain a beginner’s mindset and stay open minded regardless of your “expertise”.

The patterns in chapter three are about understanding and getting ready for an ever-going learning journey. There is always a way to improve a craft or in our case a project that we’re working on. Sometimes it’s easy to get intimidated by how far along others in the field are but the reality is that we are all on the same long road and we keep on learning.

The biggest takeaway from chapter four is not to linger in your comfort zone. It is very easy to stop making progress because we feel so good about where we’re at or, we feel accomplished when realizing that we’re doing “better than others”. The goal should be to measure our abilities and find ways to be better each day.

The fifth chapter gives away important patterns to start practicing as an apprentice in order to perpetually learn. Some of the patterns mentioned are: Expanding Your Bandwidth to expose yourself to new materials; Practice and keep practicing to get better; Reflect as you work, which leads to Recording and Sharing what you’re learning.

The last part of the book is all about patterns to build an effective curriculum. Knowledge is literally available anywhere in different formats (short text, audios, videos, …) However, it is important to still find actual books and writings from professional and use it.  A good reading list will facilitate you in this long road of learnings.

Although I am looking forward to reading the rest of the book, chapter 5 is definitely what I am excited about the most because I think it’s what I need as of right now.

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

One Step Backward, Two Steps Forward

“You have to spend money to make money.” – Peter Griffin (Family Guy)

This quote is probably one of the most familiar antitheses to the idea of “one step forward and two steps back”. Alongside this week’s reading of “Apprenticeship Patterns”, we are going to figure out how retreating into our competent “safe zones” can actually be a beneficial way to make progress into unknown territory.

In essence, the pattern describes about finding an “acceptable limit” of disregarding challenges in order to polish up on familiar material. By finding patterns in previous progress, we can empower ourselves to embrace the challenges of the unknown. It is important to note that the “limit” is respected – going too far ahead into the unknown leads to a lack of progress from ignorance. Retreating too far into the safe zone causes another lack – from fear.

I understand that taking some time to work on an easy, familiar project is a great way to create a productive sabbatical. To be honest, I have been practicing this pattern long before reading up on it; making familiar homework assignments and simple games has been a hobby of mine. Plus, once skills are learned with a “back of our hand” level of proficiency, it makes the mind bored with these tasks – it craves something more novel, no matter how challenging.

“Retreating Into Competence” stresses that we must make the regression quickly turn into progression, otherwise we may end up in a rut. While I don’t necessarily disagree, I wonder if there is a way to “charge the catapult” for an even greater forward effect. Exactly how far can we pull back on our efforts towards familiarity in order to shoot ourselves among the star s of the unknown? Is minimizing our refreshment emphasized because the “catapult method” has a short charge limit? My interest for these questions makes me want to experiment with the pattern (this would be best done in conjunction with some Breakable Toys).

In order to use this pattern professionally, I need to start thinking about time. Every moment of the past that I can regress to, was at one point “an unknown future destination”. Figuring out the methods on reaching these past points can lead to notes for successful exploration of a project’s future. Analyzation of the past should be done as scientifically as possible; getting wrapped up in the nostalgia of success or wallowing in the failure will cause us to miss the future that lays ahead.

Fun fact: this pattern itself is a “regression”; I am doing it by using a token to go back to Week-4.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

People have always asked me: “why are you so smart?”. Well, the truth is: my intelligence and my memory are a result of the same process that leads to world-famous athletes – we practice, practice, practice. I study academically during my semesters, and I study recreationally during my vacations; a true thirst for knowledge always welcomes a refill to the chalice.

This constant flow of acquiring knowledge comes with a cost though; more often than not, I have been incorrect over and over again. However, such is life within the field of science – experimentation is the process of challenging what we know to falsehood, and seeing if its truth still holds.

Connecting this ramble to Apprenticeship Patterns, I am pleased to tell you that the pattern for this week is “Practice, Practice, Practice”. The product within is just how it’s advertised; this pattern emphasizes that beginners learn best through “doing”, by performing actions under the guidance of professionals.

I find it interesting that the idea of “practice making perfect” is challenged; the new idea becomes “practice makes permanent”. Upon further analysis, I do have to say that I agree with this confrontation of the old adage – learning techniques improperly can lead to code smells. Proper, constant feedback while learning will prevent the coding landfill from becoming overwhelmed.

Personally, I would have to slightly disagree with the idea that apprentices must rely on their own resources to practice. I understand that this self-reliance can develop an independent learning process for the apprentice; however, a true leader reduces their aid for an adept apprentice (instead of completely removing it). Sure, beginners need more attention, but lifelong guidance builds relationships and motivates crafters; it’s easier to experiment when you feel tethered to a base.

While I have always stuck to the idea of constant practice, I will consider the idea of getting more constant feedback for my future professional habits. Personally, I have always had a fear of being judged for my shortcomings (and have only confronted this fear recently). In order to become the best of the best, we must practice our katas, within a dojo of coding professionals. As seen with other patterns in the book, we must assume that we are the worst (in a positive way), and confront our ignorance. Through practice, practice, practice with breakable toys, we achieve the proficiency that we strive for.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

‘C’ is For Coding; That’s Good Enough For Me

If you haven’t noticed already, there seems to be a trend of various coding practices that I tend to agree with. This is not merely a case of “kissing up” to the professionals, but rather it is the fact that I know I have been taught from the ground up by well-respected individuals. Many of the practice patterns found in “Apprenticeship Patterns” are ones that I have already been aware of, or still agree with despite their novelty. An additional agreement to add to this repertoire is the importance of “Your First Language”.

For me, this “first language” was C. To be honest, I don’t feel like there is a better option to select. C is an excellent, “mid-level” language that follows many of the practices found within my studies. For example, in “Apprenticeship Practices”, the book warns of becoming stuck within your “native tongue”; I feel as though this is negated (or at least parried) by many of the practices in C. C works closely with hardware, and involves skills found in assembly language, but can also be used to emulate higher level languages such as Java.

When it comes to my professional career, “my first language” is a philosophy that has given me a greater appreciation for the diverse landscape of large-scale projects. The C language has elements similar to Python, such as arrays. While data structures are not an impressive connection (they can be implemented among pretty much any language), it does make crossing the gap easier. Once at Python, I can learn about dictionaries, “key: value” pairs that can have an ideological equivalent found in .yaml files and JSON, and so on.

Interestingly enough, despite the emphasis on programming diversity, the pattern stresses finding a first language and staying strictly to its community. I feel mixed emotions about this philosophy: on one hand, it sounds as though “bridging gaps” found between languages should be avoided. On the other hand, constant practice is the best way to learn a first language, and that practice can be boosted by feedback from a desired community around that language.

Overall, I have an appreciation for the idea that beginner programmers should stick to one language when starting out. However, if I were to make a suggestion for that first language, I would suggest C. While challenging to learn, its connections to other languages and diverse applications can make powerful programmers.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Code, Run, Break, Repeat.

Upon reading the first line of “Breakable Toys”, I knew I was in for a pattern that I could connect to. Often, my behavior can be related to a “bull in a china shop”; while not outwardly malicious, my clumsy nature with unfamiliar material can often lead to mishaps and damages.

This is where the breakable toys come into play. According to “Apprenticeship Patterns”, journey-programmers can benefit from making similar programs to the ones that they work with in their profession. These “dummy programs” can then be played with to one’s content, allowing for all sorts of experimentation without worries of destroying the actual project.

To me, I found it useful that the pattern recommends “creating a familiar game like tic-tac-toe in many different languages”. It reminds me of my earlier projects where, as stated in a previous blog, I would practice new languages with familiar tactics. I find it to be a valuable way of connecting “Breakable Toys” to other patterns (such as “Your First Language”).

Most importantly, I believe that “Breakable Toys” is one of the most instrumental patterns to my professional future. Science is not a field involving constant “correct-ness”; science instead does quite the opposite, and computer science is a subset of the broad field. With breakable toys, we are constantly trying to find wrong answers, to push boundaries and discover what can and cannot be done with languages, data structures, APIs and the like.

Perhaps I need to read the section again to fully understand it, but I am at a bit of a loss for the example action being “to create a wiki”. As stated above, I think that better examples for breakable toys would involve familiar projects/programs in new languages, or using different algorithms/data structures. The wiki can be a good start as a “portfolio” to hold all these projects, but on its own I don’t feel as though a wiki is allowing much time out of the comfort zone.

Personally, I feel as though “breakable toys” is an easy concept to understand, but is also a bit more difficult to apply in practice. As I question the pattern’s “classic examples” (like the Wiki), I push forward as the pattern implies as its intention. However, as I leave this comfort zone, I wonder if I stray too far, over my head of expertise (even for a “failure-safe” experience)…

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.