Sprint Retrospective 1

To be honest, I think this first round of figuring everything out went as well as it could have. To start with what could be improved, I’d definitely have to say our team should establish much more concrete issues to deal with the specifics of what we prioritize for getting done. While we certainly got the gist of it as we were progressing, I was feeling quite lost in organizing epics and issues to be more to the point. A second thing that I specifically didn’t do well with was communication with the team. While in class we had no problems (in my opinion) and we get along quite well, but out of class I am egregiously bad at keeping up with messages. Thankfully, I don’t think it interfered too much with the work flow, but it certainly remains an important thing I have to remedy as I owe it to my teammates. In addition, I think the Scrum Master position was a little up in the air, as most of us were looking at each other for help with direction in our sprint. As a result, we all sort of pitched in where we could, and hopefully in coming sprints the role will solidify into a more acute position with specific responsibilities.

As for what went well, I think the team’s communication was much better than I was expecting. In some areas there was a bit of tension when it came to explaining a concept, or deciding what should get done first, but it was amicably resolved with no real issues. I personally enjoy working with everyone in the team, as everyone was ready to come to the table and pitch in. The only area of improvement I can really pinpoint is staying in contact with what each of us may be specifically working on at the moment. At one point me and a team member began to overlap what we were working on, which went on for a little longer than it needed to.  However, I don’t have much to say on this, as I think on the whole it went smoothly. The things that might need to improve I believe will just come with time as we continue to work on the project. 

As for myself, I think some members may not like me as much, as my participation could for sure improve, but that’s neither here nor there; I only say that to remind myself I need to be better. Another place I may need improvement in is with my explanations. I can be quite ramble-y with some assumptions about what others may believe, or already know. I don’t think in a condescending way, but only insofar that the gap in understanding of communication doesn’t help me to get my point across.  

As for some of my contributions, they are as follows:

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/8303274a7264a636ee71a2bc10ae57e4578b6806

Here is when I added a few schemas to the API repository.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9fe22f78eaa34a46c3cb32eedb7080bfe33b9bd5

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/71d797e318075cba6f1ded1bb31ceb0c4fcb7dd5

Here are a couple examples of when I added some basic files to get the API repository updated; I believe there are about 12 similar creations of basic files, but it would be repetitive to include them.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9412a5433a4e8adb9f617d0f892e5a879d1b2455

And finally, here’s an example of me updating a basic attribute file in the repository.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Craft Over Art

This week I decided to read “Craft over Art” from chapter 3. This chapter simply teaches us that as a craftsman, our prime focus should be to build something that serves the need of others instead of using a project for self-interests or to impress colleagues. This reminds me of most of the projects we are working on in class right now, especially the Thea’s Food Pantry. The focus is to build something that will serve the Worcester State Community.

I believe the benefit of doing something that serves the need of others is that we are doing something for real people. Seeing customers benefit our work, being happy with the product, use it and see it being successful is a great feeling of achievement. We see customers happy, satisfied and using something useful that will probably be there for a long period of time. Working directly for a client can also be stressful as there is a timeline that needs to be met, there are requirements, specifications, policies to follow and it is not always easy to satisfy every customer.

This is where I am bringing the beauty aspect. While reading the book, I understood that focusing on the usefulness rather than the beauty might only apply to a craftsman as he is still in the learning process, embracing his ignorance, taking the long road. Focusing on the beauty aspect of a project can be stressful, distracting and take away the usefulness which should be the priority. However, I believe in a more professional world, for a reputable company, being able to deliver both the value of a product and adding the refining beauty aspect is definitely advantageous. From my perspective, In the future, when I develop projects for customers, I will focus on the value and the usefulness it will bring to the community. However, one client is different from another. One community is different from another. Depending on where I work, if after getting to know the mission of the tech company I will work with and studying the type of customers we usually have, I find that beauty is something they want on top of the usefulness, I will want to deliver that and meet their needs. I think beauty is used nowadays to attract people even when the product itself is not well developed, has flaws and will not be durable. It is unfortunate that art to attract money is put first over craft to serve a community.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog Post

This sprint I feel we all did pretty well all around, and were able to accomplish almost all of what we set out to do. The workload felt very balanced throughout the sprint, not too heavy, but not too light either. My contributions to the sprint were adding files to our Documentation Repository, researched Ingress & Gateway, & researched RabbitMQ.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/3

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/documentation

The above links will take you to the issue to add the files to the repository, along with the repository with the files added to it.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11

Here is the issue to research Gateway & Ingress, what they do and how we can take advantage of them.

https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/5

Lastly, I researched RabbitMQ and what it does and how we could use it.

I cannot think of much to add with regards to change, maybe add a bit more detail to my research posts, but otherwise I think everything was solid.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

Learn How You Fail

This Apprenticeship Pattern covers learning how to fail, and more importantly how to recover from failing. It makes the point that failure is necessary to learn a new skill, and if you’re never failing then you’re likely not trying new things and not expanding your knowledge. Failure is a normal and natural part of learning something new, and it’s just as much a part of the process as anything else. If you want to learn a new skill, you can’t be afraid of failure, and you have to accept that it will happen at some point. By trying to avoid failure, you’re actively hindering your learning and limiting your potential skill.

The Apprenticeship Pattern also makes the point that learning how you fail helps with self-assessment. Through failure, you can learn more about yourself, such as what things you have more difficulty with, and what things you can pick up relatively easily. If you don’t try to push yourself to failure then you’ll never discover your limits, and you won’t know how efficiently and effectively you could be working. Failure also forces you to admit your weaknesses, and to learn not to waste time with things that are outside of your skillset, and instead spend your time doing things that you know you can do correctly.

The Apprenticeship Pattern also makes a point about not getting down on yourself about your failures. By changing your mindset from failure being a bad thing to failure being a valuable experience for learning, you will become more productive overall and more capable of learning new skills. If every time you experience failure you get down on yourself and become afraid of failure to avoid the experience, then you’ll become much less productive, much less capable of learning new skills, and much less experienced overall. The correct way to minimize failures and maximize potential is not to avoid it altogether, but instead to take it on your stride and learn from it so that the situation in which the failure would occur wouldn’t ever happen again, rather than avoiding the failure itself. Only in this way would you be able to become a proficient software craftsman, because that requires learning many new skills, and has the potential for many pitfalls and failings that you must learn from.

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

Reflection on the Record What You Learn Apprenticeship Pattern

This apprenticeship pattern encourages apprentices to record what they are learning, in either a public or private place (or both). Either in a blog or wiki or even just a personal journal. Each has its pros and cons, but in each instance, they allow you to look back and reflect on what you have learned, what you were having trouble with and can give you a map of where you have come from.

While I was reading this pattern, I couldn’t help but think of this blog itself. While at the beginning I thought of this as something I would only ever use for class, I can see myself updating it in the future to be a far more professional blog space where I can record my experiences in my professional career. Even in the past year, I have found myself checking old blog posts about other patterns I read about to form connections between them. Like the Breakable Toy pattern, where I talked about starting a wiki being a good idea. That feeds right back into this pattern, already showing its effectiveness as a tool.

I never really thought about writing being a part of this field, but as someone with an innate interest in writing, and who has gone so far as to minor in it, I am really excited to see that this is a larger part of the lifestyle of other software developers. I hope to be able to continue writing, either professionally or as just a part of my own journey to mastery of the craft. It is something that has always been a big part of my life and being able to do it in conjunction with software development is really important to me. I think that this is as good an outlet as any for that seemingly unrelated skillset.

I don’t think I disagree with any part of this pattern really. I guess if I had to pick something it would be uploading it for everyone, but even then I think that way of doing it has some value, I just think you should have something private as well. Overall, it’s a fairly straightforward pattern and aligns with what I enjoy doing anyway. I’ve been looking into using Obsidion as a wiki-creation software, and I think that it has potential for this sort of activity. Clearly, this is a fairly common practice within the industry and I hope I will be able to find the motivation to keep up with it as my career goes on.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

“Breakable Toys” Apprenticeship Pattern

Summary:

This apprenticeship pattern deals with a software developer that cannot afford to learn by failure. This software developer may work at a company that must get things correct, and thus cannot experiment and learn from his mistakes. Thus, this pattern recommends the developer to create his version of his work’s program in private, to experiment so he can learn.

I want to say off the bat that I do not disagree with anything stated in this pattern. In fact, the most I’ve learned has been from practicing and failing repeatedly, so I strongly believe that this is a very important pattern for all developers.

This pattern has helped me greatly in my understanding of development. For example, in one of my homework assignments that required me to implement an algorithm that sorts operating system “jobs” by time to process, I wanted to use what is called a “MultiMap”, that is to say, a Hash Map that allows duplicate keys that could then be sorted, by key or by value. After this assignment, I spent hours trying to figure out its implementation, and I eventually figured it out. By following this pattern, I was able to figure out more about Java types, and I taught myself how to use hashing algorithms. 

I find this apprenticeship pattern very interesting. I bring the above example up because what I find interesting about this apprenticeship pattern is that I never thought to apply it to my work projects. There is a lot of information that I’m learning about when I’m working outside of school, and this pattern has indeed changed the way I think about how I will work and what my profession will steer me towards, and vice versa. 

I will try to create a private project with homework or work in which I implement the project differently, and try to see if I come up with any valuable results. There are many things I’ve learned from applying this principle to a few homework assignments or free time projects, but I can feel that this would be very beneficial in trying this with new systems, or alternate pre-existing ones from school or work.

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

Retreat into competence

The context of this pattern is that when you realize how little you know, when you get out of your comfort zone and try new things. I think everyone who has done programming has gone through this problem. When you are writing code, nothing works on the first try then you try again the next day, and it still does not work the way you want it to be, at that time you feel like you don’t know anything at all. Then after a couple tries, the solution starts to come to you and everything starts to make sense, then you connect every idea and make it work. Just when you feel like you know everything and move to the new issue/project then the cycle repeats, once again you are introduced to the vast reaches of your ignorance, and you are overwhelmed.

The solution to such problem is to take a step back to jump two steps forward like a slingshot in carnivals. As the pattern says apprenticeship is a roller coaster ride as you thrive to learn new technologies, leveraging your knowledge and creativity to deliver value to your customers but if you compare yourself to someone who knows more than you or is an expert in the field then you will feel terror of perceiving just how little you know of things. A pattern like this is relevant to people (such as myself) who have pushed themselves beyond their ability, where they are constantly trying to learn new things, one after another, and there will be a time when this pattern kicks in. When such things happen, you retreat back to your competence to regain your composure. Take some time to build something that you already know how to build then use that experience to recognize how far you have come, then use that recognition to boost your confidence. For example, pick something self-contained that you know really well and reimplement it to remind yourself of your own capabilities. There is also a way to prevent from overwhelming, you can accept that his pattern is only a short time fix. You can set yourself a time limit. For example, I will refactor this code for half an hour before I jump into making another function or adding another feature.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

The long Road learning pattern

The long road learning pattern sets its premises on favoring rather than quick results cumulative progress. I believe that working towards a 4-year college degree and the tradeoff that comes with it puts us in that category. We all know that even after the switch from student to paid professional the road doesn’t end. In fact, one of the reasons, I decided to pursue a career in technology was the promise of perpetual learning that the field offers.

The author mentions the constant change in technology and a deeper intrinsic knowledge we developed over time to deal with them. In a sense I believe, he meant that as we acquire experience, we become more sensitive to patterns.  These patterns can help us become more agile in adapting to new tech as well as seeing projections of how they would unfold ahead of their full development. Regardless of how far we get we must not give into the ego and assume things with certainty we can’t guarantee.

We must watch for hardening during the long road. The author doesn’t offer any cautionary warning for this pattern, but I believe it warrants one. In many professions I see how the long road can become a trap to steer you away from self-development. It is extremely easy as you gather knowledge along the road to become a know-it-all. To me there are 2 versions of the know-it-all; the flexible version where one knows a lot but is open to change; the hardened version where one knows a lot and cannot change. I think it has a lot to do with egos, the flexible one is probably perceived by others as knowledgeable but does not care about the title itself so it makes it easier in the long run to reshape knowledge; and the hardened one sees itself as knowledgeable, the title is important so no exterior knowledge that conflicts with its own can be accepted. The hardened one should be avoided; professional life is about social interactions and the hardened one will become isolated or be avoided by others while the flexible one will flourish in a social environment and grow with it.

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.

Post #3 for Apprenticeship Patterns: Rubbing Elbows 

Rubbing Elbows describes the benefits of developing relationships with other developers at your own level primarily. Working closely with others in a friendly, yet conscientious way is a skill set that is very important to develop. This includes working with peers and mentors, as well as those who are less qualified than you.

It is really important to have mentors. The book focuses on having one mentor, but I think there is room to have many. If you are lucky enough to end up in an environment where you are surrounded by many talented people, it is advantageous to you and to others, to gain information on subjects that will expand your career from anyone who is willing to help, even if it is just with a 5-minute conversation. Although you should learn from mentors, you can also be helpful to them in many ways. Letting them know you will follow up on minor problems they are encountering, or that you will do further research on what they are teaching you will help. Sending emails thanking them for their time, and briefly reiterating what they have taught, will let them know you are grateful, and serious about their advice. This will make them want to help you more in the future and will also make you appear to be a real team player.

The basic intent of the “Rubbing Elbows” pattern is to have you form relationships with fellow programmers at a similar peer level as yourself (Kindred Spirits). It describes the benefits (and difficulties) of working in “Pair Programming” situations, and will make your job more enjoyable and social, but it mostly will accelerate your professional development, as long as both developers are working to help one another. There are situations where you will be paired with someone who is just out to get themselves noticed, as well as those who are looking to take all the credit for shared work, so be careful who you decide to focus a lot of energy on.  

To expand on the pattern, I would also add that I think it is equally important to help those of your peer group who may be struggling on a given issue you know more about, and to help those who are less experienced as you. These people will be grateful to you for your assistance and may end up helping you over the months and years ahead far more than you would think.

This pattern is also applicable to those you meet outside of your job. Those you meet at conferences, training courses, and Computer Science related clubs, as well as those you “meet” online in forums like stackoverflow.com can be very helpful to your goals and could actually become long-term friends.

The bottom line is that you can learn from anyone, and you can teach anyone, as long as all parties are on-board with being respectful to each other as individuals.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

For our first sprint, our goal was to familiarize ourselves with the different components of a system that we need to work with and that we don’t know. Most of the issues present in our first sprint dealt with researching these aforementioned components, for instance, RabbitMQ, EKS, and Kubernetes. As such, most of our issues were researching the anatomy of what we’d be working with via AWS EKS. I believe our main difficulty was determining what we needed to research, and what was useful or not.

To get what did not work best out of the way first, some team members, myself included, missed the deadline on some of the issues. In my case, this was due to the fact that we are unfamiliar with much of what we’re researching, thus, the issue I dealt that I’m referencing with was denser than I expected it to be because it’s difficult to project precisely how long each issue would take, or if we need to split it up into several smaller issues1. 

What worked well was our team’s communication with each other in class, and in some of the issues. It took a few classes to warm up to each other. I think the descriptions and how we formatted our research also worked well. In general, we used markdown to break down our research into more digestible sections that made it easier to understand2. Another thing I thought worked well was the description of what we may be looking for in the issue descriptions. While difficult to be too specific, it helped as a starting point for the other team members to begin once they finally started on the issue3. 

As an individual, I think I could improve on meeting issue deadlines in a more timely manner. While I mentioned earlier that the issue was denser than I thought it would be, I also should’ve managed my time better, and started working on this earlier to fully understand the time it would take, so that I might’ve been able to mention it in the next class. I also think that I should’ve talked more through the GitLab Issues / Epics rather than other means. While I did communicate using the aforementioned means, it may be better to discuss more, especially as our future sprints will more than likely demand it.

As a team, I think we should institute a better application of rules throughout the issues. While writing this, I realized the issues implement markdown format differently than others4 5. I don’t think this is a big deal, but it may be better to implement some form of standard across the issues. I also think that we may need to communicate a little more via the GitLab Issues / Epics. In this first sprint, most of the issues were independent research that usually didn’t cross over into other issues very much, hence there was little need for communication between team members. However, given that the second and third sprints will involve deployment, it is both required and vital that we communicate on GitLab.

Evidence:

  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/13#note_848604859 – A note left by me explaining why it took extra time.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14 – An example of research using markdown to partition the different parts of research as mentioned above.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/4 – Example of an issue’s description that includes a brief description and several points of interest.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11 – An issue description using spacing to separate sections.

5. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15 – An issue using titles in markdown to separate sections.

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