In this Apprenticeship pattern “Emptying the Cup: The Deep End”, it explains on how you as a developer can further your development skills by taking on challenges that may or may not involve risks. Even though there may not be risks that can affect your career as a software developer, it may cause you to fail the challenge or objective you are trying to accomplish. Of course in any industry of work that you may wish to advance or climb the ladder in, you have to tackle on bigger tasks to show that you have the skills and mindset to be in a bigger and better position than the one you are currently in. However, failure can result in the process. The Apprenticeship pattern “The Deep End”, highlights that failure is normal when taking on challenges.

“This has risks. If you get it wrong and end up over your head you could drown. Thankfully there are many places in IT where you can take risks without destroying your career if you fail. Risks are opportunities seen through the half-shut eyes of fear. This doesn’t mean lying on your resume to get a job you can’t do, nor does it mean tackling challenges without adequate preparation. Instead, it means taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.”

Drowning in this context means failure and I completely agree with this idea because as an individual, I learn best by failing and making mistakes. At times, I can be scared to fail but I know deep down it is the best way for me to learn. This pattern also reminded me that feeling fear is okay when you I think failure is staring me right in the face because the after effects of failure is more of a gain for me when taking on a challenge than being successful on a smaller, simple task. After I fail a challenge, I reevaluate what I did wrong so I can approach it differently the next time I take that same challenge head on. This concept of taking on “The Deep End” isn’t only important in Software Development but it can be applied in any workplace.

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.

The “Record What You Learn” pattern suggests keeping a record of the lessons you’re learning during your apprenticeship in the form of a journal, a blog, or a wiki, so that you don’t have to figure something out more than once. You can also keep two records, a public version and a private version. This enables you to find other people interested in the same topics and get outside feedback, but also be honest with yourself about your progress if there are things you want to write down but would feel too embarrassed to post. The writers also advise you to go back and read what you’ve recorded periodically, so you don’t write stuff down and then forget it, rendering this pattern useless.

The action the writers suggest to start implementing this pattern is what we’ve been doing for this class this whole time: write down your thoughts about Apprenticeship Patterns and ideas it has inspired. I’ve found that in any situation, writing down what I’m learning does help to process the information. During my painful Data Structures course, I took notes from the book just to summarize the concepts and make them stick in my head. Additionally, it’s common wisdom that the best way to learn something is to teach it. If you’re making a public record, you’ll get part of the benefit of teaching it by having to put what you’ve learned into words easy for someone ignorant of the subject to understand.

I like the idea of having both a private and a public record, because I would feel hesitant to broadcast what I was learning if I was still unsure of my knowledge of it. I also like the idea of creating a breakable toy to store the lessons, because then the process of recording what you’ve learned will itself be a learning experience.

If in the future I find myself making the same mistakes over and over, I’ll know that it means I’m not writing down or reviewing what I’ve learned often enough. The time investment is worth it, because it’d waste a lot more time running into problems I’ve already solved and having to relearn their solutions.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

The Breakable Toys pattern addresses the issue of learning by making mistakes in an environment where failure is not an option.  This can mean that learning substantially more difficult.  The solution that they propose is to build yourself an environment in which failure is allowed to happen.  The apprentice does this by creating a pet project (even if it’s reinventing the wheel) and just trying things until something works or something sticks.

This pattern really resonates with me and the way I learn.  I can’t just pick things up by reading code or manuals, or copying premade solutions.  I need to get my hands dirty and build things.  Sometimes I’ll “sketch out” programs first by building a skeleton of files I know I want and adjusting as I go.  Sometimes I implement the core of code and let the rest of the program grow around it.  Neither approach is necessarily suitable for a professional environment where expectations may be high, but it helps me learn.

I also think that the Breakable Toys pattern can be applied in a more limited way to a more pressured setting.  While you might not be able to just declare failure when tasked with writing a section of code, you could take a couple of runs at it if the logic or the language involved are unfamiliar.  The main difference between this and Breakable Toys (maybe this is Partially-Breakable Toys?  Scratchable Toys?) is that you still need to deliver a working end-product in reasonable time.  The toy can’t be the whole assignment or program, but maybe it can be part of it.  This approach, however, doesn’t have the longevity implied by the authors.

I really appreciate that this pattern is in the book.  Playing with problems, writing code, failing, and then finding ways to do what I want to do is how I learn things.  It’s also a big part of what I love about software development.  Reading about something like the way I prefer to learn in a book like this makes me feel validated about my learning methods, like I’m on the right track.

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

This week I read the apprenticeship pattern “Confront Your Ignorance”, I chose this one because I thought it would be very relevant to me due to the fact that I am in a new role where many things are new to me. This pattern suggests that you do exactly what the name says, come face to face with the things that you do not know. Thus far, I think that this is one of the most valuable pattern mostly because nowadays, since the industry is constantly changing if you are not actively trying to fill in the gaps in your knowledge you WILL fall behind.

To relate this to my own personal work experience, I am currently trying to fill in the Spring gap in my knowledge. I have in a sense been “lucky” for a while since I have been able to avoid any tasks involving those tools, but my team uses Spring so much that my luck will eventually run out. If I do not confront my ignorance when it comes to Spring, then when I am assigned a task involving it I will harm my team. The other great benefit to this pattern is that, if applied, will make you an invaluable member of your team, nowadays there are so many technologies and components to learn that it is almost impossible to know them all so if you are constantly trying to learn more of them, then your value is constantly increasing.

Though this all sounds good on paper, in the real world I don’t think this pattern is applied because it is intimidating. We are comfortable with what we know, and we don’t like being thrown into a situation where everything is new, never-mind doing that intentionally! Also, I think another major hindrance is time, often times you are working on a major project that is taking up nearly all of your time making it difficult to find the time needed to learn something new. A solution that this pattern provides is starting small, you don’t have to do a very deep dive, you can start with an overview and simply learning the basics and that is what is the most promising for me. By learning the basic of Spring in the spare time that I do have, it will massively decrease my ramp-up time when I have to use it. In conclusion this is a very useful pattern that I will 100% try to apply in my software career.

From the blog CS@Worcester – Site Title by lphilippeau 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.

Let’s start out this one with a hypothetical situation. You graduate college with a Computer Science degree. You walk the stage knowing that you have a job lined up. You are excited enthused and ready to learn some new things! Good!

Fast forward 3 years. You are now the person at the company that everyone asks questions and expects quality answers and advice from you. You feel like you have repeated the same thing for the last 6 months.  You have gotten into a routine of doing the same thing over and over and over AND OVER again. Long story short, you only have three years of experience and you have already maxed out your potential at this company.

This is the exact situation that Oshineye and Hoover try to help you overcome with their apprenticeship pattern “Be The Worst”. Obviously, this title is a little misleading but the solution is clear. You want to be the worst developer on a team. Not on purpose but naturally. You should look for a team with developers that are way more experienced than you. You will pick up their good habits and drop your bad ones. They will correct your mistake and teach you efficiently without you even knowing it. The authors have a great outlook on it : “Being in a strong team can make you feel as if you are performing better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think.” (Oshineye, Hoover)

I enjoyed this pattern because I feel as though I am going to be in that boat myself. I feel as though my first job will teach me a lot but I don’t want to get tied down to one job forever. This pattern actually made me feel very comfortable. For some reason, I had always thought that my first job out of college will be my last. I like the fact that it is acceptable and recommended to leave a job that you aren’t learning from. I like it because I am always trying to pick up new skills and I can’t wait to be fully emerged in the industry! With some experience under your belt, you can open yourself up to new options and jobs that you would have never thought you qualified for. This pattern will be invaluable to me in the future.

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

In this apprenticeship pattern, the authors present a problem that I’m sure many rising computer science professionals have encountered early on in their careers. They describe the context of the problem as being when one feels they are stuck in a rut, falling short from their colleagues in terms of knowledge and skill. The authors explain that the only way to address this kind of issue is to dive head first into the “deep end.” What they mean by this is that the only way to advance one’s skill, knowledge and, most importantly, confidence is to take on harder tasks that are more challenging. The authors stress the fact that it is to easy to fall into a pattern of complacency and that it is essential to take risks in order to become a better software professional. One particular quote from this pattern that really stuck with me was the following:

“Risks are opportunities seen through the half-shut eyes of fear.”

I think that fear plays a huge role in decision making when it comes to computer scientists. Most notably, the fear of failure may cause a developer to hesitate in taking on a larger role within a team or committing to working on a difficult project outside of their comfort zone. I think its important to remember that even the most brilliant developers have made their fair share of mistakes and the only way to get better is to continue making mistakes because you are bound to succeed at some point if you keep trying. In this pattern, the authors give a real-life example of how this ideology can serve to benefit a developing professional by providing testimonial from a developer named Enrique Comba Riepenhausen. Enrique found himself taking on a new role at his company that entailed much more work than his previous role. Instead of becoming overwhelmed with fear and hesitation, Enrique rose to the occasion and put his best effort forward. As a result, Enrique excelled at his position and was able to construct a customized platform for his client’s needs.  Since then, Enrique describes having a plethora of opportunities including being able to travel the globe doing what he loves.

After reading this patter I decided to take the advice given by the authors in the Action section by doing the following:

1. Make a list of the largest successful projects I have contributed to.
2. Determine the dimensions of complexity as a means of measurement for each project listed in step 1.
3. Create a chart with the information from steps 1 and 2.
4. Add any new projects I take on to the chart in order to visualize the trajectory of my career.

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