Author Archives: mikesprogrammingblog

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 ‘lint.sh’ 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 ‘lint.sh’ 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 ‘lint.sh’ 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 ‘test.sh’ 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 ‘entrypoint.sh’ into the ‘test-runner’ subdirectory, as well as installing Yarn as an additional dependency. After my ‘lint.sh’ 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.

Work:

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.

Apprenticeship Patterns by David H. Hoover and Adewale Oshineye: Ch. 1 and Introductions for Chs. 2-6

I’d like to talk about my thoughts after reading the portions of Apprenticeship Patterns by David H. Hoover and Adewale Oshineye assigned to our Software Development Capstone class. My first impression on reading the title was that this textbook would present different outlines of careers in software and information technology. After reading the introduction, however, I realized that the purpose of this book was to share different patterns and habits that would lend themselves to a successful apprenticeship in software craftsmanship.

The promotion of a growth mindset is one of the first themes established in the book. The authors talk about the growth mindset’s emergence from the research of Carol Dweck, the author of “Mindset: The New Psychology for Success”. The core belief of a healthy growth mindset is that a person’s intelligence is not fixed, and that a person can always grow their knowledge and ability through effort and learning. Through the growth mindset, people are encouraged to perceive failure as an opportunity for learning and reflection instead of as an indicator of inadequacy.

Maintaining an optimistic growth mindset is especially important for people working in software development and computer science. The volume of knowledge it seems to require to contribute anything of substance seems so overwhelming, it can be easy to tell yourself that you’re incapable of learning it all, or that you don’t even know anything as you are now. This emotional state of feeling incompetent or like a fraud despite your accumulated experience and talent is popularly referred to as imposter syndrome, and a survey conducted by Blind in 2018 found that more than half of tech workers report feeling like an imposter in their place of work. These responses came from people working with tech industry leaders like Google and Amazon, which shows that these feelings of self-doubt can exist in anyone, no matter how hard-working, efficient, or naturally talented. In a profession like software development, where the majority of a developer’s work is built on top of the sum of the work of many other people over many years, it’s essential to adopt a growth mindset to bolster your mental and emotional health despite the temptation to doubt yourself and invalidate your own accomplishments.  

In addition to the maintenance of a growth mindset, the authors propose other uniting values of a software craftsmanship community. Among them are constant adaptation, a desire for pragmatism over dogmatism, and the open sharing of knowledge. This software craftsmanship community would also value individual responsibility for one’s apprenticeship journey, and a willingness to experiment and be proven wrong.

The concept that interested me the most from the introductions of later chapters was The Long Road. I understood The Long Road as a metaphor for the lifelong journey of learning, and I recognized the necessity of the growth mindset the authors described earlier as a way to steadily propel yourself along that road. Without that mindset, the discouragement and confusion that naturally accompany learning can be too difficult to overcome.

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 Capstone Course Blog Post for week of January 16, 2024

I’m starting my (hopefully) last semester in Worcester State’s Computer Science program, and the focus of our capstone course will be contributing to the microservices supporting Thea’s Pantry at Worcester State University. Thea’s Pantry is using a guest frontend, reporting and inventory system built by the LibreFoodPantry humanitarian free open-source software community. LibreFoodPantry is managed by a coordinating committee and a board of trustees, and has adopted a Code of Conduct modeled after the Contributor Covenant. I hadn’t heard of the Contributor Covenant before reviewing the website for Thea’s Pantry. The Contributor Covenant provides a general set of community guidelines that foster a respectful and welcoming space for collaborative open-source software development. I have previously learned that a policy of enthusiastic inclusivity and openness is essential to an open-source project’s success, but I hadn’t realized that such a policy would consequently necessitate the creation of a robust code of conduct for the project’s contributors.

In the Software Design & Architecture course I took last semester, I learned about semantic versioning in software and how it’s used to keep track of a software’s present state even after many alterations to the source code. In order for Gitlab to correctly increment a commit’s semantic versioning number, contributors to Thea’s Pantry are expected to attach commit messages to their work that adhere to the Conventional Commits standard. The Conventional Commits standard requires developers to include a type of change such as “fix” or “feat” at the beginning of their commit message. “Fix” commits signal a patch, and will increment the rightmost semantic versioning number, while “Feat” commits signal a feature update that would be reflected by an increase in a middle semantic versioning number. If a breaking change will be introduced, that would be notated by either a “BREAKING CHANGE:” footer, or a “!” appended to the commit type.

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.