In this section of the Apprenticeship Patterns, the term “concrete skills” was introduced. It gives us an overview of why having certain concrete skills are necessary to have, especially when you, as an apprentice, will start developing your craft in the software development team. For example, a concrete skill can be your “First Language”, where you have prior knowledge and skills on understanding the programming language and knowing how to implement it in an IDE.

“Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications.”

I found this idea very useful and I completely agree with it because a developer who has adequate or substantial knowledge in software development has no value in their team if they do not know how to implement their knowledge in their craft. Therefore, the develop has no value in their team, and is nothing more than a dud in the team.

“The point is that you will often require hiring managers to take a leap of faith in choosing you. Concrete skills (which are ideally discrete enough that you can bring toy implementations to an interview) allow you to meet them halfway. The concrete skills you possess are your answer to the question: “If we hire you today, what can you do on Monday morning that will benefit us?” A deep understanding of ‘Your First Language’ will help establish your credibility and should prove to be extremely useful to your team.”

This idea supports that programming languages can be an effective concrete skill to have. Programming Languages, however, are not the only concrete skills that developers may need to have. Team management, communication, and organization skills are also necessary to have in order to have an efficient and cohesive team.

Reading this Apprenticeship Pattern made me think about the development capstone class because it made me evaluate myself and my team members on where we stand in acquiring our concrete skills. Within the past couple weeks, I’ve been trying to get use to Angular by doing more of the Angular tutorials so I can be well equipped on that knowledge on how use Angular. I think that would be a great task for me to do so in case if my teammates need help on Angular, I can show them, which is how I can be become a valuable asset to the team and our success.

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.

Most apprentices like me always face problems such as frustration and discouragement from peers and even their craftsmen sometimes. It is my dream as an apprentice to excel in my learning.  Some craftsmen will always intimidate their apprentices and it takes a brave and focus apprentice to stay on track. Sometimes, it is not just the craftsmen that will give you hard time. Being in a team that dictates your contribution can cause you a lot of damage in your learning. As a first comer, those who have been in the apprenticeship for years might have the mind set of you not knowing anything yet and will not value your contributions. Also, moment you have that feeling of fear and not able to speak out your ideas, you are on your way to failure.

However, this pattern has good information that can help me as an apprentice to figure out how to deal with most situations whiles learning.  One thing I have come to notice is that you cannot meet your desired expectation if you have no passion for what you are learning. Being happy or excited of what you learning or working on will actually enable you to put much effort into achieving your goals.

I am actually surprised of what makes a better team. Even though I am aware that a team of experience members can have problem due to everybody trying to be the leader, I usually think they will still have a better result. A team with varying levels of experience is the least I can think of being successful in its activities. I also think, believing in yourself that your contribution to a team will make a difference will enable you to openly speak out. Sometimes, I try to get as much as I could from my team members by listening to all they have to offer but very careful of what information I am taking from them because more often they are either misleading or conflicting with what I knew.

Again, I am not surprise craftsmen learn from their apprentices because a good apprentice will always search for knowledge outside his confined area and when his findings are openly embrace, craftsmen will benefit from it. Reading this pattern has impacted me with ideas that will help me focus on my apprenticeship journey. I will openly unleash my enthusiasm and would never allow others or circumstances around me to dictates what I can offer to my team.

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

I thought this section of Apprenticeship Patterns presented a fascinating take on how newcomers might fit in with their more experienced counter parts when entering the professional world of computer science. The authors describe the role an “apprentice” might want to take when working in a team of seasoned computer scientists. They explain that it is common place for newcomers to “fly under the radar” and not speak their ideas due to lack confidence in their ability to be a contributing team member. They point out that while every team may differ, teams typically benefit from having team members of varying skill levels, even “apprentices.” The authors also cite a study involving aircraft carrier crews that showed that it is healthier for teams to consist of people with different degrees of skill and experience and found that newcomers played an integral role in the team dynamic. Finally, the authors propose that newcomers should in fact “unleash their enthusiasm” in hopes that their excitement will rub off on other team members as well as keep other team members on their toes through asking many questions on why things are the way they are as well as presenting fresh ideas.

I honestly found this particular pattern to be extremely relatable as I am currently a newcomer in a security team that is made of individuals who have varying degrees of skill level, experience, and expertise.  When I first started, I admit that I was a little intimidated by all the tools that were being used not to mention all the acronyms being thrown around in meetings that I had never heard of before. However, I feel like that feeling of being overwhelmed pushed me to want to learn more about security and obtain the same kind of knowledge possessed by my coworkers while at the same time applying the knowledge I have acquired throughout the course of my college career. I also feel like I really lucked out because of the willingness of each of my team members to answer my questions and give me advise. After reading this pattern I think I will ask questions and speak up more confidently at work because now I know that it is important to bring a fresh perspective to a team.

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.

This pattern seeks to solve the problem of skill gaps that are making daily work more challenging.  The authors propose that software apprentices suffering from this issue attempt to actively learn the missing pieces.  This could take different forms — they suggest reading tutorials/FAQs, constructing small low-stakes projects, and/or involving other people that are either experts in the area or trying to learn the same thing.  They also suggest keeping a list of these skill gap areas, and crossing them off as they’re sufficiently learned; this goes hand-in-hand with adding to the list as your learning exposes additional gaps.

This approach to learning really resonates with me.  My preference is to actively seek out knowledge, and I tend to learn best through hands-on practice.  I’ve already used a less formalized version of this when I taught myself Python: find a skill (in this case, a programming language) that I would like to learn and then give myself a project to work on that forces me to learn and use it.  There are three major additions (on top of the formalization) that I can take away from this pattern:

1. Involve other people, whether they are experts or fellow learners.
2. Don’t overuse this pattern to the point where it causes problems for others; I only have so much time.
3. Balance learning with introspection.

The first point leads to the creation of a learning community, and extends both the resources and benefits of learning.  I know that I have a tendency to want to do everything myself, and while independence isn’t bad it’s also important to not always be reinventing the wheel.  I also enjoy sharing my knowledge, and it makes sense for me to seek that out in a more mutual way.

The second point is also something I run into often, and partially extends from the first.  I really like to build things from scratch and see how they’re made.  However, that tendency can also lead to excessive use of time and energy for what should be a simpler project, or the preference for my own solution over another (quite possibly better) one that’s already been written and vetted.

The third point encourages me to set up a cycle of learning and introspection; crossing items off of the list and then adding more to the bottom.

While actual checklists are not a tool I particularly enjoy using, this pattern has leaned me towards perhaps keeping one (and actually updating it).  That, I think, is where I’ve found the most value in Confront Your Ignorance.

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