CS 448 Post #6

I finished the patterns I wanted to write about from chapter 4 and moved on to chapter 5, Perpetual Learning. Like the last few chapters, I to post about the first pattern of the chapter and then one of the last ones, so this post will be about Expand your Bandwidth. The focus of the chapter is on the topic of the lifelong journey of learning that is taken when you are an apprentice transitioning into a journeyman, which is a concept that was brought up in the first chapter.

The first pattern is an effective start to the chapter, as it is about how you can move on from lower level problems to higher level ones, and how you can expand your learning ability. The solution given to the problem is to find different ways to learn more than you may not have been using before, such as blogs, books, and other online resources. Because of how much technology there is in the world today, there are plenty of ways to find information online, and use different avenues of learning. I have found a lot of information online by either looking things up when I had questions or issues, or just by reading blogs and articles. I have looked online plenty of times when I needed help on something, especially computer science projects. I would search based on the error codes I was getting and try different sites to see if I could find a solution that worked for me. Using online resources have been very helpful to me for my work related to computer science, along with some other courses and activities.

I agree with the last paragraph of the solution that talks about deciding when you should start expanding, because while it is good to have all this information to learn from, you still want time to put that learning to use at software craftsmanship. You want to make time to continue working and improving yourself so that everything you are reading about and learning is beneficial to your work. I like that this problem brought more attention to the topic of this being a lifelong journey with continuous learning and development, while pointing out potential problems with obsessing over learning.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

The Long Road

For this week’s additional blog post, I have decided to look at the apprenticeship pattern “The Long Road”. In this chapter you, are aspiring to become a master software developer. However, your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. In this chapter it is advised that you should focus on the long-term. Value learning and long-term growth opportunities over salary and traditional notions of leadership. No one is so far ahead that you can’t match their skill level given the decades you will have to hone your craft. No business or technical domain is closed to you. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“This pattern is not for people aspiring to become CIOs or project managers, or filthy rich. Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey. And rather than counting the days to retirement, the craftsman will willingly and joyfully work into her final decades. We don’t want to give the impression that everyone must follow a single road (see Draw Your Own Map) or that this is the right road for every software developer (see A Different Road). Some people leave development permanently and become executives, testers, salespeople, or project managers”. (Dave H. Hoover & Adewale Oshineye).

This chapter was an interesting one to read. I liked how it talked about how this is a unique profession, and you will be doing it for some time if the passion is there. I also liked how it talked about how you shouldn’t jump ship right away if there is an opportunity away from software development. I don’t think that this chapter will stick with me out in the real world, however. I feel as though this chapter is geared towards people with a mind set of already leaving this profession.

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Find Mentor

There is always a good teacher behind a good student and a good engineer needs a good mentor who will help sharpen the skills and knowledge of that person. There is a saying “if you want to go fast, go alone. If you want to go far, go together”. Together with the mentorship, the engineer will become skilled at his job and has solid fundamental knowledge in this field.

By learning from the best, we learn how to become one of them. The apprenticeship will be supervised by a series of mentors who possess varying degrees of mastery. Every master used to be a student and no one is perfect. So keeping in mind that a master must be perfect is a misconception. It can be tempting to feel that way because they know so much more than we do. We must resist the temptation because we would not want to disillusion our mentor’s inevitable weaknesses.

The story about Dave finding his mentor shows us his journey. By sending out a random email to his mentor, Wyatt, he initially did not expect Wyatt’s response however Wyatt did. The effort was a payoff and he earned himself a mentor. What we could learn from this story is that we should not afraid to ask for help because sometimes what the other is waiting for is us asking.

Good mentors are not easy to find and not everyone is willing to open their arms and welcome us as amateurs. Plus, reaching out to someone that we do not know feels intimidating. However, the risk of being rejected is low but the payoff would be huge. Even though that person does not want to become our master but if we are consistent enough, what we could get back is a good friend. Besides taking in, passing along what we have learned from our mentors is one of the ways in which we can begin the transition to journeyman status.

How could we do that? One must wonder

Choose a tool, library, or community that has an active mailing list. Start small by signing up for the list but do not post any messages yet. Gradually, we will understand the values of the community and learn which of the subscribers are patient teachers. Seek out the members of this list the next time we see them and ask if they would be interested in providing us with some advice about the lesson they have learned. As I said above, we might get rejected but the valuable gift that one might earn is a good friend.

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

The White Belt

Summary:

The white belt pattern is about learning new things. We have mastered one language or area, now it is time to learn another because being an expert in one language or area does not allow us to grow and widen our capabilities. Pattern recognizes that sometimes despite working hard and giving our 100%, it does not lead to success. We need to recognize that different areas require different methods and approaches which may be drastically different than what we already know. Solution that pattern provides for us is that sometimes we need to clear our minds and start from zero.

Why this pattern?

Ever since freshman year I have been learning Java. First, we did intro to programming, then data structure and then testing in Java using Junit. Along the way I did a little bit of C, python for data analysis, and JavaScript, CSS, etc. for projects last semester and capstone. While working on this stuff I realized I kept using concepts from Java and messing up the code. Even while using mocha and chai testing framework, I kept using testing concepts of Junit. Due to this almost every time I had to revert the code, go read the proper documentation, come back and redo the code.

White belt pattern teaches us to re-assess our knowledge. It teaches us that as computer science students there is always knowledge out there, we can learn and help ourselves grow. As Elon Musk said, “Biggest mistake smart people make is believing that they are smart.” And to learn or acquire new knowledge and skills we need to start from square one. We cannot build a skyscraper on top of another skyscraper. We need to start below the earth, lay down a good foundation and then build on it.

White belt pattern also teaches us to be brave. I personally get nervous and anxious nowadays when it comes to learning a new language like python or JavaScript, software like docker or Kubernetes, services like Gitlab or AWS, etc. Pattern recognizes that sometimes it is painful to start from the bottom but tremendously crucial in accelerating the learning process. Mastering the new language or area is far more important than the short-term loss of productivity.

Where I disagree:

I might be nitpicking with the technicality of the word ‘unlearn’ but I do not think we need to unlearn what we know to learn new things. We do not need tear down a building to build another one.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

For this week’s blog post, I have decided to look at the apprenticeship pattern “retreat into competence”. The idea of this chapter is that you, a software developer, are beginning to realize how little you know, or that you have taken on a new challenge that is not working well in your favor, or your having problems with both. Due to you realizing how little you know you begin to get overwhelmed with your ignorance. The solution to this is to pull back and launch yourself like a stone from a catapult. You need to retreat or take some time away from your task to re collect yourself so you can come back to the task stronger than before. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.” (Dave H. Hoover & Adewle Oshineye).

This pattern is most relevant to people who have stretched themselves to far thin to be able to concentrate on the task in front of them anymore. However, by pulling back you do have the chance to launch more forward than you have been able to before. Note however this pattern does come with risks as if you forget to launch back forward or don’t have the desire to there can be repercussions. I liked this chapter as I am a person who can get stretched thin very quickly and am not able to bring myself to walk away for a bit to recollect myself. I liked that this chapter talked about both the pros and the cons of using the pattern. This will be something that will stick with me while I’m in the field because I am prone to being stretched thin and will sit there and still try to figure out the problem for hours. By walking away for a bit, I will be able to launch forward.   

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 2

What worked well:

Creating branches and merge requests was smoother compared to previous sprint. We were communicating more through comment section of issues leading to better documentation on Gitlab. We were able to come up with a system for merge requests where two people who did not create the merge request would review the code or changes and then third person would write the comments indicating the author and merge the branch into main. We were able to evenly split work and issues between team members so one person was not burdened with one type of work. Even with delays and having to learn new language and concepts we were able to complete the sprint.

We also created issues for contacting AWS and IAM team members (links below). We contacted both team members via discord and tagged them to comment section of the issues that contained questions we had for them.

Personally:

Most important one is that I did not limit myself to issues only assigned to me, I was able to go over work done by my teammates and keep myself updated with new code as well as the flow of the project. API was completed so we had moved on to Backend. I created data file for cooking methods. This was difficult in its own way because we were not using MongoDB for this project. After researching backend already provided, I was able to figure out that we needed to use axios and USDA URL to call data which would return list of cooking methods or cooking methods based on its unique ID. I then wrote a main function to check if I was getting list of all cooking methods and it was successful.

Even with some setbacks, I was able to grasp the basic concepts of the new JavaScript testing framework – ‘mocha’ and JavaScript testing library ‘chai’. Since the data file and paths were completed, I created cooking method test file. With help from Jim this one completed in a week. Npm test verified that all test files were passing.

Things that did not work well:

The spring break and two consecutive cancelled classes pushed us back a little and we had a little problem getting back in sync. We were still having problems communicating and setting meetings outside of class time. Merge requests started to slow down; partly because of introductions of news framework and library – mocha and chai, verifying others work became difficult; partly because merge requests started to fail due illegal naming conventions in commits. Issue names also needed to be more descriptive with more details in sub descriptions. Issues were also not properly linked to their respective epics. We were stuck in a lot of places where we needed help from professor, and we should have been more pro-active in that situation.

We also did not hear back from the IAM and AWS team.

Personally:

I wasted a lot of time researching and reading documentation on my own instead of working with my team or asking help from professor. Also lost a lot of time figuring out how to run npm and npm test. My merge requests kept failing I was not able to figure out the reason until Dahwal pointed out that I was not using conventional commits. I kept up with other people’s code but did not get an opportunity to write an endpoint myself.

Links to some issues:

Start conversation with IAM team

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/14

Start conversation with AWS team

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/15

Test file for Cooking Methods

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/general/-/issues/2

Create Data File for Cooking Methods

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/4

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

What worked well:

Creating issues was as expected; We were able to have open communication within the team and we were helping each other in how to create issues, connect them with epics, assigning team member for work and for reviewing.

We were helping each other figure out using git again. Dahwal introduced me to Github Desktop application which made the whole process of adding files, committing branch, push branch, creating merge requests, creating new branch and switching branches fairly simple.

Personally:

I had to revise scrum techniques and how to use the scrum board but with the help of team quickly grasped the concept again. I was quickly able to assign issue to myself in the API part of the project (links to the issues below). Most of the code was very similar to homework project from last semester therefore was easier to complete. I created src folder with path, responses and schema subfolders. I created schemas for view, product, shelflife and EvoError. I had to do good amount of research on OpenAPI and also on regex for patterns and format for different schemas within the schemas like min, max, temp, etc.

What didn’t work so well:

Figuring out workings of git took longer than expected. Brushing up on scrum and trying to use scrum boards proved harder than expected. Communication in the beginning was limited to only class time, which proved to be a big obstacle in this sprint. We also ran into a lot of problems with merge request, where they were unsuccessful due to being behind on commits, improper branch creation and not having a clean working tree in general.

Personally:

I had a lot of time used in git bash until Dahwal showed me GitHub Desktop application which really helped me save a lot of time. I had to do fair amount of reading of OpenAPI documentation in trying to figure out proper patterns and formats and even after that I needed to ask help from team members and professor. I also confined myself to only issues related to schemas and did not get opportunity to create paths for the API.

Improvements:

The most important issue we need to deal with is communication. We need to meet outside class time or at least meet via discord in video calls. We need to attach issues created to appropriate epics and understand how weights work and its assignment. We also need to communicate difficulties or problems we faced regarding issues in the comment thread sections instead of only using discord. We also need to come up with a system of approvals and merge requests so most of or class time is not spent approving and merging requests.

Personally:

I need to communicate with team members working on issues similar to mine so that we can set some conventions. For example, my schemas, branches, commits and merge request had slightly different naming convention than others. I also need to keep up with emails, discord messages and other notifications and respond in timely manner. Most importantly I need to make an effort to keep myself updated with issues I am not assigned to and keep up with the flow of code.

Links to some issues:

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/1

EvoError

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/2

Product Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/10

View Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/12

Shelflife Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/11

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

This last sprint I feel as though I went backwards. I am not too happy with my results. I spent the majority of my time working on semantic-release for the backend, frontend, and api branches, which I was only able to partially complete. Reflecting on this sprint, I should have absolutely given up and started work on something else. If I had given up someone else might have tried, and one of my team members might have had a different way of approaching the problem and solved it. If I were to look at this optimistically, its good that I messed up in class rather than in a real job. I was also able to write my findings in the issues I was working on so that the next student to take up the issue won’t be starting from scratch.

When working on the backend and api branches I was getting errors that did not make sense to me. I believe that there is something wrong with the repositories since that should be the only difference between the backend and api. I communicated this in my issue descriptions.

If I had to say something good about myself I really do like my issue descriptions. I am not sure if it will be helpful for the next students, but I really hope it is. I even tried to suggest possible solutions I was thinking of. I knew that I had to try hard to write good documentation because when we inherited this project from the previous group, there was little documentation for us to go off.

Something I think my team could have done better is to check in with each other more often. Sometimes I did not know what my teammates were working on, which is something you never want when working in agile production development. We slacked off on our daily standup meetings; if we didn’t I could have communicated my struggle with semantic-release. We could have made more of an effort to perform out standup meetings correctly, and I know that would have definitely helped me, and probably others as well.

Something that I could have done better relates to communication as well; I could have asked for help. I am not sure why, but throughout my struggles with semantic-release I did not ask my group for help at all. I did ask other people, but if I had gone to my group they would have known about my problem, been thinking about solutions, and they would care about fixing it since it directly relates to them. For whatever reason I kept believing that I could solve it myself since I got it working on the frontend, but now I realize this was a mistake.

I am not going to lie to myself; I did worse this sprint compared to sprint two. I think it is important to look at your own work objectively and critically in order to improve. Like I said before, I am grateful for this learning experience while still in college. I know that an employer will expect me to make mistakes, but I am not the kind of person to be satisfied producing sub-par products. I will do my best to learn from this experience and try to not repeat the same mistakes in the future.

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

Third Sprint Retrospective

Reflection on what worked well and didn’t work well

After meeting for the Sprint Retrospective with my team as a whole, I can say that the project is progressing well. The flow of group work has improved more since everyone works together much more effectively. The front-end and back-end development teams have made significant progress towards the project. The backend is pretty much complete at this point and the frontend is pretty much there besides a few minor things. We don’t have any major programming problems coming off of our last sprint, just a few potential bug fixes and cleaning up to do. Finally, after looking back at what we did, we made it easier to run the servers, since in the last spring we had to run things one at a time, however now it will run all at once, making it more efficient. During this spring we also cleaned up a lot of the coding and did some minor bug fixes. The backend is pretty much completed now besides testing. We just didn’t have enough time for it, it would have been something we would have done if we had another sprint left in the semester.

Reflection on what changes could be made to improve as a team

The team worked great. We still have everyone on their original development team. The ones at the back end remain at the back end and those who worked on the frontend stayed on the frontend team. Both teams for this spring, started to run out of things to do since everything was either completed or almost completed at this point, or there wouldn’t be enough time to work on a new issue. From the way the meeting went, everyone was able to communicate all the problems they had with each other, and no one was afraid to ask if they needed help. For our last sprint, I would say that there was such an improvement comparing to the beginning of the semester. Everyone was comfortable with talking out loud, helping one another, and overall, just great teamwork.

Reflection on what changes could be made to improve as an individual

From my point of view, the sprint was very good. Since we were running out of things to work on the backend, there wasn’t much to do. I worked on changing the port numbers for the backend to be between 10350 to 10399. Help change the datatype for household members. As well as combining docker-compose for the backend. I worked with colleagues Jared and Vien on these issues and other issues that we had on the backend since there wasn’t much left to do for the backend. Same as the Sprint, we were able to continue to learn more from each other. In this final sprint, I would like to say that overall, I became a better programmer/ developer, and this was a great experience to be able to work on large project in a scrum environment. I was able to become more confident in my skills and also became better with communicating with team members.

Combine docker-compose Backend
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/34

Update Household Members Datatype
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/api/-/issues/12

Update Backend Ports
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/36

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

With the conclusion of our last sprint, I’ll start by reflecting on the team performance. I think we went into this sprint pretty determined to get the backend fully up and running. Those of us who were involved in the backend development started working on trying to get the backend running in order to test each of the endpoints. Though the container was running, we were unable to use http calls to test any of the endpoints. We realized that there was a bigger issue than what we initially thought, resulting in us spending most of the sprint trying to get the backend server running. Another thing I would like to point out was that we had issues that were a bit too ambitious. We structured our sprint around the idea that we were going to have the backend running fairly quickly. And because of this we were essentially unable to do a good amount of issues because they required the backend to be running.

Reflecting back on my performance, I would say that I communicated well with the team at the start of the sprint. I discussed with my team during the sprint planning, helping the team structure what needed to be done for the upcoming sprint. At the beginning of the sprint, I assigned myself issue #31 in the backend, which was to test the removeInventory endpoint. I spent time trying to test with http calls but I was not getting any response. I then learned that we were having issues getting the backend to run, which explains why I was not getting a response. I think when it came to this point, I started becoming unproductive due to the fact that my assigned issue depended on the backend running. 

As a team, we definitely could have improved in the communication aspect. At some points during the sprint it was a bit unclear as to what everyone was working on. Most of our progress came to a halt by the issues with the backend, and I think we should’ve put all hands on deck to look into the issues. I do also think we could’ve come up with more manageable issues. For example, a task such as implementing keycloak into the inventory system is something that we can’t gauge the weight of until we actually start working on it. We could’ve come up with issues to get the backend running as opposed to things to do after the backend is running.

Coming away from this sprint, I will need to remember to communicate with my team, engaging with them to see if they need help with anything. I think I should’ve spent more time looking at the entire structure of the project to get a better understanding of how it should work, that way I can look into issues as to why things aren’t running. I will also need to consider setting realistic goals and understanding what things can be done in certain time frames. I still learned a lot from these past three springs and I look forward to applying this knowledge to my professional career.

issue #31: Troubleshooting the removeInventory.js endpoint which was unsuccessful due to the backend not running as intended.
issue #3: Bundle items-api.0.1.0.yaml to be used in the backend.

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