For the next apprenticeship pattern that I would like to discuss, my choice was to do the one in the text book entitled “The Deep End.” This pattern was similar to a previous pattern that I have discussed in that it relates to a time when a beginner in programming is preparing to enter the real world of job opportunities. In the other pattern, I learned ways in which I should try to show that I am qualified for a new job if I do not have much prior experience, if at all. A lot of times, employers are looking for candidates who show that they have the skills necessary for the position based on many things (primarily prior experience or certification), but sometimes what is needed is more than that. Sometimes what is needed is the willingness to try more than anything else. For this pattern, the book discussed how to motivate me to dive off the deep end and get the job I want not just the one I think I can handle. If my enthusiasm and my will to excel and learn at the job remains strong, I should not have to concern myself as heavily with how well equipped I am for the job in the first place. I purposely decided to review this pattern because of what is going on in my life right now. I have been setting up job interviews and phone calls recently to try to get jobs after I graduate. In most interviews I have had, my background has been an issue even if the employer does not seem to think so. I am thinking too much about whether I will be able to even do the job if I get it rather than trying to get it as best as I can and then seeing what I can accomplish from there. The book explains that the solution to this problem is to reach for that opportunity even if there is the possibility that it could lead to failure. It states that “waiting until you’re ready can become a recipe for never doing a thing. So when you’re offered a high-profile role or a difficult problem, grasp it with both hands. Growth only happens by taking on the scary jobs and doing things that stretch you.” My solution would be to do just that. I am going to try to get involved in the opportunities that I have been hesitant about pursuing. The risk of failure is often overemphasized and crippling to anyone who tries to find their opportunities especially in the beginning of their journeys. I need to stop weighing the risks so heavily and quite literally “dive into the deep end.”

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

            I was looking for some materials to supplement the work we are doing in Software Quality Assurance and Testing (CS-443) and I came across a nice article from ReQtest entitled What is Boundary Value Analysis and Equivalence Partitioning? I found this to be a good supplement to our in-class activity on boundary value testing, summarizing some of the key ideas. It helped me nail down the concepts and is a nice, short resource for me.

            The article begins describing boundary value analysis. It highlights it is focused on, well, the boundary values, as, “for the most part, errors are observed in the extreme ends of the input values.” This directly relates to the topics covered in class, but is limited as it is mostly focused on single inputs, rather than testing for multiple inputs like we did in class. The article then provides a couple example for an input domain of 1 to 100. The exact boundary values would be 1 and 100, just below boundary values would be 0 and 99, and just above boundary values would be 2 and 101. This seems similar to robust boundary value testing. However, the article doesn’t consider multiple inputs, so there is no noting of nominal inputs or the single fault assumption, or worst-case boundary value testing. Nonetheless, I find it is a concise way of summarizing normal boundary value testing.

            The article then goes on to describe equivalence partitioning, which is the division of, “test input data into a range of values and selecting one input value from each range.” This goes more towards describing the domain of input values and somewhat alludes to physical and arbitrary boundaries. These are not described within the article, but are worthy of noting. The example given is again in the 1 to 100 acceptable range. The article states that one valid input class is anywhere within the 1 to 100 range, another is any value below 1, and the last is any value above 100.

            Together, these two topics do well to sum up the different ranges of inputs for boundary value testing, with equivalence partitioning touching on a little bit of worst-case boundary value testing. Overall, I thought this was a worthwhile article and was helpful. I can see myself returning to it when I actually am writing tests. Boundary value testing is quite useful in many cases, so it’s a topic I’m happy and interesting in learning more about and practicing.  

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

            The pattern called “Create Feedback Loops” in the Apprenticeship Patterns book focuses on finding ways to identify areas of knowledge which are lacking and how to overcome them. One point which I found summed up the learning pattern quite well was, “An apprentice probably shouldn’t work on not making mistakes early as much as they should be working out how to identify the mistakes you make.” In the context of feedback loops, this means that rather than skimming over the areas of understanding which are lacking, find someone to support the necessary learning and identify/correct mistakes, as this can provide a solid platform for learning. As for the areas which a “white belt,” such as myself, feels comfortable in, there should be people to feel comfortable with going to for review or correction. Essentially, you don’t know what you don’t know, which can be a huge hinderance to progress.

            I find this to be a particularly tricky learning pattern. Not that it’s hard to understand, but finding the proper resources and mentoring is not easy, especially during the current semester full of social distancing and online isolation. I think I’m very open to being corrected or shown a newer and better way to do the things I’m already good at, but finding someone to help me in the first place can be a struggle. I totally agree with the premise, but building a feedback loop is no easy task.

            I think incorporating this at a college level is definitely the best place to start, and I’m happy to be continuing my education at grad school as it gives me more time and opportunities to receive feedback in a lower pressure setting. Sure, my grades depend on my performance, but I don’t have a team/company relying on my work, and I don’t rely on the quality of that work for my well-being and forward progression as a professional. Also, having peers to work with and derive feedback loops from is better for starting as we are equals, rather than getting feedback from higher-level developers or something.

            I think one way I could implement this into my current learning is in the capstone. Perhaps there would be some time to do pair programming. I think this could be super helpful as it’s similar to working through an example problem, but I also have the support of a peer who could share knowledge and provide insight on how my train of thought is flowing, whether positive or negative. I’m happy to incorporate this pattern into my learning.

From the blog CS@Worcester – Marcos Felipe's CS Blog by mfelipe98 and used with permission of the author. All other rights reserved by the author.

Our first programming language can be similar to the first language we learn to speak or our native tongue. What this pattern talks about is to first pick a language and start to master that language by practicing and solve problems in the specific language. It also talks about having some mentor or asking questions to someone more experienced so they can help guide you along the way of learning the programming language, but also at the same time not becoming dependent on them to solve your problems.

I found this chapter to be very interesting because whenever I think about coding and solving problems, the first syntax or code to use that comes in my mind is Java. The reason for this is because it is my first programming language that I learned and I have the most experience with it. This pattern has led me to confirm my belief that we need to first become better programmers in a specific language. A lot of people try to jump from one language to another and think it will be more beneficial. However, what this results to is not thorough understanding of a programming language, and more simple knowledge of each one. It is much more efficient to pick up a specific language based on your preference, and broaden your knowledge with it. Try out different problems to solve and keep on practicing. Once you feel you are at a level that you are content with, then move on to another language and broaden your knowledge about different types of programming. If you started with an object-oriented language, then learn about a functional programming language. Also, what this does is help moving from one language to another a lot better as well as understand the differences of each. With more experience in languages, we can start to see what languages are better for certain tasks and can examine advantages and disadvantages. In essence, the goal of this pattern is to take things a lot more slowly and in a more efficient way. It will be much better taking time to learn critical details then having front level knowledge. Overall, be open minded when it comes to languages as well and don’t just stick to one and decide that is it.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.