Sprint Retrospective 6

During this sprint we actually accomplished more than any of the previous sprints. Together as a group we added in different pieces to the intake form and submitted a pull request with our completed tasks. I personally added the primary household income field as well as worked with Tic to make adjustments to my previous task, household size. Everyone else more or less completed their tasks as well. This sprint showed that given the foundational pieces that took us most of the semester to acquire, we could complete some notable work in a sprint.

In terms of how we divided the work, we simply each took a task on a volunteer basis until everyone had one task. After this point there was still one remaining task that was purdenant to what we expected to get done in this sprint I took on the household size task at the end of the last sprint and then took on the primary income source task as an additional piece of work. This worked out nicely as there was no forced level of responsibility but allowed everyone to work on tasks that varied in difficulty for everyone’s individual level of understanding of the tools being used. If there was anything I would change with this way of working is that I think in a perfect world our tasks wouldn’t all be making changes to the same two files. In a perfect world, we would have had a couple people working on those tasks while we had other people developing another aspect of the final product. Unfortunately, there simply wasn’t enough work established for everyone to have something to do if we wanted to have a clear understanding of what we were developing.

For my personal work, I had to relearn how to do ng-if’s and the basics of angular. I remembered most of the html syntax but there were little things that I forgot but almost all of angular seemed to leave my brain since CS-343. The most difficult part of searching for information on Angular is that while incredibly outdated, many of the top results when searching are for AngularJS instead of Angular 2+. If not properly inspecting the tutorial, it could be relatively easy to miss this important detail. When completing my task regarding the household size, I had to come up with a way to make sure that if a person was a commuter, they were properly entering “1” as the value. I had trouble making this persist upon submission and originally decided on a hard overwrite that would default to 1 regardless of what a person entered for that field. The problem with this method is that a person could still consistently enter non-1 values and never learn that this is not expected. Tic came up with a great idea when developing his task to create a very much visible warning message near the box for the field that needs correction. I “stole” this idea and adjusted it to my field accordingly. When developing my other task for primary income source, it was much easier than the other task as there was no real logic to work into the html other than making sure the data was passed on submission to the model. The only other real logic was that a person could only have one primary income source, but that was fairly simple.

Overall I feel that we are in a good space heading into our final presentation. We had struggles early on and throughout most of the semester, but we finished strong. We finished with by far, our best sprint of the semester and I’m happy with what we got done during this final sprint.

Pattern 10 – Draw Your Own Map

For my last pattern for this blog, I wanted to do one that I’ve been waiting to do until the end. This being potentially the last formal software engineering class I will take, I wanted to read “Draw Your Own Map”. This pattern talks about the importance of working in an environment that will help you reach your personal goals. It also makes it very clear that the person who has sole responsibility for taking the first step in each of the small goals that lead to the high level goals that make up every “goals” list, is the reader. We need to take responsibility and not blame any company, or position that could potentially be holding up back from reaching our goals.

I’ve always been a goal oriented person, whether it be in terms of finances, academics, career, or personal. So far I’ve done a relatively good job at achieving my goals and hope to continue this trend throughout my life. In relation to career goals, since I started my college career I knew that I wanted to be involved in software development in one way or another. Through my internships, I’ve learned what I look for in a company and the position that I will be starting upon graduation. I consider it drastically important when interviewing with companies to ask the employees what their goals are. If they’ve been with the company for years and their goals are similar to yours, it should mean that the company is a good fit. For me, I looked for companies that value mentorship, are current with today’s team-based practices, and allow for good work-life balance. On top of all of these, the ability to “be water” and move around within the company if my goals change is also important to me.

Everyone’s map is going to be different but it is important to stay fluid in your mindset of what is important. Do not allow yourself to be pigeonholed to a position that you may one day hate and also makes it difficult for you to find work if you decide to move on. Find a position where the company values your work ethic and desire to learn over the specific skills you have coming into the position, while they are important, they aren’t what will make your relationship with the company last for the long term.

Pattern 9 – Find Mentors

This week I decided to learn about how to “Find Mentors” by reading the pattern. This pattern gives advice about why and how apprentices should seek out to find mentors to continue down the path to becoming a journeyman. They give tips about attending conferences, joining online forums, and taking your potential mentors out to lunch if you have the opportunity.

I do agree that finding mentors is greatly important in the development process to become a successful software developer, but I think this pattern idolizes a certain type of developer and therefore limits the opportunities for mentorship for those who try to strictly follow what the pattern is advising. This pattern seems to focus on those who are directly working on the development of a particular language, framework, tool, or some variant of open-source software. They even pretty much open with the idea that it is very likely that your mentors are not local and that you will likely never meet them. I think that this is where the pattern is failing.

From my experience, there is almost always someone, or a group of people within a company that those with technical positions turn to for mentorship and advice. At my most recent internship, it was a man named Kurt who has worked on the proprietary software (Oracle) before signing onto the company that we both worked for over the summer (TJX). He initially was a contractor from Oracle, but TJX found that his expertise regarding the frameworks that made up our software made him too valuable to let go of and they hired him full time. He immediately became the go-to guy whenever anyone had a question about our software. He had been working on it for over 15 years and had gone through over 10 iterations of the software. A key thing to note is that while everyone asked him for help, they weren’t asking for mentorship. This is something that came with my internship as he was selected to be my “buddy”, which was just a fancy word for mentor. We spoke several times throughout the summer about both career goals, and different ways to solve problems. We spoke about how to solve certain problems that were specific, yet more general than our specific code base. To get this kind of mentorship, I didn’t need to lurk on an internet forum, and the same went for everyone I worked with that wanted to learn from him. All I had to do was ask. There will likely be a Curt everywhere, any of us end up working, and I plan on utilizing their mentorships.

Sprint Retrospective 5

During this sprint we organized our project boards more and actually made some progress to enhancing our form. I personally worked on an issue that added some styling, a little bit of reordering, and added a new field to the form. There was some functionality that needed to be added for this field to work properly so I had to do a little bit of review to remember how to perform certain functions in Angular. This sprint was again, more productive than the previous and I’m content with what was accomplished during this time. I think there could have been more work completed but this was a problem with communication between groups more than an individual issue between group members.

The first week of this sprint was honestly, a complete disaster. We were happy as a group at the end of our sprint planning and some group members were already starting to work on what they thought were “their” tasks. The problem was, we never assigned the tasks to individuals on Github and then the other group thought they were working on the same material and claimed it, also without directly assigning someone to the work. Miscommunications like these seem to be a recurring problem with this project and I honestly think it is partially due to the inability of the two groups to meet face-to-face to directly resolve this issue. I think this is an issue that would be immediately resolved if all groups working on this project next year were in the same section of the capstone. This would allow for direct, brief, meetings between the two groups to discuss any possible issues in overlap of work, claiming of work, and even just generally sharing what each other group is thinking of for a vision of an up-and-coming feature or functionality. While we’ve done our best to document our thought process to the extent of sharing the flow of the entire intake form, it still seems like both groups are not entirely on the same page.

There are fields that the other group seems to have talked to the customer about and that they apparently want, but when we spoke with the customer, they explicitly told us not to worry about the fields in question. These issues can be found on our Github as optional fields, and the address field.

From a stance of what was accomplished and what went well, we’ve added some new functionality and seemed to have discovered a way for the form to flow and generate fields as needed to maximize efficiency. While most of this functionality is not yet implemented, I made the first step in adding this functionality by adding the “household size” field. This involved adding a new field to the constructor for the customer object, adding some ng-if functionality in the HTML and even adding a little bit of styling to the submitted output. While not all of this was explicitly mentioned in the issue as needed for completion of the task, I felt that adding the styling was something that we were going to need to do eventually and just added it. This was documented in both my commit message and in the pull request made for merging this completed issue.
Github issue (household size): https://github.com/cs-worcester-cs-448-sp-2019/Theas-Pantry/commit/927b98896f32fed1325e57712467a420ab6c93ec

Pattern 8 – Record What You Learn

I decided to read “Record What You Learn” for this week’s post. This one is pretty self explanatory, record what you learn. The pattern says to do just this, and explains that this is a way to review key learnings throughout your journey of software development craftsmanship. The pattern also notes that it is important to not let your writings become a graveyard for what you have learned. By this, they mean that you should consistently go back and review what you’ve written in the past to possibly amend the posts, or to find links to other notes you have written.

I agree that this is a very valuable “study” technique and it works for all facets of learning. The most difficult part of this, is that this is a very time intensive way to remember everything. As you learn more, the bigger the library of written lessons gets. This mean that every time you learn something, that review session gets longer. I think that this means that it is important to acknowledge that you simply will have to relearn things from time to time, but documenting what you’ve learned for higher level topics, is a great way to save time in the future.

While I do see how this could be difficult for an individual who is learning vastly different and often irrelevant topics when compared to each other, this is definitely something that can be used as part of a company project wiki. Large companies are constantly hiring new personnel who have to play catch-up to learn a code base as well as the coding styles of their peers. Having some sort of blog or wiki for the project could help these new-hires get acquainted with how the company functions and how to solve problems that are specific to the particular stack and business logic that the company is utilizing.

I do not know if I see myself personally following this advice, because this is not really my learning style. I tend to learn something by repetition instead of documenting what I’m doing. However, I do recommend that anyone who learns well via methods like flash cards, studying notes, etc, give this method of learning a try. It could be quite useful to someone who succeeds` when applying these learning methods.

Pattern 7 – Sweep The Floor

I decided to read “Sweep The Floor” for this week’s post. This pattern discusses the idea that even if you feel overwhelmed and unable to contribute to your team, there are still ways that you can contribute. This means that even if you can’t tackle the complicated tasks and project straight out of the gate when you start a position, it is still important to be involved and demonstrate that you can deliver quality work in some way, shape, or form.

This is great advice especially for us newly graduating apprentices. When I was at both of my internships, I did plenty of “floor sweeping”. This was anything from writing up documentation, drawing out flow patterns, taking notes during meetings, and writing unit tests. One of the biggest benefits to sweeping the floor when you start a new job, is that you are learning the business logic first, then tackling the complex coding challenges that come with the job as well. For example, this way if your company is working on software that has five different user types and dozens of permissions that require different user types for access, you can learn how this works through writing the documentation and use this knowledge in future tasks for the software. You might even find yourself leading a discussion on the business logic even though you might not have contributed notably on a technical level. From my experience, it made me feel like I was one of the team. I could contribute to conversations, and offer ideas for possible solutions even though I wasn’t entirely comfortable with how to write the code for the particular task.

I also don’t think that this is limited to newly graduating professionals, or even in the world of software development. This line of thinking can be applied to all facets of business, as there are always menial tasks that no one wants to do but offer a learning avenue with a lower risk. When I worked in a hardware store/rental center, I had to learn the software we used as well as how all of our equipment worked. I cleaned the equipment and wrote up requests for customers as a way to learn more about diagnosing machines and giving customers better feedback when they called. Sweeping the floor is good advice both literally and figuratively.

Sprint 4 Retrospective

This sprint seems to be the last of nearly entirely research sprints. Now we have the tools we need to get down to business and make some meaningful changes to the code. We have access to the replica of the current, existing system, we’ve gained insight into whether or not we can use AccuTrack, and we learned how we will have to integrate OneCard Scanning. We’ve also organized our story boards to a reasonable state but there is always room for improvement and there are definitely pieces that we are forgetting to add that we’ll come up with on the go. Now it’s time to build stuff.

The first thing we did the sprint was something that actually happened at the very tail end of the last sprint, we gained access to a working replica of the existing system with help from Michelle, Beaulieu, the graduate assistant for the food pantry project. This let us see what flaws there are in the existing system as well as an idea of the complexity that the food pantry workers are familiar with. From obtaining access to this system, we learned about several new stories/epics that we’ll need to add to the growing list of things to do. This included additional fields/questions for the intake form as well as an entirely non-existent report system that we thought was somewhat integrated already. There are other small examples of things that we caught but those are the highlights.

I also met with Bridget Joiner from the student affairs office and discussed theproject. She was the liaison between Joanne and Laura Caswell, the person in IT who was setting up the system within AccuTrack for the food pantry. From this meeting, I learned that it was unlikely that we would be able to integrate with AccuTrack at all but that it was also a good idea to meet with Laura Catwell to get confirmation and possibly hands-on experience with the AccuTrack system. Following this meeting I met with Laura and confirmed that it was not possible to use the AccuTrack system and I also learned that the food pantry workers never bothered to learn the AccuTrack system so the lack of utilization won’t make a difference. I also learned that the level of communication between all parties was poor to say the least but this was a lesson to develop better communication in the future with all parties involved. Laura also confirmed that we could use a scanner and how to access the ID numbers on the card.

Next was the big move from Trello to GitHub issues. While everything has been moved from Trello to GitHub this is an ongoing process and we’re continuing to improve our system as we go along. We’ve decided that anything more than a task belongs on the LibreFoodPantry repository and all tasks should be on the one specific to our sections. We’re continuing to make organizational decisions regarding specific wording, tagging, and branches.

We’ve also obtained the scanner and confirmed the pattern that occurs when scanning OneCards for future integration of the device.

I also spent some time trying to correct some version mismatch problems with my local system and the current code that was on GitHub as of yesterday. There seems to be a new push from the other group that will hopefully resolve these issues, as the old version they had pushed used older versions of software.

This sprint was productive but not in ways that we expected. We expected to have more done regarding the actual software but instead we learned much more about the future and the long term goals of this project. We would have needed to have these conversations at some point so getting them out of the way now is not a bad thing. Hopefully by the end of the next sprint we’ll have some more developed, working software to discuss.

GitHub links to both repositories mentioned:




Pattern 6 – Be The Worst

For this post, I was looking for an eye catching pattern name and “Be the Worst” definitely caught my eye. After a second a of thought, it was pretty obvious what this pattern would be about. This pattern breaks down why it is important to not be the big fish in the little pond. It encourages apprentices to not rush into leadership roles and to not strive to become the best on your team and stagnate with your position. Instead, if you find yourself at the top and lacking learning opportunities, it may be time to move on and find the bigger pond, to surround yourself with higher tier developers when you leave.

I almost entirely agree with this pattern. I remember growing up in a relatively small town, where we had a couple athletes who were notably better than anyone else in the town at their respective sport and position. None, yes none, of them tried to get into bigger school districts where they may be challenged more and had more of an opportunity to get scholarships and even potentially make it professionally. Instead they all enjoyed their high school careers at a school with roughly 500 students in a division 3 conference. They didn’t aspire to leave the little pond and they never made it anywhere in terms of athletics. There are definitely parallels to this even in the college world and looking for positions directly out of school. There are always going to be people who are happy to just cruise by and not learn everything that they can at each step of their careers. I honestly feel like these are the people who are most likely to never even get a job in respective majors and then somehow blame the university for not finding them a job with a 2.0 GPA. No one owes you anything and you can’t expect anything to be handed to you, knowledge especially. There is always more to learn and never enough time to get everything into a four year curriculum. Never settle for being the best you know. All that means is that you need to meet more people.

The only part of this pattern I disagree with is how the authors try to sway readers from promotions. Promotions and new responsibilities even outside of coding are definitely important to becoming the best within a company. If the goal is to rise through the ranks of a company, isn’t this an obvious side effect? That being said, I will definitely consider this pattern as I move along in my career.

Pattern 5 – The White Belt

For this post, I decided to read the pattern “The White Belt”. This pattern talks about the ability of a software developer, and craftsman, to unlearn something and use an entirely different approach to solve a problem in order to maintain the ability to learn. The pattern talks about the idea of getting stuck at what seems to be your peak potential but that this is merely because you aren’t trying something completely new that would force you to try to solve the problem with a new approach.

I agree with the overall premise of this pattern. Personally, I’ve found it incredibly difficult to try to learn new languages without internally trying to write Java in language X. This summer I had an internship where one of my projects was to make a prototype program for a chat bot using Microsoft’s existing AI technology. This meant that I had to veer away from my good friend Java and attempt to use a new language, C#. I honestly don’t remember that much about C# other than that it looks like a lot like Java and I was able to manipulate the code so that it worked. I spent the entirety of the project focused on how it was similar to Java and how to write Java in C# and never even remotely became a master of the language. Granted, it was a short term project (roughly 4-6 weeks and 20-30 hours a week), so mastery was never feasible. The problem is that if I have to work on another C# project at some point in my career, I will have to start over. I never unlearned my Java knowledge to write in C#.

This coming summer, I’ll be starting a position where I will almost exclusively be writing in C++, a language I have never written a line of code in. Before I start the job, I’m giving myself time to learn the basics, but I know that I’ll need guidance along the way from the subject matter experts at this new company. There will most certainly be moments where I am completely dumbfounded about how to solve a particular problem, or what is wrong with my solution. I’ve learned that over the last couple of years of interning, and at those companies I was using a language I thought I was pretty comfortable in (Java).

Being able to put on the white belt and learn from the masters is one of the things you hear about from everyone in almost every field of technical work. I plan to put on my white belt as soon as I walk in the door at my new company.

Sprint 3 Retrospective

In all honesty, this sprint was definitely the one where we’ve made the most progress. During this sprint we were finally able to get access to the input form and sample output from Joanne and her graduate assistant, Michelle. It took several weeks of continuous emails and a face to face meeting to finally get access to the documents. This has been the story of this project for this semester at this point. From my experience during my internships, the length of time to get a response from someone can vary and maybe it is different because of the many different projects and classes that everyone involved is responsible for, but this seems a little outside what is reasonable.

Our biggest problem to this point in the semester has been a lack of communication between our customers and the other necessary parties that can get us moving with the key details of our project. We were warned at the beginning of the semester that our customers likely didn’t know what they wanted and this couldn’t be more accurate. They have the best of intentions but lack the technical foresight to think about how to organize their project to make it any bit future-proof. We’re doing our best to find a happy medium between a complete rework that makes it more scalable and continuing to follow the flows that they are just becoming familiar with.

The other group working on the food pantry project is doing more of the heavy lifting at this point as they’ve already started working on the interface for what will hopefully one day be the new food pantry software system. It is difficult to communicate with them as we’re basically on opposite schedules and everything is on a two day delay for the most part but we are making the most of what we can do.

My role for the last two weeks has been more of a product owner compared to a developer and it has for the most of this semester. I’m not upset about this as it has been a different experience than what I am used to. I’ve been our point of communication with Joanne and the food pantry workers as well as often the one organizing our Trello board and conducting the planning meetings. There is definitely some overlap between product owner and scrum master responsibilities but I haven’t done almost any code writing this semester. I honestly think what we’re doing better as a group as the semester continues to roll on, is rolling with the punches. We’re getting better at reacting faster to the curveballs that are being thrown our way. We’ve been told that everything that needs to be on the current intake form is already there, but after mere minutes of review, we’ve noted several questions that are missing based on the reports we are being asked to output for the final project.

We’re also getting better at splitting up the work between our group. The roles have yet to see much change as the semester progresses but again, I’m not upset about this and it doesn’t seem like anyone in my particular group is. We’re assigning stories/tasks better so everyone has something to work on throughout the sprint and we’re documenting who is working on what in our Trello board. Hopefully we’ll be able to utilize the issues system on Github as soon as our repository situation is resolved but we’re making the most of what we can do with the tools we are given. We’re noting down which particular project each issue/task/story belongs to by noting “[project name]” at the start of the blip on Trello. Overall, organization has improved and hopefully we’re developing a standard that can be utilized well after we are handing off this project at the end of the semester.

I would provide links to the projects we’ve worked on but they are exclusively private. This includes our private group Trello, Slack, and the access link to our newly acquired mock form/output.