The “Find Mentors” learning pattern from the Apprenticeship Patterns book is one that I definitely should have focused on earlier. This pattern is focused on find more experienced developers around you early and leveraging their knowledge and practice to take steps forward in your apprenticeship. Keeping with the master craftsman and apprentice theme, no apprentice will learn as effectively without someone to help them along their way and point out the unknown unknowns. The pattern recommends reaching out early and often. The only downside is rejection, which is easy to get over, especially if it is followed by acceptance at some point.

            In my computer science journey, I need to take this message to heart. Oftentimes, I try to do most of my learning on my own. I know I can have a kind of unorthodox way of teaching myself things, so I usually try to stick to myself when learning. I do quite often leverage the help/advice of peers though. Most of the people I’ve become closer with in the WSU computer science program I have worked closely with and either have some knowledge to gain from them or have some to share. While I realize working with peers is great, I definitely have fallen short on the front of getting help from those who are leagues ahead of me, like my professors. Looking back, I definitely should have attended more office hours and been in closer contact with my professors and advisors. That’s a goal I have for grad school, especially since I hope to be working as a research assistant, so this would be perfect.

            As the pattern mentions, it is difficult to get over the awkwardness of asking someone to mentor you. I’m not really sure how or who to reach out to in a professional setting, and I’m also not sure of what I would be looking for from a mentor. Although mentoring in school is great, it would probably be quite different than mentoring in a workplace. This is something I should look further into. Who can I reach out to as a mentor and what should I be looking to gain from them? If I can get the answers to questions like these, I think I would feel more comfortable filling the apprentice role.

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 learning pattern “Retreat into Competence” from the Apprenticeship Patterns book is something that gave me great comfort to read. The idea is that, when overwhelmed by your ignorance in the face of a complex problem or task, it can be beneficial to temporarily fall back onto what you know. This can boost your confidence, refresh your mind, and/or reveal relevant applications of the knowledge you do have. All of these things can make tackling your ignorance easier, or at least a little more manageable.

            As the book points out time and time again, it is very beneficial to accept what you don’t know and face it head on, but sometimes this can leave you stranded. There are many times that learning new concepts can feel like reading a different language or can make my eyes glaze over for 10 minutes before I realize that I haven’t been paying attention and need to start again. In times like these, I believe this learning pattern is very beneficial.

            For example, in the current course, I needed to learn Vue.js for the project. It’s a pretty straightforward task, but doing it was not very easy. I still wouldn’t call myself comfortable with Vue.js, but I definitely made some substantial progress in the face of feeling totally overwhelmed. When there were times that I didn’t know how to approach the sub-problems of learning that I faced, I found it supremely useful to take time off and look at other parts of the project which I felt more comfortable with. I retreated to things like looking over the backend API endpoints and practicing them a little bit before returning to Vue.js. These breaks allowed my mind to refresh as I could read over materials again with a better understanding and then practice the problems I was facing.

            I think the main difference in what I was doing was that I did not set blocks of time for my retreats into competence. When I returned to my real work, I sure felt more confident and had less of a sense of imposter syndrome, but sometimes these breaks were too long and help me back from real progress. I think measuring some finite time will help greatly in picking myself back up without being a hinderance to progress. There are plenty of times I know I will become lost in the capstone, as well as down the road in every project I work on, so I predict this learning pattern will be a very helpful tool.

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.

            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.

Concrete skills are something I feel as though I have an abundance, and simultaneously, a lack of. I guess this depends on what kind of skills are being referenced. If data structures, algorithms, or Leetcode is in question, I have some confidence. Not only are these topics I enjoy, but I also have solid knowledge in these areas. When it comes to automating tasks, or something more applicable to my current capstone situation, such as getting a strong grip on Docker and how each part of the project can be integrated with it, I feel… less qualified. 

The problem is, I think I can get to the technical knowledge I have, but only via the technical knowledge I am lacking. These barriers become apparent when working on a large project like the capstone. I look at the backend components, and I feel solid, even with little JavaScript experience. But picking up Vue.js makes me feel like I’m swimming in circles. There’s no point in making a backend without a frontend to support it, and I know this, but I’m not happy to confront it as it means abandoning my comfort zone for some crazy new frontend world.

          The learning pattern on concrete skills puts some much-needed pressure on me. It points out that I can have all the knowledge of theory and all the ability to learn quickly in the world, but if I can’t put real technical skills on a resume, I’ll never make it past the first round of hiring interviews. Rather than trying to find ways around the difficulties I face in everyday software development life, I should highlight my weaknesses and mark them down as learning opportunities.

          There has been a plethora of times in my CS career at which I confront a problem I have been avoiding and the knowledge I gain suddenly seems to apply everywhere. For example, last semester I learned the state design pattern, and because it came with some confusion, I dropped it quickly enough. Now, as I tried to make a Markov chain simulation in Java for my Math Modeling independent study, I realized a state pattern was a perfect fit. It took a couple hours, but I got it down and it feels great not only to have learned and used something new, but to know I have the knowledge to use whenever I need it going forward.

          I think my first focus should be some more surface level skills. As the chapter points out, the question, “If we hire you today, what can you do on Monday morning that will benefit us?” is one of the most important questions of the interview. If my best answer is, “Try really hard to get up to speed,” I’ll be job hunting for a long, long time. My new goal is to collect the skills I don’t know or feel uncomfortable with that are more common and focus my spare time on them. It will make daily life as a developer easier and take me further in my career faster.

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.

            In our practice with REST API backends, multiple times we ran into MongoDB usage, as the database we were using for the API was MongoDB. My only previous experience had been SQL/SQLite, so I wanted to know what the difference was. I came to find out there is a world of difference, in fact MongoDB is a NoSQL database (NoSQL meaning… well exactly what you would expect it to mean). I found an article – part of a MongoDB tutorial – from Guru99 called Types of NoSQL Databases, What is & Example which dove into the differences and usefulness of MongoDB and other NoSQL databases. Chiefly, NoSQL DB’s do not require fixed schemas, avoid joins, and are easy to scale, which is perfect for distributed data storage and “scaling out”, which is becoming increasingly essential in the CS world. The lack of schema is convenient too, as it allows for “heterogeneous structures of data in the same domain,” providing for great versatility. The other essential parts of NoSQL include it being non-relational and having a relatively simple API. The four kinds are Key-value pair based, column-oriented graph, graph based, and document oriented. Key-value pair based means data is stored in pairs (with a key and a value), which is optimal for large datasets and heavy loads. Column-based means that work is done on separated columns with values in single columns being stored contiguously, performing well with aggregation queries. Document-oriented DB’s (MongoDB is one) also function as a key/value pair, but in this, a value is stored as a document, which is stored in JSON or XML. It is not optimal for high performance or aggregate structures, like Key Value or Column Based. Graph based stores entities and relationships between them. Each entity is a node and each relationships is an edge, defining the relationship. This is different from relational DB’s inn that Graph DB’s are “multi-relational.” NoSQL DB’s commonly query with a key and a GET request. The CAP theorem is also important to NoSQL because it guarantees at most two out of the following three: consistency, availability, and partition tolerance. This is a key limitation of NoSQL DB’s. The last key to NoSQL falls on the concept of eventual consistency, meaning that changes to data on one machine must be reflected on other replicas eventually. Where the standard for RDBMS is ACID, NoSQL is BASE: Basically Available, Soft state, Eventual consistency. The article goes on the list advantages, disadvantages, and summarize itself before coming to a close. I thought this was very interesting to learn, as I can see how different DB styles can reflect the needs of a project or client story. I wasn’t sure why we were using MongoDB; I kind of took it as a given. But this reading broadened knowledge, so now, if I am able to build a REST API of my own over the upcoming break, perhaps I can find the optimal DB for my needs, or help me better understand future projects once I join the workforce.

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.