The ideas discussed in this pattern are often ignored by a lot of people including me. Documenting what you learn will not only serve as a further reference but will also save you a lot of time refreshing your mind on topics that you might have lost ideas. In the other hand, you may still remember what you have learned on a problem but the issue is that you have got only the main ideas, forgotten the details in it.

I got to realized how ignorance I am about recording what I learn after reading this pattern. I think I have never learn why I fails sometimes because on my reflection, I realized that in most cases, I overlook  some of the things I learn as a real event and therefore don’t  think I will ever forget them. But in the long round I lose track of most things as time goes on. On reflecting on why I sometimes don’t document what I learn, I couldn’t find a particular reason for that.  Gone on the days when there was limited storage in our computers, and in the worst case, no internet access, we could record what we learn on note books. The only problem I had with that was, as time passes, you turn to have more books and you overlook their important. Sometimes you are tempted to trash your entire old document thinking you have enough knowledge that can deal with issues coming from these documents. But I realized this is not true because not long ago, I have encountered a situation where I have to go all the way back to my high school note book for the solution.

After reading this pattern, I think I will not ignore the power of recording what I learn anymore.  With internet access, recording is going to be more convenient and effective. For some time now, I have been saving what I learn in goggle docs but after reading this pattern I have taken another twist to blog all my learning. I think this can help me easily managed and share what I learn with others.

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

This week, I will be writing a reflection on the “Practice, Practice, Practice” pattern.  This pattern addresses developers who want to get better at programming and to expand your diversity of concrete skills.  I chose to reflect on this pattern because I recently accepted an offer for a summer internship and I intend to put in quite a bit of practice before I begin working in June.   Oshineye and Hoover provide solid advice on how to exercise programming skills for those in the ideal situation of having a mentor and those who are left to their own devices.

They begin by saying “Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes”.  I think environment is a very important element in getting the most out of practice.  The environment in which you practice should allow you to focus completely on the skill you are trying to improve.  Ideally, this environment would also include a mentor that can help guide your practicing and gauge your progress.  Personally, I think an ideal environment could also include peers who are also developing their programming skills because it would provide more outlets for each individual to discuss their work and mentor one another.

They go on to say that the key to this pattern is finding time to develop software in a stress-free environment with no due dates production issues, or interruptions.  This pattern, like the “Breakable Toys” pattern, also stresses the importance of short feedback loops in practice sessions.  Short feedback loops refer to the cycle of completing exercises and quickly receiving feedback on your performance for the purpose of gauging a person’s progress toward a goal.  Short feedback loops can be found in the form of feedback from a mentor or in your own incremental completion of progressively more difficult tasks.

To implement this pattern, Oshineye and Hoover advise developers to find exercises or create their own, and ensure that those exercises will challenge them to at least some degree higher than what they know they are capable of.  They also advise that you should solve and resolve the same issue over some period of time, so that you can see how your solutions change and progress.  I have been motivated by this pattern and I intend to implement it in the coming weeks as I prepare for my internship.

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

“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.