Category Archives: CS448

Introduction to Apprenticeship Patterns

The book Apprenticeship Patters: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adele Oshineye is a powerful tool for both beginner and seasoned software developers.

Hoover and Oshineye introduce software development as a craft constantly needing to be honed. The term “craft” has been widely defined and generically used throughout multiple sources. However, Hoover and Oshineye define what they mean by “software craftsmanship” using a list of values. While the list is long and descriptive, the main gist is that the craft of software development is all about improvement. There is always room for improvement, achieved through an open mind, the sharing of information and resources, and the courage to experiment and discover through process.

To help developers hone and perfect their craft, Apprenticeship Patterns contains numerous different strategies or “patterns”, helping the reader not only to grow, but to grow most effectively.

One thing that resonated the most with me was the book’s theme on the importance of having an attitude of growth. Without such an attitude, it is easy to become stuck in one’s own bubble of perceived competence and thereby losing focus on learning. I could have all the resources available to me, every book, tutorial, guide, and mentor; but if I am not open and willing to move away from my perceived area of “expertise”, my growth will surely be stunted.

In addition to the right mindset, I found chapter four very insightful, which goes into detail about how a developer also needs a healthy environment where growth is promoted. An environment that fosters learning and communication is the key difference between a struggling software developer and a thriving one. Because of this, a developer should be careful not to be too content being the biggest fish in the pond. There is always another pond with even bigger fish and more nutrients. Hoover and Oshineye emphasize repeatedly how important it is to let go of perceived competence to focus on learning. Sometimes, the best environment is one that is a little uncomfortable.

Software development is a huge field filled with so much potential. There are dozens of languages that take years to fully experience, learn, and understand. All of this — and so much more — is taught through experience and through trial and error.

In addition however, one other important tip from Hoover and Oshineye is to learn from the best of the best. They stress the benefits of reading books which are filled with the knowledge of experts in the field of software development. Reading is the most direct way to gain knowledge made possible through an open mindset and a resourceful, learning environment.

While growth and learning are important, I also think it is important to rest and enjoy the journey. The word “craft” also implies “artistry”. Therefore, I believe a software developer should not focus too much on “becoming an expert” but also to explore and appreciate the beauty of the art of software development.

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.

Apprenticeship Patterns Blog

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye is a book covering a comprehensive overview of software testing meant to prepare the reader with the knowledge and skills necessary for working as a quality assurance tester.

In the beginning of the book, Hoover and Oshineye answer the important questions of “what” is software testing and “why” it is necessary in software development.

At the highest and most general level, software testing is a way by which a software’s quality is evaluated, estimated, and shared with stakeholders, providing an independent view of the software product. Furthermore, it is the goal of software testers to ensure that this quality meets and maintains the requirements. I found it interesting that the book mentioned the primary function of software testing to be for the stakeholders; however, it makes sense as software testing not only is needed to ensure that the program runs, but also that it runs smoothly for the user, and most definitely for its stakeholders. The best way to assure stakeholders of the product’s success is through software testing.

Chapter two of the book gives further reasoning for software testing stating that the U.S. government lost 60 billion dollars due to software defects in 2002, equating to 0.6% of the country’s gross domestic product. In a world that is so heavily dependent on technology, it becomes evident how important it is to ensure that this backbone of society remains reliably working.

So with the question of “what” and “why” out of the way, the book shifts gears into the essence of software testing. The fundamentals of software testing is split into three parts: testing basics, requirements, and test plans.

The most basic form of testing is checking expected output with the observed output based on a controlled input allowing for a clear comparison and analysis of the program’s behavior. Most patterns of software quality assurance are based on this fundamental strategy.

Before testing software, it is necessary to know what it is that needs to be tested. This is given by the software requirements. These specify exactly what it is a specific piece of software should do under certain conditions ensuring that developers know what to build and that testers know what to test. Requirements are laid out in a test plan, a collection of test cases ensuring that every requirement of a software is met.

Software testing is complex field with many moving parts. However, it all boils down to ensuring that the program works as intended, meeting all the requirements and expectations shared by stakeholders and users, which saves time and money for companies that use it effectively. It is a field of software development that I am very interested in and am excited to learn about more.

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.

Set-Up Post | Libre Food Pantry & Thea’s Pantry

Libre Food Pantry (LFP) and Thea’s Pantry are both organizations working to provide solutions to those in need by offering alleviation in grocery and other personal needs.

The LFP is developed mainly by instructors and their students who act as LFP Shop Manager and the LFP Shop respectively. Each Shop is further divided into Teams that work to develop and improve solutions.

Shop Managers are not only in charge of their shop and are also members of the Coordinating Committees whose responsibilities are to guide the direction of LFP, represent its high-requirements, support all the Shop Managers, and when appropriate, set necessary policies.

Thea’s Pantry is partners with Libre Food Pantry which is why I found it useful to learn more about how the LFP was organized.

One thing I found interesting about Thea’s Pantry was it’s relation to the Worcester County Food Bank. The pantry sends monthly reports using the Monthly Report system, which is accessed by a Pantry Administrator who specifies the month and year to generate the respective report as a downloadable Excel file.

For this reason, it is important to create a system that is able to reliably log and store activity records of the pantry about both the guests and inventory of the pantry. That is what the collaboration between Thea’s Pantry and the LFP wish to accomplish.

Knowing these facts allows me to see more clearly what I will be contributing to through my Capstone project, as well as the connections that allow it to happen.

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.

The Final Sprint Retrospective

The most headway came when multiple sets of eyes were on issues. This first proved to be true when the IAM System Community of Practice was working together to establish the logout functionality and to ensure that the user sessions properly expired to prevent unauthorized modification of the database.

This also rang true when Tim Drevitch and myself were finally able to free up time and address out standing issues. As per my comment here, and his comment here, we were able to spin up a docker instance of a database and pretty quickly figure out how to start adding to the database just shy of setting up the specific documents we needed to store individual users/entries. It was three hours of troubleshooting together, researching different aspects, and then explaining them back to each other over voice chat, but we made substantial head way where there was otherwise none (despite it not being a card assigned to either of us).

While there are obvious constraints to having green undergraduate students try to develop software on a very part-time basis, it became very obvious that not all the teams were created equal. When I would meet with the IAM community of practice we would discuss what our groupmates needed of us and I would routinely report back to them that my group had made no mention of any code, functions, methods, etc that they needed from me nor intended to integrate any time soon, much to their surprise. This signals to me an overall unfamiliarity with the tech stack which is not a judgment on them, they’re doing their best given the limited amount of time in the day and the craziness of navigating online learning. That being said it was often the bottleneck within team discussions.

What was within teammate control and —seems to be the modus operandi students within the Worcester State University Computer Science Program— very unacceptable was the lack of communication. I would consistently ask teammates what they were working on and how it was going only to get no response. In fact, there was one teammate who I had never heard talk until three weeks until working with them; it’s anyone’s guess as to why, but my experience with my fellow computer science students has been largely marred by radio silence. My biggest change I would have made to the team was to force my teammates to communicate by instead of asking them “what is stopping them” in the standups, ask them “what is something they encountered that they didn’t understand while they were working”.

My personal failings in the last sprint came largely from my pivoting away from schoolwork to build out skills that would help me attain a summer internship as well as applying to said internships. I became more focused on learning the practical skills gained from sites such as and studying for the eJPT certification so that I may pursue a career in information with an emphasis in exploit development and malware reverse-engineering. My ability to engage with school work may have declined but it was a necessary sacrifice to (hopefully) make myself a more viable job candidate.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

We must learn how to learn.

Learning is ongoing, continual, without end.

 [L]earning about what we do not know is often more important than doing things we already know how to do.

—Jim Highsmith, Agile Software Development Ecosystems

This chapter focuses on continual growth as a developer. The problem scenario presented in the text is one where we have only a basic skill level of software development as it pertains to our day job. The author suggests that we should take a multifaceted approach to learning.

Some examples of how we can seek-out new knowledge and experiences:

  • Sign up for Google Reader (or another blog aggregator) and begin subscribing to software development blogs. With modern machine translation technologies, you do not even have to restrict yourself to those who write in English. You can follow Tim O’Reilly’s advice and track the blogs of what he calls “alpha geeks” across a variety of technology domains.[26] These people are not necessarily the best programmers, but collectively they tend to sense new trends years before the rest of us. Consider using your own blog to reflect on the themes you pick up from these bloggers.
  • Start following some software luminaries on Twitter and pay attention to what they are working on.
  • Subscribe to a moderately high-traffic online mailing list and try to answer people’s questions by reproducing their issues.
  • Join a newly formed local user group that is excited about a new technology. Do not just attend silently – introduce yourself to the organizer and offer to help.
  • Persuade your employer to send you to a technical conference. Even if they will not pay for you to attend, you can still read the slides on the website and download audio/video of the speeches.

Using multiple tools to acquire knowledge and skill-sets is one of the best approaches I have tried. It is the same if you want to learn a new oral language, you surround yourself with it and continually find ways to incorporate it into your daily routine. Immerse yourself in the topic continually, not just when you are at home sitting with a book. The ending of this chapter resonated with me as the author mentioned how simple it is to take this continual search for more and more knowledge too far. I have a (possibly slightly unhealthy) obsession with learning about a variety of unrelated topics that do not benefit my life in any way.

  When I hear of a new technology or topic that interests me, I become enthralled by it. Nothing else exists until I know as much as I can about it. Currently, my obsession is with 18650 Lithium ion batteries, particularly building my own packs. This pattern will prove to be helpful in my life reminding me not to get lost in the sea of interesting information and to also not lose my practical skills in life/development.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Retreat into Competence

The problem talked about in this pattern is being overwhelmed with how little we know. I have felt this way many times, pursuing a degree in compSci. There have always been students in my classes that are better developers than I. Whether they have been programming longer than I have, or they are not juggling school with fatherhood, home maintenance, cooking for five, cleaning, paying a mortgage etc.

The solution presented in the text is that we should occasionally retreat for brief intervals into the things we are competent in. Taking some time to build something in familiar languages and frameworks will help ground us in our abilities . We are warned however that going backwards can be risky, if done without proper planning. When going backwards, it is best to set specific time limits for yourself so you don’t get stuck in your comfort zone. We desire comfort and familiarity, but growth does not exist within your comfort zone.

All throughout my life, asking questions to better understand things I am somewhat familiar with or inquiring about things I am not familiar with, is something I have always done. During my time studying to become a developer, I have experienced this feeling of overwhelm from time to time, regarding my ignorance in computer science. Due to my passion for learning, I have sought support and guidance from professors and peers alike, without hesitation. Although this has benefited me greatly in the past, it could be quite useful to retreat for timed intervals doing something I know well and feel confident about.

The idea of setting time limits interests me because it reminds me of Pomodoros, which is something I utilize quite frequently. Setting a timer to work on “task A” and another timer to step back and take a break has been working well for me. Taking that break and using it to do something I am good at and know well could very likely give me the reassurance I need in respect to my knowledge and abilities as a developer. Maybe even developing something I feel competent and confident in would help me to ground myself as a developer.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

“Sweep the Floor” is perhaps an Apprenticeship Pattern that I’ve seen most closely paralleled in the real world. The pattern proposes that the price of admission onto a team may be that the newly crested member start by doing the unglamorous jobs —hence the title of the pattern—, often this will be things such as differed maintenance or writing reports. This is manyfold: it proves capability, builds trust that you can work independently, allows for controlled and low-stakes contribution to the project, and will free up the more vested members’ time to teach you higher stakes tasks.

As I alluded to, this ritualistic humbling seems to be inevitable in any profession, particularly in what gets oft classified as skilled-work. When I was a mail processing mechanic, the first thing we new recruits were delegated was daily maintenance tasks such as changing rubber belts on a feeder assembly, or changing drive belts that were in the lower tiers of the mail processing machines; the latter considered the most uncomfortable —sometimes downright painful— task to work on. While I don’t suspect that updating documentation or eliminating technical debt will be nearly as dirty as being covered in paper shreddings and ink dust I felt this quote in particular was a very powerful way to bind the metaphor of back to software development:

“These sorts of fringe tasks benefit the team, but they will also benefit you as an apprentice, because such chores are often skipped in academic courses and by doing them you can fill in the gaps in your knowledge. This experience will serve you well as a journeyman too, because any master who takes you on will understand how valuable it is to have someone to do the unglamorous work. After all, if no one sweeps the floor, then the glamorous work can’t be done because the team is hip-deep in dirt.”

The authors made sure to mention my primary criticism of this learning style which is what they have called becoming the team’s gopher. If it were not apparent, a quick definition of a gopher is one who has become known to absorb the menial or painful work and thus gets typecast into that roll permanently, condemned to the strictly utility work which creates a lag on your understanding of current developments in the code base and hurt your chances of upward mobility. The authors’ prescription is relentlessly advocate for yourself, Nurture Your Passion, and Unleash Your Enthusiasm.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

The Tortoise Always Wins

“How long will it take to master aikido?” a prospective student asks. “How long do you expect to live?” is the only respectable response.

—George Leonard, Mastery

While reading chapter 3 of Apprenticeship Patterns, I stumbled upon the preceding quote. It resonated with me because I often get so caught up in aiming for perfection that progress becomes halted. Anything worth doing is worth doing poorly.  I have heard it said that perfection is the enemy of progress.  

This chapter focuses on the long road we all must travel to master our craft. The author talks about how we have all grown to desire immediate gratification, whether that be in notoriety, wealth, or the development of our skill. If we desire to become true craftsmen we must focus our attention on delayed gratification. Our skills will take time to develop, and the journey will be a test in endurance and patience. The problem presented in the text is of being stuck in a “golden lock” where our aim for further crafting our skill is at odds with our desire for a higher paying job. By taking the path less traveled “Robert frost” we can make all the difference in our development as craftsmen.

We must be patient and compassionate with ourselves along our journey. It is easy to get discouraged when we see how little we know in comparison to veteran developers or even peers. So long as we strive to continuously hone our craft, we can become the masters that future generations of craftsmen look up to. The long road means we do not grow into incredible craftsmen overnight. It takes long hours and is a slow process.  

When we take our time to mindfully develop code, asking questions about why and how code behaves the way it does, or why we approach problems a certain way, we deepen our understanding of not only the development process but our strategies for everyday living. We learn better problem-solving skills, we become more inquisitive into ways to efficiently meet the needs of ourselves, our families, and our communities. This is something I have struggled with as a CS major, trying to balance out good grades with deeper comprehension. Many students fall into the trap of just learning the information required to pass the class with a good grade, putting ourselves at a disadvantage. Our lives have only a finite amount of time, and sometimes we need to decide whether we should slow down and take time to comprehend the deeper truths of software development, even though it may take away from time available for studying the class materials.

If we desire to become true craftsmen rather than just working a 9-5 grind we need to recognize that the path we chose is neither easy nor short. Our field is growing exponentially with the constantly changing technological advances we are experiencing and will continue to experience. This path is not as straight and narrow as other fields, due to the continuous changing of technology. However, if we slow down and dig deeper asking the questions that lead to deeper understanding, we will see the commonalities that all software share, making it easy to adapt to the changing of software development. Traveling “The Long Road” can allow us to bring meaning and pride to our work rather than being another nameless cog in the machine for a corporation.

The tortoise always wins the race.

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective Blog Post

This second sprint has been a bit better in terms of actionable steps; this was aided greatly by the mock front and back end. The mock allowed us to test configuring a realm to a container locally which was the floor for proof of concept. Unfortunately, the lack of architecture made further progress confusing as I didn’t understand why all images couldn’t be on same container network. After it was determined that the architecture called for further subdivision, it became unclear what microservices should be on which image and/or network. For instance, it was more or less determined that Keycloak should be on its own separate container (presumably with WildFly) but at the beginning of sprint I wrongly believed, based on previous internet searches, that NGINX should be on the same image as Keycloak but this was later discovered to be unnecessary as the mock front end contains NGINX within our system.

On that same note, the task breakdown and codification into issues for the respective boards suffers from an incongruity where ignorance of the matter begets ignorance in the approach and then future work is inaccurately reflected in the process. This isn’t necessarily an issue with the approach as whole but it seems as though, for the past two sprints, this unfamiliarity with the microservices and their implementation into our architecture forced me into a series of micro pivots which quickly evanesced away from the originally declared issues. If the goal of scrum is not to constantly be inundated with creating issue cards, updating them, and closing the now obsolete ones, then perhaps it would behoove us to reconsider the amount of research time necessary or have a much more closely-guided approach to issue construction. If this rapid pivoting away from cards is acceptable (and their grades reflect this) then that’s not particularly bad news for students. However, we have to be honest with ourselves and have the hard conversation that Scrum in this setting does not accurately map to what Behr, et al. would refer to as WIP (work in progress).

The low-hanging fruit of constructive team feedback would be the necessity of more frequent external meetings. It certainly was not for lack of trying; the most charitable reading of the situation was that I found there to be no strong consensus on when the team schedules would align. We also would have benefited from more frequent contact internally. Barring all real-world, unforeseen, obligations that took team members away from us the scattering of the team into groups caused our reviews to be staggered resulting in the loss of two full class periods of collaboration. My prescription for this would be that those who come after us should successfully drill down on establishing a running prototype before splitting off into the other groups.

My individual criticisms to my work flow largely still touch on the externalities I’ve lamented in a prior blog post but, if I must touch on them briefly, they’ve stayed mostly the same. It’s quite apparent that certain teaching staff in the university have struggled to pivot to remote teaching and, if I’m to attribute to ignorance and not malice, they seem to have bequeathed those struggles to their students. To those teachers I would like to remind them that Monday holidays are not a surprise and certainly not an invitation to delegate away your teaching responsibilities because you’re lagging behind curriculum milestones. If these teachers cannot grade in a timely manner, then my deepest sympathies, but please do not complain that the bulk of your students keep getting concepts incorrect and you have to re-grade their assignments and/or assign extra credit to help inflate grades. I’m a commuter student with one semester until graduation so I will stay here at Worcester State; if I was a commuter student with two semesters left, I would have transferred out.
When paired with their “Docker Tutorial For Beginners” has been an invaluable resource to teach myself Docker and use continuously as a reference.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

The explicit context of this pattern is that you’re a developer on payroll and you have been tasked with successfully delivering an artifact of software to your employer but unfortunately you have not previously developed software with some requisite technology for the project ahead of you. The solution prescribed in this Apprenticeship Pattern is a bold one that leans on previous rapport with your superiors; it insists on radical honesty where one admits that they do not presently know all of the information necessary to deliver on the project and to appeal to their previously established competency and ability to learn new technologies.

What I find most elegant about this approach is not only the ability to tailor current expectations using honesty but also the renewability inherent in this approach:

“In this way, your reputation will be built upon your learning ability rather than what you already know.”

The implication there is that if you stick the landing on delivering the necessary code, you will have created an evergreen approach to setting expectations and earned yourself the reputation of being not somebody who is valued for their finite pool of knowledge but rather their ability to tap into an infinite pool of knowledge. The authors cite Carol Dweck’s work, particularly how the need to appear competent is a mindset (no pun intended) that has proliferated throughout industrialized societies and is hard to break through. They insist that, while this embarrassment may be hard to overcome at first, your peers will have to notice your rapid progress and moreover they may find that by you forcing the issue they may have new realizations about their intelligence; after all people like to solve problems and feel intelligent.

I enjoyed the juxtaposition the authors make between those who become experts as a result of the perhaps not being as inquisitive or less confrontational with their inadequacies and so-called craftsmanship-seekers who become experts just by virtue of interest. While the first group may not be as ambitious or aggressive in their pursuit of knowledge there is no need to disparage this group and I appreciate that the authors did not decide to punch down where many other snobbier tech experts certainly would have.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.