Skip to main content

Apprenticeship Pattern “Learn How You Fail”

For the final pattern that I will be writing about for this capstone, I wanted to write about something that I’ve felt for a while, but I did not know if my intuition was correct. I picked this one because of this line, “someone who has never failed at anything has either avoided pushing at the boundaries of their abilities or has learned to overlook their own mistakes.”

I feel that I have faced setback after setback in my life. I like to believe that it helps make me into a better, stronger, and more resilient person. When I struggle to learn something, I find that I understand it more thoroughly than if it came easy. It will also be much less likely to forget.

The struggle is something to be embraced. It should not be a reason to give up. On the contrary, it should be a sign you’re going in the right direction. It’s like a video game where you’re not progressing in the level if there’s no bad guys in the way.

I thought the “action” piece that the authors suggest is an apt one. The long and short of it is that to practice, you should use a text editor instead of an IDE to write an implementation of an IDE in one sitting. Since there is no IDE, it might catch the errors that you would have otherwise overlooked. I have not started studying for my Unix final, and this might be something I might try. However, I think we’re mostly doing things with shell scripts and the like, which is somewhat like a text editor anyway.

I think this pattern goes well what I wrote about in my retrospective just now. For as much as I enjoyed working with my scrum team, we were not perfect. Reflecting on how we fell short will ensure that the next team I work with will be even better.

I find I perform best in the areas that I have reflected the most. A part of it feels like neurotics, but it is important to do it. I reflect on most areas of my life, whether or not I am graded or paid. I feel that it is an important step to self-betterment on the way to self-fulfillment and mastery.

Comments

Popular posts from this blog

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect.  They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about.  He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things. He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something in this fi

Apprenticeship Pattern "Nurture Your Passion"

In this week’s post, I will be discussing the apprenticeship pattern “Nurture Your Passion,” as presented by Adewale Oshineye and Dave Hoover. I chose this chapter because I think I have felt like I’ve been just getting by for a while now. The  problem it identifies as, “You work in an environment that stifles your passion for the craft.” I don’t think that’s quite fair to my school or professors. I think that in any discipline, if someone is only studying for the tests or working on the assigned projects and calling it a day when they have passed them in, they are not truly adopting the apprenticeship mindset. Without a constant push forward, I will stagnate. I may get an “A” on the exam or project, but if I forget the material the next day, there is no point. The pattern suggests finding something that sparks interest and pouring myself into it. I have been wanting to do this for a while, but I have made excuse after excuse of not having enough time. The next sentence in th

A Review of Software Engineering Radio’s Conversation with eBay’s Randy Schoup (ep. 109)

I was interested in what someone from such a large website, eBay, would have to say about its architecture. There was a lot of takeaways from it, summarized in four main ideas: partition everything, use asynchrony everywhere, automate everything, and design the system keeping in mind that everything fails at some pint in a large distributed system. Although this is an older talk (from 2007), these all seem to be sound systems to design something so large. He referenced a theorem from 1998 that he said took a while to get traction. Likewise, I am sure his design principles have proven true for the last ten years. To be completely honest, there was a lot of industry-specific jargon used that went above my head. I took a lot of notes though, and looked up the terms I did not know. I still found it very interesting, though. I found it the most interesting that someone designing one of the largest websites in the world was incredibility realistic of the shortcomings of everything designed