Author Archives: kennybui986

Sprint retrospective 3

Here in sprint 3, things seemed to have progressed smoothly with the project in that we have finished most of what we have added in the product log although there were some areas of difficulty. The cohesion of the group has improved with better communication on what is to be done and the planning together seems to have gotten better. There are still improvements to be made but overall, the project is in a good state right now. The presentation also seems to be going well and should be alright. The quality of the sprint overall seems to be up and is providing good results.

On what has worked well, we have managed to get to the end of the semester and be able to finish a good amount of work on the project. We added more calls to the backend and continuously updated the API with new changes. The backend is set up with the proper semantic versioning. The android nest tester is functional and everything that we have built looks to be solid. The communication in the group looks to have improved as people communicated on what they did and were working on more than in previous sprints. The team also seemed to have gotten together more often to work on issues. The group stuck to what was planned pretty well and followed the timeline agreed upon. The issue board moved along more than the last sprint, issues were moved across the board compared to last sprint where nothing was moved until the last day.

On what has not worked well, there was unfinished work at the end of the sprint that now has to be sent over to next semester. This means that we have made mistakes during our planning on the difficulty of the work on the issues. The planning of getting the presentation done also could have been better. There probably should have been more dedicated time to get together and figure out the presentation as it felt a bit odd at the end figuring out what topics to do.

We could improve as a team by firstly, we could have worked together more regarding the issues regarding key authentication that we were unable to implement. There could have been chances to get together and try to figure out what was wrong and get it done by the end of the sprint. We could also improve as a team in our planning and plan more effectively on what can be done this sprint. We also could have been more planning with the presentation and knowing what exactly what portion each member was contributing with.

I could improve personally by putting in more of my input and getting my ideas out there. I also could have contributed more on different issues within the project. I also could have done better with working together with the group members such as when we were working on implementing the range call where it felt like backseat coding and I could have contributed more.

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

Apprenticeship patterns – Dig Deeper

This apprenticeship pattern is all about expanding your knowledge about the tools you use and that if you find yourself in a situation where you are facing problems on the applications and different utilities that you have picked up over time has started to become a burden. This can be due to you using an unreliable source when learning about this product or just not going deep enough into the tool and only using what you needed at the time. This then can lead to troubles when you are put to the test or see a problem you have never faced before. The solution to this problem requires you to go beyond and start looking at the different nuances and inner workings of the programs you are working with.

Here this problem can be seen when you are perhaps interviewed and they ask you about projects that you have worked on. They then ask you about what you did and you can say that, but you don’t know exactly how it works all together, you coded some part of the backend but can’t exactly explain how that section functions. The background knowledge of the project is lacking in areas that could be problematic when you need to work in relation to that knowledge This is a problem and that you should instead take the initiative in understanding more about what you are working with to boost yourself and be prepared for a situation when this knowledge is required.

I myself could devote much more time into learning more about the tools I use and more about the projects I am working on. I could perhaps put some time into learning more on what is going on with the LibreFoodPantry and how the other groups are working to get a better idea of the situation. The job listings and internships out there are expecting more than just basic knowledge of the tools they list and use. There is much more with docker that I could be doing and figuring out issues that pop up from time to time if they are even fixable or not.

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

Apprenticeship patterns – Kindred spirits

The pattern I have chosen today is one about kindred spirits which is when one finds themselves in an unfavorable situation regarding the workplace they reside in or the kind of organization they work for, they should seek some sort of help from someone else. That someone else should be a mentor to you, someone that you want try to emulate, feel intimidated by while also feeling secure around them. These people will help you on your journey on becoming better software programmer whether it be by sharpening your skills or even just giving some extra motivation for you to push on.

The pattern mentions that on the long road, nobody walks alone and that some sort of cooperation is well needed for you to push on with your career. The path one has taken so far should be proof of that, you should have always had someone to help stimulate your learning with your teachers and classmates available for help. They have done a great deal of work helping you realize your career and you will soon see these go away as your enter your career. This means that you will need to start to put in work yourself to build new connections to new mentors and friends that have similar career interests. The sooner this is done, the better so that way the experience is gained earlier and you are setup before any new hardships happen.

I myself should start looking into different ways on getting of connecting to a camaraderie of those who are looking into similar lines of work regarding software programming. There are tons of different sites to look through and resources to use to obtain these connections and there are probably several in the university that I can use. The pattern does mention of it creating an irregular meetup of craftsman in the region that eventually becomes large enough to be self sustaining. I disagree on getting such thing to happen to be easier than one might think and that it is probably something the average craftsman wouldn’t be able to create. I myself don’t see myself creating such a group.

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

Sprint 2 Retrospective

Now for sprint 2, much has changed in which the direction, work, communication and more has changed from the previous sprint. There seems to be more communication and a better direction of where we are going and a more complete vision based on the project. There are still questions on what to do and where exactly we are going to end up by the end of the project but hopefully that can be figured out in to coming days. There is also the collaboration between other groups that need to be sorted out.

On what has worked well, we have made good progress on building the API and backend in that there are functioning pieces of code we can work with. The NestAPIMap Joe had obtained from the previous sprint had provided a good starting point for the sprint. The http calls are functioning as they should be and the overall structure of the project seems sound. There was a lot of functionality added to which the API and the backend actually works when previously we didn’t quite have much working at all which is nice. The changes made to the project are numerous and a good sign of work getting done.

On what has not worked well, there is still a feeling of misdirection as we are still new to this kind of work so it shouldn’t be surprising that this is happening. There are parts where people work on different parts on their own and later on do different things than intended in which other people who are working on the same issue don’t know that it has already been finished. The flow of issues from being worked on to done wasn’t quite as fluid as the last sprint as most of them just stayed in process section till the last day in which we sorted them out there.

We could improve as a team by communicating better on the work being done and what is free to do so that way the work could have been more evenly distributed. It felt like some people did more work than what was originally intended/different from what was thought of. There was a lack of usage of the issue board on GitLab which contributed to this problem and that it would be beneficial to have a better flow of finishing issues so that way we know better on what to do or not to do and that there isn’t a backlog of issues all waiting to be sorted until the last day.

I could improve as personally I was also part of the problem of communicating between others on what issues were being done and didn’t quite contribute as much as I could’ve to the project. I feel like I could’ve done quite a bit more contribution work to the backend with the calls and hopefully in the next sprint I dive into some issues and get more meaningful work done. There is the issue of all the other classes I am taking starting to reach their end so I will have to watch for that.

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

Apprenticeship Patterns – Nurture Your Passion

For this blog post, I have chosen the “Nurture Your Passion” pattern in which this pattern talks about how one should keep their passion for whatever they are doing secure from the inevitable draining activities that will harm your passion. When one progresses into their career, the circumstances will change and the activities you used to do for enjoyment will soon turn annoyances or be in such a crunch that there is no time for blank. It is up to yourself to mitigate these issues and to help preserve your passion.

The time of coding and working with all these programs and getting a fully functioning product is quite fulfilling to see. The work needed to get there and the problems that life will throw at your way will make you want to reconsider your decisions however such as trying to sift through countless bugs or being in a less than optimal working environment. There a number of different options to consider when trying to mitigate this issue, such as exploring different forms of media that contain information that you would like to look at or interacting with different people with the same passion to help bolster your own. The book goes into different patterns that describe these solutions such as breakable toys and kindred spirits where you have these different resources to use to help keep you going.

This pattern does indeed resonate with me as while coding has started out as a side hobby, quick and enjoyable with no commitments to it whatsoever is slowly changing to me more intensive and time consuming leading to generally less enjoyment. This makes me think of the eventual future of potential crunch times and unenjoyable meeting that will take place in which I will have to start picking up new skills to help mitigate these issues such as improving my communication skills incase any situations such as bad interactions with other people in the workplace could be solved by talking myself out of it. There is the chance of a new hot idea in the future that I could latch onto to help keep my interest up and going.

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

Breakable toys – Apprenticeship patterns

The apprenticeship pattern I have chosen this week is the “breakable toys’ pattern which was very interesting to me. The pattern was about failure and how it is usually the best way to learn. There is a problem however when the place we are working in does not tolerate any failure and any such occurrence will have dire consequences. Here with the breakable toys pattern, we are allowed to make our own systems that are still relevant to our work. This way when we work with them and make mistakes, can can apply what we have learned to our workplaces without it hurting other people in the process.

This here is an interesting pattern to think about as so far, most students have been in a environment where mistakes are common and tolerated but later down the line, they will most likely face a much harsher environment than what they are used to including me. This means that later down the line, I will have to invest my time into these side projects in order to obtain failure and stimulate learning. There could even be one used in some of our current projects in which we could make some side projects in order to boost our learning. This also makes me wonder on the tolerance of different places on how much do they tolerate failure which is most likely very little which makes these breakable toys all the more important for one to use. Although that does make me think on whether or not the person would actually have the time to develop these programs. There is the chance that the work this person is working on is already very time consuming and that if their life was a bit too hectic with outside responsibility’s to actually make of any use of these toys in which this pattern might not be for them.

This pattern overall is a good one to learn on failure without it negatively affecting other people, especially if I were to go into professions that were high profile or had any basis in security in which failure is not an option.

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

Apprenticeship pattern: Being the Worst

The pattern I have chosen this week is the pattern about being the worst. This pattern is all about the situation you are in and the mentality you have. The idea is that you shouldn’t find yourself in a position where your learning is stagnated due to how good your team and that you don’t push yourself to learn because of this. You should instead always have that mentality of where you need to learn and continuously improve or else there will be problems down the line.

The pattern of being the worst was quite an interesting and relatable read to me. The idea of staying in the mentality of “being the worst” in which one is always trying to catch up to their peers around them. I usually like to see myself as the worst one in the team and that I have a ton of work to do to catch up and to improve myself. This does have its risk if you are actually the worst one in the team and causing issues to the team and yourself as it says in the reading. The pressure of being the person holding the team back sometimes look unsurmountable in which one just needs to keep a cool head and keep working hard on improving. In my current team, I have the same feeling of needing to improve to make sure that I am not holding them down.

The action of willingly joining a team to be the worst member instead another team that you might provide better benefit to right out of the gate is an interesting idea to think about. It can be hard to keep such a mentality up for every team you join and other people around you might be skeptical on your process and just try to put you on a different team you they think fits you in better. It’s as it says in the book being a selfish decision in which you might be bringing the team down for your own gain so it is important to contribute as much as you can to help mitigate this.

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

Sprint Retrospective – Sprint 1

This first sprint could have went better but it is to be expected as it is the first time for most people to work like this. There group so far seems to have congealed well and can communicate well with each other. We were able to obtain the necessary information for helping build the project and now we should start to move at a faster pace to get the project done.

There hasn’t been much to critique so far since we haven’t quite starting working on coding yet but some of the issues that have come up so far would be with the way this group has been going . This process is still new to everybody so people are still taking the time of getting used to working on these different issues. There is the issue of the communication of the team so far. The way that the team is going to work isn’t quite clear and the path we are taking needs meeting time to figure out so that . The team could improve by communicating more with each other more, especially when the team tries to set up meetings outside of class and part of the team does not respond or does not make it clear if they are going to show up.

Then for me personally, I don’t think that I have made much of a considerable impact so far as the team just recently has the means to move forward with the project. I have contributed in discussions in the team and helped set up tools to use for the project later on. I could improve as an individual by contributing more in the discussions and think of more ideas on what we should be doing in the project. I also could have done more on GitLab as so far while most of the stuff added was nothing new and mostly mimicking what we have already done in the past, I probably could have taken the initiative to add some work into GitLab instead of another person doing it.

The majority of the time spent on the first sprint was getting our bearings together and figure out what exactly we were supposed to do in this sprint. At first, there were hopes of getting the API up and running by this first sprint ends but that was later put down due to confusion on what the specs and information was needed from other people. It took quite a bit of time to get this information as it was obtained at the end of the sprint which means that the coding will haver to wait until the 2nd sprint. There was also work that we had placed into the sprint backlog that should have been saved for later sprints as they required information and buildup that we did not have at the time. This fuss over issues like these had costed us time that could have been used elsewhere.
I added the tools necessary to the backend devcontainer and helped some team members on running the tools.

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

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

The book Apprenticeship Patterns from what I have read so far seems to be a good insightful resource to read for college students like me still early on our learning experience through software development. I have noticed a few things from the reading that were common throughout the chapters or were interesting such as with how there is a general theme of there is always room for improvement and an opportunity to learn no matter which stage of experience you are at. It does not matter if you are just an “apprentice” like me or a master for those who have coded for decades; there is always room for improvement as the industry changes so we should steel our will and continue learning.

The chapters that are the most relevant to me so far are probably 1 and 3 because firstly, chapter 1 is the setup chapter; it hold the purpose of this book in which it is to guide us on our journey forward while we are still apprentices and gives us some good insight on our journey ahead as we progress throughout our careers. It gives us the meaning of what it means to be an apprentice and what we should be doing in general. Then with chapter 3, the introduction highlights a similarity between everyone as they walk the same road but also as old skills get built on over time as you expand into other areas of coding as it seems to be symbolically done with Dave and his training certificates. It is crucial for one to be active in the coding community all the world to obtain information on the different skill sets that people have that could provide vital information, inspiration or connections that will boost ones journey ahead.

This book so far has given me insight on what I should be prepared to do in the future whether such as to forever continue bolster one’s mind and as we become more experienced, we obtain more intuitive ways to apply our skills onto the world and help prepare for the next generation of journeymen and apprentices.

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

Thea’s Pantry

When looking through the Thea’s Pantry GitLab Group, I saw something that interested me with the release process where we have to use semantic-release when we make new working builds and new merge requests are accepted. There we can see that this helps makes the release process automatic without human interaction; leaving it “unromantic and unsentimental”. It didn’t occur to me before but when reading the link that phrase led to how people think differently about changing the version number. It looks as though when reading that website, that we don’t care about the creative values and expressions they talk about and just keep things standardized and clean.

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