Retrospective – Sprint #3

During this sprint, I contributed to 3 issues:

1. Determine what needs to be done on GuestInfoFrontend – GuestInfoFrontend/issues/88
   (As a whole team, we explored the GuestInfoFrontend for any improvements, and created tickets for teams next semester)
   
2. Verifying that InventoryAPI has the correct extensions, linters, and pipeline stages – InventoryAPI/issues/25
   (As a whole team, we reviewed and made changes to files in the InventoryAPI to ensure extensions, linters, and pipeline were all set for next semester)
   
3. Verifying that all Thea’s Pantry projects have the correct extensions, linters, and pipeline stages – Inventory Backend – InventoryBackend/issues/101
   (3 of us reviewed and made changes to files in the InventoryBackend to ensure extensions, linters, and pipeline are all set for next semester)
   

Again, this sprint I also assisted in reviewing some issues for the team

This sprint was a breeze, all of us were comfortable working with most systems at this point and we were able to complete almost every one of the issues we set out to do. We did have a little hiccup with the GuestInfoFrontend as we were unsure of the process to start a backend and frontend hot reload instance after moving from Docker to Gitpod but after some direction from Professor Wurst, we were able to continue with our Determine what needs to be done on GuestInfoFrontend issue. Other than that we didn’t run into any problems over the duration of the sprint and we completed >75% very fast this time around too.

I don’t think that there is much or anything for us to improve on this sprint since most of the issues we worked on this sprint were team-collaborated issues we spent less time working on issues than in prior sprints since we were able to collaborate and fix any bugs with ease. Any of the issues that our team members did take on themselves, such were done without much if any assistance past peer reviewing, and overall the team worked like a “well-oiled machine” this sprint.

As a team, we killed it this sprint. We improved on our weak areas from our last two sprints and further solidified what we did well. I feel like communication can always be improved as we had made strides from our first sprint but I feel as if it had stagnated to an acceptable level for sprints #2 and #3. Other than that I can say there was anything that we should have done differently as we were on point this time around. Our in-person communication was a lot better than our discord communication but in the end, both weren’t bad at all, we just could have done better in some areas.

As an individual, I felt as if I could have worked more spreading the load of work since I feel that compared to our other sprints I had taken the least amount of burden of work this time around but if I look back to sprint #1 I feel that maybe it balanced out over the whole year since I felt as if I took on a large burden of work the first sprint so overall I think it evens out. I also could have been better at communicating when I will be on for calls as I had just joined when I could due to school and life just being busy so sometimes I joined Discord later than our usual time without explicitly communicating I would be doing so.

In the end, I feel as if this sprint had been our best yet since we had completed almost all issues (1 wasn’t completed), spread our burden of work, and communicated the best we had the entire semester. While there is always going to be room for some improvement, I feel that we had found our rhythm as a team this time around and we operated at our maximum efficacy.

A New Belt, A New Perspective

This week I chose to read “The White Belt” section under “Emptying the Cup”. This pattern calls for one to fully embrace the beginner mindset when faced with new learning opportunities. It encourages placing preconceived ways of thinking aside when tackling new situations to do so with a clean slate to allow for new perspectives to be formed. By subscribing to this mindset, one can increase their learning and understanding of different languages which in turn will aid them to progress their path as a craftsman forward.

This pattern highlights the importance of learning in professional growth because, in today’s rapidly evolving market, the ability to adapt and learn new skills is crucial for staying relevant and competitive prospects. Reaching a certain level of expertise may cause one to fall into complacency or build a reluctance to venture into unfamiliar territory.

What I find insightful about this pattern is its analogy to martial arts, where the white belt symbolizes a beginner’s journey toward mastery. Just as a martial artist must approach each new technique with a fresh perspective, a software craftsman must be willing to let go of their preconceptions and embrace the unknown. This pattern serves to remind readers that mastery is not a destination but a continuous journey of growth and self-improvement.

The pattern also highlights the discomfort that can accompany stepping outside of one’s comfort zone, especially for experienced craftsmen. As someone who takes pride in their expertise, it can be challenging to admit ignorance or make mistakes. However, the quote from George Leonard reminds us that embracing foolishness and spontaneity is often the key to unlocking creativity and innovation.

I appreciate the advice provided in the pattern, such as unlearning something familiar or exploring new programming paradigms. This encourages craftsmen to actively seek out opportunities for growth and challenge themselves to expand their horizons.

While I agree with the overall premise of “The White Belt,” I recognize that fully embracing a beginner’s mindset requires courage. It’s not easy to admit when we don’t know something or to let go of our old ways of thinking. However, as the pattern suggests, the benefits of adopting this mindset far outweigh the temporary discomfort one may feel.

In conclusion, this pattern serves as a powerful reminder of the importance of courage, curiosity, and continuous learning in the development of one’s craft. By embracing a beginner’s mindset, craftsmen can unlock new possibilities, foster innovation, and ultimately reach greater levels of mastery in their chosen fields.

The Power (and Curse) of Retreating into Competence

This week, I chose to read the “Retreat into Competence” pattern and found its overall message quite interesting since I see it as a helpful but potentially harmful one. It suggests that when faced with challenges that can leave me feeling overwhelmed or upon realization of my limitations, I should temporarily retreat into known territory to prepare myself to confront the unknown. Doing so will enable me to rebuild my confidence and be able to prepare myself to tackle any challenges that may lie waiting in my future career. While retreating can be helpful, it may end up being harmful and the pattern also highlights the importance of setting time limits for retreat to avoid it from becoming an issue. Setting time limits and asking for help from mentors will ensure if I feel that I must retreat into competence in the short term, it won’t lead to the stagnation of my development in the long term.

I believe that setting time limits for a retreat into competence is vastly important in keeping one’s journey into evolving from an apprentice on the proper path. It works toward preventing people from becoming complacent or stagnant when returning to their competencies. Placing limits encourages an environment where one can gather thoughts and pool together any necessary resources before returning to the thick of it promptly. Asking for help from mentors is also important in aiding to overcome obstacles. Even if something may seem overwhelming at first approach, with the guidance of others, such may appear a lot more manageable than it had before.

I think the pattern provides a good framework on how to deal with my limited knowledge due to my lack of practical experience. It’s common for anyone to feel overwhelmed by new things, especially in the early stages of learning or taking on new challenges upon transitioning from a learning environment into a professional environment.

I have to also mention that the notion of retreating into competence can be helpful but it also may be harmful if not done correctly. It may be helpful, but making a habit out of retreating may result in taking fewer risks even when establishing time limits. I feel as time goes on, the necessity of retreating may fade away, but if a habit of retreat is developed and relied upon too much, it may do more harm than good in the long run.

Overall, I think the “Retreat into Competence” pattern sets a solid framework for new apprentices to follow by destigmatizing the fear of the unknown. It shows retreating when faced with a challenge can be beneficial if used correctly.

Valuing ‘HARD’ Skills: A Key to Professional Success

This week, I decided to read the “Concrete Skills” section of the “Emptying the Cup” chapter. This section discusses and highlights the importance of having strong technical skills, as well as good team skills, in order to be a promising and invaluable candidate for any prospective employers. I recognize that others who have been in the workforce longer, regardless of past profession, will have a head start on my soft or team skills by having more work and life experience than I possibly can at this exact moment. With this knowledge, I must understand that having soft skills alone won’t get me a position anywhere, since even though I do have some experience, it is very limited. By focusing on my hard or technical skills, I will be able to show any employer the types of direct contributions I can make to the team without needing to be taught or walked through.

I haven’t had the opportunity to gain software-related work experience, but I have been able to acquire some experience from a position working with data for around a year now. Even with that being said, I know I am still a risk to any employer since I still have yet to get my first position on a software team. By ensuring I have a strong foundation of technical skills, I can show to any future employer of mine that I can and will contribute to the team in a mutually beneficial way. In exchange for giving me a chance to learn and improve upon my craft, I will bring the pre-existing technological skills I possess to contribute to the optimization of any team’s efficacy.

Of course, as time goes on, I will become less focused on my technical skills and find the balance between displaying my “hard” skills as well as my “soft” skills complemented by any experience or achievements I will gain in the future. But at this current moment, I understand I don’t have that luxury, and any employment in the near future will be solely focused on my skills and what I could bring to the table.

Overall, this section reinforces the necessity of strength in the technical abilities of an entry-level prospective employee to ensure that their ability and understanding of programming will help jumpstart their journey into becoming a master craftsman. Over time, however, building a balance between technical and team skills, complemented by my future achievements, will be key to progressing from apprentice to journeyman and, one day, to a master.

Retrospective – Sprint #2

During the course of this sprint I contributed to 3 issues:

1. Verifying GuestInfoBackend – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfobackend/-/issues/121
   (Reviewed previous changes made to GuestInfoBackend and fixed any pipeline issues)
   
2. Verifying GuestInfoAPI – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfoapi/-/issues/150
   (Reviewed previous changes made to GuestInfoAPI and fixed any pipeline issues)
   
3. Verifying GuestInfoIntegration – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfointegration/-/issues/24
   (Reviewed previous changes made to GuestInfoIntegration and fixed any pipeline issues)
   

I also assisted in reviewing tickets this time around, although to a lesser extent compared to the last sprint.

What worked well during this sprint was our ability to cooperate in finishing all our issues quite quickly. We reached 75% completion much faster than in our first sprint. Overall, this sprint seemed to pass by more quickly, despite being longer and requiring more work than our first one. I believe our previous experience contributed to making the whole sprint run much smoother. Whenever anyone needed help or had questions, we were able to work through most things as a team. Once again, our team seamlessly switched between meeting in-person and asynchronously. If anyone couldn’t attend a meeting, ample communication was provided in advance. During this sprint, most of the tickets I collaborated on involved two or more people. I believe this also contributed to the feeling of the sprint passing by quickly, as work was more evenly distributed among team members.

The only thing I can think of that we could have done better is perhaps slowing down slightly to thoroughly review our work and look for any opportunities for future enhancements. We didn’t rush the work by any means, but we did leave plenty of time toward the end of our sprint, which I feel we didn’t fully capitalize on. However, the main focus of most tickets created this sprint was on the pipelines of various components of the GuestInfoSystem, ensuring that everything was running correctly. With that in mind, if all linters were functioning properly and not returning any errors, we reviewed the changes and moved on.

As a team, I feel there isn’t much we need to improve upon. We significantly enhanced our communication and work distribution compared to last sprint, and I believe this sprint went extremely smoothly. We executed many aspects well this time around, and I don’t see a need to revise or change our working agreement at all. Overall, the sprint was not stressful in the slightest, and I was pleased with how we operated.

As an individual, I felt I could have contributed more towards achieving team success. Perhaps in the next sprint, I will take on more responsibility for reviewing issues again. I feel this way because comparing what I accomplished during our first sprint, the distribution of work was much better this time around. However, it might have been a result of everyone striving to contribute equally.

All in all, I was pleased with the outcome of our second sprint. We were exceptionally efficient, even more so than in our last sprint, and we successfully improved on the objectives we set after concluding the previous sprint. I’m eagerly anticipating how our final sprint will unfold, and I have a feeling it will be just as successful.

Learning Never Stops

I decided to read the “Reading List” section from the “Construct your Curriculum” chapter, and I found it quite eye-opening. I have read some general books related to software development and computing, whether discussing theory or practical information. However, I must admit that most, if not all, of what I have read has either been out of necessity for course requirements or coursework-related. I have yet to build a list of literature to read or go out to seek literature to read now. After viewing this section, I will get started looking deeper into the literature related to the particular fields I’m interested in to aid me in my future profession(s).

While there is plenty to read and endless amounts of information to consume, it’s important to find things that are related and applicable to my work or studies. At this current moment, I am interested in software development in general, but I would like to get into the fields of robotics and/or artificial intelligence after graduation. Even though these topics are constantly changing and evolving, I can find some good literature to aid in building my overall knowledge related to such topics.

With the advent of the internet, text is no longer purely physical, and I can access even more literature than ever before. But with that perceived benefit also comes the caveat of there being too much for one person to reasonably consume. There are plenty of resources I can use, though, including the internet, peers, and/or mentors. Utilizing such resources can aid in my sifting through the unnecessary filler content to delve into text that will meaningfully add to my knowledge base. Even if something may not be useful directly at the moment, I also recognize that important information isn’t always apparent at the exact moment it’s consumed. Focusing on my present needs but also tending to potential future ones, will most definitely add to my progress on my craftsman journey.

I recognize that my learning must never come to a halt since complacency could easily lead my path toward becoming a master craftsman to become derailed either temporarily or permanently. By looking for and curating literature to serve my own needs and wants related to my present and future professions, I will be able to become a well-informed craftsman while remaining open-minded to new and ever-rapid changes within the entire computing field, whether that lies in practical work or research. Regardless of what field I venture into, this skill will always serve to benefit my work and hopefully help me aid others in their journeys as well.

Retrospective – Sprint #1

During the course of our first sprint, I contributed to 3 issues:

1. Gitpod Dev Environments – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventorybackend/-/issues/69 (Created new files to support the use of settings and extensions in Gitpod instead of Docker).
2. Move from commands to bin – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryintegration/-/issues/6 (Changed commands file to bin and altered any mentions or uses of prior commands files).
3. Add AlexJS linter to the pipeline – https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/inventoryintegration/-/issues/7 (Assisted in adding Alexjs to the Inventory Integration pipeline).

I also reviewed a majority of our issues at the end of our sprint and collaborated with teammates to fix any errors with issues, mainly regarding merging.

What worked well during our sprint was that we were all able to help each other and work towards achieving our goal of at least 75% completion of our planned issues. We were all able to reach out and have any questions clarified in a timely manner if anyone was stuck on a particular step or concept. We efficiently used our time for standups and were able to seamlessly transition between our virtual and in-person meetings without any issues. Regardless of our meeting location, we were able to meaningfully collaborate on issues, and when working individually, we were still able to bounce off each other if needed.

What didn’t work well is that we could have planned more properly in splitting the workload evenly per person. As a team, we could have done a better job in communicating what needs to be worked on and/or reviewed to allow for everyone to participate in our sprints. We didn’t communicate much over what we each planned to complete and just went with the flow as we went along. This did not hinder our progress, but it did, however, hinder our overall planning efficacy and the spread of participation.

As a team, we could work towards communicating better when discussing what needs to be done and what is yet to be done. By improving our communication, we would be able to reach our goals as we had in the past while also allowing for all members to have a substantial impact on our overall sprint. By better separating our work, it would also help even the spread of workload and stress to each member instead of having some members dealing with more to do than others when other members are available and willing to contribute/collaborate.

As an individual, I felt as if I could have also communicated better to facilitate more work being spread instead of taking it upon myself to make sure all work was reviewed and ready for merging. While it helped to ensure we were prepared for our review session, it still left others in our team unable to participate as much since, while I did take the initiative to get our things done, it left little room for others to contribute to our tickets if they had not already participated.

Overall, I’m happy with how our first sprint turned out, it went pretty smoothly, and I’m looking forward to our next sprint.

Don’t Trade Programming for Promotions

Even though it may seem counterintuitive, it makes perfect sense. If you take yourself away from the code you will slowly lose your way with your craft. It’s important to continue learning and practicing even as a master craftsman. Higher positions in a company won’t always equate to “better” positions for a craftsman.

It’s a part of “walking the long road” and staying on the path is crucial to one day finishing that path. As it goes for anything in life, you can never truly fail at something until the day you give up and cease trying. If one were to take a position that pulls them away from programming it allows for their long journey to appear shortened, but in reality, they just took one of the many exits along the way onto the intended destination of becoming a journeyman then master craftsman. Along this road, journeyman status can be achieved and one may choose to stop there but personally, I’m striving to eventually arrive at master status in the future.

I also agreed with the pragmatic response offered in how to react if faced with promotions that pull away from programming. If working for a flexible company, ask for better pay or non-traditional technical management roles instead of accepting such a promotion. If working for an inflexible company, it’s better to seek other opportunities elsewhere than to let yourself become lost along the long road.

I also found myself agreeing with the notion that if the rewards offered by employers aren’t appealing, one should counter with some rewards that are better suited for their interests and professional growth. It could be helpful if one were to prepare alternative incentives and rewards before refusing a promotion (if possible) to allow for transparency and understanding of the professional goals of the individual.

I think that overall, to “stay in the trenches” is a great mindset to have. It’s equipped my mind with the knowledge that shines importance on staying within a position that allows me to continue to practice and grow as a craftsman. If I were presented with such an opportunity in the future, I’d remember that it’s more important to continue on my long journey than to let some small miscellaneous gains to pull me away from my end goal of eventually becoming a master craftsman.

Exposing Ignorance

While sometimes difficult, I found the practice of “Exposing your Ignorance” to be extremely important in many aspects of life, and naturally it makes sense that it applies to software development the same.

Understanding what is left to be done/improved upon is a core part of development and this rings true for anyone’s apprenticeship. If one cannot see what needs to be improved in their craft, they can subtly become too comfortable with one expertise causing them to never be able to achieve true master craftsman status by holding themselves back due to their complacency.

By asking yourself and figuring out what you are good at and what you are bad at it will allow for the greatest improvement along the apprenticeship journey. Having humility when learning is essential, you may try to fake it until you make it but that will only take you so far before too many errors or issues arise putting your overall proficiency and potentially your position in question. Accepting you are not going to know or understand everything allows for one to learn more efficiently and quicker by choosing to reach out for help when needed rather than forcing themselves to “figure it out”.

I also found it interesting that this practice shines importance on displaying your learning ability to your team. It’s important that if you don’t understand something it’s okay to speak up and let that be known since the team you’re a part of is most likely going to be understanding of your inexperience. One must remember, that their team members had to be in your shoes at one point to get where they are currently.

From my own experience, I learned the hard way that struggling alone is so much harder than just swallowing my pride and asking for help. It seems like obvious advice but generally, I can be stubborn and sometimes I can feel reluctant to ask for help. Sure there can be lots of gratification in solving hard problems on your own, but sometimes it takes way longer than it should to make a seemingly “easy” change. This is because an “easy” or routine task for the team you’re a part of might not be “easy” or routine for a new inexperienced member.

By asking questions I can and have avoided misusing my crucially valuable development time by not being afraid to admit I need help. Struggling alone is always going to be worse than reaching out since there are many more meaningful uses of said time instead of being drained unnecessarily. If you don’t take the steps to become informed and more well rounded then you will continuously bottleneck your development as a craftsman.

Apprenticeship Patterns Introductions

After reading the apprenticeship pattern introduction and each of the chapter introductions, I found myself intrigued by the advice offered to newcomers entering the software industry. It fascinated me how the medieval craftsman model can be applied, and the concept of “seasons” of expertise can aptly describe the stages of one’s software development journey. I had never viewed the different stages of an individual’s career in the software industry as distinguished apprentices, journeymen, and masters. However, after reading the explanation for each stage/season, it makes a lot of sense and appears more applicable to the field than I had previously thought.

While not being identical to say a blacksmithing apprentice, individuals who are educated or have little experience within the industry are still apprentices with much to learn in the ever-expanding and diversifying field of computing. Understanding and recognizing this could potentially go a long way in aiding one’s development into becoming a journeyman and, eventually, a master craftsman.

I also found it interesting how Pete McBreen offers a specific distinction, he views being a Software Craftsman or Engineer as two mutually exclusive things when, from my perspective (and pointed out later in the introduction), the line between engineer and craftsman remains quite blurred. It is difficult to dictate exactly where being a software engineer or craftsman starts and/or ends.

While briefly looking over each chapter and reading their introductions, I felt reassured since I had encountered some of the advice I was reading before, reinforcing that previous mentors were knowledgeable in what they taught me. I was also struck with a feeling of my eyes being opened to new ideas or practices that I could employ to further my journey and hopefully help others in the future who may view me as a mentor, aiding them in their learning journey.

A particular part of the introduction (chapter 1) resonated with me deeply. Carol Dweck is quoted stating “effort is what makes you smart or talented,” a value I hold dear. I maintain the belief that anyone has the potential to excel in anything, but only those who put a lot of effort into learning and building their expertise are considered “smart” or “talented” in any field/profession.

Overall, I am looking forward to delving deeper into the good practices that will aid in furthering my learning and personal development, as well as contributing to the development of my peers, by being equipped with tools to help everyone succeed.