Author Archives: Anesti Lara

Blog #7

The pattern I read for this week was “Draw Your Own Map”. It was about how to create your own career path and not worry about what others think of it. This was a great pattern to read because it is so true. Everyone is living their own life in their own situation, and no two people are exactly alike. It was interesting to look at the different ways I can create my own career map, and be prepared for the future. This pattern started making me think about my own map now that my college days are coming to an end.

This pattern taught me to not take my current map too seriously as it can always change, and the map I have right now might not necessarily be the same map I have next year, and I am free to change it however and whenever I see fit. I have always worried about the big goals, and this pattern has also taught me to focus on the little goals that will build up to create the big goals. This can even make the big goals seem simpler as the little goals will build into the big ones. 

I do not have anything that I disagree with in this pattern as it all seems to be given as options for you, and not anything said as a fact. Your map should be your own, and nobody can tell you if it is wrong or not as nobody is the same. I think this pattern did a great job at making sure that, in the end, this is only for yourself, and it will be different from everyone else. There might be times when your map intersects with others, but it will never be the exact same. This pattern is very important for anyone to read no matter what your career choice is. Everyone should draw their own career map with whatever goals they have to go through their path. In the end, your career map should be unique to you, it can change as many times as you need throughout your life, and it should include all your goals you wish to achieve.

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

Blog #6

The pattern I read for this week was “A Different Road”. It was about how sometimes the career you think you will have now can change, and you want to take a different path in life. Even if the change occurs, you will still take what you have learned through this path and apply it to the rest of your life. I really enjoyed this pattern because it has always been a worry of mine to suddenly want to go down another career path.  This pattern did an amazing job on that topic. It was interesting to read the views given through the pattern that were very useful to settle my worries.

This pattern taught me that it is ok to go down a different path than the one envisioned in the beginning because we are constantly changing as people, and we are not the same people today as we were yesterday. As I mentioned before, it was always a worry of mine to suddenly want to go through another career path after all the hard work I went through to go through this one. This shows how big the lesson that this pattern taught me truly is as I now am looking forward to whatever life has to bring me, and just hope that in the end, I am doing what I love as that is all that matters.

I do not feel like there was anything I disagreed with in this pattern. It brought up something that everyone thinks about at least once, and did not try to make a controversial take, instead left it to the reader to make whatever decision they think is right. That is a great way to deal with it because it does not give them a specific side on if you should stay or go, but instead lets the reader know that the decision is only for them to make. Whatever decision they come up with is the right one for them in the end. I think everyone should read this no matter your career path as career changes are universal and not only for software development. It might even help someone contemplating this dilemma come up with their decision.

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

Blog #5

The pattern I read for this week was “Use Your Title”. It was about how to not let your job title at work affect how you work, and continue working as hard as you would if your title was something lower. I really enjoyed this pattern as I have never had this problem, but actually the opposite. I don’t let it get to my head because I always feel undeserving of what I get. I always feel like I can do better, and that I am no different from everyone else. It was interesting to read about how titles can have the opposite effect on people as well though.

This pattern taught me that titles do not matter, and whatever your title is, you should strive to be the very best that you can be. It has not changed the way I think as I never let a title get to my head, but it has caused me to think about others that I know this affects, and how this could really be of help to them. I think I should change the way I think that I am not deserving of what I get though, as I constantly work for what I get, and deserve everything that I have worked for. It isn’t like I am just doing nothing, and putting no work in at all. 

There was nothing that I particularly disagreed with in the pattern. In fact, I agreed with everything that was stated in it. Titles should never get to people’s heads, and they should not make you work any less hard. It is fine to be happy about your new title as you have worked hard for it, but you must know that I can change and go at any moment. To continue rising, you must continue putting in the work, and strive for even more. You should not get lazy and complacent of where you are right now. I think this pattern does not just apply to software craftsmanship, but everything. Everyone should read this pattern, as the issue of titles can be seen in every work area, and there will always be someone that lets it get to their head.

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

Blog #4

The pattern I read for this week was “Nurture Your Passion”. It was about how to keep your passion for software craftsmanship, while also letting it grow at the same time. It lists many ways to grow your passion from working on what you like to seeking out kindred spirits. I really enjoyed reading this pattern because passion for your job is something we all seek our entire lives. I went through all the pain and struggles all the way through college for a chance to get a job I am passionate about. Once you get the job though, you need to be able to keep that passion for your entire life, and even grow it into something more.

This pattern taught me many different ways to grow my passion for software craftsmanship. My favorite was studying the classics as I hadn’t really thought about it. That allowed me to change the way I think, and I am thinking about reading some books made by software developers of the past to learn from their passions. The way to a brighter future is by studying the past, so I should use the words of past software developers to help myself and improve myself. I thought the tip about seeking out kindred spirits is great too. You should try to find different people with similar passions as you, so you both can help each other grow, and keep what you are doing from getting boring. The more people that can help you grow your passions and help you learn, the better off you will be.

There was nothing that I particularly disagreed with in this pattern. I thought it did a good job giving different ways to grow your passions, and great reasons why it is important to do. Without growing your passions, it will soon leave you unpassionate, and lead to a decrease in your work. Passion that is ever growing for what you are going to be spending the rest of your life doing is extremely important, and it is necessary to have. I think everyone should read this pattern because it can be applied to everything, not just software craftsmanship.

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

Retrospective Blog #3

The third sprint was the shortest, but I feel like it led to some of our best work. I only worked on one issue this sprint, as we had less weight than the others. The issue was to create the test.sh file, which was being continued from the last sprint. The issue got completed with the help of Scott and Moses to clean up the queue, and the link can be found below. This blog will go over my retrospective thoughts now that the final sprint is complete.

There were many things that went well throughout the final sprint. One thing that went well was our communication. Our team has had this positive throughout all of the sprints, and it continued here. We talked to each other all the time whether on Discord or by call. Another positive for our group was how we never deterred from the goal, and from the very beginning, we were determined to finish this sprint strong. This sprint more than the others, I feel like we knew what to do and immediately got to work. The experience surely helped with that.

There were also some other aspects of the sprint that I think we can still get better at in the future. One thing that I think we can still improve on is our weights as a lot of these issues we worked on were carry-ons from the last sprint. We can still improve on that, but I think we got better throughout the semester. Another aspect that I think we can still improve on is our experience. We did not have experience with short sprints like this one, and so I feel like that put a lot of stress on us that would go away with more short sprints. The more experience we get with shorter sprints will only make us better.

There were also some things that I feel that I personally can improve on. One thing was that I was sick for most of the sprint, so I was not able to put in the work that I wanted at times. I know that being sick is uncontrollable, but I wish I would have helped more than I did. That is the great part about a group though, as everyone helped me through that time. Another thing that I could improve on is my knowledge of software development. I do not think that I had zero knowledge, but I feel like I can always get better. The more I can learn, and the more experience I get, the better I will get at this in the future.

With this third sprint over, all the sprints have finished. I really enjoyed working through all three sprints, and I am thankful for the experience this has given me. In the beginning, I was really worried about how this would all go, and I can safely say that I do not regret a single day throughout all three sprints. I love the group that I was assigned to, and I think we did a great job teaching each other aspects of the work we did not know. I feel like we all made each other better, and that is all you can ask for.

Issue Links

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/48

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

Blog #3

The pattern I read for this week was “Sustainable Motivations”. It was about how to keep motivated through the good and bad times of your career. It goes over multiple motivations you may have for your job whether good or bad, like money or love. I found this pattern great because motivation is extremely important when it comes to the profession you will be spending your life working to master. It is something that comes to my mind all the time when I think about the future. Without motivation, something can go from your dream job to the worst one possible. We need motivation to get up in the morning and give it 110% wherever you work.

This pattern taught me that all your motivation does not need to come from big goals. Your motivation can also come from small goals along the way as well. Ideas like company activities for the workers who perform the best throughout the day, can even motivate people through the days that feel like a slog. This pattern caused me to really think of the ways I motivate myself. I try to motivate myself through the week by setting up activities I enjoy on the weekends, and giving myself more purpose to complete my work during the weekdays, so I can be free during my days off. I think my way is a great way to motivate yourself as not only does it bring more life to work, but it brings more life to yourself outside of work during the weekends.

I do not think I disagree with anything said in the pattern. I think it correctly goes over how you need motivation to continue working at your best for as long as possible. Without motivation, productivity goes down tremendously, and it leads to a bad product, so it is essential to have. Motivation is something that can be found in anything, and everyone has something that motivates them one way or another. I think everyone should read this pattern, and really try to think about what motivates them, and what will continue to motivate them when the going gets tough.

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

Blog #2

The pattern I read for this week was “Craft over Art”. It was about how you should value the usefulness of an object you are creating over the beauty of it as the program can be beautiful, but it needs to be useful. I found this pattern very interesting to read as it is something that I really agree with. I have always seen usefulness as the true beauty, and have always valued something working over it looking the best. Would it be cool if the program was also nice to look at? Yeah, there is a sort of professional feeling to making a program that looks good and works, but you should never try to make code look better if it decreases its usefulness. There is always room for beauty, but not if it comes to the cost of the program itself.

The pattern did not cause me to change my way of thinking, but it did strengthen it, as I have always agreed with what is said in the pattern. To me, I always looked at the beauty of a program as something that can be worried about in the end, when the crafting of it is done first. When it is finished, then I can focus on making it look as neat and clean as possible without ruining its purpose. I have always been someone that wanted the better equipment no matter how it looked, so I think that has rubbed off on my programming.

Looking back at the pattern, it is hard for me to find something that I disagreed with. I agree with everything said in the pattern, and see it as common sense to me. I would rather make that 50 line game that is simple yet fun over the groundbreakingly beautiful unplayable game. I can see how some people can disagree with this though as some people value beauty over usability. An example of this is with kids, as some kids would rather have the worst Superman toy over the better Batman toy just because of looks. Other than those moments though, most people would agree that craft is over art.

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

Retrospective Blog #2

Our team hit the ground running in the second sprint to deliver a much better result than the first sprint in the end. I ended up working on three issues, with two being completed in the end, and the last one being saved for the next sprint. The links to all three issues can be found below. The first issue was an issue that had been unresolved in the last sprint. What happened was that I had finished the issue, but there was a problem with the commit. I received help from Scott on fixing the commit problem, and the issue was resolved. The second issue was another one that came from the first sprint. I had many troubles with updating the pipeline in the first sprint, and I really needed help with it in the second one. Sam jumped in and did an amazing job getting it to work, and we could not have completed it without him. The third issue I had started in this sprint was creating the test.sh file in the command folder. It took a lot of trial and error, but I just was not able to finish it completely, and I am looking forward to finishing it up in the next sprint. This blog will go over my retrospective thoughts now that the second sprint is over.

Many things worked really well throughout this sprint. One thing that was huge was how much we had learned from the first sprint. In the first sprint we started off slow as we were still inexperienced, but this time we just flew through the beginning, and hit a roll. This can be seen in the nearly 10 point weight difference at the end of each sprint. Another thing that worked well was how cohesive we worked as a group. Now that we had more experience working together, I felt that we talked with each other more, and worked together to finish issues more as well.

There were also some things that did not work well throughout the sprint. One thing that comes to mind is how even though we are better, our weight scaling is still a little off. An example of this is with the pipeline issue where we put it as a weight of two, and it ended up being a weight of five or six. Something else that comes to mind that did not work well is our understanding of new information. It has taken us way longer than we thought to understand Chai, and we are still entering the final sprint trying to fully figure it out.

When thinking about what we can do to improve our group, a couple of ideas come to mind. One thing is that we can try to fix our issue with weights. We could try to improve this by giving some issues more weight than we think it needs so that we can account for actually learning what to do. A lot of times we have overestimated our knowledge, and it led to us taking longer on sprints than the listed weight. Another thing we can try to improve is our communication with outside groups. I feel like we think that we can only communicate with each other, but we can also reach out to our friends in other groups for help as well, and I think we have not taken advantage of that as much as we should.

I think that I can improve in many ways from this sprint. One way is by getting more familiar with Git itself, and prevent small mistakes, like with the first linked issue, from happening again. This will allow for us to not waste time on issues that do not require it, and get our work done faster. Another way I can improve is by reaching out to the GuestInfoSystem team for help with creating the test.sh file as they have done a ton of work with that in sprint two, and have got it up and running on their system. This will help us in getting that issue resolved for the last sprint. This sprint felt like night and day compared to the last one, and our group will only improve more with this experience.

Issue Links

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/8
  2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/98
  3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingbackend/-/issues/48

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

Blog #1

The pattern I chose for the blog was the first one titled, “Your First Language”. The pattern is about the process of starting off learning your first programming language and how to progress past that. The solution was to pick one language and spend a couple of years learning it to become fluent. The pattern then went on to mention that  it can be hard to pick just one, and gave some tips on how to choose.

I thought the pattern was great because so many people have trouble trying to decide on what their first programming language to learn should be, and this really does help lay a great groundwork for what they should be doing now in the beginning. The pattern even helps with deciding which language to start learning first, by weighing the options with you. I did not feel like this pattern was not really for me to learn as I have already gone through this process in my first years of college, and am past this point in my learning by now. I feel like this pattern is perfect for somebody just starting their first year as a computer science major in this school, and could really help them pick out what they should be doing.

I definitely agree with the advice given as instead of trying to learn multiple languages at once, new people should really try to become proficient in one language, and that in turn will make learning new languages easier. This is due to the fact that starting your first language requires more time to learn the basics of what to do with the language, while with all the languages afterwards, it is sort of like translating what you already know most of the time. I think people new to programming really need to take this advice, and they will be set on the road to success.

This pattern was about how to start off learning your first programming language, and how to decide which language to learn. It did not teach me much as a computer science senior, but I feel like it would really help people in their freshman year. This was a great first pattern to read, and I can not wait to see what I can learn from the ones coming up after this.

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

Retrospective Blog

While there were some issues along the way, I feel like the first sprint was a success in the end. I ended up doing three issues with one done, and two issues still having problems and needing to be saved for the next sprint. The links to all three issues can be found below. The first issue I completed was update or add all doc, licensing, lint config, .gitignore, and .gitattribute to General, and I found no issues, so it was pretty easy, and did not take that long. The second issue was updating the pipelines, where I thought I completed it, but there was still more to do, so it was saved for the next sprint. My final issue was the same as the first but for the API, and I managed to finish it, but it had a problem from the pipeline, and needed to be saved for the next sprint as well. This blog will go over my retrospective thoughts of the first sprint now that it is over.

Throughout the sprint, there were many things that worked well. One thing that worked well was how our team developed a genuine camaraderie, which is important when it comes to teamwork. You need to have trust in each other that you will get your work done, and trust that we are there to help each other, and I think our team has developed that. Another thing that worked well was our communication during class hours. During the time we were in class, our communication was great, and we really helped each other out with our problems. Later in the blog, I will mention how we should find time to do more of it after class hours. Having these positives after the first sprint is great, and it can only get better from here.

There were also some things that did not work well throughout the sprint. One thing that did not work well was our time management. Every task we did ended up taking one weight over what we predicted. I think this experience will help this, and it will improve for the next sprint, so it is not too big of an issue. Another thing that did not work well was how one member made a change in the name of an issue, and it confused everyone else. We should be more open to the whole team for any little change made next time. We can definitely improve on these issues for the next sprint.

For our team to improve, there are plenty of changes that we can make. One change is having more communication from Thursday to Tuesday, as it is a long break to have no meeting with the team. We are planning to fix this by finding some time between the days to meet for an hour and check up on each other’s progress. If we have an issue after class Thursday, we won’t need to wait until Tuesday’s meeting to look for a fix, and waste all of the time that is precious in a sprint. Another change we can make to improve as a team is our experience. In the first sprint, we had no experience with sprints before, and it led to our issues. Now that we have the first sprint as experience, I think that will improve our team to better prepare for the next.

There are also many things that I could change to improve individually as well. One huge thing I could change to improve is my knowledge of VSCode and Docker. In the beginning of the sprint, I was having many troubles with the simple parts of VSCode and Docker, as I had not used it since Fall 2021. It got better throughout the sprint, and I am feeling more confident in my abilities now as we start the second sprint. Another change I could make to improve is to more quickly admit when I need help. There were many times during the sprint where I delayed asking for help, so I could try to fix the issues by myself. I think if I tried to come to everyone faster, it could have freed more time to worry about other issues. I think with the experience from the first sprint, I will be better with this in the next sprint. This first sprint started off a little rocky with inexperience showing up, but it ended with the whole team confidently looking ahead to what is next.

Issue Links

  1. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/96
  2. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/community/-/issues/98
  3. https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/reportingsystem/reportingapi/-/issues/8 

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