For this third and final sprint, we were the most efficient and organized thus far. It is really neat to look back to the first sprint and see how much we improved as a team. From us in the first sprint not really knowing much about how to work as a team in sprints, to now working well together as a team for many weeks and understanding the sprint structure pretty well. Though the structure seemed somewhat daunting at first, I have grown to like the sprint structure and the entire workflow throughout my time of working on the Reporting System. I think that the best way to learn anything, especially for me, is through experience, so diving right in and getting first-hand experience with sprints, sprint planning, sprint retrospective, etc. really helped me to understand how it works, not only in theory, but in a practical sense.

The first thing that we improved upon over time, and even more so with this sprint, is the sprint planning. At the beginning, judging what we thought we could get done during a sprint was mostly just guessing work, but as time went on of working on issues, we were better able to judge how long an issue would take to work on and the weight that should be assigned to each issue. However, even with the first sprint, and definitely now, we were good about finishing as much as we wanted to during each sprint. This means that we did a good job of judging how long it would take to work on each issue, and how much we could get done.

The next thing we improved at over time was the sprint retrospective. This ties into how we were able to do well with the sprint planning, because only through discussing what we did well, and what we could improve upon during the sprint retrospective could we focus our efforts upon improving specific areas and keeping up with what we were already doing well. This is why I think that the sprint retrospective is one of the most important parts of the process. This is because even if team members are individually good, only by discussing with other team members about your strengths and weaknesses can you assist each other, and improve as an individual, as well as overall as a team.

I think that the most impressive thing about our achievements over the 3 sprints is that we now have either a working, or very close to working system. While at the beginning of the sprint we only had some of the backend, we now have a working backend, frontend, and API. Additionally, we have the endpoints and functionality in place for the ultimate goal of the system, generating a report. It is really neat to think that we as a team achieved the goal of having the system generate a report, and all the components coming together to do so, as well as the functionality in place for RabbitMQ to interface with the other systems. It is also really neat to think that future teams will be building upon what we did, using the code that we wrote, and using the documentation we wrote as a roadmap. In this way, we had an impact upon the future of the Reporting System, and the whole food pantry project as a whole.

Commits:

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/commit/7ddbba9a43a71fa588c8b34f3ca1a16d43c39709

Updated backend to include more detail, including the containers and images used, and the endpoints available.

https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/commit/c0a121daa6e5d45ec00fa01642289677119d658a

Updated API to include the methods for the endpoints, as well as what parameters are required.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.

This Apprenticeship pattern, “A Different Road” is about admitting to yourself if software craftmanship isn’t the career path you want anymore. I think that this is a very important lesson to be learned, because it is much more harmful to yourself, and others that you work with in your field if you stick through doing something you don’t like than if you either take some time away or change career paths entirely. By doing something you don’t like as a career, you are doing a disservice to yourself and others, because you most likely aren’t doing the best as a software developer as you could if you don’t like it, and others may notice that you don’t like it and that you aren’t doing the quality of work that you used to, or that it is less than acceptable.

I think that instead of changing career paths immediately if you aren’t enjoying it anymore, maybe a good idea would be to take some time away, and then return to it later and assess whether you still aren’t enjoying it or not. The reason for this would be to see if you just have burnout from doing it for a while, and then maybe the time away would fix that burnout. You could have burnout for a number of reasons, but maybe taking some time away would fix it by helping you clear your head, and then if you’re still having burnout then it might be time to seriously consider changing careers.

Ultimately, I think it’s best to not force yourself into a career you don’t enjoy doing, and that goes for any career path, not just software development. Not enjoying what you’re doing everyday means that you’re likely doing it worse than you would if you were enjoying it and will inevitably lead to unhappiness. In my opinion, it is much better to do something that you enjoy doing and something you’re passionate about than something that has better pay. Additionally, there will always be other opportunities down the line, meaning a temporary career shift doesn’t have to be permanent, and you can either continue doing what you are, or return to the old job if you’ve discovered that’s what you like best.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.

This Apprenticeship pattern, “Expose Your Ignorance,” is about admitting to others as well as to yourself the gaps in your knowledge. You must admit to yourself the gaps in your knowledge before you can admit it to others and begin to ask meaningful questions to expand your knowledge. I think this is really important to know because if you are unwilling to admit that you don’t know some stuff, then you will be unable to learn it, and furthermore unable to get help from others who possibly know more about the topic. Only by admitting that you have more to learn can you open yourself up to attaining more information, which will help you in the long run.

I think that this is especially important in the software development field, where there are constantly new technologies and tools to learn, and new information about emerging systems that you must learn to keep up with the ever expanding field on software development. If you don’t keep up by learning new things, and thereby exposing your ignorance, then you will quickly fall behind, and may be susceptible to being replaced at your job, or incapable of performing the tasks necessary to fulfill your goals.

I also think that this is applicable to many different fields, not just software craftmanship, where there are always new things to learn, and you must keep up to date with the latest information in order to do your job. One such example would be a doctor, where there is always new medical information coming out, and not knowing about it could be potentially harmful. Any person in a field such as this must be okay with admitting that they don’t know something, instead of pretending like they do and not learning new, important information. Admitting that you don’t know something, and exposing your ignorance, not only makes you seem humble to yourself as well as others, but it also helps others to assess what you do or don’t know so that they are able to help you in areas where you may need it, and you are able to help yourself in this way and by learning it on your own.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.

This Apprenticeship Pattern is about constantly reading books pertaining to the subject of computer science as to supplement your real-world hands-on experience and as to not stagnate your learning. By not only learning through on-the-job experience or personal project experience, and having a few different routes of learning, you enhance your overall knowledge of the subject. This way, you also avoid stagnating your knowledge, because if for your job you are repeating the same or many similar tasks, then you aren’t really learning anything, or are just learning very little. This is because when you do the same thing over and over, you don’t really have to think about it anymore, and a lot of it is just automatic for you.

By reading constantly, you are actively engaging your brain to focus on new material. The great thing about reading is that you can do it anywhere, and at any time. Anytime you have spare time in the day, it is easy to just read for a few minutes and learn something. Also, by not reading it for very long periods of time, you avoid losing focus on the material, and instead can focus on the material in shorter, more manageable bursts.

I really like this suggestion because I have a lot of trouble sitting down and reading something for long periods of time. With your phone, computer, tv, etc. there are many distractions that draw your attention away from whatever you’re trying to focus on. This can make actively trying to read very difficult, but by doing it in whatever free time you have, you can avoid the distractions and help focus on the reading. I much prefer reading, or anything that requires sustained attention, in short bursts rather than long marathons. In short bursts I can ensure that I keep my attention on topic, but the longer I do it the more my attention dwindles.

The only thing I disagreed with was the suggestion to only read books, and not blogs or other resources. While I do think that maybe being online and not having a physical book may increase distractions, I also think that there are many great educational resources online that are invaluable. In my opinion, the thought that some things must be learned from books is outdated and could maybe even hinder learning. Everyone learns in different ways, so by suggesting that everyone try to learn from books doesn’t make sense to me.  

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

This Apprenticeship Pattern covers learning how to fail, and more importantly how to recover from failing. It makes the point that failure is necessary to learn a new skill, and if you’re never failing then you’re likely not trying new things and not expanding your knowledge. Failure is a normal and natural part of learning something new, and it’s just as much a part of the process as anything else. If you want to learn a new skill, you can’t be afraid of failure, and you have to accept that it will happen at some point. By trying to avoid failure, you’re actively hindering your learning and limiting your potential skill.

The Apprenticeship Pattern also makes the point that learning how you fail helps with self-assessment. Through failure, you can learn more about yourself, such as what things you have more difficulty with, and what things you can pick up relatively easily. If you don’t try to push yourself to failure then you’ll never discover your limits, and you won’t know how efficiently and effectively you could be working. Failure also forces you to admit your weaknesses, and to learn not to waste time with things that are outside of your skillset, and instead spend your time doing things that you know you can do correctly.

The Apprenticeship Pattern also makes a point about not getting down on yourself about your failures. By changing your mindset from failure being a bad thing to failure being a valuable experience for learning, you will become more productive overall and more capable of learning new skills. If every time you experience failure you get down on yourself and become afraid of failure to avoid the experience, then you’ll become much less productive, much less capable of learning new skills, and much less experienced overall. The correct way to minimize failures and maximize potential is not to avoid it altogether, but instead to take it on your stride and learn from it so that the situation in which the failure would occur wouldn’t ever happen again, rather than avoiding the failure itself. Only in this way would you be able to become a proficient software craftsman, because that requires learning many new skills, and has the potential for many pitfalls and failings that you must learn from.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.

The White Belt

This Apprenticeship pattern was about unlearning what you already know in order to learn something new. It is important to do this because, especially with programming languages, what might be a good habit or convention within one language may be inefficient or bad practice within another. I could personally relate to this Apprenticeship pattern a lot because in high school I took an intro to programming class in which we learned the basics of python. I found python to be really confusing at first, but over the course of the school year I became very familiar with it and began to really like the syntax and structure of the language. While this class was very useful and helpful for learning programming, it made it more difficult for me being a computer science major in college.

In college, most of the programming we do is in java. Transitioning from python to java was very difficult for me because they are two very different languages, with different syntax and structure, and different coding conventions. In my experience, it is very difficult to translate from python to java, but somewhat easier to translate from java to python. Although you can translate from java to python, the way of going about things in java is very different from in python, and the direct translation from java to python is likely very inefficient, whereas code written from scratch in python is likely much more efficient in python. This means that in order to learn java, I had to unlearn what I already knew from python. Even things that I felt were general coding practice felt completely different in java than it did in python, which made it really hard to learn java. So, in order to properly learn java, I had to think about the concepts completely independently of similar concepts I knew from python. Even though this was very difficult to do, I find that it actually fortified my understanding of both languages, and helped me to think about them independently of one another.

I couldn’t find anything I disagreed with about this pattern. I think that this is sound advice in general, even outside of software craftsmanship. You can’t be afraid to fail when learning a new skill, because only through failure will you learn to improve. As the Apprenticeship Pattern mentions, this could mean that you will get worse before you get better, as you’d be much less proficient using whatever new skills you’re learning than you were with your old skills. However, the point it’s making is that it’s worth it to see it through, as only then will you expand upon your skillset.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.

For this apprenticeship pattern, I chose Be the Worst. This pattern is about joining a team with much greater skills than yourself in order to learn from them, and as to not stagnate your learning by being on par, or more knowledgeable than your other team members. The issue with this concept is that if you join a team of members much more knowledgeable than yourself, you could be seriously behind and unable to complete any of the tasks required by the team, thus becoming deadweight and dragging the team down. The solution it proposes to this problem is for you, as a less knowledgeable member of the team, to do the more menial tasks.

I think this is a really clever solution to this problem for a few reasons. First, it allows you to still help the team, and not just be deadweight or an observer. If you were actively slowing the team down, or worsening productivity, then they would want you off the team, so it’s important for you to still be contributing something worthwhile, even if it isn’t huge. Second, since you’re doing menial tasks, it’s likely stuff that other team members don’t like doing or would rather someone else do. They would be better off using their time for more advanced tasks, so by doing the menial tasks you’re helping them and saving them time. In this way, it actually leads to more productivity for the team. Lastly, by doing menial tasks, as long as they aren’t too difficult, it means that you can still conserve most of your energy towards learning from the other team members.

I think this apprenticeship pattern presents strong and useful information, and I couldn’t find anything I disagreed with. I could relate to this pattern because I have been on teams where I was either the most or least experienced, and I didn’t like either one. Being the most experienced, you will always have to help out the other team members, while you could maybe be more productive doing other tasks. Being the least experienced, you often feel like you aren’t doing or contributing enough. This pattern has changed my view, as I now think that being the least experienced is better than being the most experienced, and I used to think the opposite.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.