-
Sprint 3 Retrospective
Sprint 3 is now completed and it is time for the final retrospective. Although this sprint was shorter than the others, my team and I made good progress on our substem. With two other sprints under our belts, my team was able to complete what we needed to so everything would be wrapped up and ready for next year’s class to work on it.
A change we made that helped the team was breaking down our issues better as well as working together to tackle those issues. Our goal for this sprint was to have a completely working test so we broke down the process of creating the test into several issues. With everyone working together on the code, we were able to get through each issue quicker than we would have as individuals. We still faced challenges but being able to rely on the other members of the group was a big help.
Something that my team could improve on is understanding docker and using the servers. The most difficult problem we encountered was counting with the server. Our first few issues were not too difficult and we were able to solve them relatively quickly but getting the test to run automatically by connecting to the back-end server was difficult. We first ran into issues just connecting, then we had issues with the server timing out. We relied heavily on the guest info system group for help with this. Docker and the severs are a huge piece of this project so a better understanding of how to get everything working would have been a huge help to the team.
In this sprint, we only worked on the backend since our object was to get an automated test up and running. Our issues were mostly worked on as a group. The following are the issues that I was involved with for this sprint:
One of the easier issues we had was reviewing the current API:
Creating the getInventory manual test was another one of our issues:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/54
Another issue we worked on was fixing the get inventory returning a string bug:
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/60
As an individual, I believe I could improve by working on my collaboration. Even though my team asked for help, I personally did not. During this sprint, I relied on my teams to go and ask questions to the other groups. I think as an individual I could take more responsibility when it comes to collaborating with other teams.
I think sprint 3 was another positive experience for the team. We continued to adapt and make the changes we needed to that we talked about from our previous sprints. This allowed us to better ourselves as developers and get through the issues we decided to work on. Even though this is the end of time together working on LibreFoodPantry, we will take the lessons we learned with us as we start our careers.
-
Sprint 2 Retrospective
Now that sprint 2 is completed it is time for another retrospective. My team implemented some of the changes mentioned in our sprint 1 retrospective and I believe they were good for us. After completing sprint 2 we found some things we could improve in order for sprint 3 to be more successful.
Something that worked well for us was changing up who worked on what. We took the problem we identified in our first sprint and came up with a solution. In sprint 1 each team member only worked on a single project within our front end for all the issues. Doing this did not allow our team to become diverse and adaptable when we only stuck to one thing. For this sprint, we made sure to change our roles which was a positive for the team. Everyone got to work on something new instead of sticking with the same project they worked on in sprint 1.
Something that our team could improve on is how we break down issues. I actually think we did not do quite as well with breaking down issues as we did on our first sprint. Our sprint started off strong and the first few issues were broken down and weighed well but later we had a problem. For our testing issues, we did not break it down nearly enough. We thought creating the test would be simple enough but creating the test turned out to be more difficult. We split the issue by which test it was for instead of the steps needed to complete the testing. This was a mistake because as individuals it was a lot to try to take on at once. We ran into a lot of issues and then trying to share what we did to get past each issue and play catch up with each other still made things difficult. For our next sprint, we need to either work as a team to tackle a large problem or break down these larger problems into smaller chunks.
Since we switched up jobs for this sprint I mostly worked on the backend of the inventory system. The issues I worked on are the following:
My first issue was updating the JavaScript in the backend to modern JavaScript
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/46
My next issue was creating the test for getInventory
https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/backend/-/issues/54
As an individual, I believe I could improve by getting a better understanding of how the project works as a whole. While working on my tasks, I only looked into the pieces of the project that needed to be worked on. I think going through the project more thoroughly and understanding what does what could have made fixing some of the issues easier.
Overall I think sprint 2 was a good experience for the team. We took our changes from sprint 1 and implemented them for sprint 2 which was a good change for the team. We found some more weaknesses that can easily be adjusted for sprint 3. With multiple chances to update our strategy, I expect that sprint 3 will be even more successful than our previous two sprints.
-
Apprenticeship Pattern: Learn How You Fail
This week I read the Apprenticeship Pattern Learn How You Fail. The context of this pattern is that failure is inevitable. It happens to everyone eventually. If someone has never failed then they have either avoided pushing boundaries or learned to overlook mistakes. The problem given with this context is that your learning skills have enhanced your successes, but your failures and weaknesses remain.
The solution given for this pattern is to identify the ways in which you tend to fail and try to fix them. This pattern is not about self-pity or trying to make things perfect. It is about gaining self-knowledge about the habits and behaviors that lead you to failure. Once you become aware of the things that trip you up you will have the choice to either fixe these problems or cut your losses. You will need to accept that there are things you’re not good at or that would require a great deal of time and effort invested to fix the problem.
The action plan to help solve this issue is to use your choice of a programming language and a simple text editor to write an implementation of binary search in a single sitting. Then write all the tests you think you will need to confirm the code is correct. Before running the test and compiling the code go back and try to fix the mistakes you have discovered so far. After that run the code and see what errors are still there. Think about what you learned and how the errors could have happened when you thought the code was perfect.
I chose this pattern because as this pattern said, failure is inevitable. I have had failures in my software projects and I will certainly have more failures in the future. I want to be able to fix these failures by correcting my weakness and bad habits. Following the action plan given in this pattern will help me understand where I might have blindspots for errors. I also need to think about my past failures and figure out the common cause that leads to them. I think taking the time to do these will be a great learning experience for me and it will help me in my future career.
-
Apprenticeship Pattern: The Deep End
This week, I delved into the Apprenticeship Patterns book once again and explored the chapter on “The Deep End”. The context of this pattern is that you are taking small steps and are left unsatisfied with your learning. You start to fear that you are in a rut, where your skills are decaying. You need to grow your skills, confidence, and your portfolio.
The solution given is to jump right into the deep end. Waiting until you feel ready can lead to never doing it. Growth only happens when you challenge yourself. This can be risky because failure is possible, but without risk, you cannot grow. This does not mean lying about your qualifications on a resume, it means taking promotions or tough assignments when they are offered. Even though taking on risk is advocated in this pattern, it makes it clear that there is a responsibility to offset that risk as much as possible. This could be as simple as having someone who can be there to help you out when you need it.
The action plan given is to think of the biggest project you have worked on and then try to find and measure its complexity. Then use the metrics you came up with to measure every project you have worked on and plot them. When you start a new project, you can compare it to your old ones and make choices based on it.
I chose this pattern because I have felt like I have been in a position where I am only making safe moves. It is a lot easier to stay at your current skill level and never try something new, but it is not sustainable. I need to constantly challenge myself so I can improve my skills as a software developer. Currently, the list of projects that I have on my portfolio is not long. Most of what I have coded has been small class work or homework assignments, but to stand out to employers, I want to get more complex projects under my belt. The takeaway from this pattern is to keep challenging yourself to improve your skills. Do not settle for where you are at because that is when you can slip into mediocrity.
-
Apprenticeship Pattern: Reading List
This week I am jumping to chapter 6 of Apprenticeship Patterns. The pattern I read was called Reading List. The context of this chapter is now that you have become proficient in your first language, you start to see the massive amount of information you still need to learn. The problem with this is there is more information that you need to learn than you can keep up with.
The solution for this is to track the books and other sources you plan to read and remember which ones you have already gone through. This pattern mentions it might be a good idea to store it in a place that will allow other people to benefit from it. Not only is this pattern used to manage books you are reading but it also helps with reflecting on your past reading habits. One of the most valuable things you can get out of a book is finding other books in the bibliographies that will be good information.
The action plan given to help with the problem is to create a text file and put in all the books you are currently reading. The text file will be your reading list and make sure you keep it up to date.
I chose this pattern because I thought it would be good to know what to do after I have really mastered my first language and am ready to move on to new things. This will probably be a little while before I am ready for these next steps but being prepared will help with the transition. I will make sure to try out the solution for this pattern but use more than just books. Books are useful but there are plenty of other good resources that I can learn a lot from such as articles, videos, and blog posts, as well as learning from other people. A takeaway I get from this chapter is there will always be more to learn so having a solution to track what you are doing will be a big help with getting through as much as possible.
-
Sprint 1 Retrospective
Sprint 1 is now over and overall I believe my team and I did a good job for our first sprint. I think there are lots of things we did well but there is still plenty of room for improvement.
The first thing our team did that I thought worked well was breaking up and weighing our epics. We took the larger epics like updating the documentation or revising the directories and split them up so each problem subgroup would have one. This worked well because each team member got to work on a piece of each epic which gave a good experience to everyone. Everyone working on similar issues was also good because when one or more of us ran into a problem the others were able to help or the team members working on frontends were able to tackle a problem together since what we had to do for this sprint was very similar. Our weights for the issues were also a pretty good estimate. We were able to get the full 35 points of work done right in time for the end of the sprint.
Something our team can do to improve for the next sprint is to spread out the work better. In this sprint, we mostly worked in a single subgroup but I think switching things up would benefit us. Since we only worked in a single subgroup only three of our group members got to work on the frontend, one person got to work on the backend, and the last member only worked on API. For our next sprint, we want to switch these roles so every team member can get experience in each area.
I worked on the CheckOutGuestFrontend as well as reviewed and merged code from other team members. The issues I worked on are the following:
The first issue I had was to update or add the files for the documentation, licensing, linting configuration, .gitignore, and .gitattributes to match the inventoryAPI.
The next issue I worked on was revising the directory structure to match the inventoryAPI again.
I then worked on updating the devcontainer files to match the inventoryAPI.
The last issue and the most difficult one I worked on was updating the pipeline/CI files.
A change I could make to improve as an individual is spending a little more time outside of class working on issues when I get stuck instead of waiting for the next class to ask about the problem. Some issues need more direct help to figure out but I think spending more time trying to figure out an issue instead of asking for help after a short time would be good for improving my problem-solving skills. I think another individual issue that can be improved is getting over the fear of completely breaking the code since I am unfamiliar with how certain things work. Sprint 2 seems like the work will be less trying to match the code up to already existing code so having to dedicate more time outside of class will be necessary.
Overall I think sprint 1 was very successful but there is always room for growth. By doing the changes the team discussed I think sprint 2 will be even more successful.
-
Apprentice Pattern: Expose Your Ignorance
This week I continued with chapter 2 of Apprenticeship Patterns once again. The pattern I read was Expose your Ignorance. The context this pattern gives is the people paying you to be a software developer are depending on you to know what you’re doing. The problem with this is your team members and manager need confidence that you can deliver but you are unfamiliar with some of the technologies.
The solution to this problem is to show the people depending on you that the learning process is part of delivering software and to let them see you grow. Software developers build strong relationships with clients and colleagues so telling the truth about being in the learning process instead of telling them that you know how to do something you don’t is important. Doing this will build your reputation on your ability to learn and not what you already know. Asking questions is a good way of exposing your ignorance. Those who do not take on the process of exposing ignorance become experts in one domain and develop a narrow focus that is important for the industry to have experts but it should not be the goal of an apprentice.
The action suggestion is to write a list of five things you don’t understand about your work. Put the list somewhere others can see it. Then get in the habit of refreshing this list as your work changes.
The reason I chose this pattern is that I am expecting to run into this situation when I get my first job as a software developer and will probably face this problem during my whole career because there will always be some new technology I do not understand. I found the solution given to make sense and it brought up some good ideas but the action plan I disagree with a bit. I think it is a good idea to list off things that need to be worked on but I don’t think it needs to go in a place others can see. As long as the list is refreshed frequently and the skills are being worked on I think it’s fine to keep it to yourself. Of course, the part about being honest with others about not understanding things and asking questions should still apply.
-
Apprenticeship Patterns: Concrete Skills
This week I continued with chapter 2 of Apprenticeship Patterns. The pattern I read was Concrete Skills. The context this pattern gives is wanting to join a talented team that can provide you with better learning opportunities than you currently have. The problem with this is the team you want to work with has no incentive to take a risk and hire someone who may not be able to contribute to the team’s work or even indirectly contribute.
The solution to this problem is simple yet challenging. You need to acquire and maintain concrete skills. Some of the skills you will need will just be to get you past HR filters and managers that look for buzzwords when hiring. Others will be to assure your team members you can be put to good use and not need to be watched over. The skills you bring will answer the question “If we hire you today, what can you do on Monday morning that will benefit us?” Later in your career hard skills will become less important than your reputation and your portfolio of previous work and qualities.
The action suggestion to reach the solution is to collect the CVs of people’s skills you respect and identify five discrete skills noted. Then determine which ones would be immediately useful to the kind of team you are looking to join. Then put together a plan and a toy project to demonstrate the skills you have quired.
The reason I chose this pattern is that I am in the process of looking for a job. I want to find a good company to work for and join a team of developers where I can learn and grow not only my career but my skills as a developer. I could relate to the problem because where I am at in my career as a programmer I do not have any industry experience so I will need to do everything I can to better my odds of getting hired and being able to contribute to a team of professionals. I will have to look into taking the actions this pattern recommended in order to expand my concrete skills to the ones I will need in order to stand out to hiring managers.
-
Apprenticeship Patterns: Your First Language
This week I dove into chapter 2 of Apprenticeship Patterns and read the pattern Your First Language. This pattern was about just starting out and only understanding a little bit of one or two programming languages. I thought I would go back to the basics for this week and this pattern would be a good read for that.
The problem this pattern presents is the feeling your job or finding a job depends on your proficiency in a specific programming language. The solution the pattern gives for this problem is to pick a language and become fluent in it. It says whatever language you pick should be your main one for years and will become your default skill you work on when practicing. The pattern mentions the choice is a challenge because it will be the foundation of your early career. Some of the examples the pattern talks about for how you can work on becoming fluent in a programming language is to work on a toy application and write tests for your programs so you can understand what is going on better. A big part of this pattern was finding an experienced coder that you can work with and help mentor you and how it can make the difference in spending minutes on a problem or days. The pattern also mentions the importance of not getting stuck on only using a single language and preventing you from learning a new one.
One of the reasons I chose this pattern is because I can relate to the problem it presents. As a college senior in my last semester finding a job in the software industry will be coming up very soon. I have used several programming languages over my years of school so I have not had to focus on a single language. After reading this pattern I think java should be the language I focus on and become more fluent in because it is the one I know best already. I think I should follow the advice of the chapter and look into working on a small project so I can get better at java. Another thing I would like to do is find a mentor to occasionally help me out. I think that could be very useful for my career. Overall I thought this was a good pattern to read about and it gave me ideas of what I can do to improve my programming skills and create the foundation my career will be built on.
-
Apprenticeship Pattern: Expand Your Bandwidth
This week I read the apprenticeship pattern called Expand Your Bandwidth. This pattern is found in the chapter on perpetual learning. The context for this pattern is you have gathered a basic set of skills and your understanding of software development is narrow and focused only on low-level details. This pattern’s purpose is to fix that by expanding your knowledge. The book explains the solution to this problem and gives several examples of what you can do to help increase your knowledge.
It starts by explaining that at this point in your apprenticeship, you have been drinking steadily through a straw but sometimes you have to drink from a fire hose of information. The book tells us we must develop discipline and techniques that are needed to effectively absorb new information and be able to understand, retain, and apply it. We must do more than just read a book but seek knowledge and experience in multiple dimensions. There were several examples of this. A few examples are using online courses, videos, and podcasts, attending technical conferences, reading a book, and contacting the author with questions.
The author made it clear that it is necessary to shut off the fire horse so you can focus on project work because it can be easy to get distracted and not get any development done.
I found this pattern to be very helpful because it helped me realize that sometimes I am gonna have to put in a lot of extra work. I can’t always be going at a steady pace and I will need to work on my discipline when it comes to learning and researching so I can expand my knowledge and improve my skills as a software developer. I also liked how it pointed out the dangers of going overboard with this. I felt like that will be something important to keep in mind as I am learning. I found the examples of where to look for this knowledge helpful and it gives me a few new ideas on where to look for new information or get some experience. I think this pattern will be especially helpful when I am looking for a job after graduation because I see a lot of programming languages I have not heard of and technologies that job listings mention and a fire horse of information is exactly what I might need to get ahead.
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Ryan Klenk's Blog 