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.

PREVIOUSLY ON MPEKIM.CODE…

So far, we have come to the conclusion that it is okay to not know everything. It is also alright to even be “the weakest link” of a team. What matters the most is the enthusiasm, the drive to learn more about our projects and programs. For Apprenticeship Patterns, this means that newcomers can be useful to a team if they provide morale and enthusiasm to expose and attack their ignorance.

To start, I believe that the book stating the idea of “repressing enthusiasm when it is not welcomed” isn’t entirely incorrect. However, I do believe that, unless an enthusiastic apprentice is drastically creating dire consequences for the team, then the members with lower morale should lighten up a bit. No one starts out “creating the next Linux”; if seasoned professionals are not held up to these high expectations, then it seems ridiculous (to say the least) that the newcomers will be held to it.

Interestingly enough, the controversial idea of repressing enthusiasm is supported by a factor of the pattern that I do enjoy: the idea of “experiencing diversity”. According to “Unleash Your Enthusiasm”, teams actually have the most efficiency when they consist of members who each have various amounts of experience. “Old farts” who have seen it all will likely be numbed and unaware of an issue that a newcomer will notice with their “fresh eyes”. Likewise, the more experienced will create sorcery, solving programming problems that the newbies weren’t even aware of.

As far as the future is concerned, I can say that I apply this pattern on a daily basis. While the book helps to reinforce this ideology, I am no stranger to “pumping up a crowd”. Unleashing enthusiasm is not only the idea of providing positivity and workplace morale, but it also involves taking the initiative. Even if they get shot down, we should always put our ideas out there – scribbles, doodles and random notes are never irrelevant. Some of the greatest ideas were the result of an accident (caused by an enthusiastic dreamer).

So far, in the grand scheme of my selected patterns, here is what I see as a “list” or “chain”:

• Find a team that you are the worst on.
• Discover and acknowledge your weak points.
• Take the initiative and enthusiasm to work on these issues.
• Give yourself the breakable toys needed to grow from mistakes.
• Practice correctly, with feedback from professionals.

In retrospect, I find it amazing to take my previous blogs, and discover a path within them (similar to a graph data structure). Now, we must take the time to implement it….

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.

“It is better to be honest about your skills and fail to land a job, than it is to lie and put yourself in a situation that’s over your head.” – Someone, probably.

That quote, while partially meant as a joke, does have some truth behind it. Unfortunately, in this world of ever-increasing job requirements, it seems enticing to claim skills that you don’t actually have. This, however, can lead to an avalanche of constantly falling behind on work, and procrastinating/struggling to keep up with the rest of the team. Tapping into my previous entry (“Being the Worst”), we can see that is better to be honest about ignorance than to “shove it under the rug”, as one would say.

“Apprenticeship Patterns” essentially states that for this pattern, we must face a very difficult aspect of our lives – admitting that we are not the best at everything, and that we need to ask for help. Similar to “Being the Worst”, I find this philosophy to be familiar, but fascinating nonetheless. While it took me more time to confront my ignorance than to challenge my skills, I understand that both of these processes will make me a better programmer (and a better person) in the long run.

The most useful aspect of this pattern is the idea that, regardless of what we do with our lives (from scientific advancements like coding software to artistic talents such as playing guitar), it is more important to learn how to learn, than to “learn towards a goal”. To phrase this with better clarity – if we can understand the most effective way to learn, it will make our challenges much easier to overcome than trying to simply take on the challenge directly.

While I don’t think that this pattern has changed my thoughts about professional programming, I do believe that it has emphasized the importance of brainstorming, “thinking outside the box”, and other important factors of discovering unknown material. Most importantly, exposing ignorance shows that, as programmers, we know that we don’t have the solution that our client desires (yet), but we are also searching for it.

Maybe it’s because I’m no stranger to shame, but I must say that I disagree with the idea that there is “tremendous pressure to satisfy clients, regardless of one’s actual competence”. For me, the best way to satisfy clients (and pacify my own anxiety) is to select the most reasonable long-term solution – in this case, admitting my ignorance. “Dodging the bullet” during the sprint planning might provide short-term anxiety relief, but the problems avoided remain unchecked, building up far more anxiety in the long-term.

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.

It seems as though across several different environments, people have come to an agreement that “being at the bottom” actually isn’t as bad as one may make it seem. Rap music often makes references to “starting at the bottom” and “creating a grind for the paper”; Harvard University, despite its reputation for requiring high GPA scores, has an urban legend of “failing new students on their first semester”. Whether or not these previous statements are framed in facts or anecdotal assumptions, the idea remains that we as a society understand that “there is always room for improvement” – every day that you don’t make yourself stronger, you make yourself weaker.

This brings me to my first pattern of self-assessment from the Apprenticeship Patterns book: “Be the Worst”. In a sentence, the pattern explains that if we have nothing/no one to challenge us, then our knowledge level plateaus or even weakens; it is always a good idea to surround yourself with people that are better than you. This gives you the ability to learn from them and become an even greater programmer.

To be honest, I am glad that I started with this pattern. While I cannot say that it’s interesting per se (since I have always had this philosophy in mind), I can say that it is useful. I get where the book is coming from, and I would like to always be the “weakest link” as it ensures that I am in good, professional company.

As I stated before, the pattern has not really changed my way of thinking, since I have already held this idea of “being the worst” near and dear to me. However, I must say that it is nice to see a professional textbook reinforcing my beliefs – while it goes against the philosophy, being correct before a confirmation is a good dopamine rush. I also cannot say that there is much to disagree with, since the pattern hits every nail on the head:

• Join a team in which “you are the worst”.
• Work harder than the rest of the team; don’t “be a passenger” or have people carry you.
• Provide as much help as possible, even if these tasks seem “menial”.

Could this pattern be an excuse for my procrastination at the start of this semester? Maybe – I think the “early start” didn’t help either (and some burnout from constantly taking classes to boot). However, in the end, I am glad that I have a great team to work with, and a bit of “set back” in order to keep myself on my toes for these upcoming classes. If this setback is my “rock bottom”, then I can only imagine how great it will be at the summit.

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.