Author Archives: Dylan Nguyen

“NICE” Sprint 3 Retrospective

During our third and final sprint, we had a clear idea about what we wanted to achieve with our application. The first two splits helped create a foundation that allowed for us to propel much faster and efficiently compared to before. After spending the last sprint working on the docker container for our group, I wanted to contribute in a way that would be helpful to the react team. I ended up creating issues for myself that were more in line with the front end side of things that the react team had not really touched upon. I first decided to clean up a lot of the code from the react team, there were a lot of styles that were repetitively used by the team so I managed to implement a style page where certain style could be called upon instead of written out when being applied to something. The next thing I tried to tackle was an interactive page for users to select which kind of test they wanted to practice. This was implemented with a side scroll feature that was imported from the react-native-gesture-handler where I was learning the design parts of how things would look based on the style I would give it. I was also able to take images and icons as well to apply to the home page and menu screen which gave it a much better appearance to the eyes of the user.

As a team I felt as if this sprint all of the puzzle pieces finally came together. The react team was working cohesively together where as the others who did not work with them originally were able to go back and forth with them to push an pull code without being out of sync. The team cohesiveness really brought out the best in one another as were we able to divide issues into more manageable ones and we could really see the final product coming together.

With the docker team finally being able to assist the react team with the application as a whole, we were constantly running the application and testing it, and that led to a lot of discussion of things that needed to be fixed or added to the app. This would lead to us effectively being able to help one another spot mishaps and expedite the results we so eagerly wanted. Although we were not able to produce a functioning writing portion, we were able to create a placeholder for it that was substituted with a input on the they keyboard from the user.

Individually, I felt as though this sprint was one were I pushed myself the most. Maybe it was because the semester was coming to the end or that the application was seeing growth, but although I was lacking in basic knowledge of react native, I wanted to be sure I contributed more to the application and pushed myself to learn more. The only issue that I had with the sprint was that I wish I was able to be part of the react native team prior to this because I know I could have contributed more than what I already have. Seeing how fast I was able to grasp things, maybe I should have stepped up before and take on that challenge because I had a lot of fun during this sprint.


From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Retreat Into Competence”

This apprenticeship pattern describes how we should approach difficulties that we encounter along our way of being an apprentice. There will be times when we are working on projects and are faced with difficult challenges that we don’t know if we can overcome, and there are ways to get around this. In the future we will try and expose our ignorance to learn new things, but in doing so we might take on more than we can handle. In doing so, it is okay to take a step and work on something else. Sometimes taking some time away from what you’re struggling on will help you in the long term. It is important that once you take that step back that you then take two steps forward and use that momentum to better yourself. Taking a step back might feel as though you are retreating into failure, but when you work on something you’re comfortable it also adds to your expertise in that area. This then leads to needing to grow as a software engineer and having to learn new things. What we must also remember is to seek support from our mentors and use them to help us become better equipped with handling these situations.

What I’ve taken from this pattern is that taking a step back from what we’re uncomfortable with okay. Sometimes it is okay to go backwards in order for us look back at what we’ve preciously done, then use that to our advantage of progressing forward with our skills. Growth can be looked at from many different views and that’s what we can take from this apprenticeship pattern. There is nothing wrong with facing failure head on, but it’s about how we bounce back that will make us better software engineers.

This pattern has reminded me of experiences I have had in my life. There have been times where I have been put into situations at work where I was required to do work I was unfamiliar with. In doing so, I reverted back to completing work I knew I could do, and once that was done I was then forced to work the things I was not too sure about. In this situation, I then reached out to engineers and other people who could assist me in my work. This then helped me to better understand how to approach this new situation and helped me gain knowledge and experience in completing it later on without the assistance of others.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “The Deep End”

This apprenticeship pattern describes how we should approach our careers when we are put into a situation where we feel like we are stuck and don’t know where to go. This situation is different than plateauing where you know don’t know what to do next but still need to grow our skills in our career. What we need to do next is to “Jump in the Deep End” and take on situations that make us uncomfortable with the likelihood of failure. They give us an example with Enrique where he was stuck with working at a place where he didn’t feel like anything was being done with his life, so he took a leap of faith. In that leap of faith, he ended up in Nigeria where the original plan failed but was able to come up with a new solution. This story sets an example of how if we don’t try and fail then there is something we are not doing right. To avoid trying to be stuck in a rut, maybe we can try taking the work we’ve done and comparing it to one another so see where our careers are heading to and to maybe see what we can improve on in the next one.

What I’ve taken from this pattern is that we shouldn’t be scared from taking a leap into uncharted territories. If we have not failed then we haven’t attempted anything that’s been worth while for our careers. Being stuck and not doing anything about it would result in our careers being at a complete stand still and not a plateau. Growth only happens from taking on projects that are scary and will push you to your limits, and it’s that kind of work that will push you out of being stuck. When faced with a situation where you fail, it might open the doors to finding a new solution that you might be able to recognize.

This pattern has made been insightful in how I should approach the future when I feel like I don’t know what to do in my career. It has also reminded me of time’s where I have been in ruts at the places where I have worked. In those situations I have felt as though with the work I was doing, there was nothing more than I could do and I was just comfortable doing what I always did. Not once did I even jump into the deep end and allowed for myself to be at a stand still for too long. If I jumped into the deep end at least once, I would have gotten out of there earlier.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

“N.I.C.E” Sprint 2 Retrospective

During our second sprint we finally began setting up what we wanted for our application. We discussed the features that we wanted as well as how we wanted to be able to set up the environment for future students. What I was tasked with was trying to develop a docker container that would be able to run react and expo so that others would not need to require to download anything in order to run it. The docker team was not well versed with docker but we managed to figure out how to successfully create one. It was a lot of trial and error, but in the end, we overcame one of our weaknesses. The next order of business was then work with the React team to include all of their dependencies in the docker container so that everyone would have no trouble using their code.

The react team in parallel of the docker team was working on developing the features of the app that we wanted to include. They created the base of the cards with questions as well as the writing portion of the app. Unfortunately, the code provided by one of our referenced sources seemed to be unviable and the writing portion is being put aside for now. With that we are now putting our focus into creating the other portions of our application.

As a team we work well with trying to help one another succeed and adding on to one another’s ideas. Our communication is one of our strongest points as a group and it allows for us to express how we feel about areas we are weak in without the worry of any backlash. There were many times where some of us felt stuck in what we were doing, and we tried to help pick each other up.

One of the biggest issues we faced was not being able to create the proper issues that we needed to. We would have general ideas about what we wanted to do and how to do them but as a result of creating those issues, we would have other smaller issues that would pop up along the way. Although smaller issues would come up, we didn’t realize that we could add those to our issue board as well and it felt like we were not making much of a dent in the work that we wanted to do.

Individually I felt like I was a lost at times and did not know what to do. It was difficult working on things that I did not know much about and trying to teach myself was one of the hardest parts. Docker was one are where I felt as though I knew nothing but took it upon myself to try and learn what I was weakest at. It taught we that with time and hard work that I can achieve anything, but it would have been nice to have someone who was well versed to push me in the right direction because it would’ve saved a lot of time and I also wanted to help the other team as well. I also realized that I do like to work independently most of the time and that might take away from others learning and finding a cohesive solution together.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns “Confront Your Ignorance”

This apprenticeship pattern describes to us how after being able to expose your ignorance, you must now be able to confront it. Once we are able to find the gaps in our skillset, it is up to us to tackle those problems head on. Confronting your ignorance does not mean to learn in isolation because doing that encourages us to create a standard where hiding your failures is okay. What we need to remember is that learning in public is always beneficial for an apprentice and that is what helps us move onto our next step of becoming better software engineers. What we worry about is when exposing your ignorance you become dependent on others as well as just creating problems for others when you don’t know something. That is why confronting your ignorance helps bridge the gap from between exposing your ignorance to being able to actually contribute to projects because confronting it is the best way to fill in your gaps.

What I have been able to away from this is that just because we don’t know something does not mean we should just constantly depend on others. If we fail to understand how to do something, we need to be able to ask for help so that hopefully next time we can do it on our own. With every project we take on in the future, it is obvious that we will need help in order to continue onward. We need to not work in secret to hide our failures and to use our mentors and peers as resources so that we grow and fill in those holes we all so definitely have.

After reading this pattern, it helped my reflect on a time where I created a Java application for work that would scan RFID badges of employees. I was tasked with this and initially had thought that if I could do it on my own I could prove I was capable and hardworking. In the end I took too long and did not have much to show for it, I was then partnered with someone who did have experience creating apps and in the end we were able to develop a functioning app. Pattern reminded me about this experience and that exposing and confronting my ignorance does not show that I’m weak, but that I want to grow as an apprentice.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns “Expose Your Ignorance”

This apprenticeship pattern describes to us how having the ability to identify our areas of ignorance and being able to reduce will be beneficial for us software apprentices in the future. There will be tremendous pressure on us in our future jobs to be able to work on and finish projects. They will expect us to be able to deliver software, and this is where we shouldn’t be ignorant of what we are not able to do because our lack of inexperience. This is where if we do not understand something, we should not be scared to reach out to ask questions and to learn about technologies and things that we do not understand. This itself reassures everyone of our ability to learn and by not pretending how to know how to do something, it exposes our ignorance to asking questions. What we need to understand is that as apprentices, there are many areas of our craft that we know nothing about, we can’t go around letting others believe that we know everything, but instead be able to reach out and ask questions without letting our pride get in the way.

What I’ve taken away from this is to not worry about questions because letting others think that you know how to do something and delivering something incorrect is even more of an issue. I think there is pride in being able to show others you can do things on your own without help, but being an apprentice means that you should be able to learn from others without your pride getting in the way.

This pattern has been helpful in letting me be able to understand how I am when I am given work to do in the real world. There have been instances where I have been given projects to work on at work, and I have tried to do things myself without help, this itself has led me to either taking too long on something or delivering work that I am not completely proud of. There have been other instances where I am completely unable to understand some things and asking others who understand it completely really helped elevate my understanding and learning of what I want. The ability to make uncomfortable situations more comfortable for me will be me exposing my ignorance.        

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Concrete Skills”

This apprenticeship describes how even though we may be knowledgeable software engineers, the knowledge we possess may not be enough to convince others to work with us. Instead, we need to show that we have the ability to apply this knowledge in the creation of software applications. Teams most of the time don’t have the luxury to hire someone who can’t contribute to their workload. It is up to us to convince them that we can demonstrate our skill practically in the workplace. It will be beneficial to us if we are able to display our skills in being able to build in various languages and frameworks. As new graduates, when being picked by hiring managers, they are taking a risk on us and our ability in our concrete skills is what should give them confidence in being able to contribute to the team on day one.

What I’ve taken from this is that I need to contribute more time into honing my concrete skills to be able to show others who take a risk on me that I am in practice and that I am capable of providing for my team instead of being a hinderance. Being able to show that I am able to use my understanding of the knowledge I already possess and translating that into other aspects of software engineering is what I should be striving to do. They also explain that what I’ve done in past shouldn’t be overlooked and that the softer skill that I have attained really are bigger than what they seem, and that these skills themselves also help contribute to being a better software engineer in the workplace.

This apprenticeship pattern reminds me that being able to be hired by a company is a testament to my ability and not just being a graduate. In order for companies to trust me, I need to show them that I can use my skills to help the team and not rely on others to help jump start my progression. This pattern also reminds me that the skills that I have acquired in the early parts of my life should not be downplayed. They do provide others that I am capable of many different things and that they can translate to many parts of my job at the workplace. I normally tend to shy away from my accomplishments from other jobs because they’re not software related, but after reading this pattern, it gives me more confidence in being able to embrace those previous accomplishments and use them to my advantage.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Naturalization Interview Confidence Environment “Sprint 1 Retrospective”

During our first sprint, our group was tasked with creating everything from scratch for this environment from the documentation to selecting the framework we were going to choose to proceed with. I was given the main tasks of assisting with the Read Me and trying to develop a working framework that was able to show IOS compatibility with React Native. The initial issue that we had was that most people in our group did not have a macbook and we needed to find a solution to developing on an ios device without the need of one. React eventually became our only solution and with it being able to project onto an ios device through expo and metro bundler. During this time we were able to assist one another achieve working react environment on everyone’s laptop.

Toward the end of our first sprint, we then proceeded to try and experiment with React where we stumbled upon another issue, and that was that we needed source code for everyone to work off of so that when merge our work together later on, it would work. Along with that, we now needed to think of the future so that students in the coming semesters would be able to work on that too. To be able to accomplish that, now we needed to create a synonymous docker file for everyone to use because many members of our group were working with different dependencies and now we needed to make it work so that not everyone has to go and download multiple things in order to get the code to work.

What worked well during our first sprint was our team chemistry and our ability to bounce ideas off one another as well as being able to assist each other with things we were stuck one. With a group that was able to communicate very well, we used class time to really try and move past any confusion regarding our project. It was also nice that no one judged one another and that we were able to openly express our ideas without any worries.

There was one thing that we lacked as a team the most and that was a sense of direction and urgency from time to time. Since our first sprint was primarily focused around picking the proper framework and most of the basic things of setting up our environment, it felt as though sometimes people didn’t know what to do due to the lack of work. I also believe that because this project was so new and no one was too sure about how things were supposed to go that maybe we were more worried about what we could achieve instead of what we couldn’t.

Individually, I felt as though I could have don’t more to put myself into contributing to things. There were times everyone was assigning things to themselves and I kind of put the groups priorities first instead of mine, and at times that felt as though I was not given enough to do. It also does feel like I am scared about trying to learn a new language and approach things I have not done before. I have the enthusiasm to go and try to learn things but also have the worry about possibly letting my team or myself down, and that might be a reason why I have not stepped up as much as I should.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “Unleash Your Enthusiasm”

What I have found interesting is about this apprenticeship pattern is that those who are enthusiastic about the work they do might not fit into their future team. It is a worrisome thing and that although there are ways to nurture your skills outside of work, most people tend to look at work as a way to work with others and expand their knowledge in software engineering. I had never thought that being enthusiastic could be detrimental to a team, but it makes sense that already existing teams probably do want to deliver on projects and their work instead of helping someone new out. It was nice to read that teams that are comfortable with themselves do beneficial from a fresh new mind and injecting them with excitement and questions will be beneficial to the team.

What I found most interesting when reading about this pattern is that as a soon to be graduate, we have the most excitement about the future of growing in our careers and that this pattern tells us that it is time in our careers to take the most risk and to speak our mind. We have very little to lose staring out and our ideas and passion will be more beneficial than detrimental to our team. As an apprentice, expressing ourselves is what we should be doing and it’s healthier for us to grow as a person that way. Instead of worrying about fitting into a future team, we should worry about being that spark that brings new ways of improving the team.

I as a person am very enthusiastic about everything I do. It does worry me that I might not fit into the team I work with in the future, but I hope that everything that I bring to the table is something that can help everyone. This pattern does make me thing about how important it is to work with my team and that hopefully my enthusiasm as a new graduate can help elevate my team to the next level. I also have experienced times where I have brought up ideas to engineers and then they shoot me down, but I had never thought about asking about how to improve my suggestion instead of just letting it go. This solution is a great way to figure out how to do better instead of thinking that your ideas are not good enough.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “The White Belt”

This apprenticeship pattern describes as how we as programmers are comfortable with the language that we are best at and then how we try to apply our knowledge to learning something else. In the end it is hard to learn something new that way. What we realize by doing this is that it is difficult to then try and learn something new, and then we may end up becoming stagnant in our growth. The white belt method tells us to forget everything we thought we knew previously and come into learning something new with the mindset of a beginner. Although we lose productivity in the beginning, it will end up being a big step in mastering something new.

One of the most interesting things I enjoyed while reading about this pattern was an example of how to reimplement a Java pattern into another language like Io and then into something like J. we can notice how the code can change drastically from one to another and yet at the end of the day they all do the same thing. This example is eye opening to showing how similar and different every language is and that we can’t just take the same knowledge we have in something and apply it to something else. We have no make sure we go in with a fresh mind and try and follow the new language’s nuances and set of rules and forget everything we think we should know instead of trying to apply it to something new.

This pattern is very insightful and applies to what I’m currently working on in class. We are attempting to learn how to code in React Native and I feel as though my growth in learning and the progress that I want to achieve is not what I want to. It might be because I’m trying to apply my skills in java to a front-end language and that does not mesh well whatsoever. I’m an impatient person when it comes to learning something new, but this pattern is a great way for me to keep in the back of my mind because progression shouldn’t come in an instant, it comes with slow and steady progress and constant repetition.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.