Author Archives: anelson42

Sprint Retrospective – Sprint 3

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.


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

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.

A Different Road

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.

Expose Your Ignorance

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.

Sprint Retrospective – Sprint 2

I think that we as a team, as well as me as an individual, improved during this sprint compared to the first sprint. While for the first sprint we had no experience working with scrum sprints or in any sort of team development environment, so the whole thing was completely new to us, whereas at least now with the 2nd sprint we had at least a tiny bit of experience. This means that we were able to improve upon some things from our first sprint, because we could see what we did wrong and could change our plan in order to avoid our previous mistakes and optimize our workflow overall.

The first thing we optimized and improved upon was our sprint planning. From our first sprint, we could better judge what we could get done during a sprint by how much we got done during our first sprint. This way we could efficiently work on items, getting as much done as possible during the sprint and not assigning too much during the sprint to the point that we end up not getting most of it done. We could also better assign weight to each of the items because we could better judge how long it would take for us to get each item done, and better judge the importance of each item to the overall project and current objective.

The second thing we optimized and improved upon was our overall communication. We still did most of our communication in class, but we now made sure to communicate through the issues on GitLab. When an issue required additional clarification or explanation, we could leave a comment on an issue and ask the creator of the issue for more details, and the creator could easily respond right on the issue. This not only improved upon the frequency of our communication, but it also helped us to differentiate and easily see what string of communication was pertinent to what issue, helping other team members to see what was discussed respective to what issues. This way, if a team member was working on an issue similar to or previously worked on by another team member, they could easily see what kind of issues that team member faced while working on it, and that could help them work through it without even requiring more help from the team. This makes the workflow as a whole much more efficient because any communication is saved, categorized, and easily searchable.

For the team as a whole, we could still improve upon our communication. Although it is efficient communicating through GitLab issues, and it does have some benefits, it is also good to have some non-official communication that doesn’t directly relate to a particular issue. Leaving this communication on GitLab would be messy, so it would be better if we did this additional communication through discord. For me as an individual, I think I could’ve helped more with the sprint planning, and better assisted my team members. For the spring planning, I could’ve better helped with coming up with weights for issues and assigning them. Finally, I could’ve better helped my teammates by being more active responding to open issues with comments and helping them finish open issues if I’m done with all of my issues.

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

Read Constantly

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

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

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.

Sprint Retrospective – Sprint 1

For the first sprint of the semester, I individually didn’t get as much done as I hoped to. I did help others, and collectively as a team we got a good amount done,  but I hoped to get more done individually. For this first sprint, I spent a lot of time looking through the project and the different repositories to find out about each component, how it worked, and how it interacted with the other components. Due to this, I feel that I learned a lot about how the project currently works, how it’s supposed to work, and what systems currently function or do not function. However, this also means that I didn’t have a lot of completed tasks.

The only issue that I had assigned myself on GitLab was the one to rename the subprocess files in the Reporting Backend. We felt that the names ‘send.js’ and ‘receive.js’ weren’t very descriptive, and in order for them to properly reflect what they were for, they would need to be renamed to something more descriptive. This sent me down a rabbit hole of looking through the project files to see everywhere the files were referenced so that nothing would be broken by renaming them, and also to be able to update the names in any documentation in which they were referenced. This led me to discovering that many things in the project were pulled from an old version of the backend, and that many things would have to be redone in order for it to pull new changes and build the image from the new repository. Additionally, I noticed that there were two sets of send and receive files, one in the subprocess folder of the backend, and one in the RabbitMQ folder. This had me very confused, as I at first didn’t know what the send file was for because our module wouldn’t need to send any information through the queue system, but then I discovered that it was simply to insert dummy test data into the queue for it to be received by the backend. I still don’t fully understand why there are two sets of these files, but I now understand what they’re for and will be able to modify and use them.

What worked well within our team was everyone being individually proficient, as well as being proficient in certain areas that others were not. Everyone on the team had their own strengths and weaknesses, and we were able to coordinate so that people’s strengths complimented each other, working towards a more cohesive whole. For example, I am more knowledgeable about the backend systems more so than the frontend systems, so I know more about how the docker containers work and some JavaScript, whereas others know more about Vue and the design of the frontend and are much more proficient than me in JavaScript.

What didn’t  work very well was our team communication. We communicated mostly only in class, and only minimally out of class such as on Discord. Given that we were all individually proficient, we had less of a problem completing tasks individually, meaning we had less of a reason to communicate what we were doing and what progress was being made. I think that sharing more information with other team members periodically, such as what progress has been made, what you’re working on, and what still needs to be done, outside of the scheduled times, could have been very productive and helpful for the team.

To improve upon this, we could have scheduled times for meetings outside of class via Discord, where we could discuss the details of what each of us is currently doing and ask others if they need help or if we need help. This way, we could more immediately resolve an issue that someone is facing, rather than having to wait until the next class to discuss the issue with the other team members. Additionally, the extra time spent as a team could help us to figure out each other’s strengths and weaknesses, and to discuss how we could work better as a team.

Individually, I could have improved upon a few things. First, I should have focused more on completing certain tasks, rather than exploring the project independently of any tasks. I could have learned everything I did about the project while completing tasks, rather than without completing tasks. Second, I could have better shared what I learned about the project with other team members.

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

Be the Worst

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.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

I found it very interesting reading about the journey to becoming a Software Craftsman. I think that many of the principles discussed here are relevant not only for people in software development, but for people in all walks of life. The base principles can be applied for anyone learning anything, and they’ll still hold true. For example, it discussed “emptying your cup” before trying to pour stuff in as a metaphor for not relying on old information when doing something new, to view new information on its own as to not transfer old habits to new skills. I think that this is a great skill for learning anything because it’s always a habit to fall back on what you know rather than expanding your knowledge to something new.

Something that I found interesting was the book’s lesson of seeking enhanced knowledge opportunities over enhanced pay opportunities. I think this is a very important lesson is today’s world because even if you do take a higher paying job, if you don’t keep up with the latest developments then you’ll fall behind and likely be replaced by someone who is keeping up. Also, seeking enhanced learning opportunities will likely lead to enhanced pay opportunities, but the same can’t be said for the other way around. For these reasons, I strongly agreed with this lesson, and I think that it’s a really important thing to emphasize because it’s often something that people either don’t learn or learn too late.

This ties into what I found in the reading that changed my opinion. Previously, I thought that the “correct” path was to get as many certifications as possible and to have an impressive looking resume even if you aren’t actually proficient in those things. The reading changed my opinion to the view that knowledge is more important than certifications, and even if you do have an impressive looking skillset on paper, that doesn’t mean that you’ll be good at a certain job or task.

However, one thing that I disagreed with was that some information must be learned from books, and that the information online can’t compare or replace the old information found in books. I disagree with this because I think that these days there are so many great resources online to learn software development, even from just things like YouTube. I think that you can find the people with more knowledge than you that the reading emphasized as important online, without ever even opening a book.

Lastly, I think that the most important chapter is chapter 4, on accurate self-assessment. I think this because without accurate self-assessment, you won’t be able to improve or pick up new skills or knowledge. The first step to improving at anything is admitting that there’s more to learn, or that you could be better at certain aspects of something. If you think that you have nothing to improve upon, then you’ll never expand your knowledge or 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.