Sprint Reflection 6

This Sprint started with us adding more tasks to the issue board, and taking on some of them. However, for the most part, we spent a lot of this sprint wrapping up our work and making preparations for our presentation to the class. We were able to reflect on our work throughout the semester and look at what we’d accomplished. From there, we reflected on things we did wrong, things we did right, and things that could be improved on the project in the future.

Personally, I think if the project was given more thought and setup ahead of time, it would have gone a lot smoother. In hindsight, having the repositories for the project set up, organizing the task- and product-backlog, and streamlining communication between the groups is something that NEEDS to happen. Making these things into assignments and writing up worksheets for them like in CS-343 and -443 would work a lot better, I think. This way, everyone in the group is getting an equal understanding of what is happening and how the project is organized. Also, having a set place to communicating between the groups from the start of the project would be helpful in ensuring no communication is being lost and everybody is being heard.

While I like the idea of being able to work on a big project with a group, it is very inefficient when there is no proper authority. Although the University obviously doesn’t have the resources, things certainly would have gone smoother if there was a project manager who actually knew what they were doing and could steer us in the right direction. The professor’s attention was unfortunately divided between so much this semester that there wasn’t a lot of time for useful reflection from a mentor.

Things I think we did right is that we worked hard and produced a product that functions. We did everything we could and made the shell of something I truly think will be useful for the University in time. Far from complete, there is a lot of unfinished work that future groups will hopefully pick up. Many of these tasks we didn’t get to are listed in the backlog. And there are even more ambitious features that we’ve thought of that haven’t made there way there. We competed the most essential features first, and got to as many of the others as we could. If we had more time, it would have been interesting to work on how to organize a backlog and rank products by level of importance.

Ultimately, despite the setbacks and difficulties this semester, I have still learned a lot about project organization, workflow, cross-team communication, and many other lesser thought-of parts of the workplace. Therefore, I still think the Capstone was ultimately useful and served its purpose. There is a lot of complexity in simply setting up a shared place to work on a project and communicate changes. All of which must be done before work even begins on a project. In the future, I intend to be more prepared and approach big tasks more proactively.

Sprint Reflection 5

Our fifth and final sprint, we focused a lot on opening and rectifying communication with the other food pantry group and clarifying some of the issues that were posted on GitHub. We have not been keeping up with our issues, which has been a real weakness between the two groups. Both groups were relatively unaware of what the other was doing, and there was a lot of redundant work being done between the two of us. Nathan also organized another meeting with Serena so we could discuss our work and some of the changes the food pantry might like to see.

The difficulty we were having with issues were numerous. The first was that we were not claiming the issues we were working on. Both groups were therefore unaware of the progress of the other group and what was available to be worked on. There was redundant work being done and a lot of general confusion. After a discussion, we agreed to be more proactive about claiming or issues, and also did more cleaning up on some of the tasks and stories we had on the repository and discussed what is important, what is redundant, what can go, etc. We cleared up our tasks and stories, assigned ourselves to what we were working on, and moved on to our next tasks.

We also had the pleasure of a meeting with Serena, who was able to look at our progress on the intake form and give us some feedback and new information. We were able to discover a few more questions/fields to plan to add to the form, and got some helpful and illuminating information about the weight system in the food pantry, and what could be done by us to make weighing everything easier for them. We deliberating what information was important to be captured by the form, for the purposes of the Worcester Food Bank and the campus’s needs. We discussed the privacy of the data we are storing as well, and how much information we should be asking for as well as what information should be optional versus the data that was essential.

It is incredibly challenging to work with people whom you do not meet with nor can you deeply discuss the changes and work you are doing on the project. We have spent a lot of time trying to streamline communication between the two groups, make sure we all have access to the same resources, and being able to work effectively on a project at the same time. Although we have come a long way, there is still room to improve, as I feel rather uninformed about the efforts of the other group, and would like to know more.

This sprint was pretty tame, and I definitely learned a lot of different ideas and strategies related to organizational operations and effective ways to communicate and share your work with your cohorts/peers. Hopefully the lessons learned here will help me avoid fumbling in my career as I have in this project.


Sprint Reflection 4

Our fourth sprint started out a little better, with us fixing the issues, stories and tasks assigned on Git so that our group could be more clear on what was being done and by whom. This also helps us communicate with the other food pantry group outside of class. Narrowing down our stories and tasks helped us more clearly define our goals and what we were working towards. Once we were done fixing the stories and tasks, we discussed who would be taking on what task.

I took on the task of adding a weight counter component to the intake form. We first had to determine exactly why the weight was being kept track of and what changes needed to be logged to better implement the weight system the food pantry needed. After determining some of the needs of our clients, I started working on making the new component. However, our group quickly ran into issues as we had a lot of difficulty in maintaining our git repository. We spent a good class period trying to fix some of the issues we were having just getting the working code onto our local machines.

As it turned out, our git.ignore file was located in the wrong place, and a lot of the local files that aren’t supposed to be uploaded and committed were being placed on the group repository. NPM and NG commands were not working properly and things were pretty disorganized. It was hard to get a working version of the front end so that I could begin to make my changes to it. After a long class discussion with the Professor, we discussed better ways to make sure the repository isn’t getting dirtied with unnecessary files, and talked about how to add changes to the main branch and utilize pull requests accordingly.

Now that we finally have a working copy of the form back on the repository, I have begun work on the weight counter again. It is going to be a new component that tracks a current weight, and can add/remove to the weight depending on user choice. Other considerations are storing the time and date that changes are made to the weight, and making descriptions for weight changes. Other future things to consider are logging which Student ID takes out weight so that customers can only receive from the food pantry once a day.

This sprint was very stressful as our group fully realized some of the issues that can arise from git repositories. Although it was mind-racking to try to figure out what the problem was, it was very useful exposure and practice to some of the mechanisms of git, as it will doubtlessly be very important in the future. Although I am still wary that I can use git commands perfectly, I am definitely much more equipped to deal with repository related issues in the future, and am more aware of some potential issues that can arise from a misplaced git.ignore file. Hopefully I can avoid some of these problems in the future, as git problems can get annoying fast.

Reading Railroad

Read Constantly is a brief section, but it is an important apprenticeship pattern. Read Constantly is what it says. You need to constantly by reading and introducing yourself to new information in order to learn new ideas and improve. Most of the learning you do is from reading, whether its from sources on the internet or chapters of a good programming book. The more often you read and the better reading skills you develop, the better off you will be.

There is a book out there for every different programming language, every concept, every challenge you will come across in your professional career. I am currently reading a book that discusses the whiteboard problems brought up during many coding interviews. The book is long, and the content inside is dense, so it is important to read it carefully, take notes, and read it again to be sure of the information. That is my usual strategy for reading information that I need to learn.

My biggest challenge with reading constantly is feeling like I’m not absorbing all the information because I’m just trying to get through it. That’s why it is always good to do exercises in the book, if any are provided. That way you can do practical work alongside the reading that helps break up the monotony of reading and also gives you a different way to learn the content.

Another good strategy I use when reading is to take notes. There are often ways to boil down a text to its essential parts and the things you need to focus on and remember. Keeping notes, highlighting key lines, and keeping track of answers to exercises is a good way to maintain a reference if you ever want to brush up on what you just read.

Read Constantly is an important pattern when you want to learn something new or build a new skill. Good reading habits can open the way to learning lots of new things in a short period of time. It is absolutely the best way to learn quickly, especially if you are an independent person.

Lost and Found

The section titled Find Mentors discusses finding people in your field who are seasoned and have a lot of experience to offer, and to reach out to these veterans of the field and try to gain from them what knowledge they have to offer. It is a simple idea, but as the text explains, it is intimidating to just ask someone to offer their services and mentor you. It is a lot to ask, and not everyone is up for it after all. Besides, it is challenging to know who is even a good mentor, and who is not.

I consider many of my professors at Worcester State mentors to an extent. However, I wouldn’t say I’ve ever had the kind of mentor-ship detailed within the section. I can definitely relate to the anxieties listed about reaching out to someone. It can seem weird and uncomfortable. I suppose it is just a feeling you have to conquer if you want the best for yourself, however. After all, nobody else is going to ask for you.

From my perspective, Find Mentors is such an important pattern because there is a limit to how much most people can learn independently. There is such a huge advantage to having a resource like someone who has been through all the challenges you are facing and can solve some of the problems that come up. I hope that in my future I have the chance to meet someone who can offer me these advantages. Actually getting into the field is a huge hurdle, and having someone who has been through it and could coach me on how to navigate it would be incredible. It is just something I am going to have to search for.

Overall, Find Mentors seems like one of, if not the most important apprenticeship pattern I’ve read about and discussed so far. After all, finding a compatible mentor that is willing to dedicate the right amount of time for you would result in huge growth and development. It is hard to obtain this ideal, but it is something worth striving for.

Sprint Reflection 3

In our third sprint, we ended up having to revisit some of our previous work and recreate it, but better. After having a lot of difficulty with the previous way of doing it, using some old code from an old project, I decided to go with a more structured approach and read the guide on making template driven forms on angular.io. This guide was incredibly helpful in creating the form, as it has step-by-step instructions, example code and is very descriptive in the how’s and why’s of doing things.

Using the guide and their code as a template, I began to customize the intake form to the necessary specifications. I pretty much tried to recreate the “Thea’s Food Pantry Intake Form” given to us by the food pantry representative. I had to make different types of input for the text and the button input, and this time I was able to get some error-handling working, such as required certain fields before submission. Instead of using WebStorm as my IDE this time, I developed everything on Stack Blitz, a free online IDE and Angular editor that displays your application in real time. It was really useful to use, and hopefully once our group figures out its intricacies and how we can use it to collaborate within it, we can use it more in the future.

I was able to use some of the lessons learned in my Software Process Management class to make sure I maintained the clearness and readability of my code as well. I tried to use good spacing and white-space in the form so that it is clear where one module of the code ends and another begins. I also tried to keep my names both clear and consistent, so that variables containing the same information are named the same throughout the program. This is an issue that caused me much confusion last semester when I was developing a different web based form.

A unique issue I ran into while making the form was the compiler getting confused about the format Student IDs at Worcester State University have. Because my ID number is “0662077” the compiler kept thinking I was trying to use an octal, which would be something like 0x662077, and would not compile. I had to accept the Student ID as a string instead of text to fix this issue. Another issue with accepting Student IDs is that the program tries to get rid of unnecessary 0’s, which ends up making my ID Number different from what is desired. It took me a while to solve this issue, as I had no idea what was going on at first, but it was interesting to see how it could misinterpret my input data because of a preceding 0.

Overall, this Sprint was relatively productive for me, and I hope to continue going forwards. I have to find out what my next goals and challenges are and figure out what I’m doing next. Hopefully it will be something I’m familiar with.

Toying Around

Breakable Toys was an interesting pattern to read about. The premise is that in order to develop your skills, you should spend some time single-handedly developing small software projects. The example the text gave was maintaining a Wiki, which over time develops many skills in different areas. Ideally you will be able to find enjoyment in your toy so you can continue to grow from it. This toy is also something you can take with you, and something you can continue to learn from.

The idea of Breakable Toys was one I’d never really thought of before, but after reading it I can say that I’ve probably used the pattern to some extent. I can recall a time where I was learning HTML and CSS just to customize a web-page on an online game. At first, I had no idea what I was doing, but after some research and a lot of experimentation and trial and error, I began to have a much better concept on designing a web page. Meanwhile, I was enjoying the learning experience and the progress towards building something of my own. The ability to find enjoyment in what you learn is what eventually lead me to where I am in the first place.

After having read the chapter on Breakable Toys, I think I will try to be more intentional with my use of interesting and fun things that simultaneously develop my programming skills. One idea would be to develop a game in a new language, that way I can learn a new programming language and do something I enjoy.  Eventually, I can also develop the same game for any new programming language I wish to learn, as an interesting way to see some of the differences and similarities between them.

Something I’m learning about a lot of these patterns is that they are all sort of things that people just tend to do naturally to try and aid their own development. I guess that’s the whole point of the patterns, but it is really insightful to have some of these ideas put into words.