Author Archives: vrotimmy

Sprint 3 Retrospective

With the conclusion of our last sprint, I’ll start by reflecting on the team performance. I think we went into this sprint pretty determined to get the backend fully up and running. Those of us who were involved in the backend development started working on trying to get the backend running in order to test each of the endpoints. Though the container was running, we were unable to use http calls to test any of the endpoints. We realized that there was a bigger issue than what we initially thought, resulting in us spending most of the sprint trying to get the backend server running. Another thing I would like to point out was that we had issues that were a bit too ambitious. We structured our sprint around the idea that we were going to have the backend running fairly quickly. And because of this we were essentially unable to do a good amount of issues because they required the backend to be running.

Reflecting back on my performance, I would say that I communicated well with the team at the start of the sprint. I discussed with my team during the sprint planning, helping the team structure what needed to be done for the upcoming sprint. At the beginning of the sprint, I assigned myself issue #31 in the backend, which was to test the removeInventory endpoint. I spent time trying to test with http calls but I was not getting any response. I then learned that we were having issues getting the backend to run, which explains why I was not getting a response. I think when it came to this point, I started becoming unproductive due to the fact that my assigned issue depended on the backend running. 

As a team, we definitely could have improved in the communication aspect. At some points during the sprint it was a bit unclear as to what everyone was working on. Most of our progress came to a halt by the issues with the backend, and I think we should’ve put all hands on deck to look into the issues. I do also think we could’ve come up with more manageable issues. For example, a task such as implementing keycloak into the inventory system is something that we can’t gauge the weight of until we actually start working on it. We could’ve come up with issues to get the backend running as opposed to things to do after the backend is running.

Coming away from this sprint, I will need to remember to communicate with my team, engaging with them to see if they need help with anything. I think I should’ve spent more time looking at the entire structure of the project to get a better understanding of how it should work, that way I can look into issues as to why things aren’t running. I will also need to consider setting realistic goals and understanding what things can be done in certain time frames. I still learned a lot from these past three springs and I look forward to applying this knowledge to my professional career.

issue #31: Troubleshooting the removeInventory.js endpoint which was unsuccessful due to the backend not running as intended.
issue #3: Bundle items-api.0.1.0.yaml to be used in the backend.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Craft Over Art

For this week’s blog post, I took a look at the ‘Craft Over Art’ pattern. Now shifting from how to improve your skills as a developer, this pattern describes using your skills to make something that is useful for a customer. The pattern encourages us as craftsmen to mainly prioritize function over form. As stated in the pattern, “The things we build for customers can be beautiful but must be useful,” meaning one should try to maintain a balance between the two. Customers will usually value a quality working product over something impressive but unusable, so it is important to not put personal interests before a customer’s request. A good mindset to have is to be able to sacrifice beauty in favor of utility.

For the most part, I think that this pattern makes sense. Reflecting on myself, I am usually the type to write code to meet specifications as opposed to writing extraneous code that only does the same thing. The pattern mentions the tradeoff between beauty and utility. There will be times when you make the wrong decision and will need to go back and fix the mistake. As mentioned in the pattern, “fixing that mistake by rewriting the system from scratch may not be in the customer’s best interest. In those situations you will need to develop the ability to refactor and repair.” On the other hand, if you cut corners, you will end up with a subpar product by trying to dish out a program in as little time as possible. With the little experience I have in this profession, I can say that customers expect high-quality code and a fast turnaround time. Making such mistakes can be stressful especially when deadlines are involved.

When writing a piece of software that is useful, it is important to maintain the level of quality it should have. One of the ways I can think of that makes code higher quality is to utilize the principles of clean code. In doing so, I end up writing higher quality code that is arguably better to have than having something beautiful. Having clean code will be beneficial in the long run when I will eventually have to refactor my code. As I continue down this path to become a software craftsman, I want to culminate the skills that it takes to consistently produce high-quality code for customers.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: The Long Road

This week I decided to take a look at ‘The Long Road’ apprenticeship pattern that covers the expectations and the reality of becoming a software craftsman. The pattern begins by explaining that society expects immediate results without really thinking about the journey. Usually one would aspire to take the highest-paying job and the first promotion as opposed to building up your skills. The pattern encourages you to value learning and long-term growth over salary and leadership positions. Keeping a long term goal in mind allows you to hone your skills as you work towards it. Of course this pattern is not for everyone, the long road is just one of many that a software developer can take on their journey.

Reflecting on what I read in the pattern, it is certainly more realistic to set a long term goal as opposed to trying to go for the high paying jobs immediately. I am definitely guilty of having the desire for overnight success. I agree that the biggest factor for this would be today’s culture and as well as my family’s expectations of me. But when it comes to software craftsmanship, I would like to spend more time accumulating knowledge instead of settling down and potentially stop improving. The only statement that stuck with me was, “Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey.” I would say that I would probably not be ready for an executive job or being a team leader, but I can’t deny that money is one of the bigger motivators when it comes to working. That being said, you always have to start from somewhere, and I have much to learn. This pattern is more so a reminder for me to take the time to improve my skills and success and money will come after.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Following sprint 2, I will start off by saying what worked well. I think we are a little more comfortable with how the sprint process works. An improvement from the last sprint was that we knew what needed to be done for this sprint. We as a team decided to try and flesh out the backend and get it working before we start building the frontend. I think that we went into the sprint strong as everyone sort of picked up issues and started right away. Personally, I spent most of the sprint time working on the removeInventory endpoint and trying to wrap my head around how it would work. I had to look back on past endpoints that I worked with to try and find something to base it off of and ended up with something that made sense to me. For the most part, everyone finished their respective issues and we ended the sprint with a more structured backend.

Of course there is always room for improvement so I think we could definitely improve in terms of communication. There wasn’t much communication between class sessions, mostly reporting back to the team during the standup meetings. While it wasn’t detrimental to the workflow, it should definitely be something to keep in mind, myself included. In the second half of the sprint, we were trying to get the endpoints in one place so that inventory.js could be written and tested. There were some inconsistencies that I found between the endpoints and inventory.js so we should’ve definitely coordinated to decide on function names. We also ran into some issues trying to run the backend container so we couldn’t actually test it this sprint. For the next sprint we will need to test the backend and make it function as intended.

Based on my previous statements, we should make a point to increase communication outside of class time. During this sprint it wasn’t a major issue since we were mainly focusing on our own issues and only needed to coordinate once everything was done. That being said, we should make sure to notify teammates when we finish working on things so that we can carry on smoothly. Since we will need to get the backend working for the next sprint, I think coordination between those who worked on the endpoints will be essential. 

I will say that I am guilty of the lack of communication. I should have just sent a quick message to the discord when I had created a merge request or had an issue in need review. In this case, once the removeInventory endpoint was completed, I should’ve let Sebastian know since he was writing Inventory.js and I could’ve coordinated with him on the function names. Throughout the sprint, I essentially only worked on one issue, which was creating the endpoint. I would like to be more productive, finish issues within their set weights, and then move along with the development. I know what needs to be immediately done for the third sprint so we should be going in strong. I look forward to getting the backend tested and moving onto frontend work.

Issue #25 in the backend involved creating the removeInventory.js endpoint, where I referred to the API and existing endpoints to create.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: The Deep End

This week I decided to take a look at ‘The Deep End’ pattern, which covers the next step on your knowledge gaining journey. The main message of this pattern is to not be afraid and take that next big leap, whatever it may be. The pattern certainly doesn’t suggest taking a risk that jeopardizes your career, but rather taking on new challenges. Software apprentices can apply this pattern to scenarios such as taking on bigger projects, more complex tasks, working with larger teams, or in new places. While these opportunities may seem daunting, learning is all about stepping out of your comfort zone, even if it means failing at times. 

I am surprised that the pattern suggests diving straight into the deep end as opposed to starting shallow and gradually growing deeper. But I suppose if you were doing the same type of work day in and day out, your biggest break would come from a new challenge. Looking forward, when such an opportunity arises, I think the best way to face a new challenge would be to go into it prepared. This is certainly easier said than done. There is of course the mental hurdle of overcoming the fear of failure and the risk of actual failure. But again, as mentioned in this and previous patterns, you should be able to reach out to mentors and kindred spirits to help. I think that is one thing I should keep trying to recognize, that I should not be afraid to take on difficult projects if I know there is a network of people that can help guide me. 

This pattern is a good reminder to step outside of your comfort zone and it reassures you that it is okay to take risks in your professional career. Given that you have the preparation and a supportive work environment, taking on challenges will only help you gain more experience. I would think that currently, I am in the middle of one of these challenges. Up until now, I have only worked on smaller-scale projects with at most two other people. And for this capstone course, I am working with a team of 6, attempting to develop a fully functional inventory system from backend to frontend. So through this process, I have only been gaining experience and I look forward to what else I can learn.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Confront Your Ignorance

Last week I took a look at the ‘Expose Your Ignorance’ apprenticeship pattern, and this week I will focus on the ‘Confront Your Ignorance’ pattern. This pattern is closely related to the last. Once you have become aware of the gaps in your knowledge, you will need a way to address those gaps. It may seem overwhelming to try to learn skills that you are expected to have in the first place, but this pattern provides insight on where to start. In the previous pattern, you are advised to write down a list of things that you don’t understand fully, and then you can begin confronting your ignorance. Start with one skill, tool, or technique at a time, and educate yourself on the topic. There are many different approaches in doing so, including reading documentation and FAQs, building ‘breakable toys,’ and consulting with ‘kindred spirits.’ Once you have reached a level where you can comfortably work with said skill or tool, you can decide whether to continue honing your skills, or move onto the next item on your list.

I like that they have separate chapters that focus on exposing and confronting your ignorance. While both topics are related, they are entirely different hurdles that need to be leaped over. The pattern also mentions the balance between exposing and confronting your ignorance. Confronting your ignorance without exposing involves  learning in private potentially due to fear of criticism. Doing this only encourages that mindset that failure is not an option. On the other hand, you can expose your ignorance without confronting it. This can involve not taking action against your ignorance, which is also detrimental in a team environment.

Like I said in last week’s blog post, it is always best to recognize what you are unfamiliar with and take action as soon as possible. This is especially true in a professional setting, where things need to be completed in a timely manner. Thinking back to my first two years at Worcester State, I don’t remember asking for help often, which was definitely detrimental to me. Now, I am more open to the idea of looking into topics that I don’t have a strong understanding of and reaching out to classmates for help.Moving forward, I would like to continue practicing applying these patterns. Especially now that I am working in a team, it is important to not overly rely on them or drag them down by confronting my ignorance all the time.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Expose Your Ignorance

This week, I took a look at the ‘Expose Your Ignorance’ apprenticeship pattern. The pattern describes the dilemma in which your employer is relying on you to do a job, but you are unfamiliar with some of the required tools. This situation can be the result of many things, one of them is you are the only person that was available to do the job. The pattern proposes that you “expose your ignorance” when you need help rather than staying silent and learning on your own. It is potentially beneficial for everyone when you can present the problems you are having. Over time, it becomes detrimental to protect your pride and hide the fact that you don’t understand what you are working with. Not only does it prevent you from learning and doing work, but it also increases the pressure and workload for the team. So the best way to avoid all of this is to get comfortable with asking for help and showing off your learning ability.

As soon as I read through the pattern I could immediately relate to the problem described. In the time I have spent working, there were always a few occasions where I would be completely lost. And though it was embarrassing at first, it was always beneficial to ask for help as soon as possible rather than waste time getting nothing done. I could also see this potentially occurring in a sprint, where team members are all occupied with their respective issues, and you are left with a task involving concepts you aren’t familiar with. There is always the pressure to show competence when working in a team, but as stated in the pattern, asking questions will expose your learning ability to your team and can even help them gain new clarity about their knowledge on the subject.

The therapist’s story mentioned in ‘The White Belt’ pattern was mentioned again, which involved taking a not-knowing stance to better understand clients. But in this case of this pattern, it is not feigning ignorance, but exposing it to learn. I think the comparison between an expert and a craftsman was interesting: “experts will do everything they can to remain wedded to a single context, narrowing the scope of their learning, their practice, and their projects. Craftsmen, on the other hand, need to have the courage and humility to set aside their expertise and wear The White Belt as they pick up an unfamiliar technology or learn a new domain.” But as mentioned before, it is not the goal of an apprentice to become an expert, but a craftsman. I will continue to keep in mind that it is important to expose my ignorance.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Concrete Skills

This week, I decided to take a look at the “Concrete Skills” apprenticeship pattern in chapter 2. This pattern describes the problem of potentially joining a team, with the expectation that you will learn more than you already know, and the team not wanting to take the risk on someone who may not be able to contribute to the workload. It is important to acquire and develop “concrete skills.” Concrete skills serve as proof of your competence, as it more so demonstrates your ability to apply the knowledge that you have. The pattern suggested that one should always acquire more concrete skills than just the bare minimum required in an interview. It is always beneficial to have examples on hand as proof of what you can offer to the team. The examples of concrete skills provided include writing build files in various languages and having knowledge of popular open-source frameworks. And so, concrete skills help reassure your future teammates that you are capable of contributing without the need for “day care.”

My immediate reaction to the pattern was that I can see myself in this specific situation. The pattern starts with a quote from Pete McBreen, where he states, “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications.” That quote stuck with me because we can spend years studying a certain topic, but your expertise shows when you apply the knowledge. And reading through this pattern encouraged me to take a deeper look at the concrete skills I have developed thus far.

For the most part, I think this pattern gives some useful tips on how to build an impressive resume and come off as a capable job candidate. The question: “If we hire you today, what can you do on Monday morning that will benefit us?” is something that I will keep in mind since I will need to evaluate myself before even applying for jobs. I do think this pattern gave me a bit more insight into my intended profession. I never really thought about the fact that teams are more likely to hire someone that can be an immediate help rather than someone they would have to teach. So I think this is more encouragement to further acquire concrete skills. Perhaps I will spend more time with frameworks, especially ones we are working with in class such as Vue.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

With the end of my first ever sprint experience, I would like to reflect back on what worked, what didn’t work, and what changes could be made. To be honest, I felt like we were kind of just thrown into the first sprint with little time to prepare, but as the sprint progressed, my team ended up getting the hang of it. As a team we managed to create enough issues to work on throughout the sprint and everyone took up different issues to work on. We were swift to approve merge requests and review other members’ changes, so I think we worked efficiently on that part. 

As for me individually, I took on three issues, all of them involving the rearrangement of the file structure for each of the frontends. Issue #3 involved refactoring the file structure of checkInventoryFrontend where I based it off the MicroServices example. Issue #4 involved refactoring the file structure of addInventoryFrontend where I based it off the MicroServices example. Issue #6 involved refactoring the file structure for CheckoutGuestFrontend where I based it off the MicroServices example. I didn’t have much of a problem with them, as they were not complicated to complete.

As for what didn’t work well, overall, I think we as a team spent a lot of time trying to understand what everything was supposed to do. From each of the frontend to the backend, there was basically nothing implemented nor functional. I think because there was the daunting task of having to create the inventory system from the ground up, I had trouble actually picking out what needed to be done for this sprint. That aside, we managed to dedicate this sprint to preparing the files for implementation so that we would be able to start working in the next sprint.

As a team, I think we were able to come together and get work done. Some of the members of my team are people I have yet to work with, but there was no issue there. I am happy that I was able to help a fellow teammate resolve an issue they were having with the API. Aside from that, there was not much else communication between teammates during work periods as everyone was focusing on more individual tasks. This first sprint was more focused on the housekeeping tasks so there wasn’t much need for collaboration in the first place. I think in the next sprint, we will be able to greatly benefit from more communication and asking for help when needed. 

What I can improve on individually is to come up with more meaningful issues. This last sprint, I only created a handful of issues, all of them involved creating or moving files around. Now that this coming sprint will be more hands-on, it will give me a chance to come up with more specific issues, focusing on parts of the project that need to be implemented. I would like to work more efficiently, finishing issues within their estimated weight time. Overall, I am looking forward to the next sprint now that I have an idea of how the entire sprint process goes.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: The White Belt

This week, I decided to look at the next apprenticeship pattern in chapter 2, “The White Belt.” This pattern describes the dilemma of a programmer being confident in their skills of a language but has reached a plateau in their personal development. This pattern offers a solution to those who feel that they are not acquiring new skills fast enough. After reading through the previous pattern, I’ve gathered that it is important to keep learning and honing your skills. And this pattern directly addresses an issue that one would encounter when doing so.

The solution provided in this section is to put aside your current knowledge when approached with new knowledge. While this will potentially affect productivity in the short term, it will allow time for new knowledge to sink in. In the pattern, it states, “wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” This can be applied to learning anything because it can be beneficial to approach something new with the mindset of a beginner. The example with Dave the therapist was an example of when the mindset could apply outside of learning code. Dave found that taking a “not knowing” stance when working with clients opened up a new door of unforeseen possibilities and solutions. He put aside his expert knowledge on the subject and approached clients with curiosity.

Another example that I would like to refer to is that of the 10-year industry veteran Steve. He mentions that after reading “Working Effectively with Legacy Code,” his codebase improved into a better tested, adaptable system that was more fun to work with. While Steve did not go into detail, it was interesting to know how much more a 10-year veteran could grow. I certainly don’t have that many years of experience, but when learning new things, we are all starting at this hypothetical white belt. For the most part, the languages I have learned thus far are all based on similar logic. It would be beneficial for me to take one of my existing programs and implement it in a vastly different language. Not only would it give me a chance to learn a new language and the idioms, but it could also improve my coding skills in general, as mentioned by the 10-year veteran Steve.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.