Sprint 2 Retrospective

Photo by Kaique Rocha on Pexels.com

During our second sprint for the InventorySystem project, we focused primarily on getting basic “skeleton” systems in-place. By this I mean that we tried to get simpler versions of each of our components working so that they could be used as a baseline for future development. The frontend, backend, database and IAM (Identity & Access Management) systems were focused on primarily throughout this period of work.

I would say that we likely had a proper amount of work planned for development, during this sprint our team was actually bigger, so it was a great help to have more people around to work on development tasks. Because of the larger team, we were able to split-off and each focus on a specific area of the project more effectively.

Two people focused on the frontend (one person worked on one of three necessary frontends each) since there was the project requires multiple front-end interfaces to function. One person focused on the IAM system specifically, and one person focused on the backend system initially. As the sprint progressed, everyone generally was able to complete the majority of necessary tasks, and the project went from having lots of documentation with little working code/examples to having a collection of basic interfaces and systems.

One difficulty I faced specifically was in trying to decide on the appearance & layout of the frontend I worked on during the sprint. Because the preexisting site for the food pantry exists only as a page on the main WSU website, I didn’t have much to go off-of for design besides the general color choices and logo design provided by the university. Something which I found helpful was to organize a meeting with the other teams working on the project, and to ask some questions regarding their process and design choices for their own front-ends. Additionally I was able to get some good advice and feedback from others on my own team based on the development of their frontend components for the project.

I think that having more team members definitely helped our team to be more productive, the process of “splitting-up” tasks worked a lot better this time around because of it. Previously the idea of each person “specializing” seemed harder to achieve, as despite the benefits of distributing the work, there were less people overall, and focusing on one thing meant that other areas would lose out on development focus. Now having a bigger team we were able to use this to our advantage and distribute work more effectively throughout the sprint.

In terms of communication, we used GitLab throughout this sprint to coordinate our efforts, and it seemed like everyone was more used to the process of creating issues and communicating concerns/ideas regarding those issues throughout development. Here: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/inventorysystem/community/-/issues/36 is one of the issues I worked on, and generally I tried to include things like screenshots of the work I was doing, links to the repository for any code or examples I had worked on, and descriptions included in the comments regarding the process and anything I might have concerns about. Other team members used Gitlab similarly, posting links to relevant resources which could be helpful to others, linking to their work/posting screenshots and describing any difficulties or issues they ran into. Overall I think it has been an excellent tool for organizing our work for the project, as a place to discuss problems related to it, and as a major source of reference.

Conclusively, I think that this sprint went well, and we were able to get some good progress in over the course of ~5 weeks or so. The increase in the size of our team, being used to the process of using Gitlab for coordination, and overall focus on creating “useable” mock-up and skeleton framework code seemed to allow for increased productivity during the sprint.

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

Sprint 2 Retrospective

Backend Example: https://gitlab.com/LibreFoodPantry/training/spikeathons/winter-2021/stoney-manage-items/backend

For the second spring, our team focused on developing the frontends, backend, and keycloak of the inventory system. But a big problem the team encountered during the sprint is that to develop the inventory system, we had to learn all this new material such as Vue.js, Express, and API. Even though I was introduced to these concepts last semester, it’s still comparatively new next to all the time in college where I used Java and C++. And even though we had the entire first sprint to get familiar with the material, actually applying it to a project is a bit more difficult. It caused the progress on development to lag and a decent chunk of what was planned for the sprint didn’t get finished, like writing the API for example which was my responsibility and I’ll get to that later.

I worked on developing the backend and event system components for the inventory system during the second sprint. For the event system, I met up a couple times with the team members working on the event system from other teams. We talked about how our systems were going to communicate with each other to the point I at the very least know what to implement on my side. The inventory system just has to send messages to the reporting system whenever the inventory goes up or down and it will do that through a JavaScript file called “send.js”. I also managed to create a base skeleton for the backend which is heavily based on an existing example which I’ve linked above. I also tried to write the API but I didn’t really manage to finish it well enough and even though I did work with APIs last semester, it’s been a while. I feel that the biggest reason for the unfinished API is because I didn’t even study API during sprint one, I mainly studied express. All of these tasks most of what I did during sprint two outside of a few miscellaneous things that don’t come to mind immediately.

On what to improve as a team, I can’t really think of much outside of trying to keep up with the new material because I feel a good portion of the class is dealing with the same problem. I feel that the inventory team is doing decently all thing considering. As an individual I could improve on my knowledge of API and some other subjects by using the inventory system wiki more. I could also try and free up more time to work on the system since I planned to work on the API some more and I barely got anything done since I had a test last Friday and I have another test this coming Tuesday. I might have time on Tuesday afternoon or Wednesday but I also have other classes that I have to keep up with and I should also set a concrete goal or write a to do list to guide myself. I just came up with that and it sounds like a good idea so I’ll stick to that plan.

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

Study the Classics

            In the “Study the Classics” learning pattern of the Apprenticeship Patterns book, the focus is on catching up with the well-known literature or practices in the field when your knowledge of theory is more limited. Luckily, I feel as though Worcester State has prepared me well with a mix of theory and practical, technical skill, but this pattern stood out to me, nonetheless. Sometimes, when talking with peers or reading online from people more experienced than I am, I find I can get bogged down in references to things I have no knowledge of. This usually detracts from what I was initially trying to find out about. There’s more than enough “good” material out there for many, many lifetimes worth of learning. What concerns me is finding the right material and learning about it in the best path. Even if I can find all the proper materials for my learning goals, working through it can be difficult or impossible if I don’t go about it in the correct way.

            As the pattern mentions, exposing your ignorance is as essential part of opening yourself up to learning. This is something I don’t think I really have a problem with, as I usually try to put my ego to the side when taking on new tasks. What I really need to start doing is also mentioned in the pattern: keep a reading list and read constantly. I’m not great on this front. Perhaps these are particularly difficult tasks for college students because most of our work comes outside of our courses anyways, but I could definitely stand to try more, especially once I’m out of college.

            I also find difficulty in using the classics to inspire more current learning. I do feel confident applying my knowledge to new topics (I feel confident that my knowledge is translatable) but discerning the relevant material from the outdated in the first place can be difficult. This is a very handy skill and I think it probably comes with an expanded knowledge base anyways. As long as I get on the road of continued learning and studying the classics, I think this skill should develop.

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

Apprenticeship Patterns: Learning Languages

I am once again impressed with the relevance of these patterns, covering many issues that I have been struggling with recently. For this week I chose to focus on the Your First Language pattern. This might sound strange, as I am a senior and at the end of a pretty significant part of my journey as a software engineer, and yet I feel as though I have yet to become an expert on any particular aspect of programming. In terms of programming languages, I have found myself vaguely utilizing many without fully understanding how they work. This is exactly the issue discussed in the pattern.

This pattern focuses on a few different tips for learning a new language well. After choosing a language to focus on this pattern advises you to focus on creating a useful feedback loop with whatever type of work you are doing. This can be through a variety of methods, being finding existing communities of practice online or someone you know who is an expert themselves. As for how to learn the language, there are a few different methods recommended. The overarching method is to have a specific problem to solve rather than just solving small examples present online and in books. I have often ran into this exact situation myself, finding my initial excitement in learning a new language stopped abruptly by some frustrating example problem that has little relevance to what I want to do with the language. Instead, what is recommended is to think of a larger problem you would like to solve with a program. Starting from this very general level try to break it down into smaller components and, after getting to the most basic component to work on, start from there.

Personally I once again had little to disagree with. I have realized that learning new languages seems to be a critical skill for software developers, as there is such a variety available. Each language generally has its own advantages and disadvantages, with some having specific use cases, like html for web design. Thus it is important to know how to go about successfully learning a new one,  as it is its own little road on your greater path to becoming a software developer.

Source:

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#your_first_language

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

It probably goes without saying, but this sprint certainly seemed more effective than the first. This is essentially a given, as a good portion of the first sprint consisted of figuring out how to work within my team in addition to adjusting to the teams shifting around a bit. After this, I feel as though we were able to accomplish everything we set out to, and a little more in some circumstances. Though this sprint certainly was not entirely bereft of some issues, at least with my own contributions to the team. Other than these though, I am satisfied with how this sprint went.

After adjusting to being embedded into the InventorySystem team, the sprint went very smoothly. Initially I had some difficulties being in a community of practice and the team, not really knowing if I should be meeting with others from my COP. We ended up establishing some meeting times and help each other with some parts of Keycloak. We were able to find a method of connecting our mock frontend app to keycloak, in addition to developing a logout function. Additionally, both Keycloak and the mock frontend app were containerized in docker. These were the major issues that I had focused on this sprint and all were effectively completed. Beyond myself, the InventorySystem seemed to accomplish many of the issues, with the exception of maybe one or two, that were posted for this sprint. One part that I felt did not go entirely well was how exactly I could help out the InventorySystem team. It might have just been the nature of the issues I had involving just using Keycloak, but I was concerned that I could have been helping them more in some way. Other than this there were no real issues that I could think of.

Despite the overall success of this sprint, there are a few more thing that I personally feel could change to improve the next sprint. I should clarify that these changes are entirely with myself, the first of which being what I felt was my own lack of participation in the InventoryTeam’s issues. I did not feel like I involved myself enough, this is also the reason why I cannot really speak on how the team can improve. As for changes I can make, I will simply try to involve myself a bit more, if not through taking up some of their issues then just through communicating more. I will try and ask where they are at throughout the sprint so I am more aware of what is happening and, ultimately, when I will be implementing Keycloak into the system. Additionally, I still had some struggles balancing my work for this class with some others, but I have been working on improving this for the next sprint. I have been sticking to the time I have set aside for working on schoolwork and have, at least, kept up. In conclusion, I am very pleased with my current progress going into sprint 3 and am excited to finally finish implementing Keycloak into a system!

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Code Review

Link: https://smartbear.com/learn/code-review/what-is-code-review/

According to the article linked above, to code review is to consciously and systematically convene with one’s fellow programmers to check each other’s code for mistakes. There are many different ways to code review such as through an email thread, pair programming, over the shoulder, or tool assistance. Through email, a programmer can easily send their colleague a file with the un-reviewed code allowing both of them to exchange regardless of schedule or location. Pair programming is when two software developers work on the same code side by side, allowing both to more fluidly exchange ideas. Developing over the shoulder is similar to peer programming except only one developer actively works on the code while the other acts as support. Tool assistance allows for even more flexibility than email chains since it allows for code review through software-based code review tools.

Code review is a very simple concept as it is simply peer reviewing in the context of software development. The importance of peer review is that another person can examine and point out someone’s mistakes unlike automated processes. Developers are still human and make human errors which are less likely to be picked up through artificial means. And solely relying on tests written by the original developer runs the risk of overlooking errors not picked up by tests or in the worst case, following the assessments of a flawed test. That’s why peer review, and by extension code review, is so important to speeding up and streamlining software development.

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

Stay in the Trenches – Apprenticeship Pattern

What this apprenticeship pattern starts off talking about is how you have been developing extraordinary code for years, meeting the standard for the company, but all of a sudden you are offered a management position which will in fact take you away from coding into another direction. Now the pattern states that this may be tempting and show that you are leveling up, but it is actually sort of an illusion in a way. You may feel that a promotion will help you out, but in this case it is taking away from the journey you have took so far and the motivation to be a good programmer. When you take the promotion, then you will start deteriorating in the skill of programming slowly as time passes by. What staying in the trenches means is to stay true to your passion, and try to find rewards for you exemplary work in some other sort of way by negotiating with the company.

I think the main message of this pattern is important and how it is talking about staying true to your passion. One thing that I don’t agree with is just because you may come across a different path in life that may be outside of programming, does not mean that you should not take. There are a lot of people that won’t be able to be in the position of manager and although a person has a passion for programming, there are times when someone needs to go to the uncomfortable side to level up. It may be time to start learning more about the bigger picture of software development and managing a team of programmers, then just doing programming yourself. It will be a different change and the only way to find out whether you like it or not, is to try it out. In the future, if you believe that the role isn’t for you, then you can always go back to some role of programming at a different level. The goal however shouldn’t just be to give up programming all together, but to try some different path while also staying up to date with the programming aspect. I personally believe that this will help you out more with experience of leading a team and not only focusing on the developing aspect. The more variance experiences a person has, then in the future it can help apply in all sorts of different aspects.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – A Different Road

For this week’s blog post, I read the section  “A Different Road ” from chapter three of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section talked about how taking a different road could be a risky or life-changing event.  Despite this risk, I believe that one should be not afraid to do something different with your life. A change no matter whether they seem good or bad at the time will teach you something new or a new experience that can drive you to push forward. The author started the section by talking about explaining how saying goodbye to the craft can be risky, but  “Even if you leave the road permanently, the values and principles you have developed along the way will always be with you” I think this is very true, no matter the change, the principles you have acquired so far in the career will always be there for you.

Currently, I want to talk about the sad reality and risk one may face when one changes a craft. The author talked about how a person switched from an IT job to be a teacher and afterward it was hard for the person to get back to the industry because “most HR people in big companies didn’t like it.” Sadly, most software companies nowadays see the gaps in a person’s career, and you must justify within their value system why you left and why you are coming back now. Also, as technology is evolving daily, companies want individuals that are willing to learn quickly and adapt to the environment rapidly. The solution suggested in this section I found quite helpful, which was to Write down some of the other jobs you think you would enjoy doing, find people who are doing those jobs and ask them questions regarding them. This interaction will help an individual to decide if they are making the right decision to choose a different path. Reading this section made me think of what my life will be if I choose a different road, it is risky, but is it worth it. Sometimes you must risk It for a greater reward.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Be the Worst

There is a saying in China: Better be the tail of a lion than a fox’s head! There is another saying: Better be the head of a chicken than the tail of a phoenix.

 

Surround yourself with developers who are better than you. Find a more robust team where you can be the weakest member and have room to grow. In the beginning, you may not feel confident in your life, but the process of developing and learning in the workplace that makes you stronger is lovely. In this society, no one will care how beautiful and challenging your strategy is. The most important thing is the result. Have you grown and become stronger during this period of enduring learning?

Remember, the probability of being rejected or thought strange by a potential mentor is not high, and the potential payoff is enormous. Even if the person isn’t interested in taking you on as a full-time apprentice, asking her out to lunch can be a valuable investment of time and money, like why dinner with Warren Buffett was auctioned off at such a high price. An early-stage businessman, or an established businessman who has achieved success in a particular field, is all vying for this opportunity. Do they care about the meal? No, they need to learn something from talking to Buffett. Such as looking at the market, investment vision, and the future development trend of business. In computer learning, the principle is the same. By talking with the people above us or the successful people, we can get the information and direction beneficial to our future development. Opportunities are for those prepared, and the accumulation of experience and insight in life will make you soar when opportunities come.

Ask lots of questions.

Tasks such as maintaining build systems, product support, responding to maintenance requirements, bug fixes, code reviews, eliminating technical debt, creating project wikis, updating documentation, acting as a sounding board for other people’s ideas, and so on. Typically, you focus on the less risky edges of the system rather than the core, which often has many dependencies and a lot of complexity. Jean Lave and Etienne Wenger look at apprenticeships in different industries and find that “in the workflow, the tasks of a novitiate are often placed at the end of a branch, rather than in the middle of a series of clips of work” (Situational Learning, p. 110). These fringe tasks benefit the team and you as an apprentice, as they are often skipped in school classes and fill in the gaps. The experience still helps when you become a skilled worker because many of your mentors understand how important it is to do the tedious work. After all, if no one cleans the floor, the team can’t do the glamorous work because it is Mired in a mess.

What’s the most grubby task your team has been putting off for months? It should be the one that everyone complains about, and nobody wants to fix. You solve it. Don’t hold your nose and force yourself to do it; See if you can solve the problem creatively in a way that exceeds people’s expectations and is fun for you. Many people feel that this is a job that is not worth their time. If you don’t do well, you will help the team take the blame. If you do well, the team will take the credit. But you grow as you solve what the team can’t do.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Practice, Practice, Practice

Last semester I had to learn a new programming language for a class. It was a short time of period to learn it and I had to use it in a project. I really wanted to learn how to code in R and it was something that I enjoyed it. But the thing that helped me become better in it is practice. Take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes.

The book describes an ideal world where a mentor would assign you an exercise based on her understanding of your strengths and weaknesses. When you finished the exercise, the mentor would work with you to rate your performance using an objective metric and then work with you to devise the next exercise. Even though this is a good practice and would really help a lot of people, we do not live in an ideal world, and must fall back on our own resources to achieve the same effect. So we have to practice to understand our weakness and transform them.

The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions. Now that I’m more free to practice R I can see the benefit of this pattern. I usually find exercises, small projects, books online and practices my knowledge on those. It is more fun and I’m not worried about meeting a deadline or missing any instructions. As Dave Thomas says of practicing, “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.”

There are some things that you have to keep in mind when you practice though. Practice makes permanent, so be careful what you practice, and constantly evaluate it to ensure you haven’t gone stale. A good way to ensure you have interesting exercises to use in your practice sessions is to trawl through old books. I personally like to get my information in different sources and then compare. I feel like you learn more this was. Take that knowledge and try to find or devise a new exercise that will have a measurable impact on your abilities. Repeat.

References:


Apprenticeship Patternsby Adewale Oshineye; Dave Hoover, Published by O’Reilly Media, Inc., 2009

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.