Author Archives: Sarah T

Sprint Retrospective #3

Hello Blog!

It’s time for my final sprint retrospective for Thea’s Pantry! 

For this third and final sprint, we were focusing on closing up issues related to the previous sprint and closing epics. My team was having issues with the automated testing and the test runner docker container. We were all previously working on our own tests, but because of everyone having errors with theirs, it was decided that we should all take the time to work on testing together to try to get at least one test working. And that we did.

The following are links for issues worked on, in collaboration with my team:

My team also tried putting our heads together to handle issues with the automated testing with test-runner, searching for any typos or missing components in the code that could be causing issues, and this work was also done in collaboration with another team.

What worked well was that we were able to spend this sprint working together more on issues and get through them instead of continuing to be stuck on several different issues at the same time like the last sprint. It also worked well communicating with another team working on similar issues especially when trying to handle errors they also faced so we could progress faster and get closer to tackling the issue.

I don’t think I have anything to say about what didn’t work well. I think communication was better this sprint than before and we all tried to look for things we missed in the code when trying to handle errors. I also don’t think I have anything to say for improving as a team. 

To improve as an individual, I think I could have spent some more time outside of class experimenting with the issues. Burnout and the buildup of outside commitments really hit me this sprint and the last, but I can work to improve my time and work management. Not too much time has passed since the last sprint retrospective where I said I hope to be more daring. I still believe that I need to work on being less afraid of breaking things when I make changes, but I do find security with how Visual Studio code shows some changes we made or displays some code before and after the change we just made. I also make notes of things I change to help keep track of what might mess things up, so I’m building my confidence with those.

This may be my last blog post, so “Good morning, and in case I don’t see ya, good afternoon, good evening, and good night!”

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #2

Hello blog!

Sprint 2 has come to an end and it is now round 2 of sprint retrospectives. This sprint was a little different from the first sprint, where our issues were similar amongst the five projects and we all took one project. Instead of one person having to take on all issues for InventoryAPI, they were able to take on frontend work, or whatever was available. This was a change based on what we discussed during the first sprint retrospective–that we should rotate around what we’re working on rather than being stuck in one project. 

The first two issues I worked on were for AddInventoryFrontend:

The following issue is what resulted in the greatest struggle:

I think what worked well was that in the previous sprint there was the suggestion of changing projects for teammates since they did not want to stick to one of the five projects the whole time, and teammates did swap where they were working. We were also able to help each other out well for a few issues since we all had similar things to change.

What didn’t work well was that we did not gauge well enough how to weigh the tests. We did believe that it would give us issues, but not to the extent that it did. The backend tests should have been split into manual testing and automated testing in Chai since just the manual testing was giving issues that took a long time to address. It was also an issue that almost all of us were making changes to InventoryBackend at once and getting errors from different sections that were fixed by one person but another person was not informed. 

To improve as a team, we could definitely communicate more on errors we have received and what we’ve done to fix them–as soon as we reach them. There are times when some teammates further ahead have gotten errors and fixed them somehow, but forgot what they have changed or updated. Doing so would be of great help for reference and also just good practice. We could also improve as a team by finding more time to work together, like the testing issues for example, since we were all in a similar position, and everyone collaborating on one test first would definitely push us forward. We all have busy and differing schedules so it has been difficult lately, but it can be an improvement.

On the topic of improving as an individual, I still have a fear of breaking things, so I should work on being less afraid of making changes. This sprint I’ve experimented a lot with trying to fix the errors I received trying to get my manual getApiVersion test to work. There were countless changes I made that ended up not making a difference, or would trigger the same error under different conditions. So while I did make efforts to be more “daring”, I could still use some more work on that. I think what scares me more is entering commands I’m not familiar with at all in the terminal, but that can just be an instance of reading more into them.

This sprint felt like a call to be more communicative with my team and also a call to communicate outside of the team with those who have worked on similar issues.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

A Different Road Pattern~

Hello!

For the final pattern blog of the semester, I decided to close off with the “A Different Road” pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. 

This pattern is related to following your own map but straying from the Long Road in the process. As you spend time following the Long Road, you may come to see that your values have changed. For example, you may value family or money more than before. Your goals may not align anymore and this may cause you to leave the Long Road. However, what you have learned along the way isn’t rendered completely useless–they can be applied in other ways to whatever you choose to do. 

You may realize after leaving the Long Road that you would like to go back. There may be some organizations that would give you a tough time for that gap in your resume, but there are some organizations that aren’t as bothered by that and may welcome your perspective of leaving and returning to the field. The pattern encourages you to not be afraid to go for something different, and either way, your skills can be utilized in a different way. You can take action by making a list of what you would do if you were not a software developer, and what you may enjoy– and reach out to people who are doing those jobs to learn what their experience is like, and compare it to what you like about software development.

I think this was a useful pattern to read. It is recognizing that some people change, and they may shift what their focus is on. I think it’s reassuring to see that it acknowledges the industry may be tough on people who have gaps in their resume but that wouldn’t be a complete set-back. It wouldn’t be the end if we can’t exactly make it back to the kind of position we were in before, but some important skills we gained along the way can be transferred to something new. There’s more flexibility than we think, and I think that I would definitely have this in mind going forward. Sometimes it feels like I may be reaching a dead end if I don’t meet certain deadlines, but of course, we all have different timelines and paths. I don’t have anything I disagree with for this pattern as I agree that diverging doesn’t mean the end of everything or means that everything would be wasted.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Craft Over Art Pattern~

Hello!

Welcome back to the blog. This week I am discussing the Craft Over Art pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of this pattern is that you are being paid to make something to solve a problem for a customer. The problem is that there is already a solution for how to fix that problem, but you would be able to come up with something creative to address the problem that would impress your coworkers. 

The pattern discusses that being a craftsman is impacted by relationships we build with others–we should work to build strong connections with customers, making sure we deliver to them something of quality. We shouldn’t aim to focus on our own interests. You should be working to the best of your ability but also keeping the customer’s best interests in mind. Part of our growth is being able to give up the opportunity to make something beautiful and instead create something useful when needed.

The pattern advises that in the next 24 hours you work on something to be useful rather than beautiful, and to think about what you should be focusing on while you make the decision on making something useful. You should also reflect on your past experiences where you tried to do something creative rather than follow an already-made path for solving a problem and the result of it, and what would have happened if you chose to use a previously established solution.

I thought that this pattern was an interesting read. Throughout the patterns, I’ve been seeing that we should work to hone our skills and not get too comfortable with certain activities–try to branch out some more or we may get stuck. And this pattern is saying that although we should exercise our skills, we need to find a balance between creating something ingenious and creating something based on an already existing solution. I think this is important to think about when doing work. Of course, I think it would be great if you could figure out new ways to do things. But it’s also important to deliver products to the customer in a timely manner, and it may be too resource consuming to create something from scratch as the pattern mentions. I don’t have any disagreements with this pattern. It would be great to develop the ability to know when to sacrifice utility vs beauty and it would definitely be on my mind when I need to solve a problem in the future. I usually tend to look for any known solutions and make slight adjustments to the solutions when necessary.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

The Long Road Pattern~

Hello!

Welcome back to the blog. Today I’m discussing The Long Road pattern from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of this pattern is that our culture values quick rises to fame and holds material values.

The problem relating to this pattern is that we have a main goal for what we want to become–for example, a master software craftsman–but there are other people and outside factors that expect differently from you. You may be offered a great promotion and are urged by others to go for that rising opportunity, even though it would derail you from your “end goal”.

The pattern brings up as a solution to recognize that it might not seem like you would match with your end goal, and to also keep looking forward to your end goal. You should prioritize learning opportunities and any other growth opportunities that would help in the long-run rather than taking the higher-salary position or a leading position. For people hoping to hone their skills for something specific, they should be prepared for it to be a lengthy process.

For action, the pattern discusses thinking about your future–what role you may have a decade from now, and what experiences you want to have under your belt decades from now. Imagine you have to write about your professional history four decades from now, what would you want to see? Use that to plan out your career path. 

I think this was an interesting pattern to read about. This is meant for someone really dedicated to having a specific range of skill sets rather than someone aiming to quickly get promoted and become managers or someone higher up. I was thinking about what I would do–do I have a specific thing I want to become, like a master software craftsman? Not really. But it was interesting for this pattern to get me thinking. I do agree that if I wanted to become a master software craftsman, it would be important to not take on a role that is unrelated to using skills relevant to programming or being hands-on with software utilization. It could make you stray away from your path too much and could take away major opportunities for your growth for your career goal. If I end up having something in mind that I really want to become, this pattern will surely be on my mind–to make sure I stay on a path that will help me hone my skills and gain experience necessary for my career plans. I don’t disagree with the pattern since it’s meant for a specific end goal in mind.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective #1

Sprint 1 has come to an end, and it’s time for the sprint retrospective. For the first sprint of this semester, I worked on issues for AddInventoryFrontend for the Inventory System. The following are links showing my activity for the project:

I have also reviewed a merge request from a teammate in which I checked if they created the necessary files with content similar to GuestInfoAPI: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryapi/-/merge_requests/5 

What worked well with the group is that we all separately worked on the same type of issue. If one member had difficulties with the issue, then another member who figured it out would be able to guide them. For example, we all worked on updating pipeline/CI files and there were some cases where a few people working in frontend had the same errors like issues with using commads/build.sh and were able to work it out with each other. We also had great team communication and were able to freely communicate what we were stuck on or working on, and could easily reach each other outside of class. 

We cooperated well as a group and didn’t seem to have any issues. We had just technical issues rather than teamwork or workload issues. Even then, we did help each other out and I took note of what we may need to remember moving on. When I was stuck facing some errors on an issue, a teammate helped by picking up an issue for AddInventoryFrontend that I was too preoccupied to handle.

To improve as a team, we could work more on projects at home and also try to branch out more. We sort of stuck to our own projects–for example, I handled most of the issues for AddInventoryFrontend, one person worked on InventoryAPI, one for CheckInventoryFrontend, one for CheckOutGuestFrontend, and one for InventoryBackend. It might be more fair to work on different areas for people who ended up working on an area they didn’t want to work with.

In terms of improving as an individual, I could put more time outside of class into my issues–but of course this would happen naturally since this next sprint would have more “intensive” work rather than some copy-pasting situations we had for issues this sprint. I should also be less afraid to make some changes thinking it could mess something up.

I think this first sprint went well with our communication and team support system.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations Pattern~

Hello!

This week, I read about the Sustainable Motivations apprenticeship pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of the pattern is that while we’re still starting out as an apprentice, we have to explore many different things to expand our skillset. Because of this, we come across a rocky path of handling new projects with tough demands to address and things we are unsure of how to approach. Even though you have some love for your job, this exploration gives you troubles and you find yourself feeling pressured, stressed, and even doubtful of your career path.

The pattern also brings up an example of some people being trapped, wanting to move on to something else, but being held back by their motivation of money–they want to switch careers but their current job pays well. It spotlights the importance of matching up your motivations to those that will help you in the long run– to reach mastery.

The action you can make for Sustainable Motivations is to concoct a list of things that motivate you. You should then leave some time to write some additional motivations later on. You should also take the time to reflect on the motivations that you yourself really want versus what other people think. Analysis of the motivations should be done to figure out how much of these are truly what you want and which are the five most important motivators of your life. The list can be referred back to when you find yourself struggling again. 

I think that this was an interesting pattern. I do find myself doubting where I’m heading at times, especially when I face some difficult new tasks and need to branch out to something completely new to me. I like that this pattern brings up that we do find ourselves loving/feeling passionate about our job/what we’re working on, but there’s also a mix of that and being unsure of what we’re doing anymore. I find that more relatable because there’s times where I find myself loving how everything gets put together in the end, and working on certain tasks, but sometimes the process feels really discouraging. From now on, I think I’ll make a list of motivations to keep me going and know that I shouldn’t let my motivations keep me from growing as well. I think more self-analysis wouldn’t hurt. I don’t disagree with anything in the pattern. It’s a good reminder to prioritize your values and where you want to go.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

The Deep End Pattern~

For this week, I wanted to read over and discuss the Deep End pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. 

The Deep End pattern can apply when you’ve only taken safe steps or have only worked with what you’re comfortable with, and you’re starting to feel that where you’re at is hurting you. You feel that you need to expand your knowledge and what you can work with. So, this means that you have to start working on more complex projects or tasks, maybe more high-stakes projects. You shouldn’t jump blindly into a complex project, but you should first prepare or gauge what you’d be able to do. If you take on something unprepared, it could just have a negative impact on you. The pattern gives a warning to make sure you don’t take on something that you may have no foothold in at first–with an example of Enrique Riepenhausen moving out of the country to act as a consultant for a client in Nigeria, but knows the language and someone who lives there.

To work on this issue, the pattern says to think of the projects you have worked on. Then, write about the scope of the project–complexity, how many lines of code, how many developers, etc. From these answers, you can give projects a rating or make a general scale of their complexity and compare new projects to the scale and use it as a tool to help you reach your career goals.

I thought that the pattern was useful in the way that it says you should measure/compare complexity of your past projects that you can use to then compare to future project opportunities. It would be a good way to see that it is complex enough to boost your skills instead of being something on the lower end of complexity that wouldn’t launch you forward. I do agree that we should take on something more difficult so we can learn more things–for example, I knew how to do little tasks for my internship, but I hadn’t written code for a report before and worked on a template nor a form–basically a bunch of aspects I had not touched before–and had the task of working on them. And I’m glad I did, because I learned so much from that complex project that I can now apply to so many more. I also did not step into it completely blind, because I had coworkers who could help me if I really needed, and a knowledge database available. I think it would be interesting to think about my portfolio this way moving on. I do not have any disagreements with the pattern.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

Greetings!

This week, I wanted to kick off with the pattern “Retreat Into Competence” from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. 

Retreat Into Competence relates to scenarios when you realize how little you know or you’re facing a challenge that’s making you reflect back on your knowledge, and you feel overwhelmed. The solution to this is to give yourself a moment–or a little longer, and step back from the challenge you’re facing. Then, take some time to work on something you’re familiar with or know that you’re capable of doing. 

The pattern touches upon how you may feel the thrill of learning new technology along the way of your journey, and the satisfaction of delivering things to customers. And then, you meet more experienced people along the way who make you feel that you really know nothing, and you can also feel this way when there are fast-approaching deadlines and product issues. And sometimes, to deal with this, you need to go backwards to move forward again.

The book warns to not retreat too far back into what you’re comfortable with if you’re afraid of failure, because what you’re comfortable with may no longer be used in the future and the extent of what you know is very limited and you may need to face the consequences of that. Therefore, the book says to use this pattern only as a little pick-me-up, and not to use it for too long because it can be a double edged sword. For action, it’s suggested to pick up something you are well acquainted with and work with it once again. 

I find it interesting that I have utilized this pattern with my internship. When given a new task to code for something in a report, I often change the report template and form corresponding to that report. My biggest challenges come from changing the code in the report, so I sometimes find myself taking a break from that and moving to the template or changing the report form–tasks I find more simple that I have a better grasp on. I agree with the book that it is a short-term fix and should eventually move forward. I’ve recently realized how much I’ve learned from my internship when I took a step back to work on the form and template. It had been something that I had no idea how to handle not too long ago, and now it’s something I’m most comfortable changing. And that’s what made me feel so accomplished and happier to move onto the report code, knowing that I’ll eventually be able to consider the report code something not too difficult to handle. There wasn’t anything I disagreed with.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance Pattern~

Hello! 

For the grand start of my discussion of apprenticeship patterns from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, I wanted to begin with the pattern Expose Your Ignorance.

Expose Your Ignorance is related to the notion that managers and team members expect you to know what you’re doing. For your position, you may know most of what is expected for your role and overall what you need to be doing. However, there are some components that you are bound to not be as familiar with, or have no experience with, like some new technology. The solution to this is that you should reassure them that you’re learning how to deliver to them what they want, and not to pretend that you know how to do it. You would be able to form a reputation of having a great learning ability rather than playing on with fake expectations of what you know.

One way to expose your ignorance is to ask questions. It may be difficult to do so at first, but eventually communicating with team members who are very knowledgeable about the topic won’t be such a tribulation. This would be helpful to give your team members a scope of what you can do and learn, and could also help them understand more about the topic as they explain things to you. The book suggests keeping a list of things you don’t understand related to your work in a place others can see.

I appreciate that this pattern addresses my concerns as someone new and heading into the workforce. I often feel pressure that there are some things that I probably should know how to do, or that I need to do something but it involves something I have not heard of before. But as discussed with the pattern, I do know a good chunk of what I need to be doing, and what I don’t know are just some gaps between them, so I don’t need to feel so pressured. This reminds me that team members I work with have been using this technology and certain methods for a while now, and I just haven’t learned them yet, so I am not too behind. 

 I’m very open to learning and I can reassure them that I’m studying and practicing what I’m learning from them and other sources. I also shouldn’t be afraid to ask questions, because asking someone for help can help put me on track faster to having a better foothold on the technique/technology I’m working on. Of course, I still try to solve things on my own for as much as I can so I won’t have to repeatedly ask for help, but I keep in mind time constraints. I definitely agree that I shouldn’t just specialize in one thing, but aim to branch out and learn more to have a better foothold in different components of technology. I don’t think I have anything I disagree with for this pattern.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.