Find Mentors

            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.

Retreat into Competence

            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.

Boundary Value Testing & Equivalence Partitions

            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.  

Create Feedback Loops

            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.

Sprint 1 Retrospective

This was easily accomplished by everyone. This was learning the issue board.

This was us choosing a Scrum master. We decided on Tim Drevitch.

This was our review of the LibreFoodPantry website which was to get an idea of LFP.

This was creating the requirements for the GuestInfo EventSystem, in which I linked resources and described the requirements.

This was the most time-intensive task. I linked multiple tutorials for Vue.js, all of which I completed. This encompassed most of the first two weeks of the sprint for me.

This is the repository I made which contains all of the simple examples we created for small Vue.js, Express, and MongoDB applications to pull from.

These 3 activities are encompassed in the GuestInfoSystem section of Thea’s Pantry. There is a repository for frontend and backend work. It has basic files for each which is taken from the WNE example.

This is created a sample Vue.js project, which is on the example work repository.

            Overall, I think we worked quite well as a group, and I would attribute a good deal of it to how well our sprint planning went. We were thorough in going through topics which we felt we needed to cover and created individual cards for everything so that all of our tasks were tangible. Furthermore, we were fair in our division of labor and honesty in what we wanted to do while still taking on enough responsibility as individuals to support the team as a whole. What worked well towards the end of the sprint was also when we focused on what we hadn’t yet finished and allotted the work evenly. Not only this, but we had also made enough progress that I found it to be helpful to have a sort of progress report session in class. We were going through with our Scrum meetings daily, but it was more in-depth, and we were able to articulate what we had done and where our progress was taking us. This was very helpful and perhaps we could incorporate this into our Scrum meetings, allowing us to have a better stream of communication.

            There weren’t many things that didn’t go well for us, but a few include some lacking communication at times and a lack of due dates. As I articulated previously, I was only able to notice any lacking communication when we did communicate better. It wasn’t that our communication was impeding our progress, but it definitely helped to have a clearer picture of the project as a whole when each of us was clearer about our individual progress. As far as a lack of due dates, we became a little rushed towards the end of the sprint since we spent a little too much time completing our learning tasks. If we set limits on these tasks, because they were more open ended, we could have gotten some of our more rushed late sprint activities done faster.

            As far as changes to be made as a team, I would focus on making the changes I stated previously. To get better communication, we should make better use of the cards on the GitLab issue board. Each card should have documentation of information learned and progress made it on it. This makes it much easier for everyone to read the cards instead of having to check Discord or wait for the in-class meetings. Also, we should start putting due dates on the cards for our own sake. This would keep us on track better.

            Individually, I should plan out my time more. I was feeling lost with Vue.js so I spent a lot of time on it. I got into stuff that, later on into the sprint, I found out that I didn’t even need. I need to be better at setting due dates and creating more incremental tasks. I took a couple longer tasks and rather than breaking them down, would try to accomplish a couple things at once which could have been subdivided. This, along with better documentation on the GitLab cards, should put me in a better spot for success in the next sprint.

Concrete Skills

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 confidence. I enjoy these topics and 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, 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. I’m not particularly happy to confront these limitations it as it means abandoning my comfort zone for some crazy new frontend world.

          The learning pattern on concrete skills puts on some much-needed pressure. I can have all the knowledge of theory and 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 any hiring interviews. I should highlight my weaknesses and mark them down as learning opportunities instead of finding ways around them.

          There has been a plethora of times at which I confront a problem I have been avoiding and the knowledge I gain seems to apply everywhere. 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 for my Math Modeling independent study, I realized a state pattern was perfect. It took some time, 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.

Apprenticeship Patterns Introduction

            In reading the introduction to the Apprenticeship Patterns book, I found a great deal of the material to be interesting. Looking at the learning curve of a software developer in the style of the apprenticeship to journeyman to master stages provided a much better framework for progression than I had seen before and putting it in these simple and recognizable terms makes a career feel more tangible. Beyond this, I was quite interested in a couple of the chapter introductions. Chapter 4 focuses on “Accurate Self-Assessment,” specifically the concept of complacency of being a big fish in a small pond. I do a fair amount of reading online about careers in software development, mainly focused on entry-level positions, competitive internships, etc. It stands out to me that many people in the field push and push to start at the highest level that they can, which makes sense in such a competitive environment. Whether this means working at a FAANG company or maximizing total compensation as fast as possible, the focus tends to shift away from becoming the best the one can be and instead on landing in what is generally perceived as the best environment/position. While I can’t say this is at all unreasonable as people have themselves to worry about and not just their software development skills (I know I definitely have this focus too), it can come to the expense of their long-term career. By this I mean we find a place where we want to be in the present and allow this to perpetuate for however long, not to the detriment of our skills as a developer necessarily, but not really broadening our skills either. The book elaborates on this, saying, “You must fight this tendency toward mediocrity by seeking out and learning about other teams, organizations, journeymen, and master craftsmen that work at a level of proficiency that an apprentice cannot even imagine.” This means that getting comfortable is easy, and for most, it’s preferable to be within one’s comfort zone. Getting outside of our comfort zone is so valuable though. I think it’s inevitable to play the game of comparisons with one’s immediate peers, even at our level of being students. It’s saying, “Well, I could go on and learn x, y, and z, but I’m doing better than most of the class at the current topic, so I don’t really need to.” It’s a trap I’ve definitely fallen into. But our class, our little sector of the computer science world is just that: a tiny little sector. It’s more valuable to focus on what we don’t know than what we do know at any level of skill. I love this concept, intimidating as it is, and it provides great motivation.

MongoDB and NoSQL Databases

            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.