“Reading List” is the first in a set of design patterns written to help the apprentice craft a learning curriculum.  As more and more material becomes available, it’s important to carefully select a set of materials that can effectively guide oneself.

This particular pattern is focused on managing material, not necessarily curating it (although it does recommend asking mentors for suggestions).  The recommendation here is to create a list of reading material, and maintain it in a way that lets you see what you have read as well as what you have yet to read.  This allows you to fill in gaps as you go, even if the original list was not particularly comprehensive.  The basic form of the pattern is to keep a text file as a reading list.  In more complex implementations, you can use a version control system to track changes, or use a public form (like a wiki) so that others can benefit.

I am not sure how helpful this pattern will be to me.  While I do understand the need for continued education, and I do enjoy reading, I’ve found that I learn far better from practical, hands-on experience than books, blogs, or powerpoint slides.  While I definitely got a lot out of Clean Code, I got more out of taking Uncle Bob’s suggestions and putting them into practice.  I also tend not to take well to to-do lists, either making or sticking to them — although, perhaps, this pattern would give me an opportunity to expand my horizons in personal organization as well as software craft.

My implementation of this pattern might be a bit more complex than the simple suggestion of keeping a version-controlled text file.  I would prefer to curate a list of resources that contain practical, hands-on components (like Apprenticeship Patterns, although many of those are fairly abstract), or to learn from tutorials that give me room to experiment.

You could even apply this pattern to parts of a book (like Apprenticeship Patterns) that is more fragmented, or easier to digest across multiple readings.  Perhaps also to a video or article series.

From the blog CS@Worcester – orscsblog by orscsblog and used with permission of the author. All other rights reserved by the author.

In this Apprenticeship Pattern “Draw Your Own Map”, it explains the importance about creating and managing your career path once you are exposed in the software development environment. A couple of key points that the pattern states are:

1. Your manager, professors, or colleagues are not in charge of where you position your career as a software developer.
2. Your are responsible for your destination and goals.

These couple of points emphasizes the concept of a software developer’s individuality. It is true that within the software development field, everyone is a programmer and creates many different types of software. It is up to you as an individual to take steps towards what you aspire to do and become within this field of development. One quote that stood out to me was this one below that talks about your vision of goals versus the employer’s vision for you.

“If you find that your vision of yourself is not in accord with your employer’s vision for you, and there doesn’t seem to be a way to reconcile the differences, examine other opportunities to see if they’re heading in the desired direction. Remember, there isn’t one single path that all apprentices follow. Instead, successful apprentices follow paths that share a certain family resemblance. These resemblances do not happen because apprentices are inexorably shepherded into making the same decisions by their mentors. They happen because each apprentice, consciously or not, chooses their route through life based on an overlapping set of values.”

I agree with this idea because it seems like it will be the most realistic to me once I start working for a company that may not have the same vision for my career as I do. This idea also will allow me to change the way on how I would manage my goals and career paths while working in the field. I will continuously plan and weigh options that would be available to me out there in the software development field since there are many companies and employers to work for. It goes back to the concept of leaving your current job for a better one because it does not meet your intended needs or it doesn’t help you grow in the field. For me, I’d like to work for a place that respects my needs and aspirations. As a future video game developer, I want to have that luxury of being able to grow into a successful video game developer and there would be nothing more  important than that.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern is the flip side of last weeks pattern, expose your ignorance. Now you have to confront the ignorance that you exposed to your team mates and coworkers . You start simply by choosing one thing you do not understand fully, and then researching and working on it until you fill in the gaps in your knowledge about that tool or framework or some such. You work on fixing your ignorance on your own time, until a point where you decide to continue working on it or move to something else you are ignorant in.

This is a very necessary pattern for an apprentice, especially paired with the previous pattern of exposing your ignorance. They both need to go hand in hand for an apprentice to advance themselves as a craftsman. What happens if one uses one pattern but not the other?

If someone uses the expose your ignorance pattern without confronting their ignorance, then they do nothing but stay ignorant. Whenever you are tasked with doing something you are ignorant of, you simply state your ignorance and then… that is it. You just shrug and say that you ca not do it. Without ever learning about things you do not know, you can never advance as a craftsman.

However, while confronting your ignorance does lead to learning and advance in oneself as a craftsman, doing only that without exposing the ignorance in the first place can be problematic. If apprentices only ever learn in their own time without letting anyone know that they were ignorant in the first place, everyone would silently work on their own problems without ever asking for help. There would be no discussion of issues, or allowing others to help you get through something you are having a large amount of trouble with. The reason one exposes their ignorance is to gain help from those on the team more experienced than them.

This pattern made a lot of sense to me. The part of the pattern section that discussed what confronting your ignorance without exposing it is was like was familiar to me. In the past I had moments where I would try to work on a project on my own for a long period of time, and bash my head against a wall until I figured it out. Then realizing I could have just asked someone else for help and reduce my frustrations by an enormous amount. Nowadays I was always strive to get past my pride and ask for help, to avoid a lot of headache and to help myself learn more effectively.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

This week, I will be writing a reflection on the “Dig Deeper” pattern.  This pattern addresses developers who feel that feel that they only possess a superficial knowledge of some of the technologies, tools, and techniques utilized at their workplace.  The problem that arises, in this scenario, is that the developer begins having trouble with maintenance of his or her code because it was written with only superficial knowledge that is likely to be forgotten.  I chose to reflect on this pattern because I really like the advise that Oshineye and Hoover provide about how to truly immerse yourself into the learning process and transform your superficial knowledge to deep knowledge.  I also agree that having a deeper understanding of the everyday things in your life can be incredibly beneficial in a number of ways.

The primary importance of deep knowledge is that allows you to explain the inner workings of systems you work on, which will distinguish you from colleagues that are unable to do so and show others that you are more proficient in working with that system.  I recently had an interview for an internship and many of the questions I was asked were related to my contribution to and understanding of past projects.  The recruiter got back to me a short time after the interview and informed me that I ‘knocked the interview out of the park’ and I was offered the position – I accepted!  Oshineye and Hoover explain that deep knowledge can also act as a safety net in that you can refer back to how you gained your deep understanding in that area to gain confidence about learning something new.

They recommend that developers ‘dig deep’ into the tools and technologies involved in the project they’re working on, until they have a deep understanding of how those tools and technologies work and why they are being used.  One of the ways somebody can dig deep into something is by getting their information from primary sources.  Primary sources understand the problems they were trying to solve.  Another way somebody can dig deep is by looking at tutorials and guides regarding the thing(s) they want to learn, and asking themselves if there are underlying computer science concepts behind what you they are learning.

I think this pattern will prove to be a useful piece of knowledge in my repertoire.  I will try to apply it regularly in my career and I strive to become a person who truly understands the tools and technology utilized in the software I am working on.  I have used this pattern and seen it work, first hand, and I hope it will lead me to more success in the future.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

This pattern also captured a very important issue that is often ignored. As a newcomer, you need someone to guide and coach you to get grounds in the field. We sometime failed to understand that only what is learned in class can’t take us to the field. The outside world has its own convention of doing things and a newcomer need somebody who is already in the field with experience to guide him. There are so many benefits for having a mentor. Working alone is the hardest thing you could face in the outside world and having someone as a mentor walking with you side by side or sitting with you face to face could save you a whole lot of time spent trying to figure out how to dealt with certain problems. Even though it sound very simple to say find a mentor, it is usually challenging to get someone who is willing to accept you as an apprentice.  Even though the writer talks about the field being young and which we can’t tell who is a master craftsman, I don’ think that is a problem. Because, no matter the situation is, those who are already in the field will have some experience that a newcomer doesn’t have. The issue here is everybody readiness to share what have been learned. Most people don’t want to share their knowledge with others because they feared their jobs would be taken from them. They also forget the fact that when you teach other of what you know, it helps you remember it all the time. In fact, it sticks in your mind forever. With regards to this problem, if you are fortunate to have many people mentor you, you will definitely gain enough knowledge to keep you going in the field. Another thing that every apprentice needs to know is that nobody knows everything and though the master has more experience than he has, they might both be learning certain things together. Regardless of whatever challenges I might face in the industry, with this whole ideas in my mind, I think I can survive in the industry.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.