Sprint 1 Retrospective

Overall I think sprint 1 went well. I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. We had times when life got in the way and work didn’t get done and we made sure to let each other know. We were also open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. All of us displayed aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part. 

I worked on 4 issues in total. I worked on one with the group and 3 on my own. The issue I worked on with the group was “Gitpod Dev Environments -InventorySystem/Documentation”. In this issue, we set up the files needed to configure the Gitpod Dev Environment for Inventory System Documentation and asked any questions we had to make sure the rest of the similar issues would go smoothly. The issues that I completed on my own throughout the sprint were “Move from `commands` to `bin` – InventoryAPI”,” Add AlexJS linter to pipelines – InventoryAPI”, and “Add AlexJS linter to pipelines – InventoryBackend”. The “Move from `commands` to `bin` – InventoryAPI” issue was a bit difficult because there was no build or test file. I figured out that I had to disable those two jobs for the pipeline to run. For both of the issues the lint.sh files weren’t created during the “move from commands to build” issues for the respective projects so I copied the file from a project that already had one. Because I knew that all of the linters that were included in the file also applied to each of the projects I worked on, I left those linter commands along with the command for AlexJS. However, I only enabled AlexJS in the pipelines for since the issue was only created to add AlexJS and we planned on adding the rest of the linters to the pipelines of the projects during sprint 2.

As a team, I think we did fairly well but we needed to adjust how we work to ensure there is evidence of everyone’s contribution on GitLab. Most of the communication was through discord which resulted in a good amount of the team receiving a poor individual grade for sprint planning. We realized this and decided to split up adding issues and weight for the sprint planning and backlog refinement for future sprints. We also did not rotate reviewing issues as we originally planned when creating our working agreement. In future sprints, we plan to set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. We aren’t sure if we would like to set time aside during our weekly meeting on Discord or set a system where one would just review the last issue in the “needs review” column. As an individual, I need to make sure I’m on top of my work throughout the sprint. Although life can get a bit hectic, I need to make sure I am pulling my weight for the team. I want to plan specific days where I work on issues to stay on track.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Expose Your Ignorance

One of the patterns addressed in Chapter 2 of Apprenticeship Patterns by Dave Hoover and Adewale Oshineye is titled “Expose your Ignorance”. It is a pattern that helps a programmer identify their weaknesses so that they can better know how to promote their personal growth.

When a company hires a software developer, they are trusting that the software developer is well suited for the job and knows what they need to know to do the job well. However, sometimes even the most experienced developer may come across an issue or technology with which they are unfamiliar.

To combat this, it is necessary to “expose your ignorance”. This does not necessarily mean to down-sell oneself by listing out all weaknesses and struggles, but rather, to be open with one’s learning progress and improvements. Being open is a road that leads to trust and reputation in any software developing team.

How does one healthily expose ignorance?

Ask questions! Learning from experienced software developers is the most direct way to becoming an experienced software developer oneself. Asking questions exposes ignorance, but it also exposes one’s ability and willingness to learn.

What happens if one does not expose ignorance?

The opposite to exposing ignorance is hiding it, and while it may save face in the short term, hiding ignorance will only stunt personal growth. This is bad for both the software developer and the team who depends on the software developer to be able to do their job well.

What are my personal experience with exposing ignorance?

When I was starting off with my research projects, I suffered from “imposter syndrome”. There was simply so much I didn’t know and had to learn to catch up and progress through my research. However, instead of hiding in my shell and trying to keep up a facade, I swallowed my pride and let my advisor know when I wasn’t understand something, or when I needed help. I had to remind myself that this fellowship is a chance for me to grow and gain experience! My advisor does not expect me to know anything and is there to help me learn.

Because I was willing to ask questions and exposed my ignorance, I was quickly able to learn and gain a deeper understand of my research project.

From this experience, I became to like being surrounded by people who know more than I do because it gives me the opportunity to learn so much. It exposes my ignorance not only to those around me, but arguably more importantly, to myself.

Seeing where I struggle pointed out clearly to me, it gives me the chance to address that weakness by doing the necessary research and practice to strengthen my understanding in an area that I would be otherwise unaware.

From the blog Stories by Namson Nguyen on Medium by Namson Nguyen and used with permission of the author. All other rights reserved by the author.

sprint 1 retrospective

This sprint, I handled the Gitpod Dev Environment implementation for the Reporting System, specifically for the Reporting Integration, Reporting Backend and Reporting API repositories. I also acted as the scrum master for the team, handling most of the logistics and communication with the product manager.

Gitpod Dev Environments: Import extensions via the .gitpod.yml file, set workspace settings via the .vscode settings.json file.

In terms of what went well, we did complete most of the issue weight (75% of the weight assigned for the sprint was dealt with). Speaking with my team members, we agreed that the meetings were productive and efficient, and we didn’t waste time on any of the meetings we had. I made it a point to not have meetings that could have been done over a short text conversation, and it seems to have paid off. We also agreed that the communication that did occur was quality communication.

While we completed most of the work for this sprint, there was still 25% of the weight left. This was entirely comprised of the Reporting System Deployment issues where we had to write docker-compose files to set up MongoDB local volumes. In talking with the team, we thought that the weight didn’t reflect the difficulty of the task. In retrospect, looking at the Deployment epic again I can see that there was a lot of confusion, not only because of having to read through documentation for Docker, but also because the initial task that was to be done before the implementation through docker-compose files (the actual mounting of local volumes from MongoDB) was not accomplished by another team, and was even removed from their sprint. This was excacerbated by the approach we took, where each one of us worked on issues individually without much assistance from other group members. This changed towards the end when two team members worked on the deployment together, but by then it was still ineffective, especially considering the uneven distribution of issues. It seemed like the weight of issues did make sense in a vacuum, but considering that I did all of the Gitpod Dev Environment issues for example, it was obviously very quick to complete 4 weight when the first 2 weight was done, because it’s an application of what I just did.

Another consideration: I think having one person (me as the scrum master) deal with a lot of the issue-creating and handling GitLab logistics was efficient, it didn’t lend itself to the most clear working environment for my team members that weren’t very well acquianted with the workflow. Details were located in epics rather than easily accessed directly in the issue that was assigned, and it made it more difficult to see what you were actually working on. In addition, it made it seem as though I did all of the work in the activity log when in reality it was a cooperative process, and the byproduct is that I end up with all of the credit as well.

For next sprint, we should better assist each other as necessary on issues when complications arise. We should assign weights more accurately based on our experience on the last sprint, and allow all team members to share responsibilities on GitLab, both for learning and to better tell what’s going on. As an individual, I should be more proactive as scrum master to really address problems as soon as they arise, rather than leaving everyone to their own devices as long as they check in. With these adjustments, I think our team will be able to perform much better in the next sprint.

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

Nurturing Passion in a Challenging Environment

Summary:

The pattern “Nurture Your Passion” addresses the struggle faced by software developers whose passion for their craft is hindered by the work environment. Often kept to “simple” tasks or faced with demoralizing conditions like corporate hierarchies or project death marches, developers find it difficult to maintain their enthusiasm. However, the pattern suggests several strategies to protect and grow this passion.

Reaction:

The pattern could be related to deeply with many software developers who have found themselves in similar situations. It highlights the importance of preserving one’s love for the craft amongst challenging circumstances. What’s really interesting is the acknowledgment that not everyone has the privilege to earn a living through their passion, making it important to safeguard and nurture it.

What’s Interesting and Useful:

The emphasis on working on tasks that align with personal interests stands out as a practical approach. By dedicating time to activities that spark joy, developers can reignite their passion and find fulfillment in their work. Additionally, the idea of seeking out like-minded individuals and immersing yourself in the classics of the field serves as a reminder of the rich heritage and community support available in software development.

Impact on Professional Outlook:

The pattern encourages a reevaluation of how someone approaches their career in software development. It makes individuals prioritize environments that support their growth and passion, even if it means diverging from conventional career paths. Setting clear boundaries and maintaining a sense of wonder about programming, as said by Paul Graham, becomes essential for long-term satisfaction and success in the field.

Disagreements and Reflections:

While the pattern offers valuable insights, some may find it challenging to implement certain suggestions, especially in highly demanding work environments. Setting boundaries and steering conversations towards positive topics require courage and confidence, which may not always be feasible depending on organizational culture and power dynamics. However, the underlying message about the importance of preserving one’s passion remains relevant.

In conclusion, “Nurture Your Passion” serves as a reminder that maintaining enthusiasm for software development is a deliberate effort, especially in the face of adversity. By embracing strategies outlined in the pattern and staying true to their passion, developers can navigate challenges and thrive in their careers.

From the blog CS@Worcester – Site Title by rkaranja1002 and used with permission of the author. All other rights reserved by the author.

Code Reviews

Reviewing your code is important, it makes sure that the code is correct and functions the way you want it to. Code review helps cover so many areas of your code. You want to make sure that your code is understandable for anybody else who looks at it and that it’s clear, by reviewing your code you can go back and fix anything that could be making your code more complicated. Code reviewing is important when working with a team, your team should understand what your code is trying to execute without being confused. When it comes to coding so much of your work can change throughout the process which is normal but with so many changes happening it can get confusing. Code reviewing comes with so many different solutions when it comes to writing code it nitpicks what parts are important or not. It’s a helpful tool that helps coders make sure they have clean code and that when working with a team everyone’s comments are heard and changes are made.

Code reviews can be tough if the team isn’t together so questions and comments can’t be answered. Another thing is that the code could be overlapping, and missing a team meeting could affect the code and confuse team members about what they should be writing ending up in similar code. If that happens the next person reviewing the code will find duplicate code and will end up pushing the team’s work behind. Making sure your team communicates will help prevent more code from having to be fixed and reviewed even though you don’t want to add more work on top of what you already have. Code review makes sure your work is good quality and organized. Having sloppy issues and mistakes doesn’t look good for you, your team, and your job. Code review is about making sure your work is organized and clean, you want to make sure you put out good work without having a lot of issues. Especially as a team you want to meet those standards and follow them. Always make sure to review your code because there could be small errors or even confusing comments that will make your code more complicated than it needs to be.

https://blog.pragmaticengineer.com/good-code-reviews-better-code-reviews/

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

Cultivating Insight: “Reflect As You Work” Week-5

Introspection in Action:

The “Reflect As You Work” pattern, from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, emphasizes the importance of ongoing reflection during your software development journey. This pattern encourages developers to continually assess their experiences, decisions, and outcomes. It’s about developing a habit of introspective thinking that allows you to learn from your actions and continuously improve your skills and approaches.

A Personal Acknowledgment:

While I haven’t yet embarked on a professional software development career, this pattern resonates with me for its universal applicability. Reflective practice is a concept that I find valuable in any learning process. “Reflect As You Work” aligns with my belief in the power of self-awareness and learning from one’s experiences, whether in academic, personal, or future professional settings.

The Power of Self-Reflection:

What stands out to me about this pattern is its focus on the transformative power of reflection. By regularly taking stock of what works and what doesn’t, and why certain approaches succeed or fail, one can gain deeper insights into their work and personal growth. This practice turns every task and challenge into a learning opportunity.

Shaping a Reflective Mindset:

Though I am yet to apply this in a professional context, “Reflect As You Work” shapes how I view future work and learning. It instills the idea that real growth stems from not just doing but understanding and analyzing the process and outcomes of one’s actions. This continuous cycle of action and reflection is what drives deeper learning and skill development.

Embracing Reflection, Balancing Action:

I wholeheartedly embrace this pattern’s message, but I also recognize the need for a balance between reflection and action. Constant reflection should not impede progress or lead to over-analysis. The challenge lies in integrating reflection effectively into the workflow without it becoming an obstacle to productivity.

In conclusion, “Reflect As You Work” is a pivotal pattern for anyone who seeks not just to work in the field of software development but to excel in it. It encourages a mindset where every experience is a source of learning and every challenge is a stepping stone to improvement. This pattern is a reminder that the journey to becoming a skilled software developer is as much about introspection and learning from one’s own journey as it is about acquiring new technical skills.

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

Code Review

For this week’s blog post, I chose the article “Code Review Best Practices – Lessons from the Trenches” by Drazen Zaric. I chose this article because its topic fits perfectly with the cove review segment in the syllabus. This article discusses why you should do code reviews, how code reviews act as quality assurance, how code reviews function as a team improvement tool, how to prepare a pull request for preview, and, of course, how to review code. In this article, I will be discussing why you should do code reviews and how they work as quality assurance.

Reviewing code is one of the most essential parts of the development process. “It should be obvious that the primary purpose of code review is to assess the quality of the changes being introduced. I mean, the dictionary definition of review says precisely that ‘review (noun) – a formal assessment of something with the intention of instituting change if necessary.’ Of course, code being code, there’s a lot of things that can be checked and tested automatically, so there’s nuance to what needs to be checked in an actual code review.” As mentioned in the article, there are many things that can be tested and should be tested. This leads to a need for many people to review your code, and you will need to review many other people’s code to make sure the best possible software is being developed. Quality assurance must be done well as a significant part of making sure your software is the best it can be.

In this section of the blog post, I will discuss how the article mentions how code review is incredibly useful in quality assurance. “There are many ways in which code reviews help maintain the quality bar for the codebase and the product. In the end, it comes down to catching mistakes at a level that can hardly be automatically tested, such as architectural inconsistencies. Also, the code for automated tests should be reviewed, so there’s a meta-level at which reviews help with QA.” As mentioned, code review’s main boon to quality assurance is finding issues that can’t, or often need to be caught, through traditional testing methods, like automated testing. The article also mentions using checklists for storing what needs to be checked and how and what the results of said checks should be. “You can have your own checklist or make it a shared list for the team or a project. There’s a ton of material written on the usefulness of checklists. In Getting Things Done, David Allen puts forward a simple idea – our minds are great at processing information but terrible at storing and recalling it. That’s why checklists are a great way of externally storing and breaking down a planned or repetitive task.” Having a method of keeping track of what is done, what needs to be done, and what is incomplete is essential in working on any large project, let alone on a software development project.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

The Long Road

In this week’s blog post, I will be discussing the “Long Road” pattern discussed in chapter 3 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I often worry about not being able to learn or grow more in my field, becoming stagnant because there is nothing else I can learn. Thankfully, this pattern dissuaded those fears of mine and inspired great confidence in my future endeavors.

The quote that this pattern opens with immediately puts much of my concerns about the limits of what I would be able to learn to rest. “‘How long will it take to master aikido?’ a prospective student asks. ‘How long do you expect to live?’ is the only respectable response.” In comparing computer science to Aikido, it implies that no one can possibly learn all that there is to know in computer science. Another quote from this section that makes me even more excited to be a part of this field mentions that for every step you make, the finish line is two steps further away. “For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.” While this may seem like a disappointing aspect of our field for many, the limitless opportunity for me to grow is why I love this field of knowledge.

I did not think it was possible, but further reading in this section made me even more excited and proud to be in computer science. “Close your eyes and imagine the strangest possible role you could be playing in 10 years’ time. Have fun thinking of the wackiest possible future for yourself. Then think about 20, 30, and 40 years from now. What kinds of experiences do you want to have tried? Imagine that 40 years from now, you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices.” This quote had me thinking about incredible and outlandish possibilities in this field, which made me even more eager and excited to be in this field than I thought possible.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Static Testing VS Dynamic Testing

The blog post highlights the qualities as well as the differences between these two types of testing, static testing and dynamic testing. I chose this blog post because as this course covers software quality assurance and testing as well as the fact that we have spent time in class covering these two types of testing I believe that this blog post is able to highlight and reinforce core concepts that will be able to assist in gaining further knowledge withing this class. In addition, the blog post is able to explain the information regarding static and dynamic testing in a simple and easy to understand format that further compliments the idea of using this blog post as a resource to reinforce these topics.

The blog post as previously discussed covers static testing vs dynamic testing. We learn that static testing involves testing the code without actually running it while dynamic testing involves running the code to test it’s outcomes through various testing circumstances. From those two descriptions we can tell how static testing relies on testing through software documentation as well as the design of the code itself. However, dynamic testing is able to execute the program allowing the testers to test how the code will work in an assortment of testing scenarios. This concept allows testers to see how the code will work once it is released to the public to verify that it works as intended. These two types of testing are very different in their methods of achieving a successful test. Static testings wants to identify problems and improve on them early in development while dynamic testing wants to validate the performance and functionality of the code once it is in a executable state. Since they have different intents your requirements for the project is what determines what testing you will choose.

From what I have learned from the blog post I believe it was very helpful and was able to reinforce core concepts that will help me further in this class. I believe learning more about static and dynamic testing will help me when it comes to working in this class as well as assist in knowing how to test in a professional setting. Knowing the core differences between the two will allow me to know what type of testing will be best for certain circumstances when it comes to projects. In conclusion, this blog post was very helpful and will be utilized in the future.

https://testsigma.com/blog/static-testing-and-dynamic-testing

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

Stay in the Trenches Individual Apprenticeship Pattern

This week I continued to read about Individual Apprenticeship Patterns for CS448 – Capstone and focused on the “Stay in the Trenches” pattern. This pattern emphasizes the importance of gaining continuous hands-on, practical experience in the craftsman’s chosen field(s) at all levels, even as they may advance within a company. It can be common as software developers move up to transition to more managerial roles focusing on handling teams and deadlines rather than hands-on coding.

However, doing so will inevitably and quickly result in deterioration of the craftsman’s coding skills. Instead of getting too caught up in theoretical knowledge or managerial roles early (or at any point) in a developer’s career, developers should ‘stay in the trenches’ and continue working on practical/coding problems to keep developing and advancing skills and expertise. By immersing ourselves in the actual work, we’ll learn from the day to day experiences and continue to grow in ways that upper level managers often cannot. 

Often, I’ve heard of upper level software managers spending most of their time on coordination, time/schedule management and strategy/design planning – from a craftsman’s standpoint, only code project strategy and design planning are particularly applicable. While it surely is far more abstract and long-term or larger in scale, developers who are working hands-on with code are still managing and accomplishing tasks and exercising their code strategy and design skills. So when considering that hands-on coders will also further several other skills related to their craft, these managerial roles seem like a clear downgrade in terms of job quality and day to day activities even if it comes with a pay increase.

This brings up the final major point of this pattern, which really stuck out to me – identifying other avenues and ways for craftsmen to advance within their company/career and be rewarded for high-quality performance. Some practical examples could include a simple pay increase, more involvement in internal strategy meetings/decisions, job-title shift/improvement, etc. There’s no clear or definite answer here, but individuals in this position are probably in good standing as the company is looking to reward them, and they should communicate and work with company management to find incentives and reward mechanisms that align with the goals of both parties. If not however, this pattern stresses the importance of staying on the craftsman’s path and considering advancement positions at other companies that are more flexible.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.