Sustainable Motivations is an apprenticeship pattern that touches on the idea that despite loving programming issues such as frustration, lack of motivation, and in extreme instances burnout are still very possible. This apprenticeship pattern discusses how to deal with issues and attempt to mitigate them before they even really begin. One way to go about this is to make sure you keep a healthy balance between your work life and personal life. The apprenticeship pattern also gives anecdotes about times other developers dealt with an issue regarding a loss of motivation or uncertainty about what direction they want to take their careers.

To be honest this apprenticeship pattern did not click with me as well as the other ones I have read about so far. While I agree with the overall statement that you need to keep your ambitions and work in check to ensure you can maintain a steady level of motivation, it doesn’t really go into too much detail on how to go about it. The example I mentioned in my initial paragraph is one of very few where the authors actually talk about ways to manage this issue. They do reference another apprenticeship pattern called walking the long road, which discusses similar issues; but as an over all approach to trying to solve the specific problem they presented in this pattern the solutions given were mostly abstract and anecdotal. There is not too much that I can clearly take away from this pattern. Regardless there is still some lessons that I think are valuable, mainly the example I mentioned earlier regarding balancing time.

In my own life I have struggled with healthy balance of time. I tend to fluctuate between two extremes, either over focusing on work and sacrificing my personal life, or over focusing on my personal life and having my work suffer. Given this I can understand what this pattern is trying to say in that regard. While I was aware of this balancing issue in my life and have improved on it over time, reading through this pattern emphasized the importance of a good work life balance through anecdotal examples of issues other developers have also gone through.

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

I moved on to chapter 4 for this post and wanted to start with the first problem for it, Be the Worst. The problem is here when you learned all you can about a certain skill or skillset and cannot grow any more at your current position, with the solution to this problem being to move on to another position and group where you are the worst at what is being worked on. That way, you will have plenty of room to grow and you have help for when you make mistakes. It’s a case of starting from the bottom and working your way to the top. I can see how effective this can be and it has been successful for others, but I also agree with the possible risks that may come from this tactic, such as bringing the team down, not catching up, and possible self esteem issues. It can lead to problems not just for you, but for your team. However, you can deal with these risks by joining teams that are open to this mindset, and/or checking in with the team on your progress to make sure you are not falling behind.

Some people prefer working with others and can improve faster than they would if they were alone. I usually work with other people that I have similar skill levels with, so I don’t have that many examples of teams that I have been in where I or someone else was the “worst”. I do have examples where I was having some trouble and was worried about falling behind, and I would talk with the other members for tips or to get help on what I was working on. However, I do usually try to figure things out on my own because I sometimes think I may be bothering my teammates. This has led to some issues where I came close to falling behind, but I was able to deal with it before it became a problem.

Collaborating with others is a very effective way at working and improving yourself, and the idea of being the worst in a group and working your way up over time is a successful path, but does come with risks that you will need to be able handle.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

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.