Welcome back everybody to another Apprenticeship Patterns by Adewale Oshineye, Dave Hoover blog post. Today pattern is to learn how you fail which is about how we should gain knowledge from our failure. I agreed with this pattern context that failure is inevitable. I believe every successful person failed more than they succeed. I think that failure can be anything from programming to any day life activity. When reading this pattern, I realize that I have a lot of daily life fail goals. I will prioritize the fail and figure what is worth solving. I learned that it’s important to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead me to fail. I disagree that we should consider cutting out losses and accept that there will be some things that we are not good at. I believe that some things that are out of our control should consider cutting loose but things that just requires more effort should always be work on to fix. I think it’s important to set unrealistic goals every day so you can push your boundaries. Even though I different thoughts on this patterning method to set realistic goals, I can envision that setting accomplishable goals can be more effective than setting unrealistic goals. This method will result in many failures but that will have many benefits as well when progressing to be a better version of yourself. After reading this pattern I am more aware of the way I now work. I feel the need to go over my failures and evaluate them. I found this pattern useful but very familiar. Even though this pattern was very brief, I still think it’s important for every programmer to review. This pattern made me realize that setting too many goals and I should be more focus on the worthy ones. I didn’t physical do the action exercise, but I don’t the main objective of the activity when reading it. I think the main idea of the action is that error is inevitable. All in all, this pattern learn how you fail is worth reading and change the way I work.

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

Draw you own map was the topic i picked for this week. I really enjoyed reading this pattern. It gives me the understanding of how to beat or overcome the huddles of learning new stuff and become very good at what we do or love.

From the reading, i also got to know, in order to be happy at your work place or your next career. You will have to pick a field you enjoy which most of my time i will be spending. The stories that Desi and Chris’s gave, give me the knowledge that planing your career at an early stage helps a lot. It makes you know what to expect and also what you want. Also from their stories, they could have prevented ending up in a a job they dislike by getting more info or doing more research about their next career or job. In case you did your research and landed to the job and later found out that it is not good for you. It is not late to change or learn new stuff. The pattern also gives ways on how to draw you own map. To me, it was very easy to understand and also felt it is the best way. The actions taken when drawing the map will definitely land you to the dream job you are looking for.

I really like this pattern(draw your own map. It has showed me a lot on how to really design my map in terms of my next career or job. it has also open my mind not just on my field of studies after graduating but also in life in general. I realized this technique that book showed, applies to everything. Not only for programmers or computer science students. I even made my own map which was really fun. I add four desirable jobs i will want to have for the next six years to come. On map diagram, about the desirable jobs, i included jobs no related to my field. Added fields like being a chef and nurse. Also added things i should be learning, whether things not related to my field or new programming languages.

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

For the third week’s reading, I chose to read the pattern, Unleash Your Enthusiasm. This pattern is about handling the excitement of being a software developer once you join a team. Joining a team brings responsibilities such as considering how the team functions. The enthusiasm you bring into the team could be accepted or rejected. Depending on what happens, you are required to handle it correctly. For example, being overly enthusiastic could potentially backfire such as making a bad impression in front of a well-established team that is currently low on morale. For teams open to excitement, you can be yourself, as they are accepting of possible ideas and creativity you could bring. This type of environment allows yourself to throw ideas with very little to lose as well. By being a newcomer, it’s said that you are in a unique position of having a fresh perspective for the team. As with any team, improvements and suggestions can be made by all members, as such, your opinion also matters.

What I found interesting about this pattern is the excerpt about a study on the collective mind of aircraft carrier crews. The conclusion of the research was that its healthier for a team to having people of all levels of experience. This is true in a sense that if you have a team of all veterans, it’s very easy to be in a mindset where you could do no wrong. While incorporating members that have less experience, the veterans would benefit from reviewing basic information that they could potentially overlook or forget. As such, new comers do have a unique role as stated earlier in the pattern. Another interesting part of this pattern would be the action it proposes. It seems to be assessing the thought process in rejecting an idea you have before getting opinions from those you are suggesting it to. By surfacing the scrapped idea and presenting it to said person/group, the individual could learn more about their idea and maybe more. Taking risks is apart of life and sometimes proposing ideas aren’t as risky if you benefit from learning from your peers.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

Often times, as programmers, we will run into problems and will not know how to deal with these issues. Figuring out how to proceed is one of the most difficult things to do. What if the tool I am using doesn’t work? What if I am not fluent in a certain programming language to understand how to overcome a certain bug or fix a certain algorithm? These are all questions that concern us. The Dig Deeper method is very helpful in that it tells you to not just take everything that you learn for face value. Although tight deadlines and code maintenance may be daunting, you should always try your best in order to make sure that the code is clean. What we mean by this is that if you look up tutorials on how to do a certain task, those tutorials may have helped you solved the issue, but they could also have set you up for a lot of issues in the future. The tutorials may have cut corners or not complete things as efficiently as they should.

I really like this idea of Digging Deeper because we often try things sequentially that we find and just hope that the first or second method works. And if it does work we tend to just stick with it without even batting an eye at potential issues or large overhead that can carry. By completing tasks fully and really understanding problems inside and out, it is good to check multiple sources or tutorials. Code maintenance is huge aspect of live design programming. If you were to just look up random tutorials on how to do certain things for your code, you can get confused. You could look sup so many tutorials for each problem and eventually you won’t even be able to understand what does what action in your own code. And at that point, is it even yours? Being curious and making sure that you understand your code in a meaningful way will help you succeed and make further improvements to it. And the nice thing about this method, and many other methods, is that they don’t only apply to programming, but actually working with your team.

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

When I was reading each of the introductions of the “Apprenticeship Patterns” book, the term “breakable toys” came up a couple of times. I wasn’t sure what the authors were trying to describe, so the Breakable Toys pattern was the next that I read. As it turns out, this pattern resonates deeply with me and my workstyle.

Breakable toys are essentially more private projects or spaces where practice is encouraged, without being concerned about the potential consequences of failing. For an apprentice who works in a high-stakes environment with no room for failure, this pattern is key to better understanding and learning about the tools used in their workplace. It removes the pressure of having to consistently be correct when developing software, which would be daunting not just for apprentices, but also for those with more experience. Breakable toys are great for anybody who simply wants a safe spot to work on projects away from their work environment.

Whenever I am writing code, or really doing anything in general, I am always nervous about failure. In conjunction with my previous post (which touches upon the apprenticeship pattern called Be the Worst), I also get intimidated when working with those with more experience, which in turn causes me to get worried about causing any failures when working with such individuals. For me, implementing a Breakable Toy would be great so that I could comfortably learn at my own pace, without fear of messing up in front of the development team and further affecting my ever-present impostor syndrome. I already have started various personal projects and courses, which I can now view as Breakable Toys of sorts.

Reading about this pattern didn’t really change the way I’m thinking about development and my apprenticeship process. Rather, it helped me realize that the kinds of activities that I’m already taking part in (like coding projects on my own or working my way through courses/textbooks outside of my schoolwork) are great steps that I should be taking in order to fine-tune my skills while also embracing any failures that may arise. By encountering these failures now, I can also better prepare for being a part of a development environment with less room for error.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

For this week, I have decided to read “Concrete Skills” pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I have chosen this one since it is a good refresher for understanding that knowledge known is not the same. I believe this will help me in making so that I can be sure to give more demonstration than telling by just writing it out.

This pattern starts with the context of seeking out a role in a group of talented people that will provide better learning opportunities than currently. The problem is that the team, when asked, they can not risk of bringing someone that would not be able to contribute for the intended workload. There is also when thinking further, the possibility of not being able to do even the simplest task when asked. The solution to that problem is concrete skills, acquiring and maintaining them. With these skills, demonstrating and having them will increase the possibility of being trustworthy and be able to reach the goals. Eventually, there will be less dependent on these set of skills as the possibilities increase in being hired for the jobs intended.

From this pattern, what I found useful is the listing for concrete skills as an example to give the point of giving trust to the employer. As we try to give a good impression and trust for the likes of employers, we want to be sure that we at least have a clear understanding and demonstration of the basic things to do like JavaScript and the standard libraries by choice for computing jobs. Skills may require more thoughts to give an even better impression than intended, but it does answer questions to which the employer may ask. This pattern has changed my way of thinking in my profession. As I read the short pattern, it has become clear to me that I should not only directly say as intended but also if needed, demonstrate what I can do even if it is the basic thing. For this pattern overall, there is nothing I don’t disagree upon and this is because the pattern was able to give good perspectives of knowing what to do with this concept.

Based on the content of this pattern, I will say this is a simple but effective one. This pattern has showed good examples of the real-life scenarios. It allows me to be aware in the future of demonstrating than telling by just paper. For practice, I will show some technical work to give good impressions.

Link to the pattern: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Practice as they say, makes one perfect. Practice is the act of rehearsing a behavior over and over for the purpose of improving on it to be perfect. From the readings, i notice the statement which says “Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. ” which i think was quoted by George Leonard. Actually, i think he is getting the whole thing wrong. Practice actually make you perfect and also makes your permanent. Whether you are learning the good thing or the bad thing, you will eventually be very good at it, leading to perfection.

I also learned by practicing, you do not have to do it alone. Just by being at work or under a master, you will be learning a lot. By learning you are practicing at the same time. You should also be making sure you are learning the best stuff, since what you are learning, can be come permanent. You don’t want to learn being good at something that will not profit you in the long run. That will be a waste of time and resources. In order ways while you are searching for a good place to work or a mentor, you should make sure you picked the right person(s).

Also while getting used to things, make sure you are learning other new skill. You don’t get stuck on one thing. You need to know more, and by doing that, you will have to learn new skill when ever you thing are okay with others. Pick harder stuff or projects to practice on. Always check you strength, if too easy move to harder ones.

This pattern has not caused me to change the way i viewed practicing. But it has showed me there are ways i can practice in an excellent way or a better way.  And also types of practicing i can take. Also to my understanding, practicing with peers is more an effective way to be better at your skills. I really enjoyed this pattern and i know it will help me now and very well in the future.

From the blog CS@worcester – Site Title by Derek Odame and used with permission of the author. All other rights reserved by the author.

          The “Be The Worst” pattern is described as a way be able to keep learning after you begin to hit a roadblock and your rate of learning has plateaued. The book explains that the solution to this problem is to make sure you are around developers who are better than you and can help you identify your weaknesses by comparison. It removes the sense of comfort that builds up once an individual performs better and makes you recover faster from mistakes with more competent team members at your side. The learning process can become smoother through this pattern and allows the individual a better sense of understanding of their skills before and after joining the team. The goal is to not remain the weakest team member and to be constantly working hard to make sure that you can surpass your team members. This can lead to sudden risks of dragging the team down if you cannot catch up quickly enough and affect how you view yourself. The motivation of an individual is tested here as well how much stress one can endure and to push through for the eventual endgame.

          I found that this pattern is very relatable to me which in turn could be useful to apply into my daily life. I find it interesting how much of the situations the book brought up were so similar to problems I’ve faced in the past in terms of moving my skills up to the net level. I found that my learning had plateaued as well and didn’t really understand how to deal with it. The idea of removing my sense of comfort form my first language is thought-provoking because it seems to be very difficult for me to let go of my first language and move on to more difficult concepts. I have always loved learning Java, but this pattern as shown me to look past a single language and continue to grow with the industry. I still am hesitant to let go of my coding habits from Java but realize that I have to make this change immediately. I should surround myself with those that are better than me and try to survive in that environment to evolve my understanding of code at a faster rate. I agree with this pattern completely after fully understanding how it works and how to better my skills through my environment.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.