This week, I read the apprenticeship pattern “Learn How You Fail”. To quickly summarize, this pattern asked you to stop looking at your successes and start actively seeking your failures and weaknesses in order to learn from them. I really liked the message behind this pattern because it is different from what we are accustomed to. It is normally very easy to focus on getting better at something you are mediocre at, and even easier to focus on getting better at something you are great at, but it is really difficult to confront your shortcomings and approach what you are terrible at. My interpretation of this pattern was that it doesn’t seek to discredit the good aspects of your skills but rather putting a focus on the bad as to make you a better engineer overall.

This is another applicable pattern for me personally because I still have a few areas of weakness in my development skills, even in some of the technologies and languages that I’ve been using many years. I have caught myself opting out for a simpler but worse performing option because I didn’t want to confront an area of weakness needed to implement the better solution. The other key aspect of this pattern in accurate self assessment, asking yourself “am I really this good at X, or is there major room to improve there”. I often find that we normally give ourselves the benefit of the doubt and say “Yes we are that good”, and this closes out any potential opportunities to actually improve. What this pattern teaches is to really ask and assess deeply and even ask for an external opinion (via peer review) for areas of weakness.

I agree with this pattern and I plan on implementing this going forward in my career. This pattern should be fairly easy to apply because of its practicality. If you are weak in a skill that will no longer needed, the pattern suggests that you shouldn’t waste your time with that and focus on more important areas of weakness. The only challenge to applying this pattern will be the reluctance to do what we are not good at, but I believe that overcoming this will be much easier if we think about the benefit that will come from fixing our weakest links.

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

The pattern “Breakable Toys” can be found here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

This pattern is a little longer than some of the other patterns I have looked over. Long story short, Breakable Toys is a pattern designed to help you learn. Kind of like Be the Worst but is more focused on you as an individual. The problem is that you are working in a company that can’t afford errors to destroy their data/program/whatever (who can afford that?).  However, the other half of the problem is that you are just learning this stuff and need a safe space to practice. You should create your own safe space project that relates to the problem you need to solve in the company, just at a smaller scale. This pattern tells you you need to build these breakable toys from the ground up to learn the insides and outs. Once you have these breakable toys, they are yours forever to use with other jobs and problems.

I thought this pattern was very useful. I was always told that if I want to learn, I have to do. That’s what this pattern is saying. You have to take the initiative and build these projects in order to learn. The best part is, failing only harms your breakable toy, which you built specifically to be broken!

The first line says “If experience is built upon failure as much as success, then you need a more or less private space where you can seek out failure.” (Oshineye, Hoover) I love this first line because it tells you that failure really is okay. That is how you learn. Being successful on the first try only teaches you what works for this situation but not for others. If you fail, you can learn a whole bunch about what doesn’t work and what does work. I don’t think you should intentionally fail, but failing will help you improve your skills and knowledge (so don’t feel too bad). The most important part about failing is getting back up and trying another approach. I could definitely see myself using this in my intended profession. I get worried all the time about breaking things that are important and this pattern gives you a way around that.

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

I wasn’t sure if “Share What You Learn” would be applicable at my current level of experience for exactly the reason the writers give for why apprentices might have doubts about the pattern: I assumed this sort of thing should be left to people who know exactly what they’re doing. They brought up points I hadn’t considered in response to this. An apprentice’s minimal knowledge will make their explanations short and to the point, and they won’t make the mistake of assuming the people they’re sharing with have prior knowledge that they don’t. This makes their explanations, in some ways, more useful to other apprentices than an explanation from a journeyman or master.

The benefit to the apprentice sharing what they’ve learned is something I acknowledged in my blog on “Record What You Learn”: the best way you can learn something yourself is to teach it to someone else. The writers mention this benefit, but they also warn of several ways that applying this pattern can end up doing more harm than good which I hadn’t considered. Sharing your knowledge might get you into legal trouble if what you’re sharing is a trade secret, or sharing particular information may actually be harmful to others. You should be careful about what you choose to teach others, and if no one else seems to have explained it, you should consider why. Other concerns include that people might feel as though you’re bragging or explaining concepts in condescending ways if you’re not sharing with humility, or they might assume you have an ulterior motive. Conversely, the writers assert that it’s selfish to seek ways to better your own learning and not consider how others could benefit if you were to share what you know.

They suggest developing a habit of applying this pattern early on, but I still don’t feel like I’m ready to offer anything substantial. If in the near future I learn something I identify as significant enough to record it, I will remember to apply this pattern as well and write an introduction to the topic that others might find useful.

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

Our team is currently tasked with creating an offline password-encryption service for the Ampath application.  After consulting with the people at Ampath, we made the decision to devote this sprint to creating test-applications that utilize the 3 encryption-libaries we discussed with them.  Unfortunately, our meetings were interrupted again this sprint; 2 of our 4 meetings were cancelled due to snow.  The days that we did meet, we spent a majority of our time coding and discussing our progress.

I was tasked with creating a test-application that utilizes the encryption libary bcryptjs .  Bcryptjs uses salt and an adaptive function to improve security and its implementation purely in JavaScript provides resistance to brute-force attacks.  I was the team member who suggested bcryptjs, when we compiled options to discuss with the Ampath people, so it felt natural for me to be the one writing the test application.

I did run into some trouble, though –  all of the resources and APIs for bcryptjs are tailored to JavaScript, rather than TypeScript.  This has been quite an impediment for me as I am not proficient in JavaScript, so I have had to learn a bit of JavaScript at the same time as I develop this test-application.  We are using WebCharm to work on development for the application, and WebCharm has a tool to compile TypeScript to JavaScript, and I have been looking into whether it is possible to compile JavaSvcript to TypeSript.  As I mentioned earlier, 2 of our 4 meetings were cancelled due to snow and I was without power for 3 days of the sprint, so I was not able to troubeshoot and push through this problem in time.  The issue of being unfamiliar with JavaScript, as well as installation and compilation errors, has also been afflicting my teammates – nobody was able to produce a working test-application by the end of the sprint.  Spring break is coming up and, while we are not required to work toward sprint goals during break, I intend to try and get myself up to speed with Angular, JavaScript, and bcryptjs so that, upon our return to school, I will be ready to make a meaningful contribution toward meeting this goal for the Ampath organization.

It definitely felt like all the teams had much more direction during this sprint.  We have begun implementation and feel more familiar with the application itself.  Our team has been using our in-class meetings more efficiently and I think we all have more of an idea of each other’s working-pace.  I feel a bit worried about the fact that my teammates and I feel unsure of ourselves within JavaScript, because I think it will be hard for us to have to learn JavaScript at the same time as we work on the Ampath application.  I’m hoping that Spring break will allow us to gather ourselves and come back more productive than ever.  I have still enjoyed working on the application, so far, and I hope that we can make some sort of meaningful contribution(s).

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

The “Learn How You Fail” blog pattern is about finding the ways in which you tend to fail or make mistakes.  The solution does not claim to save a programmer from ever failing (that’s not possible), but is instead about learning what tends to lead you to failure.  It’s part of drawing accurate boundaries around yourself as a learner: figuring out where you can grow and improve, what tends to throw you off track, and what may not be worth the effort of improvement.  The authors have a very concrete action step to help: using only a text editor, write an implementation of a simple algorithm, write all of the tests, refine the algorithm until you’re sure it will compile and pass the tests, then actually try to compile and test it to see where you failed.

Learning my weak points, where I tend to make mistakes, is a big part of my life as a gamer.  I try to improve my performance (whether that’s technical gameplay, strategy, tactical decision-making, etc.) with every game.  A very important aspect of that is determining what kinds of mistakes I tend to make.  Where do I overthink?  Where do I underthink?  What can I take away from losses, and when is it worthwhile to acknowledge but let go of a weakness (at least for a while) to focus on something else?

This apprenticeship pattern also resonates with me for a different reason.  I struggled through much of middle and high school with a mild nonverbal learning disability.  It took years of practice and tutoring for me to really be able to work through it.  An important part of that (or, I think, any therapeutic process) was finding points of failure.  I struggled to express myself in writing, especially meeting word counts for papers.  I had (and still have) difficulty breaking focus or task-switching.  Recognizing these things was the first step to improving them.

I think that learning how you fail is not just a skill that’s important for software apprenticeship and craft.  It’s an important life skill; at least, it has been for me.

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

https://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines

This week is another blog post on code review. Unlike the other article which gives suggestions, this article is an overview of code review. So, what is code review? This article defines it as a systematic examination of programming language source codes. It main intent is to find and fix mistakes overlooked in initial development phase. This helps to improves the quality of the software and also helps give critiques on the developer’s skills, which is always an advantage to improving their skills.

Why are code reviews important? We start with some statistics. The article lists that the average rate for detecting defect is 25%, the rate found through functional testing is 35%, and that found through integration testing is 45%. In contrast, the rate of defect detection through code review is 55% to 60%, indicating that code review is one of the most important aspects of code review. The article further goes on to list some important statistics on code review that I thought were extremely interesting. Before code review were introduced into the organization, it is estimated that about 55% of one-line maintenance changes were in error. After its introduction it decreased to 2%. After code reviews were introduced it was estimated that 95% were correct the first time whereas before under 20% were correct the first time. In an experiment, a group of 11 programs were developed by the same group of people. The group were split into 2 groups. The first 5 developed without code reviews. The remaining 6 developed with code reviews. After its release into production, the first 5 had an average of 4.5 errors per 100 lines of code. The other team had an average of .82 errors per 100 lines of code. Reviews were found to cut the errors by over 80%, which demonstrates the importance of code reviews. For this study however, I wonder if for both teams the individuals had equal experiences and skills. Were both sides equally weighted? An interesting statistics is the IBM Orbit project. IBM’s 500,000 line Orbit project used 11 levels of inspections and had only about 1% of errors.

Finally, we close off this blog post with a discussion on the main goals of code review. The article lists the main intent to spot and fix defects early in the development process. The second goal is to share ideas with other team members, so that everyone can share from one another. Sharing ideas then helps to maintain a level of consistency in the design and implementation. Finally, code reviews helps to build confidence in the stakeholder about the technical quality of execution. Code review overall, helps to create more confidence and reliability in the product, since as a team it is easier to catch bugs.

Overall, I choose this article because I strongly believe a good code review is always difficult to conduct. It takes practice to be efficient. This article emphasizes the importance of code review in software engineering, but still it takes time to develop the essential skills to be effective in code reviews. That is why I chose this article this week to emphasize the importance of code reviews and to learn about its main intents and advantages in software engineering.

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