Author Archives: Eric Nguyen

Sprint 3 Retrospective

As many of the others in my group have said this was probably the best Sprint, we have had this semester. What specifically went well this semester was right when the Sprint started. That was a problem we had the last Sprint because we had a slow start because of Spring break. When this semester started, a lot of us were in the middle of working on issues so when this Sprint started, we continued working on the issues. A big problem we had last Sprint was we did not do enough documentation. Towards the end of the second Sprint and the beginning of this Sprint, our group made a big change. We decided that we would do little to no work in class and instead focus on updating the group on what we are working on, cleaning up our issue board, resolving any major issues that we encounter before that class, and documenting the progress we made in and out of class. This is because we made the realization that most of us in the group worked better alone, but when we ran into issues none of us were shy about bringing them up in the group meetings. We also did not have any issue asking others in the group for help. This was one of the most successful changes we made to the group. When we made this change, it caused the productivity of the project to skyrocket.

What I think did not go with this sprint was how ambitious our group was this sprint. We planned to get a lot complete in a short time and it did not all get done. For example, we wanted to complete the cards.js file and the display.js file as well as the prompts.js and writing.js file. We also wanted to add theming to our project so that it would look neat and professional. We ended up finishing the cards.js file but did not finish working out all of the bugs for the display.js file. In terms of the writing portion of the project, what we wanted to use at the start of the sprint did not end up working and we ended up adding a placeholder with some functionality so that we could have something to present.

I think we did not have too much to work on this sprint as a team. For the most part, I think it worked out very well. I think as a team we really improved our documentation this sprint. What I think we can improve a little is our individual documentation for issues and other small features that we worked on. Towards the end of the sprint, our documentation was a little lacking compared to the beginning of the sprint because we were rushing to the finish.

During the sprint, what I worked on was leftover from the previous sprint. In the previous sprint, we made a display page, but it did not properly transfer information from one page to another.

So, for a while, I contemplated how to move forward in the project and considered restructuring our project or looking at other ways to transfer information from one page to another.

How I fixed these issues was by simplifying our structure and moving screens to their own respective files.

Before this change, our app.js file did too much and was handling the navigation for the project as well as creating multiple screens. Moving things to their own files simplified our file structure and fixed some of our earlier navigation issues as a result.

When I did this change to restructure our project, it made creating the display page a lot easier and I was able to get it working to an extent. We can transfer information and display it on the screen but it currently does not display the correct information.

This is not because our function is wrong but because our logic is off. The function displays whatever we pass but we have a hard time figuring out what to pass. I was really stubborn at first when I encountered this issue and did not want to ask for this last issue. I have the issue at a weight of 2 but it is definitely more. Even when we had three people working on it, it was not done. So, what I need to improve on is to be less stubborn and ask for help even if it’s last minute.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Learn How You Fail”

I am choosing to write about this section this week because I can feel like I can relate to this topic deeply. In one of the opening statements of this section, the author talks about how people who have never failed or say that they have never failed have avoided pushing themselves or have just glazed over their failures. I agree with this statement. Another point that author brings up and I agree with is reflecting about your mistakes is not about ranting about the mistakes that we have made but rather it is a matter of character. We should be reflecting on our mistakes so that the next time we do something similar, we can make something better. This is a sentiment that I can really relate to because whenever I finish a project or assignment, even I did it correctly, I would look back at it afterwards and analyze my work to see what I could have done better or done instead. For example, if I barely finish something before the due date, I might look back at it and think to myself, “I wish I had more time and added this feature” or “this feature took a lot longer than I thought it would and that I should have managed my time better”. One point I disagree with is ranting about our mistakes. I think being able to identify the mistakes that we made is very important and when I talk or rant to someone about the mistakes that I made during a project, I am able to identify more mistakes that I had made that I did not realize before. Another topic that the author brought up in this section is the importance on certain skills or goals. I am finding myself agreeing more with this statement each and every day. I used to do the opposite and try to identify all of the skills that I am not good at and tried to get better at all of those skills at once. This did not end well. I often found myself spreading myself too thin. I found that I was spending too much time on one topic and not enough time on another. This led me to feeling that I had mastered no skills at all because I was trying to learn and master too many things at once. So, I am going to end this post by echoing something that was said in this section. At some point we need to realize we cannot excel at everything and that we need to know and accept our limits so that we can focus what we know we can improve.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Stay in the Trenches”

For this week’s blog post, I decided to write about this section of the textbook because I feel like this is an issue, I can see myself having when I get into the field. If I were to summarize this section in two statements, it would be “don’t let success go to your head”, and “never let someone take you away from something you love”. In this section, the author talks about what we should or should not do when we get a promotion. The author cautions us to be careful and warns us against blindly accepting a promotion because while in our new position we may never have to code, and if we do not practice on our own time, it can be easy to let our coding skill become dull. In addition, the more we move away from programming, the more we become disinterested in programming. This relates to a previous section in the book about nurturing our passion. If we don’t continually nurture our passion, we may lose that passion. As an alternative to the promotion, the author recommends that we work with our employers to find other ways to reward our hard work such as a pay increase or role change so that we can continue coding.

First and foremost, I agree with most of what was said in this section. Where I see myself having an issue later on in life is I feel like I am the type of person who when they receive a promotion will blindly accept the promotion and not think too much about the implications or effects until it is too late. In which case, I can also see myself having the problem of not being motivated enough to continue practicing programming during my own time and let my skills dull. So, reading this section made me realize that I probably will want to find some way to keep motivated before I go out there and get a job in the field. I am not sure what it will be or what it may look like just yet, but I have time.

After reading this section, I also thought it was really interesting because throughout this section, it seems like the author was making an emotional appeal to our sense of pleasure and focuses on the idea that a lot of people that go into this field go into it because they enjoy the work. That is why I am going into it but that may not be the case for everyone.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #2

For our second sprint, I think our group had a lot of ups and downs. At the start of the spring (before Spring Break), our group was very productive. Before break, we divided our group into two subgroups, three people working on the programming portion of the project (Sofia, Emmanuel, and I) and three people working on constructing a Docker container (Pernesso, Joao and Dylan). Early on, Dylan was able to get a Docker image and container working for our project. So, the Sprint was off to a strong start. During the last class before break, Sofia, Emmanuel, and I managed to break up the programming portion of the project into separate parts and assigned each part to a different person. So, each one of us knew what we had to work on over and after break. Some of us in the group had made plans to meet up over break using Discord to work on the project over break, but things came up and not everyone was able to meet. Sophia and I managed to work over Discord during break and I think we got a lot done. We did a mix between going over issues on our issue board and actually programming. For example, one of the issues I was going to work on over break was the Oath of Allegiance page and Personal Information page.

Originally, we had these issues as one issue which we decided did not really make sense because we were building two different screens. After an extensively discussion with Sophia, we also decided that the Personal Information page should go into our product backlog because if the purpose of our application was to just let people practice before taking the exam, then adding a Personal Information page does not really much to the functionality of our application. If the application was to simulate the exam, then adding a Personal Information page would make a lot more sense. So, we decided adding a Personal Information page was more of a luxury item that we could implement in a later Sprint if we have time. After our meet up, both Sophia and I documented what happened and our decisions on GitLab. So, in the beginning of the Sprint, we had decent documentation. It was what happened that everything kind of went south.

While I think our documentation was fine before and during break, I think documentation was one of the areas that fell apart the most after break. After we came back from break, we never followed up with one another on what we worked on during break or the week after break and so it was difficult to what was or wasn’t getting worked on or even what already done. Another issue that we had was we did not adjust the weights accordingly. When we initially made the issues in class before break, one of the things that we talked about was how for some of the issues, we did not know how to give it a weight because the issue may have been too broad, or we don’t know how to break up that specific issue. So, we were going to break some of those issues over time during the Sprint. This did not end up happening and our weights were off.

What I really to work on as an individual is working on a team. During this second sprint, I talked to my teammates a lot less than I did during the first Sprint. I just worked on the issues that I was assigned to and did not check in with anyone from the group unless I needed their feedback. For example, another issue that I worked during this Sprint was creating a UML diagram.

This was one of the few times I checked in with my group. I made two different diagrams. One simple diagram and one where I was trying something new and wanted my group’s feedback. So I feel like I need to work on checking in with my group more to see what they are working on and let them know what I am working on.

Another thing that I need to work on is writing issues as they come. Sometimes when I am working on an issue, I encounter more issues and I wait until the end of the sprint to put those issues on the issue board and forget about it until I talk to someone about it.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “The Deep End”

I decided to write a post about this section because I found very interesting. The author starts off this section with a quote from Christopher Hawkins,

“If you’ve never fallen on your face, odds are you haven’t attempted anything worth a damn.”

– Christopher Hawkins, “So You Want To Be a Software Consultant”

This quote made recall an experience I had during my freshman year of college. I was meeting with my advisor in her office, talking about how I was having difficulties learning the content in one of my classes. I was debating whether to retake that class in the following semester because I thought if I retook the class a second time, I would understand it better. My advisor advised me not to and gave me this piece of advice, even if I don’t understand everything in this class right now completely, this was fine. As I took more upper-level courses, I will gain new insight and start to understand the material in previous classes a lot better and may even learn to see it in a different light. At the time, I found that piece to be very strange because I had always thought if a course is prerequisite, you need to understand in the previous course to understand the material in the next class. Now I see in later classes, you apply the information that you learn in a previous class and by doing so, can understand the ins and outs about that topic and gain a better understanding of the topic.  

In this section, the author talks about the dangers of taking it easy and taking on only tasks that you know you can complete. He also talks about how by doing so, you will not grow because their skills will not improve and as a result, they won’t become confident in their work. Whilst it is true the author wants us to step outside of our comfort zone, he also talks about how important it is to be smart while doing it. In the short story given in the book, Enrique who was challenging himself by taking a job in Nigeria, did not blindly take a leap. Before he even made the move, he connected with people who knew were already working there and so he got himself a mentor that helped ease the transition.

I agree with the points that the author brought up. One additional point that I want to add would be the author does not say it is important to make large leaps or take on a challenging problem without a mentor, it is just easy when there is someone there to guide you.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “A Different Road”

For this week’s post, I wanted to look at a topic that I see myself coming back to at a later date, which is the topic of walking away from software development. This may happen after their first job or 50 years down the line when they are a senior programmer. Regardless, the point is this can happen at any time during a person’s career. In this section, the author talks about some of the reasons why a person may suddenly have a change of heart about the field. Some of the reasons listed were that person may have found something else that had piqued their interest, or they found they did not enjoy the field as much as they initially thought. Another aspect that I noticed about this section was that the author really emphasized the importance of being open-minded and supportive of their colleagues. A person may leave the field now, but that does not mean they will be gone forever. In addition, the author also talks about how companies might not look at that person kindly because they left the field and may not be as forthcoming as they should be when/if that person returns. But as fellow programmers, the author implores us to welcome that person back with open arms and encourage them to try to do something different with their lives.

I found this section to be interesting to read because I have always viewed myself as a jack-of-all trades. I have always had many interests and that is why I took so many different classes not pertaining to my major in college. I wanted to explore as much as I could before I graduated because I have always thought of myself as the kind of people who would have many different careers over the course of my lifetime. This section really made me think because I knew I wanted to change careers at some point, but I did not put a lot of thought about what I wanted to do after I changed careers or what career I wanted to pursue after being a software developer. I think part of the reason why I did not give this topic a lot of thought is because I don’t really know when I might want to change careers or when I might get tired of programming.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Familiar Tools”

For this week’s blog post, I decided to pick a topic that I think is very important and is something that we should remind ourselves time and time again. The topic I wanted to go over this week is on the topic of familiar tools or using things that we are familiar or comfortable with. How the author defines familiar tools in this section is a familiar tool is something that we can use without needing to look at the documentation. We have seen it enough times to know the ins and outs of whatever we are using. In the beginning of the chapter, it talks about how when we use familiar tools, it gives us peace of mind because we can give clients rough estimates or timelines of when they can expect something to be done. It is also because of this peace of mind that the author says that it may increase productivity. While there are advantages to using familiar tools, the author also cautions us to be careful. Using familiar tools may make us feel too comfortable and cause us to lean back on these tools and use them to try to solve every problem. So, the important reminder that author gives us at the end of the section is that we need to remember there will come a time in which our familiar tools will become obsolete and that we should not be unmovable. When the time comes, we need to be ready to adjust and throw away our familiar tools.

I found this section to be interesting because a while back, I was having this conversation with my team. We were talking about how when were learning introduction to programming, we were taught that our default branch on GitLab is master and when GitLab made the change to their naming convention from master to main, it threw everyone in the group off. Reading this chapter made me realize that everything we are learning now is mostly relevant now and that in a couple years, everything we learn may just become an artifact of the past. The principles may stay the same but the naming or software we may be completely different. Reading this chapter also reminded me of something that my R professor once told me. She once said something along the lines of, “Right now, we may be standing on solid ground but in a year from now or even in 6 months, the floor may disappear from beneath us.” When she told me this, she was referring to how our libraries may quickly become obsolete and when the time comes we should not be resilient to change.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Practice, Practice, Practice”

In this apprenticeship pattern, it talks about the importance of practicing our coding skills and how we should practice. The section starts off by talking about how the reason why people make coding mistakes on the job is because they are practicing and learning the skill while they are doing it. A lot of programmers do not have the time to practice and learn the skill before they have to put the skill to use at their job and with the looming project deadlines that is why there are often so many mistakes made on the job. So, the first thing that the chapter talks about is the importance of finding time to practice coding skills on our own without any deadlines. Without deadlines, it removes the pressure of having to learn a skill before a certain date and we can learn at our own pace. In addition to making time to practice our coding skills, the section also talks about how we should allow time for criticism. This is because if we don’t, we may or may not pick up bad habits without knowing it. The last topic that the section talks about is the importance of not practicing so much that it becomes a permanent habit and that instead we should be careful on what we choose to practice.

I agree with this section and think that practicing is very important. I think this is something that I personally need to work on. Often after I learn a skill in class, I don’t touch that skill again until it is brought up again in another class and usually by then, I had let that skill become stale. Another thing that I agree with from this section is the importance of not practicing too much and that we should be careful of what we practice. I agree with this because I was guilty of letting this happen before. A while back when I was practicing coding with my cousin, we were both working on the same problem, and I coded it how I normally would. My cousin asked me why I was coding it that way and I told him that it was how I always coded it. Then he showed how he did it and his way was very different from how I did it. So, he showed that I was letting practice become permanent and that I was coding the same way whenever I see a similar problem. So, my cousin reminded me that there may be more than one way to solve a problem and that we should consider the best way.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint -1 Retrospective Post

For our first sprint, I think our group did some things fairly well and had some things that we need to work on. From the first day of Sprint planning, our group got along very well and that made it easier for us to work together. We got straight to work on most days but there were also some days where we all got sidetracked for a while and needed to get railed back in. What I think worked well in the group was we were always asking questions. There were definitely points in the project where we were not sure about what were supposed to be doing and rather stumbling in the dark, we asked each other questions so that everyone in the group was up to speed and knew what to do and what was expected from each other and the project. Another thing that I think worked very well for the group was how open-minded everyone in the group was. We found out very early on in the project that most of us in the group had no experience working with mobile apps. Since we did not know where to start, we all decided to research what frameworks were out for creating apps. This led to the group creating separate issues for each of the frameworks (Ionic, Flutter, React Native). Even though some people in the group already had an inkling feeling that React Native would be the best fit for our project, we still decided to investigate all three frameworks to cover all of our bases. One thing that I think my group fairly well but also poorly was communication. When we were investigating the frameworks, our group of six broke up into three pairs. While we were in pairs, I think we did an okay job communicating with our partners. For example, when I was working on Flutter with Emmanuel, we forwarded resources to another one and let each other know our availability using Discord. So, we kept our partners well informed on what we were working on and when. This is where I think communication is something we need to work on during the next Sprint. Sometimes resources we forward to each through Discord do not end up on GitLab. Discord direct messages is not public information so there was sometimes no public record of what me and Emmanuel were working on. While I think we did a good job communicating with our partners, I think we could have done a better job informing the rest of the group as to what we were working on sometimes. I think as a group we did not do a very good job making sure everything that we did was documented and ended up on GitLab. This is something that I think we need to work on during the second sprint.

As an individual, I think I need to work getting more consistent results. I have a tendency of doing everything all at once so sometimes throughout the week, I don’t think I contribute a lot to the group or the project and then seemingly out of nowhere over the weekend I may contribute a lot to the group whether it be links to resources that I think would be valuable, comments on issues and/or code snippets to mini programs on what we were talking about in class. One thing that I need to work on in class and I am very aware of this issue, is I need to work on listening more to my group. When I work, I tend to become absorbed in my work and ignore the people around me. So, during the next sprint I think I need to work on knowing when to pause my work so that I do a better job listening to my group.  

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Kindred Spirits”

For this week’s blog post, I decided to review a chapter about a topic that I have thought about a lot. The topic that I am reviewing this week is the importance of mentors and finding kindred spirits. For those of you who does not know what a kindred spirit is, a kindred spirit is someone who shares your interests or attitude about a topic. I find this topic interesting because it is a topic that I have thought a lot about. In the past, when I was a Mathematics major, I felt like I had found a lot of kindred spirits. I used to spend a lot of time in the math lab and center solving math problems with these people. When I think back about those days, I view it as some of my most productive years in my undergraduate career. I used to be very studious and was very motivated to be in school. As people within the group graduated one by one, I found myself at a loss and became very unmotivated. This is why I found the first segment of the section interesting because it talks about the importance of finding kindred spirits in order to stay motivated. One line from that section that stuck to me was the line about the impact of having a relationship with a kindred spirit. Some relationships may be short but may make a major impact in a person’s life. This was how I felt about the relationships I formed when I was a math major. The time I spent with those people may have been brief but the time we did spend together did feel meaningful and I would not have had it any other way. One thing this chapter has changed is how I thought finding new kindred spirits. After the last of the group graduated, I tried finding other kindred spirits in those who were still there, but I did not feel that same connection. So, I have always tried finding kindred spirits by physical vicinity. I have always thought of myself as a follower so one thing that the chapter brought up that I never really thought is why don’t I just a start a group of my own. This thought was something that went over my head and is something I think I may consider some time in the future.

Another topic that the chapter talked about is the topic of group thought. I think this is a very relative issue that needs to be addressed when thinking about creating a group and I think there should be precautions in place to ensure that the group can still have healthy debates.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.