Category Archives: CS-448

Record What You Learn

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Reflect as you work

So far, of all the patterns I’ve encountered, Reflect as you work seems to be the one that can be most easily tracked in a more concrete form! This is very interesting to me because many of the other patterns deal with almost abstract topics, whether it be considering how you yourself grow, or how to approach learning, it is usually hard to determine your growth, but Reflect as you work makes a tangible ‘map’ that someone can reference!

Reflecting as you work, to put it simply, is the process of making some sort of way to track what kinds of things you are doing. It seems like it could be a map of your skills and process, or it could be a variety of other things. But essentially, as long as you are making a way to visualize the types of skills you have, it is a way for you to go over each of those different skills and see if things are working, or if they are counterproductive. An example that was made was that if someone made a map of these skills, they can go over them as time goes on, and though this process or that approach might have worked in the past, it might need to be updated, or transformed all together.

Overall, this is something that I have never really thought about doing, but it seems incredibly helpful. No doubt, if I made a map of my own skills to reflect on, it would make it blatantly obvious to see which things I am lacking, or even better, which things to improve on. Already, I have an idea that my algorithm skills are a bit lacking, but I am sure that there are other things that I can improve upon as well. With the creation of a visualizer, I can much more easily reflect on the type of work I am doing, and overtime, I can also see if the things I am doing are good, or a bit flawed. I know for a fact, that if I looked back at my older works, I’d be complete horrified by some of the ways I fixed problems, and I know that in the future, it will be the same! This process of reflection is usually just internal, but with a concrete tool to use, it would probably be so, so much easier.

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Unleash your enthusiasm!

As I was going through the patterns, I came across the Unleash your enthusiasm. At first, I didn’t consider it too much, and took it at face value, and as it was explaining the pattern, I was frankly confused. From my perspective, it appeared like the author was trying to curb a bit of enthusiasm rather than nurture it, but there is actually more nuance to the whole pattern than it seems. Rather than the pattern being all about your own enthusiasm, I think that this pattern has much more connections with the team aspect.

The pattern does briefly go over this, but if you’re anything like me, it might have flown over your head, but I believe that this key fact is very important to processing the pattern. Mainly, if team morale is low, or if they aren’t as accepting, there are other ways to unleash your enthusiasm without compromising the team dynamic! I believe that out of the few patterns I’ve gone over so far, this pattern is the most grey! There is no definite answer to each and every team that you might join in, because there is just no ‘correct’ way to deal with people as a whole! It is very important to adjust your own standards, and thus, adjust your own enthusiasm on a case by case basis! Some people might be more receptive, while others might not be as receptive, but either way, it is important to find out beneficial ways to unleash your enthusiasm.

The pattern has a small action portion, but I believe that there are much more ways to show your enthusiasm! I think that if your team is not as receptive, you can show your enthusiasm by finding peers, or other like-minded communities! And if your team does welcome it, then there is no harm in showing the interest you have! Being able to find healthy ways to channel your enthusiasm will benefit not just yourself, but the whole team! As it even states, unleashing your enthusiasm will ensure that new perspectives aren’t missed, and with plenty of questions, everyone will grow! Staying silent would only be a detriment, because if you spot something that others might not, or if you keep questions to yourself, you won’t be able to reinforce ideas and also actively prevent yourself from learning! 

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Learn How You Fail

This week I read the Apprenticeship Pattern Learn How You Fail. The context of this pattern is that failure is inevitable. It happens to everyone eventually. If someone has never failed then they have either avoided pushing boundaries or learned to overlook mistakes. The problem given with this context is that your learning skills have enhanced your successes, but your failures and weaknesses remain.

The solution given for this pattern is to identify the ways in which you tend to fail and try to fix them. This pattern is not about self-pity or trying to make things perfect. It is about gaining self-knowledge about the habits and behaviors that lead you to failure. Once you become aware of the things that trip you up you will have the choice to either fixe these problems or cut your losses. You will need to accept that there are things you’re not good at or that would require a great deal of time and effort invested to fix the problem.

The action plan to help solve this issue is to use your choice of a programming language and a simple text editor to write an implementation of binary search in a single sitting. Then write all the tests you think you will need to confirm the code is correct. Before running the test and compiling the code go back and try to fix the mistakes you have discovered so far. After that run the code and see what errors are still there. Think about what you learned and how the errors could have happened when you thought the code was perfect.

I chose this pattern because as this pattern said, failure is inevitable. I have had failures in my software projects and I will certainly have more failures in the future. I want to be able to fix these failures by correcting my weakness and bad habits. Following the action plan given in this pattern will help me understand where I might have blindspots for errors. I also need to think about my past failures and figure out the common cause that leads to them. I think taking the time to do these will be a great learning experience for me and it will help me in my future career.

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

Sprint Retrospective #2

Hello blog!

Sprint 2 has come to an end and it is now round 2 of sprint retrospectives. This sprint was a little different from the first sprint, where our issues were similar amongst the five projects and we all took one project. Instead of one person having to take on all issues for InventoryAPI, they were able to take on frontend work, or whatever was available. This was a change based on what we discussed during the first sprint retrospective–that we should rotate around what we’re working on rather than being stuck in one project. 

The first two issues I worked on were for AddInventoryFrontend:

The following issue is what resulted in the greatest struggle:

I think what worked well was that in the previous sprint there was the suggestion of changing projects for teammates since they did not want to stick to one of the five projects the whole time, and teammates did swap where they were working. We were also able to help each other out well for a few issues since we all had similar things to change.

What didn’t work well was that we did not gauge well enough how to weigh the tests. We did believe that it would give us issues, but not to the extent that it did. The backend tests should have been split into manual testing and automated testing in Chai since just the manual testing was giving issues that took a long time to address. It was also an issue that almost all of us were making changes to InventoryBackend at once and getting errors from different sections that were fixed by one person but another person was not informed. 

To improve as a team, we could definitely communicate more on errors we have received and what we’ve done to fix them–as soon as we reach them. There are times when some teammates further ahead have gotten errors and fixed them somehow, but forgot what they have changed or updated. Doing so would be of great help for reference and also just good practice. We could also improve as a team by finding more time to work together, like the testing issues for example, since we were all in a similar position, and everyone collaborating on one test first would definitely push us forward. We all have busy and differing schedules so it has been difficult lately, but it can be an improvement.

On the topic of improving as an individual, I still have a fear of breaking things, so I should work on being less afraid of making changes. This sprint I’ve experimented a lot with trying to fix the errors I received trying to get my manual getApiVersion test to work. There were countless changes I made that ended up not making a difference, or would trigger the same error under different conditions. So while I did make efforts to be more “daring”, I could still use some more work on that. I think what scares me more is entering commands I’m not familiar with at all in the terminal, but that can just be an instance of reading more into them.

This sprint felt like a call to be more communicative with my team and also a call to communicate outside of the team with those who have worked on similar issues.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Find Mentors

Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Find Mentors

Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Find Mentors

Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.