When you have read deep enough into “Apprenticeship Patterns” as much as I have, you start to notice a key feature of the book: many of the practices found within it are pre-requisites or co-requisites to other practices. Similar to a tech-tree structure found in a video game, proper software programming practices go hand-in-hand – this allows one to become proficient in many skills at once.

As usual, I have found that “Reading Constantly” is actually a practice that I already engage in. However, in contrast to the book, my level of “daily reading” is much smaller; I read for about 5-10 minutes each day, and it may not necessarily be related to the programming practices I need to study on. However, the book does state that reading during down time (even standing in line) is beneficial – perhaps, in an attempt to disagree, I was corrected by my own reading. This reinforces the idea: read, read, read!

I agree with Apprenticeship Patterns, and must also state that you should have a “queue” of books lined up; as you finish one, immediately start another. Tying in with “Practice, Practice, Practice”, constantly reading will keep you well-informed and up-to-date on problems that are relevant in today’s programming era.

When it comes to professional applications, “Reading Constantly” does not simply involve reading to obtain more knowledge. It also consists of:

• Reading to acquire new connections within the academic community
• Reading to apply skills from previous experiences
• Reading to non-verbally communicate the idea that we are willing to improve ourselves

So, by taking some time to read every day, I am essentially performing both a “working” and “recreational” activity. I am able to boost my workplace performance in an enjoyable manner. Similar to the ideas found in the coding dojo, reading should come at ease, with information effortlessly flowing in like a gentle stream. Forcing yourself to learn new information is both un-enjoyable and ineffective.

Overall, I think that everyone and anyone who is considering an advancement in their career to read constantly. In a way, it makes us similar to our machines – we take in new input, compute it within our brains, and create solutions as output for our audiences. It’s a beautiful cycle, and it all starts with a good book.

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: 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.

“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.

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.

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.

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.

I think it’s a fair statement to say that anyone who has ever seen me fail, knows that I have often failed spectacularly. Failures of mine come with embarrassment, enigmatic errors and explosions as far as the eye can see. Long story short: I’m no stranger to shame.

Due to my experience with failure (and my tolerance towards the ensuing embarrassment), I often fail without thought or fear. This is an essential personality for learning exactly how I fail, and how to improve upon this type of failure. Reading Apprenticeship Patterns’ reflection on the topic has also helped me come to terms with “failure analysis”.

According to the book, everyone has experienced failure at some point; people that haven’t either never left their comfort zone, or are denying a past failure. It also dabbles on selecting which failures are worth improving upon to salvage sub-par skills. Finally, it admits that some skills may have to be left to rot, as an example of embracing our non-perfect nature.

I agree with the idea that no one is perfect; extending on the topic, I also agree that “ditching” some forms of failure are necessary to becoming a specialized worker. As the old saying goes: “a jack of all trades is a master of none”; I admit myself that trying to work on various topics only results in a mess of files, each one being less impressive than a single, focused file of well-written software.

However, I run into conflict with the pattern early on: its solution mentions “working on problems that are worth fixing”. In my opinion, as contrary as it may be to my above statements, ALL problems are worth fixing. The priority should be chronological, not a binary form of “assert/ignore”. Yes, figuring out our failures and becoming specialized is great, but even a specialist should be somewhat familiar with as much material as possible. A good team member benefits from a great crew, but can also proceed on their own (even if the progress slows down).

Going forward, I plan on using this pattern in my Capstone adventures (as well as my professional career) by trying to figure out what my specialty is. Which failures are the most extravagant? Which ones are fixable? Which ones are worth the effort despite the challenge? A big problem about my stance in computer science is that my stance is too vague (this was the original reason why I declared this major).

Hopefully, I will be able to cut down on this “vagueness”; despite computer programming being applicable in many fields, I will find the one that I am meant to work in. By finding my failures, the search will increment ever more closely to a successful result.

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.