Week 13: Reading List

For this week, I chose to read ‘Reading List’ from Chapter 6: Construct Your Curriculum. I thought this pattern would be a good last pattern to read about now that the semester is ending. This chapter consisted of mostly patterns that are useful for post undergraduate stuff and things to reinforce in your head moving into your software career. So, for the context of this pattern, after becoming proficient in your first language (another pattern), you begin to look around and see the vast sea of info. I found this relatable as there is so many different languages in software programming and so many different technologies that accompany it as well, there is a lot to learn. However, with that in mind, I think that just makes me wanna learn about a lot of the different languages and technologies since software development is so vast.

For the problem of the pattern, you are unable to keep up with the amount of books you need to read. I thought this was kind of a weird problem, if you reach this problem, you probably aren’t managing your time well and need to readjust your curriculum in my opinion. However, the solution tackles this problem similar to what I was thinking, managing your time better. The solution is to maintain a reading list, this isn’t to only manage the books you read but also to reflect on past reading habits and you can use this info to construct a path on what to read next and what to focus on. I thought this was pretty clever, I wouldn’t have a reading list for that purpose, I would just use it to manage my reading habits. The solution does come with caveats though, it’s difficult to implement this pattern without having a deep understanding of your topic in order to figure out which books to read and the order. Ultimately, I think this pattern relies on having a deep understanding of what you want to learn about and what rabbit holes to go down in order to become more proficient at those topics.

For the action, you obviously create your reading list, however you keep it under source control and up to date. Pretty simple action to do, it’s just finding out where to start and what to read that is the hardest part of this pattern.

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

Sprint Retrospective #3

This Sprint was the last Sprint for this semester and with that being said, there is still more work for the next team to come in and work on. During this sprint, we worked on both the back end and front end. I was responsible for building the test, however, there was not much to be done due to the complexity of the test case. T has helped me during this sprint as well, as she has always done with the other Sprints. It would take me all day to admire her effort in this project. She not only does such a good job but also is supportive of other teammates.
Since there was not much to be done in this project test case due to the completion of this project. I had switched to the front end to work. The point is to make the submit button retreat data whenever it is pressed. It took quite a while for me to figure out how to get that button to work. It was not tricky but since I did not enough knowledge of HTTP calls, so it was sort of a struggle for me to find a solution. However, T and I worked out and fixed the problem by using the right method. We also added a function to download CSV files for the front end. This method is used to call back to the backend for retreating the data and then downloading the data to the user’s computer.
During this last sprint, we worked well on most of the issues that we listed in the first two sprints. We finished them on time and perhaps most of the issues were finished before the Sprint Review. However, that does not mean the work is finished. Since this is the last sprint, the improvement in working as a team and communication has been developed significantly. We improved ourselves a lot in this one and there were barely any conflicts that happened.
Besides all the improvements that the team had improved in this Sprint. Some new issues had appeared. Since this was the last sprint, we understand that every team member has projects and finals to study and work on. Therefore, some of us did not spend much time working as much as we had hoped. But that was understandable by each of the team members.
In addition to the team, there was me. During this sprint, I honestly did not contribute much as I had hoped. I was all over places from different classes, exams, and my internship. I managed time badly and I could have said that I was burned out. If there is anything that needed to be improved, I would say it was me. I need to prioritize some tasks over others such as choosing which tasks need to be finished first. I failed to do that in this sprint which led to many things that had not been done as the deadline came close.
Since this is the last Sprint, I have learned what I need to improve and what I need to change. I would need to manage tasks more carefully with more attention. I have improved a lot in working with my team and got better over three sprints to have better prepared for the professional world.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/36

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/generatewcfbreportfrontend/-/issues/15

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

Nurture Your Passion

This week I decided to right about Nurture your passion. As I finish my academic career and move into the professional world, nurturing my passion is something I will be conscious of.

The problem laid out in this pattern is that the craftsmen is working in a workplace where his passion is stiffled. I think that everyone will experience this. For my part, I have gone to long team meetings that felt like they could have been half the time. And that is one of the best problems to have. Work places can be toxic, or there could not be oppurtunities to learn and grow. With this problem explained, Dave sugguests that the craftsmen should look to nurture his passion outside of his job.

There are a few ways to do this. One is my making interesting side projects or Breakable Toys. I could see this being a nice change of pace, where I could focus more on learning instead of meeting the deadline. Another solution is to meet kindred spirits. Dave suggests meet up groups. One thought I have here is that if I am coding for six to eight hours, five days a week. I may not feel like building breakable toys, or going to meet ups. I like writing code, but not everyone has time to write open source in addition to working a full time developer job.

The action Dave recommends is to write three positive ideas down to bring up at work everyday. And bring one up if things turn negative. Finding happiness and positivity at work is important for anyone. So I think is is a very meaningful pattern.

I think the best advice here is that if the craftsman finds himself at a firm that stiffles his passion, it is time to move on. This piece of advice is very relevant now as we are in the midst of “The Great Resignation”. I think finding a job that a craftman can at least partially nurture his passion is very important. We spend so much of our lives at work. So it is very important to find happiness there, if possible.

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

Apprenticeship Patterns: Chapter 4 Part 2

Sweep The Floor

A common stereotype amongst movies and literature when an apprentice first begins their work, they are handed a menial task and told to perfect it. Often sweeping or “wax on, wax off” from the movie Karate Kid, the task being grueling and numbing in a sense. This task assigned to you wasn’t to demoralize you or just give you something to be distracted by, it was to get you ready and perfect a skill by practicing frequently.

As an apprentice you are nearly always going to be on the lower rung of experience and will find yourself doing work closer to your skill level. With programming the metaphorical broom might not be clear, or obvious. Instead of waiting for instruction you should take the initiative and volunteer for things. Take a task that you can complete or learn to complete and lighten the load of others.

This won’t necessarily seem like sweeping the floor but in a sense you are taking the tasks that will help yourself and the team you are aspiring to become an essential part of. I understand this aspect fairly well absorbing this concept through admittedly far more media than I should have, but I agree with this pattern pretty much wholeheartedly. Being apart of the group and not being as skilled as them is fairly demoralizing, but taking the lesser tasks can still make you a vital part of the process while you make the effort to become as skilled as your group members.

While learning and developing your skills you do have to step back and learn the basics. Focusing your skills and learning the essentials is integral and necessary. It’s also usually the tasks that most don’t want to work on. Mind numbing maintenance and formatting is one task that higher level workers dread maintaining. These tasks are necessary and vital to the projects success and someone needs to do it. You might as well put yourself into the problems you can solve and along the way you will learn things vital to improving the project and increasing your skills. To learn the basics is to master them. Sweep the broom before you place the first brick of the new structure. Stack bricks thousands of times before you can build a sturdy wall. This pattern is to take the mindset of the novice within your group and how as an apprentice you can learn while also helping out your group.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 4 Part 1

Find Mentors

When first understanding how you learn, and the general experience of how human beings learn, you’ll find yourself in a situation where you want to learn something, but you don’t know how to go about learning it. You take your first stab at it and find that you are learning some things but not learning constructively. You blunder around accumulating random knowledge and at some point, you might experience some success and get lucky. But more times than not you’ll blunder around and this effort might demoralize. The fault was not in your but your methods.

Mentor-ship and finding mentors is critical to learning something more specialized within your own skill set. This apprenticeship pattern perfectly describes an issue that I have frequently run into myself. It describes this path as exploring a blind alley, and this is an apt description. During my first sprint during my computer science capstone I made an effort to try and learn HTML. I looked over some example code and learned generally how to write it but fundamentally I didn’t understand how to structure it. I was blindly exploring the learning process and was failing.

I felt how I was failing and I knew I needed to reach out to something far more similar to a teacher. Some see the name mentor but what is a mentor but a highly skilled teacher. Yes of course there is more to teaching than just knowing the skill but they have the knowledge of learning the skill you are trying to and the path that helped them succeed. You need to find yourself a path that has been traveled by a human instead of blindly traveling that avenue.

I sought an actual HTML course that is commonly available in YouTube format and learned in a structured manner from a person who understood it as a whole. Now this isn’t to deter you from learning something new without a mentor as you do need the ability to learn new things without help, but something completely foreign to you requires a teacher. Mastery of a subject will require a mentor. Both require a desire to learn and to realize when you should seek other’s help.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Sprint #3 Retrospective

During this sprint my previous work in getting the front ends linked to each other for testing would finally be quickly integrated for the two front ends addInventory and checkInventory.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkinventoryfrontend/-/issues/6

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/addinventoryfrontend/-/issues/8

While figuring out how to properly implement it into checkoutGuest front end, it was found to be not properly set up like the other projects and would require setting it up to be the same as the other front ends in terms of their vue formatting.

I was spending the majority of my time learning more about vue and how to set it up within an already created project and managing the new changes when I decided to take a peek at the previous branches as the way this project was currently setup didn’t match the others and I considered the possibility of something in development perhaps being left behind.

I found a branch called updatedFunctionality, and in it was a project formatting exactly like the other front ends and I knew then and there that we needed to integrate it within our current branch. My professor recommended that before we merge it into the main one to do a merge into a test branch to simulate what it would be like between the two and see what conflicting merges we would have to deal with. He also preferred that we didn’t just erase the main branch’s development as to not leave out the work created by previous students.

I successfully merged the two branches and got approval to merge the main and this branch and deal with the conflicting merges of which there was not too much. With some help from my fellow group member Fadi Akram the branch would be merged and my I would implement the changes needed to connect this front ends to the others like I did at the start of the sprint.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/11

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/checkoutguestfrontend/-/issues/10

Afterwards I would spend my time testing and working on the user interaction portion of checkoutGuest as it involves a point in which the user of this station will be scanning or manually entering in student ID’s to record items being taken out of Thea’s Pantry. Working on previously established work from Professor Wurst, I modified the user interface to accept ID from both keypresses, scanning, and manually entry by keypress in the same format as it being scanned. I also made sure to prevent future issues by preventing negative values being submitted and locking the text box for user ID when a proper value is entered to prevent further changes if there was a mistake made. I also added a clear button should the user desire to make a change as they have entered the ID, should it not match the one they have typed.

There is still some modifications that should be made to the interface like allowing during manual entry to delete the desired values and modifying the value of the idnum variable to match. It would be just checking for the backspace or delete keypress and modifying the value, but it would require testing and I can’t say I am certain if that would work perfectly just from that idea.

Overall this was a far more productive sprint for myself than the previous ones. The efforts made in the previous ones helped me to succeed in this sprint thanks to understanding vue and html better.

During this sprint my team was primarily focused on fixing the backend and had I finished my work sooner I would have been working with them as well trying to debug it. My team did come together well to focus on that issue but our ability to work on testing the backend was limited by it not being able to startup and work.

I did struggle with some of the JavaScript coding while refactoring it a bit and that is definitely one avenue I need to take to improve on my own skills. It’s fairly similar to other languages I have used but some of the syntax did in a sense fight back against me, like how JavaScript handles operands with their weird truthy and falsey system. While creating conditional checks some would still pass through as it was still considered “truthy”.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Breakable Toys

Summary:

I have chosen breakable toys for this weeks Apprenticeship pattern. Breakable toys pattern is about learning through our mistakes. The pattern explains that we work in a high pressure jobs and environment and understandably success is expected or at times even demanded of us. However, pattern also recognizes that failure is the key to success. By failing and discovering our faults, our flaws is a crucial step in the process for us to grow, learn and build on our experience which all in turn eventually leads us to succeed. Pattern emphasizes the importance of step one for any work we are attempting to complete. First step needs to be just that, the first step – a simple README file in Gitlab with a rough structure what we are working towards is as important as every code we write and every feature we experiment on.

Why this pattern?

This is one of the most important if not the most important Apprenticeship Pattern I have come across. There many external factors affect the work that is being done like time restrictions and financial restrictions which prove to be nothing but a hindrance. This year, I had to keep learning new languages like R, python, JavaScript, mocha and chai and services like docker, R studio, VS code, Jupiter, anaconda, etc. I cannot count how many times I have been stuck on some piece of code, spiraled down because I knew failure was unavoidable and start feeling the paralyzing fear take over.

Knowing and remembering that failure is as important as success in a learning environment has helped me lot. Organizing my failures as a software developer proved to be as important as completing building our backend because It’s not wrong to make mistakes, it’s wrong to repeat them. Pattern suggested that we should work on our smaller projects because it gives us the time to learn our tools and a safe environment where we have our freedom to fail. I have written simple codes for calculator and tic-tac-toe in python. Deployed a simple ‘Hello world’ website using AWS. To quote Thomas Edison, “I have not failed. I have just found 10,000 ways that won’t work.” The trial-and-error process has immensely helped me grow and then further implement that knowledge in my projects.

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

Sprint 3 Retrospective

Issues Evidence

Issue:: HTTP Get Range of Questionnaire Submissions

This issue was added to this sprint to complement the client specification. The main idea was to create an endpoint to query the questionnaire data set and return values within a specific date range.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/issues/19

Issue:: API: determine input fields for Guest info and QS collection

This issue is vague and shows that we have much to improve on naming issues. I interpreted this as looking at the API calls and parameters to make sure they all meet client specification.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/issues/15

Issue:: testing API for getRange

This was done in multiple levels. At the backend with dummy values and a working clone of the app designed to emulate the android calls.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/issues/17

·  Reflection on what worked well

This sprint started well we had a better understanding of the agile workflow. Communication was key to many of the problems we had to tackle. We meet a few times online outside classroom to clarify definition on what needed to be worked on. We shared our work during these sessions and worked out the logic for a few methods. The attendance was important, and participation help us be successful this sprint. Not everything was as smooth as it could have been, but we did finish the sprint with working elements of this current sprint goals. One very important element that was added to this sprint was the mock app feature which allowed for integration testing. This helps because it shows the API will work not only in a web page or web app but also in an android environment without any unintended consequences. I can attest to integration problems because in my robotics project different components networking with each other would behave strangely in ways we didn’t expect or understand. So, checking communication was made successfully with no hick ups is a big plus.      

·  Reflection on what didn’t work well

We still struggle to give tasks meaningful names that everyone understood. At the end of the sprint finals and projects kept most of us busy. Not the entire group meet during the off-class meetings. We worried so much about having something to show that we perhaps missed out on the opportunity to write better documentation to assist future developers. The API version correction was not completely done because we lacked understanding of the CI environment and other school commitments kept most of us from dedicating a huge amount of time to it.   

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

We could have used more time outside the classroom. We did meet more often and had more meaningful interactions than the previous 2 sprints but there is still a lot of room for improvement there. Communication on what each of us were working on could improve. Sometimes we would not work on things because we thought they were being worked on or started working on things already done. Some of us merged the work to main which is fine, but it caused some conflicts trying to merge the branches back. Some issues were not taken or if taken not assigned causing confusion.

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

I could have dedicated more of my time understanding the technologies and concepts. Although I gained a great amount of knowledge on JavaScript, I still don’t have the adequate know-how to be proficient in the language. Another thing that I could have done better to help would be to dig deeper in understanding the GitLab CI/CD environment and its automation. This lack of understanding prevented me from accomplishing some goals I wished I had completed this sprint. I wish I had taken less classes this semester and dedicated more of my time to this class. A few times I obsessed over parts of projects where I was stuck and wasted time without meaningful gain. This happened less often than other sprints because I did make note of this bad habit, but breaking the habit was more difficult than I thought. The few times I overcome this habit and broke away from the infinite loop of no success I was able to stumble into the solution later because my mind was uncluttered and clear. One of the goals I have for myself in the future is to never dwell or obsess a problem.  

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

Blog 6: Share what you learn

The context given here is that You have been an apprentice for a little while. You know a few things and people are starting to look to you as a source of knowledge. Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman, you will need the ability to communicate effectively and bring other people up to speed quickly. A good way to prepare you for that is to develop the habit of regularly sharing the lessons you have learned. This may take the form of maintaining a blog or running “brown bag” sessions amongst your peers. You can also make presentations at conferences or write tutorials for the various technologies and techniques that you are learning.

The books highlight that Being part of a community of individuals where both learning on your own and humbly sharing that newly acquired knowledge are valued is one of the most powerful aspects of apprenticeship. It makes otherwise-esoteric fields of knowledge suddenly accessible, and provides apprentices with guides who speak their language. That being said some lessons should not be shared, and it’s important to keep in mind that there is an ethical dimension to knowledge. Before sharing something, consider whether that lesson is yours to share. It may be a secret, or it may harm others. Things that seem obvious to you because of your current context may in fact be your employer’s “secret sauce” and it is all too easy as an apprentice to overlook the consequences (legal, financial, and political) of sharing that knowledge.

I can personally relate to the content in this pattern because I have worked for 2 years as a tutor for introduction to programming class (java) and it has helped me on so many levels. I remember my first instinct was to decline the job when the position was first offered to me. But then I took “a risk” and started working as mentor and all of a sudden, my understanding in the class material got better. I got comfortable sharing knowledge in an effective way, and I got great public speaking skills

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

Blog 5: Use Your Title

The context given here is that as a result of your dedication to learning, you have been hired or promoted (formally or informally) into a position with a title containing words such as “senior,” “architect,” or “lead”. The problem is then that your job title doesn’t match what you see in the mirror. When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description. The solution suggested is not to allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness. Use your title to gauge your organization, not yourself.

Impressive titles and responsibilities do not indicate that your apprenticeship is over. They only serve to remind you that there is a shortage of craftsmen in our industry so we should not be fooled by an impressive title. Another variant of this theme is informal versus formal titles. For instance, you may have grown into a position of authority on your team, despite your formal title remaining the same. These informal titles can be hard to ignore, because they are constantly reinforced by your peers, even if they conflict with your self-assessment. During these times, your connections with your mentors and peers will be critical to keep you grounded in reality.

I was really glad to see that the title subject was tackled in this book. So many times, I have found myself in jobs doing way more than what my title said sometimes even doing something completely different. In my current position, I am doing my job and some part of the data analyst job and at first, I got slightly annoyed but I have now realized that I would try to learn from it as much as possible rather than complain about it

I also really liked their action plan which is to Write down a long and descriptive version of your job title. Make sure it accurately reflects what you really do at work and your skill level. Keep this updated, and from time to time imagine how you would view a stranger who had this job description.

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.