Confront Your Ignorance

For this week, now that I have read through “Expose Your Ignorance” in the Apprenticeship Patterns, I continue on to read through “Confront Your Ignorance”, as they seem to go hand in hand with each other. To sum up this chapter, it mostly talks about the advantages and disadvantages when taking action to fill up our knowledge once we identified the gap.

The problem posted for this chapter is that while we have a lot of tools and techniques available out there that we can get our hands on, a lot of developers like us do not know where to start and a lot of common things that people know, we are expected to have those knowledge when we start working. I feel like this is the exact current state of a lot of new people who just got into the field and this chapter seems to be important to know about when we get started. The solution that the author presented, which is picking one skill, tool, or technique to actively learn about it, caught me off guard as I would never imagine it to be a simple answer. It is true that we have a start somewhere and using those as foundations to learn others. He then moves on to explain that to do whichever ways work best for us like reading articles and FAQs or constructing Breakable Toys and ask around for people who knows better or simply just people who are looking to acquire the same skill. The best part of this pattern is when he stated that we don’t have enough hours to get all the skill we need, and making trade-offs is necessary in order to get better. This is what I always think about whenever I get into learning something new because I might potentially forget part of what I know now and there will be more and more to learn once I get used to new skills. The author begins to explain that confronting the ignorance can be done in private, but then it would promote the bad habit of being failure or openly learning something in a work environment is unacceptable. And worse side effects that can be found by applying this pattern would be to let our personal gain for knowledge affect the team and we should keep in mind to separate them when we do.

I do agree with every point that the author put out on this pattern as I am sure that it will prove to be helpful when I am required to learn something new. With such simple solutions and tips, I think this chapter is pretty straight forward telling us to keep on practicing ourselves outside of work time, which still keeping up with the team progress so that we can become better without stubble upon failing what we are supposed to do and I think it is useful for new developers to know.