Author Archives: mikesprogrammingblog

CS448 Software Development Capstone – Apprenticeship Patterns – “Confront Your Ignorance”

For my final Apprenticeship Patterns reflection, I want to talk about the “Confront Your Ignorance” pattern in the second chapter, “Emptying the Cup”. In the last sprint of our software development capstone course, I felt that I wasn’t able to deliver my best work – partly because of how undeveloped my unit testing design skills are, and partly because I caught a mild cold partway into the sprint that zapped my energy levels. If I want to be honest though, the former problem was the more severe of the two, and it will stick around far longer than the sniffles I had. I’ve realized how much more I need to study the technologies I’ve been working with. In combination with the “Reading List” and “Record What You Learn” patterns, I want to put this pattern into action over the summer break and establish a disciplined reading and studying habit for software development topics.

In addition to the unit test design, there were other parts of the work I took part in over the semester that I didn’t completely understand before it came time to implement them. Docker is one subject I want to take the time to research in further detail, since it was an essential component of our work. I first encountered Docker last semester, but it wasn’t until this semester that I’ve understood what the purpose and benefits of virtualized containers are. I know now that Docker allows development teams to create applications within a common virtual operating system. What I want to learn more about is how to write docker-compose files to initialize a functional HTTP backend server. One of my tasks this sprint was to do just that for one of the backend microservices in Thea’s Pantry, and I wouldn’t have been able to do that if there wasn’t a complete docker-compose file in another backend that I could adapt for the repository I was working in.

The largest gap that in my knowledge that I’ve been wanting to address is my technical skill with Java. Java has been the language that I’ve accomplished the most with, next to Python, but I haven’t taken the time to write any Java this semester besides the foundations of my MonsterFactory project, which I realize now could qualify as an example of the “Breakable Toys” pattern from the textbook. Over the summer I think I would like to implement my studying of unit test design into the MonsterFactory and create some tests for the abstract factory classes.

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

CS448 Software Development Capstone – Sprint #3 Retrospective

The third sprint was uniquely challenging for our group, because each of our members were faced with personal challenges and setbacks while we worked to resolve our assigned issues. I was primarily concerned with writing a unit test for the ‘InventoryBackend’ microservice that would evaluate the operation for adding a weight value to the weight stored in the inventory. This test was supposed to ensure that responses were returned for either of the operation’s two outcomes – a ‘200’ HTTP status reflecting a successful addition to the Inventory’s weight, or a ‘401’ HTTP status, indicating that the HTTP request contained invalid values for one or both of the ‘weight’ and ‘Id’ fields.

While discussing the unit test design process with Professor Wurst, we realized that the HTTP ‘401’ error code was the incorrect choice for communicating the error to the user. According to the list of HTTP response codes hosted by Mozilla, the ‘401 Unauthorized’ error code from the server reflects an unauthorized or unauthenticated request from the client. In our situation, where there exist invalid values in our HTTP request, the error code ‘400 Bad Request’ would be more appropriate.

I was not able to get my unit test to a point where I felt that it was ready to be merged into the main ‘InventoryBackend’ branch. I was having difficulty getting the backend server to build in my Gitpod workspace with the ‘bin/’ command, which caused the portions of the test which checked for a valid HTTP response to fail. I also had doubts about the construction of my test, as one of my groupmates had pointed out that my test should be using the getInventory function to monitor the value of the Inventory’s weight as the operations are performed.

One of the things that was holding me back the most, in addition to the challenge of researching and learning unit test design, was that I got sick in the middle of the sprint. It wasn’t anything serious, but my energy levels and ability to concentrate were impacted, which ultimately had an effect on my work this sprint. I would have liked to contribute more than I was able to in this last sprint.

Another thing that was holding me back form designing the best unit tests that I could was that I need to spend more time studying and reading about HTTP backend operations. I’ve realized the importance of setting aside the time to read, absorb, and reflect on the material through writing and taking notes as part of the learning process. Over the summer after this semester, I want to take the time to read a book on software unit testing and take notes as I read. I’ve been considering taking the advice from the Apprenticeship Patterns textbook to build my own personal wiki as a way to organize my notes on all the subjects I’m interested in, like software development, information technology, and data science.

Despite the challenges in my own life during the sprint, my team was a tremendous support during the sprint and I’m really proud of all the things they were able to get done while I wasn’t feeling my best. We all did our best to communicate over text between meetings to coordinate our next moves, and we all still showed up for our scheduled voice calls to work on our assigned issues together. I would be happy to work with any or all of them again, and I’m hoping to keep in touch with all of them after graduation.

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

CS448 Software Development Capstone – Apprenticeship Patterns – “Record What You Learn”

In this blog post, I want to talk about the “Record What You Learn” pattern from the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye. The premise presented in the pattern’s introduction,

“You learn the same lessons again and again. They never seem to stick… You remember doing very similar things in the past, but the exact details escape you.”

, captures some of the feelings that I’ve been having as our development group continues our work on Thea’s Pantry. I remember doing so much backend HTTP server work last semester, but I haven’t retained the lessons as well as I wanted to, and I feel like I’m repeatedly reviewing old material.

Lately, I’ve been reflecting on how well I’ve been nourishing my writing abilities – I stopped keeping a daily journal some time ago, and I’ve noticed that I haven’t been taking as many handwritten notes in my classes as I used to. The first reason I can think of for not wanting to stick to the habit is that I haven’t been exactly clicking with the record-keeping tools that I’ve been using. At first, I wanted to keep digital personal journals with tools like Microsoft Word or a journaling app on my Android device because I liked the idea of having as much space to write as much I wanted, without having to think about reaching a physical “end of the book”. However, I’ve realized over time that there are parts of the electronic writing process, like the glow of the monitor and the distractions of other applications, that can make it harder to concentrate on personal writing as opposed to pen and paper.

I’ve also been reflecting on my writing practices in addition to the tools I’ve been using. I’ve known for some time that I would be helped by keeping records of the things I’ve learned about computers, networking, and software development in my own writing, but I just haven’t known how to start or structure a collection of notes that I want to return to and reference in the future. One solution offered by the “Record What You Learn” pattern is to utilize a personal wiki to organize and store your notes. While I’ve been thinking I want to return to pen and paper for more personal writing, I think that a digital tool like a wiki would be a great choice to organize knowledge-based writing and references to further learning resources. The review process is also an essential part of using the “Record What You Learn” pattern. The authors emphasize the importance of rereading your material: “Your notebook, blog, or wiki should be a nursery, not a graveyard—lessons should be born from this record, rather than going there to die.”

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

CS448 Software Development Capstone – Sprint 2 Retrospective

Throughout Sprint 2, which began at the start of March and was divided by our week of Spring Break, our team tried to spread our work out across several of the repositories in Thea’s Pantry instead of focusing on just one. Our tasks in each repository were centered around making sure the linter extensions were configured correctly in the Gitpod workspace, and that these same extensions would be included in the Gitlab pipeline whenever a new push is made to the repository.

These tasks were more difficult in some repositories than others. Repositories that had received more attention in the recent past required little work or reconfiguration in order to run the ‘’ shell script and have no errors reported in the Gitpod terminal. Most of the issues that I encountered were with the formatting of developer documents. These files were reviewed by the ‘markdownlint-cli2’ linter, which has a set of rules that it expects the markdown files written by the developer to follow. These rules include a limit on the character length of each line and a restriction on trailing spaces, which I found were the two most common issues I needed to address in the developer documents.

One prominent difficulty I had in configuring each linter was learning where in the repository each extension looked for exceptions to their built-in rules. The ‘markdownlint-cli2’ extension had its own file in the root of the directory, as did a few others including ‘alexJS’. Other linter extensions had more obscure locations; the frustratingly similarly named ‘markdown-link-check’ needed additional arguments to be added to its invocation within the ‘’ script, and not written in a distinct file in the repository like most other linters. Each member of our group discovered the necessity of modifying the linting shell script after running our initial ‘npm install’ commands. This command creates a hidden directory in the root of our repository called ‘node_modules’, which contains files related to the extensions we have installed as project dependencies. However, if we attempted to run the ‘’ script without explicitly ignoring the ‘node_modules’ directory, some of our linters, the ‘markdown-link-check’ especially, would run for a prohibitively long time reviewing files in the ‘node_modules’ directory. Since the ‘node_modules’ directory contains files written by developers outside of the Thea’s Pantry project, it isn’t our responsibility to lint these files.

One special responsibility that I had for this sprint was to research the Mocha testing framework and Chai assertion library for later use in Thea’s Pantry. The ‘GuestInfoBackend’ repository already had a functioning test framework, and I used that as a model for adding Mocha and Chai as dependencies to the ‘InventoryBackend’ repository. My first task in the ‘InventoryBackend’ repository was to create a ‘testing/test-runner’ directory which would hold the package files and unit tests utilized by Mocha and Chai. Then, I was able to install Mocha and Chai in this subdirectory through the npm utility. Once I had installed all the files, I needed to modify the ‘’ shell script to call the Mocha framework. I got caught in the weeds at one point because I thought that the ‘docker-compose-test-runner.yaml’ file would create the Dockerfile, and I didn’t know whether this Dockerfile was supposed to be manually created or edited by the developer. I resolved this issue with the help of Professor Wurst by copying the Dockerfile present in ‘GuestInfoBackend’ and modifying it to meet the needs of ‘InventoryBackend’.

There were a few more steps to go before successfully integrating Mocha and Chai into ‘InventoryBackend’, including adding an ‘’ into the ‘test-runner’ subdirectory, as well as installing Yarn as an additional dependency. After my ‘’ was returning no errors, I had to add the ‘test’ stage to the Gitlab pipeline. In the previous sprint, I thought that adding pipeline components was something our group would need to ask permission for, and only realized near the end that we actually had that capability as developers through the ‘.gitlab-cli.yaml’ file. Armed with that knowledge in this sprint, I realized that all I needed to do to enable the ‘test’ stage in the ‘InventoryBackend’ pipeline, was to remove the ‘test’ argument from the ‘disabled stages’ field.

One thing that I think our group could improve on is our review process before pushing our work to the main branch. What we’ll usually do when one of us is ready to create a merge request for our branch, is pick another one of our group members that we haven’t asked to review our previous merge request and have them approve the changes and remove the ‘draft’ marking from the merge request. What I looked for as a reviewer was whether all the pipeline stages passed, primarily. In the future, if we are working on configuring linters again, I think it would be best to have an example of working linter configurations to compare our changes against. This way, I think we would spend less time untangling the proverbial knots that the linters are catching on, and we would also avoid the possibility of introducing breaking changes to the repository.


Reviewed Mocha and Chai documentation for integration into ‘InventoryBackend’ repository

Configuring linters and Gitlab pipeline in ‘InventoryIntegration’

Added Mocha test framework and Chai assertion library as developer dependencies to ‘InventoryBackend’

Add Yarn as developer dependency to ‘InventoryBackend’, in the process of integrating Mocha and Chai

Configuring linters and Gitlab pipeline in ‘ReportingBackend’

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

CS448 Software Development Capstone – Apprenticeship Patterns: “Be The Worst”

This week, I wanted to reflect on my habit of self-comparison in relation to my ability as a software developer. I’ve recently found myself preoccupied with how much I don’t know as compared to others in the computing world, both at and above my perceived level of competence. It feels awfully paralyzing comparing my present knowledge with the unfathomable set of things that I’m not even aware that I don’t know about. It’s becoming difficult to even take a break from ruminating about how far behind I feel, because Youtube and Instagram’s content generation algorithms keep delivering me videos with sensational titles like “5 Sorting Algorithms You NEED To Know”, or “Learn THIS Framework NOW”, or “Build THESE Projects To Establish Your Software Career”. It’s exhausting! Before I’ve even started, the amount and complexity of the work that I believe lies ahead of me makes me feel hopeless. How am I supposed to learn anything or get anything done if I think that my best is so far from acceptable, and to do better sounds so exhausting as to be impossible?

Spending so much time and energy spinning my wheels over this issue has me considering a counterintuitive approach. I can’t stay here in this weird superposition of feeling like I’ve been spending all my available energy on becoming the best programmer I can be, yet also feeling like I’m not working nearly hard enough to produce results that anybody would pay me for. That’s why the title of this pattern from chapter 4 of “Apprenticeship Patterns” caught my eye. I knew before that striving to be the best would be a fruitless and frustrating endeavor, but I didn’t foresee that striving to be my best could still lead to as much paralysis and burnout.

I’ve held myself back from contributing to open-source projects or joining online programming groups partly because I’ve been afraid that even if I try really hard, my best won’t be good enough. My rate of output will sputter, and my code will be full of mistakes, then I’ll lose the respect and patience of my team, and soon I’ll be drowning with no hope of rescue. That’s what my imagination says, anyway – it’s annoyingly silent about what my life would be like if I put some confidence into the skills I’ve learned and started believing that people wanted me on their team. This pattern, “Be The Worst”, asks the apprentice to embrace their role as the worst member of a team they are considering joining. From this place as the weakest member of the team, the apprentice can soak up knowledge and experience from their more capable team members and work their way up.

This pattern is one of those in this book that I think goes back to learning to let go of your own ego and presumed sense of competence. I need to be getting more programming experience outside of school, but because I am so petrified of people thinking that I’m incompetent, I never actually get anything done. It’s kind of terrifying to imagine myself as the weakest member of a team working on an important project, because then I imagine the situation where my being on the team has become a burden on the project despite my best efforts and intentions, and now everyone is mad at me when I’m trying so hard! I should have known better than to bite off more than I can chew! Extremely unproductive and exhausting attitude, I know. Maybe I’ll be able to wade my way out of this strange emotional swamp surrounding my sense of industry someday, but maybe more likely is that I’ll end up living that situation where I’m the worst on the team and I just cannot find it within me to do any better than I already am, and I’ll have to learn that regardless of all that, I’m still valuable.

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

CS448 Software Development Capstone: Apprenticeship Patterns – “Reading List”

After my week of spring break, I’m looking to get back to building constructive habits and reinforcing my software development fundamentals. I was inspired to return to this chapter of the “Apprenticeship Patterns” textbook because I recently learned about a computer science problem called the Circle-Ellipse problem.

This hypothetical problem is meant to highlight the limitations of the object-oriented programming paradigm, specifically when using subtype polymorphism in your class design. In the Circle-Ellipse problem, two classes are defined, Circle and Ellipse, with the Circle class inheriting from the Ellipse class. The Ellipse class includes two member methods, stretchX() and stretchY() which can modify, or mutate, two private member variables of Ellipse each representing an X and Y coordinate. The programming language understands all instances of the Circle class as also being instances of the Ellipse class with this inheritance relation. The problem arises when considering the requirements of a subclass. A subclass needs to implement all the member variables and methods of its parent. The Circle class needs to implement stretchX() and stretchY() as a subclass of Ellipse. Using either of these methods to change the dimensions of the Circle would consequently make that object no longer represent a mathematically correct circle.

As this problem was explained to me, the Liskov Substitution Principle was mentioned. I remember reading about this principle as one of the 5 SOLID software design patterns. The Liskov Substitution Principle essentially states that in a program using subtype polymorphism, an object ought to be able to be substituted by one of its subclasses without breaking the program. The Circle-Ellipse problem represents a violation of this principle because an Ellipse cannot be substituted for a Circle except in one very specific case.

I hadn’t considered the limitations of inheritance relationships in software design before learning about this problem. I decided that after the lecture where I learned about the Circle-Ellipse problem, and after seeing so many titles and authors name dropped in “Apprenticeship Patterns”, that I should start compiling a reading list and start more intentionally defining my daily schedule, including time for reading about software design and computer science. I started with a summary of the Circle-Ellipse problem, and then went through the appendix in “Apprenticeship Patterns” to choose a few books that the authors cited the most often.

The pattern introduces the possibilities of making your reading list public on the internet or using an existing list to source further reading material. The reader is also prompted to look ahead to the future and maintain the reading list to use for reflection on their learning journey.

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

CS448 Software Development Capstone – Apprenticeship Patterns: “Concrete Skills”

I would like to continue my reflection on my fundamental software development skills and how to reinforce them in this week’s blog post. The “Concrete Skills” pattern in the “Emptying The Cup” chapter of “Apprenticeship Patterns” by David H. Hoover and Adewale Oshineye describes the practice of building and maintaining your concrete skill set to make yourself a better choice for a professional role. Knowledge on how to write build files, familiarity with the standard libraries for your chosen programming language, basic web design, and JavaScript are some examples of concrete skills given by the authors. Possession of these concrete skills are what allow you to stand out as a candidate for a developer position. The authors recommend constructing “toy implementations” to demonstrate your understanding of these concrete skills in an interview.

I wanted to read and reflect on this pattern because recently I was challenged with a programming problem where I needed to iterate through the nodes of a linked list. I remember learning about the linked list as a data structure in a previous course, and now in the elective course that I’m taking, we’ve been tasked with implementing a linked list as well as performing operations on it. The implementation of each linked list node as an object with a ‘head’ containing data, and a ‘tail’ that functioned as a pointer to the next node in the list was familiar to me. Despite my previous experience learning about the linked list, I still spent a long time implementing a function that would do something and then iterate through the linked list. I knew I had to repeatedly set the head of the list to its tail within a while loop until the data ‘head’ of the list was empty. It was only with the help of my classmates that I rediscovered how to express that implementation in code and properly operate on each element in a linked list, and then exit the while loop once the ‘head’ member variable of the node was empty. I realized that while I believed that I understood basic data structures like linked lists, trees, and queues conceptually, I struggled with implementing those design concepts when put to the test.

The pattern’s recommendation to demonstrate your concrete skills through small-scale projects has me reflecting on my goals for a project I started a few weeks ago and have only spent a few collective hours on since. I’ve been wanting to practice my design patterns, so I started a Java project called “MonsterFactory” as an exercise. I have a collection of Java classes like Zombie, Werewolf, or Vampire that all inherit from a Monster superclass and share some member variables and methods. I want to implement a MonsterFactory class that follows the Factory software design pattern that could instantiate whichever Monster subclass we could want in any given situation. This project could serve as a functional example of my understanding of software design patterns, and I could also expand upon it to take advantage of the libraries offered in Java. I’m primarily working with strings and integers as data types in this project but learning how to work with images as a data type to accompany each Monster could be an entirely achievable goal for me to add to this project.

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

CS448 Software Development Capstone – Sprint #1 Retrospective

For our first sprint in the software development capstone course at Worcester State University, our team was tasked to investigate epics attached to multiple repositories within the Thea’s Pantry Gitlab page. We also needed to learn how to use Gitlab’s productivity and team management tools as we went along so we could appropriately divide up tasks among ourselves and monitor our progress. Most of our work was accomplished within the GuestInfoSystem repository and its component microsystems. We also spent time investigating the component InventorySystems in preparation for construction of test suites in the next sprint. I personally contributed to the issues attached to GuestInfoBackend, as well as contributed to sprint planning during team standup meetings and meetings outside of classroom hours.

The specific issues that our team was tasked with resolving were configuring the repositories within GuestInfoSystem for remote Gitpod development environments, renaming the ‘commands’ directory of each repository to ‘bin’ and modifying any scripts that reference the ‘commands’ directory to reflect the name change, and integrating the AlexJS linter into the Gitlab commit pipeline. After that work was finished, we would be responsible for investigating the GuestInfoSystem and InventorySystem repositories to prepare to build testing suites for the frontend and backend services during our next sprint.

Before we started work on the issues, we came together as a team to discuss how much time and effort would likely go into the completion of each task, using the weight system used by Gitlab as an estimate. The weight system is a scale from 0 to 3, with each increasing level of weight meant to represent a relative increase in time and effort necessary to resolve the issue. We attached a weight of 0 to some of our tasks while planning our sprint, which may have led us to expect that some of our work wouldn’t take as long as the task would end up requiring of us. The 0 weight in this system represents a task that shouldn’t take more than a few minutes. The only issue that we worked on this sprint that I would still argue would constitute zero weight would be the renaming of ‘commands’ to ‘bin’. Everything else required more investment of our time and concentration than we had anticipated, in part because we were still learning how to use Github’s tools to coordinate as a software development team.

Once we had agreed as a team on which weight values to assign to each of our issues, we decided to begin our sprint with preparing the repositories for development in Gitpod. Instead of cloning code from the Thea’s Pantry Gitlab page to our personal machines, we can open the repository files in a web browser based Visual Studio. This remote workspace is maintained by Gitpod for as long as we are working in it, and for 14 days of inactivity afterward. To create a workspace for the repository we want to work on, there are tools within Gitlab that allow for easy creation of a new development branch based on an issue, as well as the creation of a new Gitpod workspace based on that branch. I’ve been getting to enjoy using these remote development features, personally, and I appreciate how I can have access to all the functionality of Visual Studio without needing to install extensions on my machine.

To get each repository configured for development in Gitpod, we needed to copy the names of our desired settings from the existing ‘.devcontainer/devcontainer.json’ into ‘.vscode/settings.json’, and to copy the names of the extensions that each repository requires into ‘.gitpod.yml’, a file that can be created in the repository while working in Gitpod by using the terminal command ‘gp init’. However, we found that because of a part of the Gitlab pipeline that lints the files in the repository, we needed to change the formatting of some of the files created by that command so that no lines were longer than a certain character limit. In hindsight, I think it would have been better to try and include those files in the ignore files for the linter extensions. Ignore files are files that point to other files and directories within the repository that we don’t want the linter to review or raise any issues with. We began to recognize the utility of ignore files near the end of our sprint, but at the outset it hadn’t occurred to me to try and get around the linter errors by adding the newly created Gitpod files to an ignore list.

The issue that challenged me the most was adding the AlexJS linter to the GuestInfoBackend and to the Gitlab commit pipeline. I wasn’t anticipating that I would struggle with a task like this, because I thought I would just need to type ‘AlexJS’ into a few files and I would be done with it. While that was part of the process, I also needed to add certain files like licenses and the Code of Conduct to an ignore file. The linting process would have returned a failure status otherwise because those files contained text that would be flagged by the linter. I also spent more time I would like to admit waiting for the linting process to finish while it was iterating through the lengthy ‘node_modules’ directory. That directory needed to be added to this repository’s linter ignore files to avoid an unbearably long (and doomed to fail) linting process. I also realized by the end of the sprint that I had misunderstood the task to add AlexJS to to the Gitlab pipeline, and I had only added AlexJS to the lint shell script within the development environment. In the future I’m going to make sure I review a linter’s ignore file when newly installing it into a repository.

My most significant takeaway from this first sprint is that I shouldn’t underestimate the effort I’ll need to invest into issues that sound like they’re well within my comfort zone. We’re working as part of a cooperative effort on a complex software project, and that requires an advanced degree of communication and attention to detail. I’m not going to be able to go into tasks assuming that they will be easy just because they sound similar to problems I’ve solved before.

Gitlab issues:

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

CS448 Software Development Capstone – “Apprenticeship Patterns”: “Create Feedback Loops”

The part of the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye that I find myself flipping back and forth through the most is the fifth chapter, titled Perpetual Learning. I’m planning to depend on my skills in software craftsmanship to establish a stable career and earn enough money to finance my other pursuits in life, and consequently I need to think seriously about nurturing my foundational skills and refining my learning process.

I’m taking a course this semester that has me relearning C++, a language that I haven’t used in several years. I had been programming almost entirely in Java since beginning Worcester State University’s Computer Science program, and the material of this course is requiring me to jump right back into the deep end of C++. I find myself unsure whether my approaches to certain challenges are correct or not, as well as feeling more concerned with whether my code will compile instead of whether I am learning the tools of the C++ language effectively.

When I want to truly absorb some kind of knowledge, I’ve realized that I learn something best when I receive positive feedback when I demonstrate my skills properly and correctly. When I wanted to learn how to play the guitar when I was younger, the first thing I tried to learn was the start of “Breaking The Law” by Judas Priest. The positive feedback I got from learning that part was hearing sounds from the guitar that I was playing that sounded a lot like actual music! After that, I couldn’t stop myself from learning how to be a better guitar player because of how much I wanted to keep myself in that positive feedback loop. I kept learning, I sounded better, and the feedback loop has been growing more rewarding as time goes on. I’m confident that lots of other people can relate to this experience, even if the thing that they were trying to learn wasn’t music or playing an instrument. Being able to gauge your own progress through positive feedback benefits the learning process dramatically.

This pattern is concerned with creating that same kind of positive feedback loop within the context of software craftsmanship. Seeing the quality of your output increase in proportion to your effort in learning can be the fuel that keeps a programmer engaged in refining their craft. The pattern is introduced with a quote from Jerry Weinberg’s “Project Retrospectives”:

“We in the software industry are working with a more or less invisible product, yet this very invisibility only heightens our need for feedback.”

It feels difficult for me to decide “where I am” as a programmer without comparing myself to the people around me. That approach takes my focus away from my own growth however, and I want to avoid it. So instead, the solutions proposed by this development pattern include researching test-driven development and using interactive interpreters that can let the programmer catch errors and see outputs as they write code. The programmer also has the option to intentionally reach out and seek feedback on their coding process from peers and mentors, or by participating in pair programming. A given example of applying this pattern in the real world is asking the interviewer for a position that you were not accepted for why the company didn’t want to bring you on board. This is a more positive framing of what could be a rather upsetting situation, and an outside perspective can also give you insight into aspects of your work and yourself you hadn’t paid attention to.

The key to collecting all this data is to construct useful and actionable feedback for yourself. The pattern defines “useful feedback” as feedback that you can do something in response to that informs you whether to do more or less of a certain behavior. The textbook challenges the reader to put this pattern into action by identifying a metric in their working environment that they have the capacity to change and measure. Then, use the measurements of that metric to try and understand how your actions have changed your “working environment”.

Reflecting on this pattern has made me realize that I have rarely, if ever, sought out external feedback for projects that I’ve worked on outside of school. I’ll write code, compile it, and push it to my Github, but I’ve never made the effort to construct testing suites or seek external criticism from other programmers. These habits have enabled a feeling of doubt to sprout within me about whether my code could be adapted to perform a useful task, or whether I’m actually making any progress in my learning. I’ve started thinking about the advice proposed by this development pattern, and I’m going to take the time to read “Test-Driven Development: By Example” by Kent Beck, the reading material sourced in this pattern. I’m also going to research the features of Visual Studio, my preferred text editor, to see if there are any extensions that allow for the features offered by interactive interpreters.

I’m not sure that I understand the pattern’s advice about “gathering metrics to understand the effects of your changes to your working environment”, but the practical advice of using software tools to provide feedback as you work as well as inviting constructive criticism from others makes perfect sense to me. The pattern also urges the learner to put themselves in situations conducive to building these feedback loops. I think that some of the strongest fuel for those feedback loops are the relationships we create with others along our learning journey, and in the online realm of software development, I don’t think it would be hard to find a community of developers eager to forge and fully energize those feedback loops.

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

CS448 Software Development Capstone -Apprenticeship Patterns: “Practice, Practice, Practice”

The first pattern from “Apprenticeship Patterns” by David H. Hoover and Adewale Oshineye that I would like to write about is “Practice, Practice, Practice”, from chapter 5 of the textbook. I’ve been learning how to code since shortly before I started my first semester at community college, in the fall after I graduated from high school. I’ve been able to complete the lessons that I’ve been assigned at school and through online resources, but even still today, whenever I’m working, I feel like I’m calling on every last bit of knowledge that I’ve got, and that once I’m on my own in the real world I’m going to end up drowning. This anxious feeling can get especially distracting when I imagine how much more progress and work there is to do in building myself into a competent software developer, let alone an exceptional one. Consequently, reading this textbook has been something of an exposure therapy exercise for me.

Developing some kind of practice regimen to reinforce my fundamental skills would go a long way toward constructing a sense of basic competence that I can eventually build on to enhance my skillset. Here I am about to graduate with a degree in computer science, and I honestly can’t say I know how to practice programming outside of school without starting a project and “just doing it”. This approach results in me feeling a lot of pressure to learn many new concepts and produce something useful before I get up from the chair again, and because my emotions quickly become too strong and distracting, I don’t end up doing either of those things. I need to develop a new way to practice my computer programming skills.

The phrasing of the problem presented in this pattern caught my attention because of how much I related to the sentiment: “It’s as if you’re always on stage.” I feel like every time I open my text editor to complete my daily tasks, or whenever I need to research a new subject, it’s the ultimate test of my ability and merit as a programmer. It’s going to be incredibly difficult to test my limits over the course of my career if my everyday experience feels so drastic. The solution offered through this pattern is the technique of practicing through “code katas”. The author explains that the term “kata” is borrowed from martial arts, and that it as a term which refers to a sequence of movements provided by a teacher to their students, performed without an opponent. The purpose of executing the kata is to reinforce the student’s fundamentals and build their physical control, fluidity, and power.

The benefits of applying the same practice of repeating fundamental movements to build overall competence towards the craft of software development are that it enables a practice environment without deadlines or expectations and that this method of practice allows learners to build their self-confidence without introducing the stress that comes with delivering complex software projects. About practicing with code katas, software developer Dave Thomas says “It has to be acceptable to relax, because if you aren’t relaxed you’re not going to learn from the practice.”

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