Learn How You Fail

The pattern that from Apprenticeship Pattern that I read for this week is “Learn How You Fail”. The chapter mainly talks about how to identify our own problem during the development process and seek to fix it in order to get better.

I really like what the author said within the context. Failure is inevitable and people who has never failed would either stay in their comfort zone and avoid going over the boundaries, or they have overlooked and ignore their mistake all along. This holds true to me since I have done multiple personal projects that requires me to constantly make mistake and discover what is needed to be done for even a single line of code to work. It is pretty obvious that errors will push ourselves to find out what works and what does not, give us a space to fully explore the capacity of the technology so that we will not make a same mistake later on. Moving on to the problem, he states that the learning skills may bring us success, but there are weakness and failures still remains. I agree with this and I think he did it brief but covered all the aspect of this chapter. The author then gives us the solution, which is as simple as to always seek the errors or failures and resolve what is worth fixing, and more importantly, we have to accept that there will be a lot of things that we are not good at. The solution itself is pretty much self-explanatory and I agree that there’s no better way to improve it without starting to identify the problems and spend time and effort to fix it.

Another way to solve this problem is to is to always arm ourselves with knowledge to make better decisions when carrying out working and identify our own boundaries and limitation to push it when we need to. These changes and improvement can also enable us to have a realistic limitation on our goal. That limitation is what we need to be mindful about as we cannot know everything, and that limitation will greatly help us in filtering out which one is distraction, which on we should spend more resources on to excel at what we are trying to accomplish. I like the example that he put out, which is making time for PhD courses, or simply give up what we know as it requires maintenance to be fortified and maybe to make room for what we need at the moment. I both experience a similar form of these two examples since I had to dedicated time and resources to be able to just learn a new language or a piece of technology.

Personally, I like the chapter because of its simplicity and how it encourages people to not afraid to push their boundaries, while at the same time, accept that we can never know everything, and we have to prioritize one over the other. Like I mentioned, I had experience what this pattern is saying in the past, and I believe that this can be extremely useful for a lot of people, especially the one who has quite some decent knowledge about an area to encourage them to learn something not quite similar to what they have been using.


Popular posts from this blog

Software Quality Assurance Introduction

Reflect as you work

Static testing and Dynamic testing