I love this apprenticeship pattern. It immediately caught my attention, and although I knew exactly what it was getting at by reading the title, it’s a great reminder.

We’ve probably all heard the phrase “if you’re the smartest person in the room, you’re in the wrong room”. That’s what this pattern is describing. As the worst on a team, you will have an occasion to rise to, riding on the coattails of your teammates and becoming better for it. This means harder work. It requires the ability to apply many other patterns described in the book to succeed efficiently.

The above quote is a bit harsh, though, and isn’t mentioned in the book. It’s not that one should be openly criticizing their coworkers or consider themselves the smartest person in the room, despite every programmer’s periodic God complex. Besides, it’s difficult to ascertain who exactly is the smartest, or best developer, or best employee. There are many metrics and a team is full of people with different strengths and weaknesses. The individuals are less important than the group: this pattern is probably best implemented by looking at teams as a whole. Are your skills lower than those of the group as a whole? This could be caused by a lot of great developers not working well together. This, too, will slow your progress down. This, too, is a reason to change.

I have mixed feelings about this sentiment. It’s patently true that working with people significantly above your skill level will help you improve if you’re willing to put the work in. But it would be a real shame to leave a close, efficient team just because you’re no longer worse than all of them.

But that is an important part of growth: knowing when to move on. Finally ending my college career makes me consider all the things I could have done, or could do if I finished a second concentration or major. Or what I missed for general education credits, extra curricular activities, and social experiences by cramming the entire degree into three years and not taking my time to enjoy it. It’s nearing the time to move on, though. Despite a connection to classmates and professors, it would not be wise to stay longer. This doesn’t mean professional or academic relationships have to end, but the majority of my time will soon be spent improving in my chosen career, with new challenges, on a new team.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

This week I decided to write about the Breakable Toys pattern because the last pattern that I wrote about mentioned this pattern, and it was in the See Also section of the last pattern as well. From the title, I have gathered that this pattern is about just random coding projects that have no consequences and the programmer can just experiment with the code and try out new things.

After reading the Context section i discovered that this pattern involves failure and learning from those failures in order to become a better developer. The problem of this pattern basically says that you work in a field that doesn’t allow for failure, but your individual growth depends on failure. This makes sense because there isn’t a lot of room for mistakes in a real work environment because mistakes can lead to much bigger issues.

The solution to this problem is as I mentioned earlier with slight differences. Rather than coding just random projects, you should code projects that “are similar in toolset” (Oshineye, Hoover). The authors recommend using Wikis as your breakable toy. They say this because of their simplicity. They also mention that they can be great for learning HTTP and REST which I thought was interesting because our Capstone involves both HTTP and REST, so maybe I should start working on a wiki on the side. Another breakable toy idea that they suggested that one of their ex-colleagues used is creating games. This is a cool tool because it is a fun way to learn how to code because at the end you are given a product that you can play with way after the fact. Realistically, you could just look up Tetris on the internet, but it is much cooler if you are playing something of your own creation. Lastly, they mention how this pattern is similar to Be The Worst which is actually what I plan on writing about for my next blog.

The Action section basically just tells the programmer to create a very simple wiki, and add features into it as you continue with your career. I like this method because there are no repercussions if you mess up and you can learn from these mistakes. I think that I will actually use this pattern in the future, and my internship has kind of done this for me too. The projects that are assigned to me are projects that they use in their day to day life, but I have freedom to make mistakes and learn from them.

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

Failure is an acceptance of what you are capably of. Not in a means of saying that you can not but in terms of stating that being aware of what you are missing. This prevents the boundaries that you are creating, such as giving up for being stuck at only one thing that you already know.

Failures are a big part in order to be successful. I have experienced it many time when learning my first programming language. I even decided to change my major to Business. 

At first it seemed really interesting and i was curious to learn more about how functions, objects and data works n java. I practiced and started ding the same problems again and agin until i had an idea of what the code was doing. But when I had a similar problem but it it was conned in different way I was lost. I ended up belly passing.

I then met one of my class mates, she was a minor and had better experienced then me in programming. She was really good at explaining. She taught me an easy was to adopt new skills. She told me which text editor to use, how to consume your time,being tim efficient, and which programming language is easier to understand.

“Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and a constant searching for new solutions.”

Atul Gawande, Better.

I applied those skill. I was still failing but was making progress, i was understanding what Mistakes I was doing. I was only missing out minor mistakes or I was sometimes rushing. But pointing out my mistakes I was ale to prevent myself to stop giving up on programming, 

Now as a senior I am not afraid to take th risk. I take failed as a new learning experience wirer I am able to apply my understanding in much more effiecnt way.

That is what the author is trying to tell. Many people see fair as a negative condition. However, It is a part of being successful. 

From the blog CS@Worcester – Tech a Talk -Arisha Khan by ajahan22 and used with permission of the author. All other rights reserved by the author.

The pattern “Be the Worst” is one that most people have heard many times and its a great life lesson that can be applied to many other situations. The idea is to surround yourself with people that are better than you and learn from them and grow. Basically don’t be afraid to not be at the same level as your peers and try to surpass them with every experience. This can also be a way to help others that are struggling or want to be better at something that you excel at. This pattern is definitely one that i could see myself using in my professional career and also in my education because the quickest way to learn something is to be surrounded by people that understand the concepts and to observe them and ask questions. Everyone has weak points and things that they wish they could be better at so finding people that excel at what you struggle with can only help you to learn and grow.
The one thing that I feel this pattern failed to make an extremely important part is that you should strive to go on and become the best at what you learn. I might just be a competitive person and this may not apply to all people, but I personally would want to become the best at whatever I do. This pattern also fails to really talk about doing the reverse which would be helping others in the same way that you want help. This pattern changed my perception about the profession of software development because I didn’t really think about how people from all over the place could be assembled to help one another understand things and it makes me think of a coalition/brotherhood rather than work or a job. The pattern talks about how it is a little selfish to join a team knowing that you are the weakest link and that you might hold them back a little, but sometimes you need to be selfish and think about yourself and what you need to grow and become better. Being selfish at times is needed to advance yourself and your career, so I’ll probably do this pattern unashamed and ready to become the best in every group.

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

The first of the patterns in Apprenticeship Patterns that I have decided to discuss is titled “Expose Your Ignorance.” This pattern deals with situations where we do not understand every skill we need to use for a project. In such situations, people tend to fake an understanding of things they don’t know in order to appear competent. Rather than hiding our ignorance in this way, the pattern recommends acknowledging when we do not know something and explaining to colleagues that we are still learning about it. This makes it easier to build relationships and improves our ability to learn, which are both important skills for a software craftsman.

I chose to share this pattern because I found it relatable. During many programming projects I have been a part of, I have had trouble understanding topics that my peers seemed to have no problems with. Despite this, I’ve avoided asking questions due to a fear of appearing inadequate or ignorant, and have generally tried to answer my questions through my own research. I think that following this pattern would greatly improve my ability to learn new skills quickly. I would likely have an easier time learning new skills directly from someone with experience instead of trying to teach them to myself.

Knowing that this pattern could improve my ability to learn new skills quickly, I think it may change how I approach future programming projects. Previously, I have felt ashamed of not knowing things and have felt responsible for teaching myself in order to meet the expectations of my team members. I think this pattern will help me accept that it is okay not to possess every skill required for a project. It will also encourage me to communicate better with other developers in order to gain the skills I need. I have always had trouble asking questions and communicating in general, and I think this pattern would encourage me to get better at it. I will try to approach future projects from the perspective that it is okay to not have every skill I need, and that I should try to learn from other developers instead of keeping to myself. This communication might also help me build relationships with other developers as well as a reputation for myself that could lead to a more successful future.

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

The next apprenticeship pattern I was drawn to has to do with the imposter syndrome. The problem comes when you obtain a title that doesn’t seem to reflect your skill level, at least in your mind.

The description of the pattern is much different than my expectation. I had imagined using a title to advance your career, but the suggestion is quite the opposite: it posits that the title is ultimately pretty meaningless as far as your skill level, but you can use it to gauge your employer.

An impressive title is tempting to pursue. It seems to prove to others that we’ve achieved success, which can be tempting for someone with parents to make proud or neighbors to keep up with. This can be completely removed from your actual success and may not reflect your actual job duties. While not explicitly stated in the book, this pattern suggest that if a company sets your title to something prestigious, and you don’t agree with it, it might be possible that the company sets the bar too low. If you know your skill is below a senior engineer, you should be somewhere where the senior engineers will help you get to their level. That’s not possible if all the senior engineers are at your level and know you don’t have the skills.

I’ve always reached out of my job title, as suggested by the Draw Your Own Map pattern I wrote about last week. As such, my job title did not reflect what I was actually doing. “Use Your Title” says that this can tell you whether you are appreciated, and reflects your employer more than your skills, and this has led me to leave jobs before.

I did have some problems with this pattern. It seems a bit contradictory, saying to not let your title affect you, but then saying to use it to decide how you feel about your company. Regardless, it sparked some thought about how I will be perceived and will help me to consider how my employer feels about me in the future.

I’m going to admit ignorance here: I don’t understand how the suggested action ties in with the description of this pattern. It says to write down a long, descriptive job description and consider how others would perceive you upon reading it. While this exercise might be useful, I don’t see how it applies to “using your title”. My only guess is that you want your actual title to match as closely as possible to your own goals. When there is a mismatch, for better or worse, it might mean you are not aligned with your company.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.