The ‘confront your ignorance’ apprenticeship pattern talks about what to do when you have discovered a gap in your skillset that you need to fill for your daily work. Though you have identified this shortcoming, you aren’t sure how to begin overcoming it. Hoover and Oshineye recommend selecting a single skill, tool, or technique and working actively on your understanding of it. This can be done in any number of ways, such as by reading introductory articles or constructing breakable toys. You should choose a learning method that works for you. Once you are satisfied that your knowledge has been sufficiently filled in, you can decide to either continue pursuing this topic or move on to another gap in your knowledge. This pattern should be used in tandem with the ‘expose your ignorance’ apprenticeship pattern. Confronting your ignorance in public as well as private encourages an environment that is more tolerant of failure. Focusing too much on developing your skills in private may pull you away from your actual work, and it may become an issue for your team. On the other hand, focusing too much on the ‘expose your ignorance’ apprenticeship pattern may become obnoxious to your team members and prevent you from doing anything meaningful about your lack of knowledge. At the risk of coming off as either arrogant and unwilling to work or passive and unwilling to learn, you must strike a balance between these two patterns.

I think this apprenticeship pattern is really interesting. I have always found it useful to study topics that I feel I am weak in private; it’s nice to be able to focus on learning in a space I don’t need to worry about how that lack of knowledge makes me look. Learning in private can only get you so far, however. It is important to also communicate with people with more experience and who can help you better understand the topic you are pursuing. I think as Hoover and Oshineye suggest, this pattern would be especially useful when employed alongside the ‘expose your ignorance’ apprenticeship pattern. I do agree that these should be used within a reasonable amount. There is no point in expanding upon a skill if it is going to ruin your daily work.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The ‘expose your ignorance’ apprenticeship pattern addresses the issue of you not being completely comfortable with the technologies your work requires you to work with. Your impulse may be to lie to a customer in favor of appearing competent, but you should curb this impulse. Instead, you should be honest and open about your knowledge or lack thereof and focus on your ability to learn. Asking questions is a good way to let people know that you are both needing and willing to learn. Asking questions of your team may also help your team recontextualize and reunderstand their own knowledge. Your goal should be to expand your knowledge to a variety of topics, especially while you are still new to the profession, rather than focusing on becoming an expert in a handful of technologies. It is important to be able to recognize areas in yourself that could use improvement. It is similarly important to expose those areas and work on learnig from them, rather than hiding them.

I think this apprenticeship pattern has some very useful advice. I think it is great advice to admit your knowledge in an area is lacking and use that as a chance to learn. Hiding your lack of knowledge in an attempt to save face and spare your pride is unwise and will succeed only in stunting your learning process. This is something I try to work into my daily life. I used to be very scared about coming off as incompetent for lacking in a given area, but I find it is much more rewarding to admit that I am weak in an area and use that as an opportunity to expand upon my knowledge.

The only thing I disagree with is the action that Hoover and Oshineye suggest taking. I don’t know if posting a public list of things you don’t understand will help you better yourself, I think it is just going to make you look weird to your coworkers. I think it would be more useful to keep a private list of things to work on, and just keep that list in mind in discussions with others in case the opportunity to develop your knowledge presents itself.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The ‘sustainable motivations’ apprenticeship pattern discusses the realities of beginning a career in software engineering. In the process of developing your skills, you may be stuck working on projects with obscure specifications and fickle clients. This work can be, as Hoover and Oshineye describe, “rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining,” and it may start to wane on your motivations. The trick is to not become wrapped up in your motivations; you should recognize that some days will be harder than others. You should not be driven by a single desire; if you are motivated only by money or a desire to build your reputation, you might burn out and lose that motivation. Your motivation should also come from wanting to master your craft

I thought that this apprenticeship pattern was really interesting. I think it highlights how easy it can be to become disheartened with your work, especially if you are not properly motivated. It can be devastating to invest time and money into a career you wind up losing interest in, and it is helpful to see advice on avoiding this.

I like the suggestion to have multiple motivations for working; obviously, if more factors are motivating you, you are less likely to lose interest in your work. The suggestion to, in addition to your other motivations, be motivated by mastery to avoid stagnating your skillset seems very useful. I also like the advice in this apprenticeship pattern to maintain a good balance between your work and your life. I think a healthy work-life balance is so important; your work should not demand so much of you that you are unable to enjoy other parts of your life.

I don’t agree with the first example discussed in the ‘solution’ section of this apprenticeship pattern. The person in this example hates the programming that their job requires, but they like the money and the reputation. The solution to this example is that they endure the job until it improves. I think this solution sounds absolutely miserable. I realize this is not as realistic a suggestion as it should be, but you should probably switch professions if you hate performing the main task your profession requires.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The ‘reading list’ apprenticeship pattern supposes a solution to a situation where you are finding books you want to read faster than you can get through them. There are lots of really good resources available for programming, and reading them is a great way to help you improve your programming skills. However, with such an abundance of resources, it becomes difficult to manage everything you want to read. The solution is, as is suggested by the name of the apprenticeship pattern, to maintain a reading list. This list should store both books you want to read and books you have already read. Hoover and Oshineye recommend storing your reading list somewhere public so that other people can see and learn from your list. Keeping a list like this for several years will allow you to analyze your reading habits and pick out spots where there might be gaps in your knowledge. As you work through your list, you can use the bibliographies of the books you read to add new books to your reading list. This can also help you narrow your research down into an area you take interest in.

I think this apprenticeship pattern is interesting, and I think it’s a great way to keep track of what you want to read. I think the advice to read books included in the bibliographies of books you thought were useful is really useful. I also really like the idea of being able to monitor your progress as you work through your reading list. I already kind of do this, just not exclusively with programming resources. I use a website to keep track of the books I want to read and the books I’ve already read. I like being able to see all of the books I have or want to read, because I know if I didn’t store that information somewhere I would forget all about it. It’s also really interesting to be able to analyze my own reading statistics like what genres I tend to read and what days I read more. I use it mostly for pleasure reading, but I think it would be useful to dedicate a section of my existing list to programming resources.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The ‘dig deeper’ apprenticeship pattern imagines a scenario where you have familiarized yourself with a number of tools but only enough to be able to implement them into your own system. You do not take the time to properly engage with these tools, and you only ever learn enough about a tool to get through your own individual work. This superficial understanding of your tools can lead to issues, and you may have trouble recognizing and solving bugs that arises because of a given tool. The solution is to take the time to acquire a more in-depth understanding of these tools and technologies. This will give you a good foundation to build off as you learn other tools and will give you a more holistic understanding of the systems you work on. You should learn enough about the tools you used to be able to solve any issues, but you should not completely devote yourself to becoming a specialist in those tools.

I think this apprenticeship pattern is interesting. I am interested specifically in the Hoover and Oshineye recommendation to become familiar with debuggers that show you your running program, become familiar with wire-level debuggers, and be willing to read specifications. I knew that different types of debuggers exist, but I was never sure in what situations you would use them. I should follow this advice and do some in-depth research on at least the debuggers they mention. I also thought it was interesting that they recommend reading through specifications for tools; I do try to do this whenever I am introduced to a new tool.

I am definitely guilty of only learning a tool enough to use it in my own project, but I want to get better about understanding the tools I use. I think the advice in this apprenticeship pattern is very useful in this way, particularly the advice to obtain information about your tools from primary sources. I think being able to read through, parse, and fully understand specifications and defining theses would be beneficial to my career. I would feel a lot more confident working on a system with tools that I can comprehend the workings of. I think this is a good way to develop my skills and prepare for my future career.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The craft over art apprenticeship pattern becomes relevant when you are hired to build a solution to a client’s problem. Building this would give you the oppurtunity to try something new, however a standard and stable solution already exists and is readily available. Hoover and Oshineye suggest focusing delivering to the client what they need rather than indulging an interest. It is better to build something functional for a customer over something beautiful, and you should work to balance the desire to create something artistic with the need to create something useful.

I think this apprenticeship pattern is interesting. I think, especially in a professional environment, your priority should be to create something your customer can easily use over something cool. It this pattern could be really useful if used in tandem with the breakable toys pattern I wrote about previously. I don’t think it’s bad to want to do cool and artistic things with your projects. Building something you think is beautiful sounds like a really good way to expiriment and develope your skills. However, if that interest interferes with your ability to deliver functional products to your customer, it may be wise to indulge that interest outside of work.

Reading through this design pattern has helped shape my expectations for my future profession. It highlights for me how focused the industry is on utility. I was not expecting to be able to use work projects as expressions of creativity, and this has confirmed that. I know to keep my personal and professional endeavors separate.

I do disagree a little with the way Hoover and Oshineye discuss creating beautiful works. In sections of this chapter, they talk about wanting artistry in your craft as if it is a bad thing. I agree that you should be able to recognize when it is appropriate to invest time in making a customer’s product beautiful, but I don’t think that urge should be shut down completely. That energy could easily be channeled into a personal project; you shouldn’t stop trying to use your skills to make beautiful things just because it might not benefit your employer.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The breakable toys design pattern proposes a solution to working in an environment that does not welcome failure. Since failure is such a huge part of the learning process, it is important to create a private space outside of work where failure will not damage anything. Hoover and Oshineye recomend building a simple system that is relevant to your work and easy to build upon. For example, you could build your own wiki and use it to learn HTTP, databases, and web design. You should enjoy the thing you are building so that you are motivated to keep building and breaking it.

I think this design pattern is really interesting. I can see how it would be useful to have a private project to mess around with and not have to worry about breaking it. This seems like a very good way to build up your confidence in an area while also being able to experiment with new skillsets. I also think it is useful to build a project you are personally interested in. If you are interested in the project you are using to learn, you are more likely to keep experimenting with it.

I probably will wind up adopting this design pattern once I enter my professional career. I like the idea of having a private project to experiment with; it would be nice to have the chance to get more comfortable with concepts I’m less familiar with in an environment where failure has few consequences. I am specifically interested in the example the book mentions of creating breakable games. Especially if it’s a project I’m interested in and enjoy working on, I think it would be easy to keep myself interested in working on it.

I do disagree with this being the solution to a work environment that doesn’t allow for failure. I think any work environment should be able to tolerate failure; if your work expects you to succeed all the time, you should not be working there. Rather than taking on extra work in an effort to avoid failure, you should find a healthier work environment.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.