Author Archives: rickwphillips

The Abstract Class – Sprint Retrospective #1

The Abstract Class – Sprint Retrospective #1

Our team, named The Abstract Class, reached the end of its first Agile Sprint today and this is my retrospective. This week, I learned about building and running my first Angular application cloned from a shared repository. This was part of a larger group of accounts and applications that had to be processed mentally. There is Trello, Jira, CatME, Slack Channels, and GitHub groups. As a team and individually, we each had to navigate the many new interfaces and learn the intended uses for these new tools. I feel out team effectively grasp and started using the tools as intended.

The most technical feat our entire team accomplished this week was cloning of the AMPATH application and connecting to our test server. We ran into a situation where we attempted to build the application with ng serve and not npm start. This caused errors. Once we realized our mistake, entering the correct command got us up and running.

Our team handled AMPATH application ladda build errors using the class Slack channel. We shared screenshots, log files, and advice when one of us was having trouble. We accomplished getting a teammate up and running strictly through this Slack channel conversation. This provided other class members the ability to view our conversation and avoid the same issues, potentially. We could continue to publicly resolve future issues in hopes that this inclusive feedback will help resolve issues quicker.

Our team worked very well together on this sprint. We used Slack appropriately and resolved issues on that platform efficiently. We could have used Trello more effectively during the sprint, as we were moving the boards around during the end of spring class. Our stand-ups were a little spotty in the beginning but we, as a team, finished strong.  

We created our GitHub team group and began discussion on the best way to manage changes and pull requests. We are unsure of which of the following approaches is best:

  • Create individual branches for each developer on the group’s fork of the Master branch. We would create an additional branch called merge_changes which would act as the buffer between our branch changes and the Master branch. Pull requests would be merged as a group.

  • Create individual forks for the group’s fork of the Master. Then each individual form would create a branch on their fork. Merge requests would still be handled by anyone who did not create the pull request.

We have yet to determine which of these is best. Our next Sprint planning meeting will have to include discussion on this point.

We also discussed the best way to handle our group’s Trello board. During this spring, most of the tasks were required to be done by each member. This caused some confusion on the boards. We were not sure of the best method to have some of us done a particular task while other were not. There were some suggestions about checkboxes, multiple cards, or color coding. In the end, we determine that the future tasks should be more individualized. This makes the requirement for us to find a better way less important.

Here is a list of things I would recommend for a better and more productive sprint:

  • Log into Slack everyday of your sprint. Your teammates may have left you messages.

  • Get Slack on your mobile device. It is a seamless transition between the desktop and mobile versions.

  • Ask for help. Your teammates are usually more than willing to give a hand.

Looking towards the next sprint, I expect to get much more technical and in-depth. I will also be looking for opportunities to find retrospective material to include.

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Reflect As You Work


Self reflection is not always easy. Still, we must find a way to look at our work as objectively as possible. Using a Personal Practices Map and a feedback loop, we can gain a better understanding of the current state of our practices and methods.

My Reaction

The Personal Practice Map is the first thing that was be to me. I am not sure if I can remember back well enough to create one from my previous experience. But I can make one for today and begin to map my methods moving forward.

An approach I could use with the map would be to note the things I did not know back then. Some of these legacy items could include, “I did not use proper testing for my code,” or “I was not coding to an interface.”  These are some of the items that could be included on an earlier version of my personal practice map.

I agree with the concept of mindful and unobtrusive observation.  Watching and learning from those who have the skills that you would like to obtain is an excellent way of absorbing those skills. I look forward to engaging in group programming in my career and think that I would try the write a test then code to the tests patterns. This seems to be an interesting and efficient way to get fast results.

In conclusion, the Reflect as You Work pattern makes a lot of sense to me. It reminds us to be mindful and observant for opportunities to learn from ourselves and others. It makes the claim that watchful introspection is key to real personal growth. I agree with the sentiment wholeheartedly.

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Create Feedback Loop


Self assessment can be a very difficult thing to accurately accomplish. When learning a new skill, we may not be aware of our mistakes as we are making them. Creating an early and open feedback loop can be a very useful tool for identifying and mitigating these mistakes.

My Reaction

This pattern is very useful in that it teaches us to remember our tendency to overestimate our own aptitude. It even notes a correlation between our lack of real ability and the lack of perceived ability. This was an interesting concept that seems obvious in retrospect, but I found to be intriguing.  

Finding opportunities to get feedback involves being willing to hear both praise and criticism. This may be scary for some, but understanding and learning from our mistakes is worth much more than our fear of failure.

I had not considered the idea of stop energy. This is when feedback received does not provide constructive, actionable input. Instead, it is meant to stifle and discourage. This type of feedback is mostly about the person giving it and usually lacks any kind of real consideration about you or your current situation. Understanding how to identify the difference is important to maximizing your positive feedback loop. This was a new concept to me and it taught me a new approach to my future feedback opportunities.

There are two types of positive feedback that can be used to constantly adjust and adapt. This is the biggest take away from the pattern for me. The two type to consider are balancing and reinforcing feedback. They operate to push a system to relative stability and maintain longevity within that system.

Balancing feedback encourages us to do less of something while reinforcing feedback encourages us to do less of it. This is a very simple yet profound idea. The distinction between positive and negative feedback seems much easier to determine. This finer granularity within positive feedback is much tougher figure out.

Getting better at this takes practice. It takes understanding more that just what someone says but how it is said. It involves considering context and meaning. These things take time and are tough to convey in a book. I will try to use these lessons in my next project, assignment, or human interaction. There is always an opportunity to establish and learn from a feedback loop. Simply interacting with others and seeing what they think and feel is an example of one.

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – The Deep End


The need to grow your skills is a necessary part of being an apprentice. Part of this is getting outside of your comfort zone and trying new and challenging projects. Understanding what your deficiencies are can help. Waiting until you are comfortable is a recipe for accomplishing little. To truly understand what you are capable of, you have to jump into The Deep End.

My Reaction

In Chapter 1 we were warned that some of these points may seem obvious. When I first read through The Deep End​, I believed that this was one of those. But the very next point in the first chapter was that successful people around me were already doing these things. That was the most profound take away from this point was for me. I am struggling to expand my understanding beyond the web centric background from which I come from. My attention could be better directly communicating with those in class who have completed larger projects that me.

I do not believe that this pattern has changed my opinion about my intended profession. In fact, this articulates a gnawing hunch that I couldn’t quite grasp. It motivates me to find ways to expand my understanding and abilities. Just today, I created, signed, and installed a new SSL Certificate for a client which allows them to process credit cards on their site. I believe these are the types of incremental boosts in confidence that jumping in The Deep End may provide. 

I agree with this pattern because it makes obvious sense on the surface yet may be one of the hardest to put into action. I enjoy branching out in class creating applications in Java but find a certain comfort in Drupal web development and its environment. I have done it for years and know it well. But if it is not plateauing, I may be in a bit of a rut. This pattern helped me realize this about myself.

The other part that I agree with involves how you can ask yourself the question regarding your past projects and their scope. You should have the answer to this handy to determine where to go next. This can also help you gauge to measure every project you have ever been a part of. I will try to see how well I am able to do this. 

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Find Mentors

Short Summary


From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Chapter 1

My thoughts on the first chapter

The opening chapter of the book Apprenticeship Patterns serves as a brief introduction for what to expect throughout the rest of the book. There were a number of concepts that I am unfamiliar with and am looking forward to learning more about. I had previously heard of the terms apprentice; journeyman; and craftsman;  but never I had not thought of them in the context of software development. 

Once we wrap up all of these new concept applications, we arrive at the idea of the Software Craftsman. Within this moniker are suggestions on applicable mindsets that encourage pragmatism, information sharing, and surrounding oneself with those with better skills. Each of these taken individually seem obvious. But once you line then up under a single purpose, they highlight an approach to becoming an accomplished developer through community and experimentation. 

Breaking down the titles

The opening chapter offers us a loose definition of the hierarchies we can expect to encounter in this book: Craftsmen (or Master), journeymen, and apprentices. But beyond these archaic titles is a value system that should be imbued on the reader. This system lays the foundation for becoming a better software developer. 

The apprentice is probably what most of us in this class would classify themselves, yet this assumes a journeymen/master who is teaching us. The classroom model is our current vehicle, but soon it will branch out as we become journeymen and expand on our skill set. 

The master or craftsman designation seems to be reserved for those that can and are willing to further the zeitgeist of his or her craft. These are those who reach a point that they re-examine the methods and rules of his or her craft and attempt to better the tools and means of it. 

My takeaways

I am learning that there are pattern languages for just about any discipline one could imagine. I am not confident enough in mu understanding to say whether I agree or disagree with the material but am intrigued by the prospect of bettering my skill set and understanding of the development world. I am eager to dig into the material and begin to apply it to my career. 

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

WSU SP18 CS-448 Introductory Blog

This post is to satisfy the WSU CS-448 blog entry post required for class. 

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.