Summary:

This pattern arises when a programmer is aloof by deeper concepts of a topic, even based on one that he may know, such as a programming language. One of the best ways to solve this issue is digging deep by reading books constantly. Books can offer a huge amount of information about one or more topics, and should be prioritized over blogs as a main source of knowledge.

Branching from the “Unleashed Your Enthusiasm” pattern, this pattern is one of the most important I’ve come across. Even if you are enthusiastic about learning, or are proficient in a skill and or a programming language, the ability to sit down and read to grow your knowledge is what I believe to be the most important skill and behavior. Even someone that is not enthusiastic, or does not know a language, or does not know a tool, if he can make himself sit down and read to learn more about a topic, he has far greater potential than he who doesn’t read.

As such, I strongly agree with this pattern. It also is a strong reminder for me to start reading more, and I tend to not read books to learn more. While I strongly agree with this pattern, I also want to add a note that does not run contradictory to it. Sometimes not reading and getting familiar with something is also beneficial. Reading is extremely important, but getting an intuitive understanding of a tool, like driving a car, is also an important task that should be done concurrently to reading constantly.

As I’ve mentioned before, I am competent with the C++ programming language, and I’m able to use it confidently without having to constantly look things up online or in a book. However, this pattern has me thinking about what I should start reading. One of the things I understand the least of in C++ are Move Semantics. Move Semantics involve utilizing rvalues and rvalue references to avoid creating unnecessary copies of an instance. An rvalue tends to be an immutable value that tends to be on the right of an assignment operator, such as an equal sign (hence rvalue). How this works aloofs me, and I believe this can be a good starting point for me to begin my habit of reading books since I understand the context of its existence.

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

For this week, I learned a pattern called Learn How You Fail. Through this pattern, the author tells me that everyone is not perfect; and no one can avoid failure. “Failure is inevitable. It happens to everybody sooner or later”, he said. Moreover, the author also suggests to the readers how to deal with their failures or how to reduce the consequences of the next failures. First, you need to identify the reasons which might cause you fail, then instead of wasting your time to feel self-pity about those failures, you should try to resolve it. Gaining self-knowledge about “the patterns, conditions, habits, and behaviors that lead you to failure” is one the most important solutions that can help you become aware of your boundaries and limitations. When your boundaries and limits are found, you should face and accept the fact that you cannot be good at everything. There is still something you are not good at. Your awareness and your accurate self-assessment will allow you to make conscious choices to overcome your failures. There are two options suggested, that is, between working harder to push your boundaries or cutting your losses by accepting your limitations.

In my opinion, this pattern is helpful for all apprentices; because I agree with the author’s opinion that failures happen to everybody sooner or later. That means most of apprentices including myself cannot avoid failures when walking on the long road of the careers. Therefore, exposing with this pattern in advance can help me know what I should do if I fail. I should learn from my failures, learn what causes me fail, learn about where my boundaries or limitations are, learn how to assess myself accurately, learn to accept my imperfection, and eventually learn to make a decision to overcome those failures.

However, if I were asked what my decision would be if I failed, I would choose to put more effort into pushing my boundaries instead of accepting my limitations. It is not because I cannot accept my limitations, but it is because my definition of the word “failure” differs from its standard meaning. According to my own dictionary, failure means that I did not put in enough effort to achieve my goal. However, I believe that as time goes on, at some point, my own dictionary will be updated if there is a situation makes me accept that sometimes effort cannot change the result, then “cutting your losses” is a better choice.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

I decided to write a post about this section because I found very interesting. The author starts off this section with a quote from Christopher Hawkins,

“If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.”

– Christopher Hawkins, “So You Want To Be a Software Consultant”

This quote made recall an experience I had during my freshman year of college. I was meeting with my advisor in her office, talking about how I was having difficulties learning the content in one of my classes. I was debating whether to retake that class in the following semester because I thought if I retook the class a second time, I would understand it better. My advisor advised me not to and gave me this piece of advice, even if I don’t understand everything in this class right now completely, this was fine. As I took more upper-level courses, I will gain new insight and start to understand the material in previous classes a lot better and may even learn to see it in a different light. At the time, I found that piece to be very strange because I had always thought if a course is prerequisite, you need to understand in the previous course to understand the material in the next class. Now I see in later classes, you apply the information that you learn in a previous class and by doing so, can understand the ins and outs about that topic and gain a better understanding of the topic.  

In this section, the author talks about the dangers of taking it easy and taking on only tasks that you know you can complete. He also talks about how by doing so, you will not grow because their skills will not improve and as a result, they won’t become confident in their work. Whilst it is true the author wants us to step outside of our comfort zone, he also talks about how important it is to be smart while doing it. In the short story given in the book, Enrique who was challenging himself by taking a job in Nigeria, did not blindly take a leap. Before he even made the move, he connected with people who knew were already working there and so he got himself a mentor that helped ease the transition.

I agree with the points that the author brought up. One additional point that I want to add would be the author does not say it is important to make large leaps or take on a challenging problem without a mentor, it is just easy when there is someone there to guide you.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

When you have read deep enough into “Apprenticeship Patterns” as much as I have, you start to notice a key feature of the book: many of the practices found within it are pre-requisites or co-requisites to other practices. Similar to a tech-tree structure found in a video game, proper software programming practices go hand-in-hand – this allows one to become proficient in many skills at once.

As usual, I have found that “Reading Constantly” is actually a practice that I already engage in. However, in contrast to the book, my level of “daily reading” is much smaller; I read for about 5-10 minutes each day, and it may not necessarily be related to the programming practices I need to study on. However, the book does state that reading during down time (even standing in line) is beneficial – perhaps, in an attempt to disagree, I was corrected by my own reading. This reinforces the idea: read, read, read!

I agree with Apprenticeship Patterns, and must also state that you should have a “queue” of books lined up; as you finish one, immediately start another. Tying in with “Practice, Practice, Practice”, constantly reading will keep you well-informed and up-to-date on problems that are relevant in today’s programming era.

When it comes to professional applications, “Reading Constantly” does not simply involve reading to obtain more knowledge. It also consists of:

• Reading to acquire new connections within the academic community
• Reading to apply skills from previous experiences
• Reading to non-verbally communicate the idea that we are willing to improve ourselves

So, by taking some time to read every day, I am essentially performing both a “working” and “recreational” activity. I am able to boost my workplace performance in an enjoyable manner. Similar to the ideas found in the coding dojo, reading should come at ease, with information effortlessly flowing in like a gentle stream. Forcing yourself to learn new information is both un-enjoyable and ineffective.

Overall, I think that everyone and anyone who is considering an advancement in their career to read constantly. In a way, it makes us similar to our machines – we take in new input, compute it within our brains, and create solutions as output for our audiences. It’s a beautiful cycle, and it all starts with a good book.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Reflect As You Work is a pattern which requires retrospection. When working it is important to actually gain experience and not just go through the motions. Quoted from the pattern, “The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways” is an excellent quote which I think encapsulates the entire idea of the patten. As apprentices we want to learn as much as possible since not doing so will start us on a road to complacency.

One thing that I will implement into my work is the idea of Personal Practices Maps. This seems like a very useful tool which will aid in retrospection. Right now I know my strengths, but I do not know my weaknesses. Using the Personal Practices Map will allow me to observe trends in what I do and help with my retrospection.

Another thing that I enjoyed about Reflect As You Work was that it mentioned how good experience directly leads to career opportunities. When Dave learned about a new pair programming technique it directly lead to him writing an column for StickyMinds.com. While I don’t expect to be writing any columns, I do hope that the skills I gain will lead to other employment opportunities in the future.

Reflecting as I work will help with Drawing My Own Map. While navigating the map I should be acquiring new skills which will shape the future of the map, which will lead to even more skills. Over time these skills will drastically improve my marketability, which will have a much greater impact on my map as opposed to earning a lot of experience at a single company.

Reflect As You Work is a good pattern which, while not flashy, is very important to remember throughout the entire apprenticeship. As an apprentice, the goal is to learn. It is important to always learn from your experiences and grow as a developer; if not you will become stagnant. My goal after reading this pattern is to begin reflecting on my work and actively try to improve myself, because if I don’t no one else will.

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

Draw Your Own Map is all about defining your career path and how it aligns with your values as a programmer. When working at any job it is always important to keep in mind your goals and aspirations; don’t let a company’s goals supersede your own. Sometimes it may be tempting to stay with a company that doesn’t fit your map since they offer promotions and raises, but it will benefit you in the long run to find a more suitable job.

I think this is a fantastic pattern for apprentices to learn since it is very tempting to stay with a job to peruse promotions. I worked at Taco Bell, a job I didn’t like, for four years because I accepted a managerial position. If I had learned about Draw Your Own Map before I began working I wouldn’t have stayed with Taco Bell so long.

When choosing between fast food jobs there is not much difference between work environments, but when choosing between software development jobs there is a huge amount of difference between two companies, let alone the entire industry. This is why it is so important to Draw Your Own Map wisely and choose the right path, because you do not get a second chance.

Your path compounds on itself, as shown by Desi’s experience. She began work as a system administrator, but found that she wanted to program. Few companies would hire her since she had a lot of systems experience, but little programming experience. This is why it is so important to always stay on your map and make sure the experience you gain is experience you want. Eventually Desi found a company which hired her, and is much happier at her current job.

Reading this pattern has definitely changed my perspective on my future career path. Draw Your Own Map suggests to set small goals for yourself since achieving these goals will help you create new ones. I’ve been debating if I should (professionally) hop around jobs, and this pattern has convinced me to do so. Hopping jobs will allow me to experience what the industry has to offer, and to decide what I want to do based on personal experience rather than my own thoughts about what software development is. I thoroughly enjoyed Draw Your Own Map and I think it’s insights are invaluable, especially to someone like me.

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

This apprenticeship pattern really tries to tell apprentices, relatively new software craftsmen, to allow their enthusiasm and new set of eyes to help guide older, more experienced members of a group. It encourages us to speak our minds about issues, and offer new solutions that may be looked over by the more experienced members of a development team, but that we can see with fresh eyes. It’s mostly about the value that new developers can bring to a project, and how at this point in our career we can gain a lot from suggesting things, whether they’re accepted or shot down, we will still learn something from the experience, and really there’s nothing to lose.

The thing that I found most surprising about this pattern was that new members of the team are actually pretty important, they cited a study about aircraft carrier teams being more effective with new members, and stated that it is similar in the software field. The new members bring in new ideas and a freshness that the more experienced group members have lost, and that it all creates an important balance between experience and freshness. It is important in the early part of our careers that we harness the new, fresh, outlook on the field in order to bring more creativity to our projects, find new ways of doing things, and are given the opportunity to advance and learn from people that have been around for a long time. And then we will eventually get to be the ones to temper the new apprentices’ expectations, and teach them, but also learn from their ideas. It is just fascinating to think that we are part of this ecosystem that has lasted for generations of developers and that despite our relative inexperience we are still invaluable assets.

I know that after reading this, I am feeling a lot less nervous about graduating in the next few months and that my contributions to my future development team will be necessary for their survival, and I’m excited to learn what I can from them. However, I’m not sure how the “Solution” part of this pattern really addresses the core tenant of the pattern. Yes, it is a good idea to make sure that your voice is heard and have a more experienced person tell you if there are flaws in your idea and where to improve. However, for many of us, we’ve never really been in a professional environment so it is kind of hard to achieve their solution. However, I don’t think there is a real issue or something I disagree with, but it just seems like it isn’t fully attainable for everyone.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.