Author Archives: gchyoghly

Apprenticeship Patterns: Retreat to Competence

                Today marks the last blogpost I will make about “Apprenticeship Patterns” by  Dave Hoover and Adewale Oshineye. To finish off this series of posts over the past few months brings us into the unknown, of what is yet to come and may not even be revealed until the last second. Many of us reasonably fear the unknown, anything that cannot be controlled in our lives is unpredictable and may at time overwhelm us. This is exactly what this book has been attempting to get the reader to reconcile with and it is evident in the pattern “Retreat into Competence” that they realize just how overwhelming it is to venture into the unknown. Having a place to return to and gather yourself before venturing once more unto the breach is an important tool but should not be a crutch for your lack of knowledge in other areas.

                One might be an experienced Java developer and comfortable with the language and its many quirks and features, however they will one day be met with another language or toolset that is completely foreign such as REST APIs or C++ and C code. This is the rollercoaster of apprenticeship where the thrill of learning and the terrors of facing your vast ignorance coalesce. This however is all part of “Walking The Long Road” As described by Hoover and Oshineye. This vast ignorance is something you must expose and confront if you are to grow as a craftsman. (You can read more about exposing your ignorance here)  

                One of the most important things to overcome as a software developer is the fear of the unknown and sometimes one can benefit from retreating to something they know and returning with a fresh pair of eyes to their previous roadblock. Taking a break to refactor some Java code can be beneficial if the REST API portion is stumping you. However it is important to note that this tool must be used responsibly and not as a reason to avoid exploring new avenues that reveal your ignorance. Becoming an expert in something you already know is tempting however there is a risk associated with such expertise as the industry will eventually leave that technology behind for bigger and better things. Once this has happened you will find yourself in a situation where you know nothing about other technologies being used and even worse, have nothing to fall back on to recompose yourself should you being to feel overwhelmed.

                With this in mind, I would like to challenge the readers of this post to explore a new avenue of software development. Explore a toolset that you either have not used or, even better, have little experience with due to being overwhelmed the first time around. If possible attempt to either adapt a piece of software you created in another toolset or take a tutorial and create something new out of it. Learn its intricacies and, if necessary, take a break and return with a fresh pair of eyes after working with a more familiar tool for a while. Even if it is a small program, it will deepen your understanding and help to thin the overwhelming veil of ignorance that makes learning something new so daunting.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

My Third Sprint: A Lesson in Legacy

                With the ending of my last sprint in my capstone class I have completed my first of many cycles of development. Throughout this series of three sprints I have gained a better understanding of what I can expect of myself and how I can begin to improve my performance in an actual working environment. This last sprint, like the previous two before, taught me new concepts that I had not previously considered when going into the sprint. Throughout this sprint, especially in the last two weeks, the mains idea that stuck out to me was that of legacy, and what our group leaves behind for those who are coming next.

                When beginning this sprint, I had first focused on what was laid out during the planning session, involving the implementation of docker and containerization in general on to our identity access management system. The system worked when running on the operating system without any overhead so the next step was to get it working with docker to later be adapted to the Kubernetes clusters being used to host the Libre Food Pantry system. On the second of three weeks into this sprint, it had occurred just how close we were to the end of our journey and I began looking at the other spring backlog items. The one that struck me as most important was working on refining existing tutorials within the GitLab repository for the next group of developers to be easily able to get up to speed on what has been done and what needs to be done.

                As in previous sprints, time estimation, while once again improved, was a problem for us. This was especially noticeable as the end of our journey loomed closer.  While we had not gotten as much done as we would have liked to, we had made a concerted effort to condense our findings into the important information and save it to the GitLab repository for future groups to pick up on.

                Our group was tasked with creating a presentation for the end of the semester and this helped us to filter unnecessary information and include only the most important parts that applied to the project at hand. To go along with this I myself had even created a tutorial video that exemplified all of my own findings which would allow new groups to create a secured application with key cloak. Despite being a basic webpage, it is better to start with this than with nothing like our group had.

                As a group we can still improve not just on our time allocation but also our recording of information. Being able to properly record our finding as we make them is important in allowing both the group and future developers to have easy access to pertinent information regarding this project. I myself could have made this a focus as I performed research from the very beginning and would have had a library of information for it.
                Aside from this however, I still have a long was to go in making an effort to communicate with my peers. I often find myself “suffering in silence” whenever I run into a roadblock and, just as before, I tend to withdraw and become distant which benefits no one at the end of the day.

                Overall however I can say with certainty that there is a foundation here for future developers to work on. Our legacy will have an impact on future progress and provides a point for future groups to jump off of in order to finish what we started. The updated ReadMe created in the repository will hopefully hold useful information to users that takes away from the research that would have been spent on getting key cloak working in the first place.

GitLab Contributions: · KeycloakWithoutDocker · LibreFoodPantry / Common Services / Identity and Access Management System / Keycloak Research · GitLab

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

My Second Sprint: An Improvement in the Journey

                Over the past few weeks I have once again had the opportunity to take part in developing the LibreFoodPantry software platform. From start to finish this second sprint has challenged our team in creating a solution to the question of security for this software. In this sprint we had mainly focused on how key cloak deployment would work and how we would adapt the existing web pages to utilize this security platform. We learned much throughout the sprint however we found that there was still much more to our role than just the webpages.

                Just to reiterate our goals, a group of my peers and I were tasked with creating a secure login service for LibreFoodPantry that would allow users to sign up and sign into the food pantry’s website. We had previously spent the last sprint attempting to understand how this third party software functioned and what we would need to do in order to implement it. This sprint would focus on the implementation of Keycloak and what would be the least disruptive method of doing so. The goals were as follows; create a working instance of keycloak with a front page without any containerization, understand how to create and maintain users, roles, secure each new page we added within the same login system, then transition this system to a container system such as Docker.

Getting started we first focused our efforts on everyone getting an instance of Keycloak running. After ensuring that I could get it working reliably I posted my results on Gitlab for my peers to have their own working version of Keycloak with a frontend page. We were then able to move on to our other issues. I was tasked with reviewing NPM and how to adapt existing frontend pages to Keycloak as well as ensuring that permissions and logins could be carries between different pages. Others among us worked on researching the deployment of Keycloak on a Kubernetes cluster using AWS as well as communicating with other groups to begin to synchronize and ensure we were working on features that mattered for the other groups.

                The team worked well together, and we once again made a point to meet twice a week to discuss progress and synchronize ourselves outside of normal meeting times. It was worth the extra meeting times as I was able to assist group members in ensuring that they could have Keycloak working and that their computer was set up to properly install and run Keycloak and the frontend page.

                Our main problems came about once again in properly updating our work in the issues tab and a failure to properly estimate the weight of some issues we had created. I once again found that I was stuck on a single job most of the sprint trying to adapt existing pages to utilize Keycloak. It would be apt to say that I was again immersed in my own work and communicating less than would be ideal. However unlike last sprint I was able to work past this in a shorter time frame and was able to communicate this to my groupmates. With this out of the way I had started work on adapting this system to work in containers such as those found in Docker or in a Kubernetes cluster.

                At the end we had started to make more progress quickly but by that time the sprint had come to a close. While this was not an ideal sprint, it was definitely an improvement over the last and I feel that we had done better in estimating the weight of certain issues although not solving this problem entirely. We hope to continue practicing working in the Scrum format and improving our grasp on what issues need to be created and how much weight they should carry.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Study the Classics

                Often when we as people begin our education in any field we tend to lean either towards readings and studying our predecessors, or jumping into a more practical hands on approach. I myself have often leaned towards a hands on approach to learning. I find myself learning best when thrown into real work rather than boring myself reading textbooks and taking note of the though process of our predecessors. This is exactly how I have honed my craft for a majority of my time as a software craftsman so far. While this method of studying has its merits, it has also hindered my growth by minimizing exposure to the thoughts and theories of others before me.

                Oshineye and Hoover go into detail within this section explaining how and why we ought to delve into the books written by those who came before us. Classics such as Rodney A. Brooks’ Robust, Layered Control System for a Mobile Robot” and Valentino Briatenberg’s “Vehicles: Experiments in Synthetic Psychology” have long been used in the world of robotics and for good reason. They present a series of theoretical ideas and thought processes that yield results that may have otherwise been unexpected. Briatenberg’s Vehicles guides people that are new to robotics into a mindset that inspires out of the box thinking.

Briatenberg’s vehicles are examined not for their capability, but for their behaviors and different configurations exhibit different behaviors. Along with this, one might read Brooks’ work and apply the idea of subsummation to one of Briatenberg’s vehicles. Starting with simple behaviors that are subsumed by higher level thinking can be applied to vehicles to ensure they at the very least can perform certain task such as avoiding collisions with objects while carrying out their main goal.

The goal of these theories and mindsets presented by classic literature is the same as the very text put together by Oshineye and Hoover. It will not directly help with your skillset as a software craftsman, but it can lead to utilizing what you do have in new and interesting ways. An adherence to a certain design philosophy and being willing to experiment in ways that may not have been directly taught to you is important in forwarding your own skills as a craftsmen as well as forwarding the industry when one becomes a master craftsman.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Breakable Toys

                We all grew up with a favorite toy at some point or another weather that be a doll, a car, bike, computer, lego, etc. At one point or another they may have broken in some way and when that happened you could either throw it out and be done with it or attempt to fix it or find another use for it. This is exactly the idea behind the breakable toy pattern described in ‘Apprenticeship Patterns’. As a software craftsman many workplaces will leave little room for failure and thus little room to learn from those failures. Many of us in today’s workplace are expected to know how to use tools given to us without time to experiment and fail to use those tools.

This aversion to failure often stunts the learning process in many people as failure is one of the best teachers there is. Being able to safely fail in a private space where you can learn from and fix your mistakes at your own pace is healthy to the learning experience. Breakable toys are essentially an implementation of a commonly used tool that you may be inexperienced with. This toy can be simple as long as it applies to your work, your life, and is pleasing to work on. As Hoover and Oshineye describe in ‘Apprenticeship Patterns’ you can create anything from a wiki page, to games, to even a calendar or even blogging software.

Creating a breakable piece of software that won’t affect anyone should it break gives you the opportunity to experiment without worrying about failure while reinforcing what you do or do not know about a certain tool, giving you a sandbox to play with to deepen your knowledge of said tool. Our toolsets are always changing as software craftsmen and being able to keep up with this quickly evolving trade is arguably the most important part of being a software craftsmen. I whole heartedly believe this to be a great place to create breakable toys as I have with my own website.

If you are turning up few ideas of what you can do then consider the idea left at the end of this chapter by Hoover and Oshineye. Create a wiki page for yourself, it can be about whatever you want and start as simple as being able to edit plane text documents. Over time as you learn more about Web Design, HTML, and other tools involved you may add features that will distinguish it from other wiki pages. Keep this breakable toy or create new ones as you learn, so long as you allow yourself to fail you can take advantage of it and enrich your own experience.

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Using Your Title

                When entering the workforce, one aspect that can cause a great deal of frustration is the job title you are given. Many software focused companies will have different titles to differentiate developers of various skill and seniority. Junior developer, developer, senior developer all carry with them an expectation of skill. Depending on which title you are given, it can have an adverse effect on how you view yourself and your skill level.

                ‘Apprenticeship Patterns’ delves into this explaining the common reactions to situations involving being given a seemingly improper title. Those who are given titles such as ‘senior’ or ‘lead’ developer may find themselves frustrated in the fact that they themselves do not feel worthy of such a title. Or on the other side, a person may far surpass their peers in skill and yet be given the same title as them.
Dave Hoover and Adewale Oshineye reflect upon this stating that a title is merely a distraction from the improvement of one’s own skill. Those with a high position of authority should refrain from becoming complacent and those with an unimpressive title must not let fact cloud their judgment.  

The authors explain that the conundrum of titles is a sign that “our industry has a problem” and should be used as a point of judgement for the organization rather than yourself (Hoover, Oshineye pg 51) . Being given a title that seems to be above your skill is often a byproduct of a “shortage of craftsmen in our industry” (Hoover, Oshineye pg51). Being given a title below your skill level can be frustrating but must not distract from your goal as an apprentice. Hoover and Oshineye mention keeping connections with your Mentors (See Last week’s post) and kindred spirits will help keep you grounded in reality.

                I myself have felt at times that my contributions at my old workplace far outpace my current job title. As stated in this pattern, I used this as a measurement of the organization I worked for which clearly did not recognize the skills of those lower in the ladder. Others may feel that their current title implies they are capable of more than they are currently feeling anxious of living up to such a title. All of this comes down to a matter of proper recognition and belonging which is sadly pushed aside in todays fast paced work environments. There is no way to change the industry overnight but having mentors who can reassure you in times such as these goes a long way in ensuring you remain focused on your goals of improvement as an apprentice.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Scrum and I: My First Ever Sprint

                Recently I have had the opportunity to take part in the development of a new piece of software. That software is known as LibreFoodPantry, an open-source tool that is being developed to streamline the day-to-day operation of and record keeping involved in running a food pantry. This is the first real piece of software I have ever worked on with a team and the first real application of the Scrum framework I have taken part in. Being in this unique situation I am inclined to talk about the experiences and difficulties I faced during my first Sprint both to those who may have not used Scrum before and to those who are just looking for something to read.

                From the beginning I and a group of my peers were tasked with creating a secure login service for LibreFoodPantry that would allow users to sign up and sign into the food pantry’s website. This sign on system also had the goal of allowing administrators to log into and manage the website and its users. The main goals then were to create a sign in that both users and administrators could use and having the website display different options based on the role of the user signing on. While nervous at first I found it fairly easy to get behind this idea, especially considering the goal would be to utilize ‘Keycloak’ an open source login service that will take care of most security aspects leaving us with the task of understanding how to utilize it, and configuring it to run with the website.

By virtue of this being a Scrum based workflow, we were left to plan out a backlog of jobs to finish in this sprint as well as hosting regular meetings to ensure we progressed accordingly to the jobs assigned for this sprint. We also needed a Scrum Master to ensure that everyone was able to progress as needed and suggest solutions to any roadblocks that may appear during the development process. For this first sprint I was lucky to be chosen for this position and with that we got to work.  

Splitting those large goals into smaller tasks to put into the product and sprint backlogs generally proved to be easy enough. We then got to work and were each assigned separate tasks to complete. I myself was given the task of creating documentation for each of the repositories while may have created a simple frontend to test Keycloak on. Much of this first sprint came down to research on how to integrate Keycloak with our website and how to allow users to sign up, login, and disallow any use of the site without a login.

                The team worked well together and we made it a point to, at least twice a week, have a meeting to discuss our progress and if anything was holding back our progress on a certain job. From a teamwork perspective communication was solid and any resources found were shared via a group chat should another team member find them useful.

                It became clear as we went on however that we had underestimated the amount of work some jobs might take. Along with this, it dawned towards the end that we do not need to all commit to different jobs, but we can create small groups within our team to quickly take care of larger jobs. All of this really became clear as we neared the end of the sprint and realized that there were still some remaining jobs. I myself found that I was stuck on a single job most of the sprint trying to get Keycloak to work in some capacity and did not get to do any job past that. Along with this I found myself being too immersed in my own work and communicating less than would be ideal especially considering I was suck and could use the help.

                While none of us lacked enthusiasm it was clear that we lacked experience working with Scrum and the Sprint cycle. This however is nothing that cannot be improved upon with due diligence and time.  Scrum in of itself is a self-organizing workflow that sets aside specific times for review and adjustment. Going into the next sprint I can say with certainty that we will perform better and build upon the experiences of our first sprint.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Finding Mentors

We all have people we look up to, those who we see as guiding lights in the unpredictable lives we all live in. These special few, these mentors can be anyone, from friends, to family, to anyone in between. Having a mentor does wonders to the process of learning as well as providing a source of motivation and consultation when you find yourself struggling or at a dead end.

In ‘Apprenticeship Patterns’ by Hoover, Dave H., and Adewale Oshineye we see the pattern of seeking mentorship described in detail. Consider being an inexperienced software developer who has run into dead end after dead end while developing a new piece of software. Often we turn to those more experienced than us for insight into our problems and this case is no different. We seek out anyone who has had a similar issue and ask what they did in that situation.

Finding a master craftsman and learning from them is the goal of all aspiring apprentices and an ideal that we all seek. This however is often very rare today so many of us will find mentors who we can gather advice from regarding their own past experiences. Our field is relatively young and often changing, leaving few master craftsmen to teach those who are just starting out. Along with this many of these masters may not be physically available to you. This is where the mentors arrive to fill in the gaps.

Weather they are a coworker, a dear friend, or an anonymous individual online, a mentor can mean the difference for many software developers out there. They can offer insight on their prior experiences that may mirror your own, expose you to new ways of thinking, or just offer genuinely good advice. It is just another way to break your coding block when you find yourself stuck with a nonfunctional or misbehaving program you are attempting to get working.

With that said however, we all ‘walk the long road’ at the end of the day (Apprenticeship Patterns Ch 3). and finding someone to guide you can be hard so I will leave you with a recommended course of action by the authors. Find a library, or community with an active mailing list and being observing any messages left there. Over time you will pick up on the values of the community and which members are patient and willing to teach others. At the next opportunity, seek them out and establish that first connection with them in order to see if they would be interested in offering any informal advice or lessons they have learned over their time.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Exposing Your Ignorance

When previously looking at ‘Apprenticeship Patterns’ we discussed the importance of the pattern ‘The White belt'(You can read more about that here: That pattern focused on the importance of being able to set aside past experiences to learn something new. To build upon this we will be looking at the pattern titled ‘Exposing Your Ignorance’.

As we previously saw, it is important to always be learning, especially for software craftsmen who must always be prepared to learn a new language or technology stack for their current job. However, this ever-evolving profession presents a common risk that many fall victim to. It is far too often that we feel pressure to appear competent in front of our peers and our managers. People depend on us to be confident and deliver on whatever job is put in front of us.

You may feel pressured to give your manager reassurance that you know what they want, how to give it to them and when it will be done. But to do so will only be detrimental to your reputation in the long run if you cannot deliver. Instead, it is important to set aside your pride and be truthful with both yourself and your peers regarding your capabilities. If you want to reassure anyone on anything, do so on your ability to learn.

Dave Hoover, an author of this book worked as a family therapist previously and often took the “not knowing” stance when dealing with every new family. This feeling of not knowing would eventually become something that he grew attached to, as a reminder that he was in the right place, that he was learning something new and growing as a person.

To “Expose your Ignorance” you must embrace the learning process, you must have the courage to “Wear your White Belt” and commit to the learning process. Some don’t and fall back on what they are already familiar with. Those people generally become experts but this is not the goal of an apprentice. An apprentice will, by the end of their apprenticeship, have a solid grasp on a few different technologies they can use to create robust software applications. A master craftsman will have a handle on a myriad of different technologies and be able to create large, complex software.

One thing that is discussed in the book you can do now is take a sheet of paper, write down a list of 5 different software tools you do not understand. Post this paper in an area that you and anyone else can see it and update it as you learn more and your work changes. Setting aside your pride to do this can help prevent future pressure from causing you to act in ways that may be detrimental to you in the future.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Wearing your White Belt

Last week I had posted about my first look at ‘Apprenticeship Patterns’ by Dave H. Hoover, and Adewale Oshineye. In it I discussed how the little bit I had read at the time had left a lasting impression on myself and how I view my current software development skill set (you can read more about it here: Since then I have read more and will be starting a multi week long endeavor to go over some of the patterns that stuck out the most to me. A pattern that stuck out to me in Chapter 2 titled; ‘The White Belt’ will be what I discuss today.

Many of you may already realize what it can mean to wear a white belt. Generally those who wear it are considered inexperienced, untaught, or just starting out. What many might not realize however is that it is not only a marker of one who is inexperienced but one who is seeking to learn.

The book starts this chapter by describing a situation many software developers may have found themselves in at one point or another. You have developed a deep understanding of your first language but it feels like their pace of self-education has slowed down or even stalled out entirely. The solution presented is to set aside previously knowledge as you approach new situations.

It is often said that at a young age you absorb information like a sponge and as you age you just cannot learn like you did as a child. Maybe the reason we learned quickly as a child is because you had nothing else to reference to try and make sense of a new subject. When learning a new programming language, it can sometimes be beneficial to start with just that language in a vacuum without thinking of how it compares to other languages.

I found myself that learning how to create a REST API backend required me to unlearn anything prior and start from the beginning. One of the authors, Dave Hoover took this approach as a family therapist to keep from feeling they had an expert knowledge on the troubles of different families. Therefore I will leave everyone with a challenge from the authors themselves. Find an opportunity to unlearn something, ideally something that forces you to set aside past experiences like moving from Java to C++. Many are in general afraid to set aside their past experiences for fear of being seen as silly and inexperienced however you will know just as much weather you openly admit it or not. Being willing to face a new challenge without the burden of past expectations can sometimes lead to unexpected solutions.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.