Category Archives: CS448

Breakable Toys

Experience is built upon failure as much as (if not more than) success.

Breakable Toys is about purposefully creating learning opportunities by pushing yourself outside of your realm of experience and designing and developing complete software projects on your terms. The concept of this pattern is one that I speak of frequently, in regards to many areas of life. The comparison of the jugglers was actually pretty insightful. It would not make sense to attempt something new, knowing you may fail without having practiced it first. As the saying goes, “Practice makes perfect.”, and this is especially so in software development.

Trial and error seems to be an obvious concept whenever learning something new. Although, it does not seem likely that one would have room for many failures in software development, as that would become costly. With that thought in mind, the suggestion to build your own systems on your own time – your Breakable Toys – is ingenious. Within that suggestion, one of the Breakable Toys given as an example in the book Apprenticeship Patterns is to create a personal Wiki page. The book mentions that in doing this, you can gain knowledge in web design, HTTP, concurrency and parsing. Not only that, but you gain experience and a growth in work ethic, confidence and pride in yourself and your work. An equally beneficial reason to create a personal Wiki page is that it is a perfect way to keep a record of what you learn.

Breakable Toys is a pattern I can see becoming one of the most useful patterns I’ve learned of thus far. With knowledge of this pattern, I am confident that with hard work and dedication – and more than likely a whole lot of screw-ups – my abilities and confidence as a programmer will progress. Going forward in this field, I fully intend to start building some of my own Breakable Toys in order to enhance my skills and broaden my understanding of software development. I would encourage other programming students and programmers alike to invest their time in building their own Breakable Toys.

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

Reflect As You Work

The “Reflect As You Work” pattern in Apprenticeship Patterns has much to do with developing a methodical and concrete approach to introspection within one’s software development career on both a macro and micro level. On the micro level, Hoover and Oshineye make the recommendation to consider your day-to-day practices when programming and to take notes on the practices of more senior team members to see what makes them so effective. On a macro level they describe what amounts to a hotwash or after-action review of the operation (to borrow government idioms) but caveat that a certain level of trust by management is necessary for the approach detailed and that may not always be the case.

One of the exercises in this Apprenticeship Pattern I finally found to have immediate utility in my life is accounting for the things that I do or do not do adequately in regards to programming. The exercise as described by the authors:

“If there is something particularly painful or pleasant about your current work, ask yourself how it got that way, and if things are negative, how can they be improved? The goal is to extract the maximum amount of educational value from every experience by taking it apart and putting it back together in new and interesting ways.”

Like many of the Apprenticeship Patterns and the exercises contained within them, much of the immediate implementation is lost due to the apprenticeship patterns pre-supposing that the reader is currently writing a meaningful amount of code to have established a personal pattern. Despite that fact, I’m able to use this exercise to dissect my personal habits prior to entering college which were things such as poor commenting, not adopting to the bracketing style of the language, not using tests, not using git, and CI/CD. What was pleasant about my past work was my consistent use of the Microsoft Visual Studio IDE to debug and step through my programs. Unfortunately, I’ve been able to write substantially less code since I made the choice to return to college but look forward to using the exercises that I learned about in this apprenticeship pattern to maximize the value in learning from my mistakes.

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.

Practice, Practice, Practice

While it is a likely contender for the most self-evident of the Apprenticeship patterns, I have found “Practice, Practice, Practice” to be the most inspiring thus far. The context that the particular pattern describes is a situation I found myself in quite frequently in my previous undergrad; there is a need to get better at your craft, develop your skills but it feels as though you’re constantly in performance mode. While there may be some merit to having a mirror by my side checking my posture and a metronome in my ears pushing me to increase my words per minute, it’s far more likely that the deliberate practice the authors allude to has more to do with firing the synapses dedicated to problem solving rather than strengthening the myelin sheathes governing my ability to put a stick to the head of a drum.

I enjoyed the reference to K. Anders Ericsson’s research on the matter but was predictably bummed out when the authors pointed out that reality is not in fact perfect and that we, as apprentices, do not have a readily available pool of benevolent masters who will take us under their wing. As someone who was raised primarily to throw a baseball and complete schoolwork assignments put in front of me, the idea of mastery never crossed my mind; talent was something I was born without and that my success in life would largely have more to do with my ability to follow orders and do necessary tasks linearly than anything else. As a latecomer to this world of musical craftsmanship I lacked not only the pedigree but also the prior mentorships that allowed my peers to sail through and seek out additional opportunities. I recognize in hindsight the benefits of a mentorship but also know that with mindful practice I was able to catch up to my peers and even succeed where some of them failed.

My ability to successfully achieve competency happened not because of strong mentorships (which I never received) but rather because of slow, concentrated practice much like the katas of the dojos mentioned. My favorite prescription presented by this article is at the “Action” section, to carve out some additional time to do mindful practice, as practice makes permanent.  I have several exercises in mind and once I finish a few more homework assignments I look forward to practicing!

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.

Sprint 1, a Retrospective

Mired by a litany of confusion and growing pains our group managed to come out on top. Actually, that is a boldfaced lie; our group disbanded but I assure you these two things have little to do with each other! All joking aside, our plan at the outset was to learn about utilizing the information access management software known as Keycloak. As it was our first sprint working with completely unfamiliar technologies, the sensible thing seemed to be to read the darn manual and document our findings. While this worked for reinforcing our individual assigned topic from the official documentation, I have to wonder if it really helped us deliver a tangible product or just slowed us down. To elaborate, it seems as though we read a lot about the technical aspects of Keycloak but at the end of the day there was little to analyze and report other than that the documentation seemed to be thorough. In hindsight, I believe the better approach would have been to work together as a group and walk through the configuration process, documenting the whole thing. Moreover, we should have raised questions about the size and scope of user volume and based on those factors decided on a configuration (cluster versus standalone comes to mind) to attempt. While configuring Keycloak and WildFly on our local machines certainly gave us insight, we would have discovered that learning about WildFly and its subsequent installation may have been completely pointless depending on which configuration we decide on going forward.

Given our approach I found that the best work was done when we were collaborating together. I touched on this concept earlier when I was describing how – with the benefit of hindsight – our group ought to have approached the assignment, but synchronous communication and action taken towards configuration yielded drastically better results. It was during these sessions where the team was able to best overcome technical hurdles (such as versions of Docker mismatching) or discover some steps might be superfluous (such as installing and configuring WildFly when not using a local instance of Keycloak). It pains me to say it but it seems as though, of the work we got done, a very small portion of it ended up being useful and that our approach seemed to be driven more by how we could fit our work into the agile framework and not how the agile framework could best help us implement our work. This isn’t to say the framework is of no value or inherently a hindrance, nor is it an indictment of any particular person, but it seems as though our group was not able to mesh well with the framework to get results.

Individual improvements can mostly be derived from the same tired critiques in the vein of rugged individualism whereby things such as losing power, health problems, email harassment must not dampen one’s spirit and certainly, above all else, not their work ethic. Perhaps if I had instead made a measured effort to calculate how many hours of autodidacticism I could throw out so that I may stay in the low C range (as opposed to the upper range) of a non-major class, I may have been able to find more time to commit to exploring Keycloak. Is it unprofessional for a student like me to complain on an assignment for my personal blog? Perhaps. I would argue it’s at least as unprofessional for a teacher to underperform in their profession and that students should have to internalize that as an individual failing.

Links to work done on our team’s wiki:

This wiki entry is the reference page I accidentally wrote on the Authorization Services.

This wiki entry is the reference page I created for WildFly.

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.

Concrete Skills

The “Concrete Skills” pattern in Apprenticeship Patterns can be understood, at a baseline level, to be the process of obtaining skills to achieve acceptance into a group of software professionals. This pattern elaborates on how the acquisition of skills has both intrinsic and extrinsic value in differentiating you as a potential candidate for the position in question.

Upon reading the Context and Problem section of this pattern, my brain immediately conjured up a preconceived notion as to what I should expect from the rest of the article to follow. In many respects that notion was correct; I was anticipating a description of the courting ritual between the gatekeeper(s) and the applicant. In the previously mentioned ritual, the applicant admits to humility but shows sufficient competence and desire to improve to the gatekeepers who either make an affirmative judgment leading to the conditional induction of the neophyte, or a rejection leading to the applicant walking away with redoubled determination to step back into the fiery crucible of honing their craft so that they may be better prepared the next time for the acceptance ritual. I embraced this struggle personally in my desire to create music; having been composed of solely aspiration and perspiration, I fell below the musical competency threshold during the audition process several times but I came back with a vengeance and was able to squeak out acceptance.

In the context of software development, Hoover and Oshineye are designating the in-group as a software development team who has a hiring manger that will be vetting your technical skills rather than several bandmates vetting your musical chops. The authors make mention of the concept they borrow from someone else called “day care”, and this is to illustrate the mentality of the gatekeeper who will ultimately be held responsible for the hiring and subsequent failings of the neophyte in an environment where time is software and software is money. I also appreciated that, aside from the intrinsic nature of possessing the technical skills, the authors made sure to mention that the need to develop these skills is also for the extrinsic value of passing human resource applicant filters and “managers who construct teams by playing buzzword bingo”.

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.

Breaking Out the White Belt (Disambiguation)

As someone who has been a caddy, industrial mechanic, butcher’s assistant, retail manager, letter carrier, web development intern, substitute teacher, and referee over the course of my life, it’s safe to say that I’m no stranger to breaking out the white belt. The chapter sets up the scenario wherein you’re a competent programmer with a narrower-than-desired field of knowledge and although your competency allows you to feel confident in your day-to-day operations, this coziness with your language or technology stack has limited your ability to wrestle with the novel in a meaningful way. The suggested solution is to embrace the unknown and throw away your preconceived notions about what it means to program or write software, actively avoiding the temptation to relate your previous world to the task at hand. The authors call this mindful approach to limiting context “maintaining a not knowing stance”, an ethos that I would argue is truly the heart of science and fundamental for discovering something new. The case here is that we (the readers) are software developers and the personal discovery is the new world of idioms, approaches, and paradigms that we will hopefully be able to synthesize and, upon achieving contextual competence, apply.

The pattern certainly confirms to me what I already know; being humble is an evergreen approach to learning, however the authors chart territory that I do not know in the chapter and that is the premise given at the outset where one hits a level of competence and plateaus there. I’ve not really been able to wrestle with any technology stack or programming language long enough where I feel competent or fluent to meaningfully contribute, let alone act as a guiding beacon for peers. While I may not be ready now to apply what I’ve learned in the pattern, if I imagined myself a competent C++ developer accustomed to the object-oriented programming paradigm, I would then make an attempt to learn a declarative paradigm, perhaps functional programming. Ultimately one’s next foray in software development will tend towards whatever is productive for their endeavors, occupational or personal and should likely reflect the adage of “picking the right tool for the job”.

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.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

While there were certainly many important concepts presented in the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman and the subsequent chapter introductions, I felt that the increasing level of conceptual involvement made the earliest sections far more fruitful in regards to spurring introspection. It cannot be overstated how well the logical flow of concept presentation is and how the breakdown into sections (Context, Problem, Solution, and Action) allows the reader to take the somewhat abstract elegant concepts and ground them in personal and actionable terms.

An example of how this played out: as I read the introduction to Chapter 2 – Emptying the Cup – I found myself having just digested a well-crafted opening but somewhat hazy about how the previous material would be of substantial use to me. To my pleasant surprise the authors had anticipated this and conveniently delivered me a whole section titled, “Context”. The section read:

“You are just starting out and have only a shallow understanding of how one or two programming languages.”

Indeed, it was so! The “Problem” section then provided what occupational or educational stumbling block I may be facing, followed by a tremendous helping of sagely advice to overcome the aforementioned problem, peppered with technical examples and some relatable anecdotes from the authors themselves. It concluded with a section appropriately titled. “Action,” which provided the hard-hitting actionable steps that, deep down, every person facing a self-improvement regimen knows will create an amount of existential friction surpassed only by its constructive value. Due to all of the above I found myself absolutely loving this book and can imagine it becoming a staple source of wisdom and motivation to come.

Speaking of existential friction, my favorite quote from the assigned reading was actually not in the assigned content but rather the “Audience” section before it. The quote reads, “[E]ven people with a decade or more of experience—particularly those who may be struggling to navigate their careers—will find inspiration and perspective to counter the siren call of promotion to management,” spoke to me because at my last job I spent many a night fighting with inept management only to open my phone on my lunch break and gaze in despair at my Quora feed littered with horror stories of talented principal engineers being given the axe because they had become too expensive to employ, wondering if they should have relinquished their craft and made the jump to management instead. For full disclosure this not some Marxist indictment of the labor aristocracy; I have been both the employee and the manager in my life and may one day find myself on the managerial side of the coin because I genuinely do believe that I am a strong mediator and leader. But the introverted tinkerer within me grasps firmly at any notion that it is possible to succeed largely based on the merit of my toiling and not the bureaucracy of corporate telephone; if this book is to be believed then it seems the inner tinkerer may have a leg to stand on.

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.

Finishing Up The Patterns

The final pattern I will be writing about from Apprenticeship Patterns is “Retreat into Competence”.

The “Retreat into Competence” pattern describes how to solve the problem of when you begin having issues as you start working outside of areas you are comfortable in.

I like the ambiguity of the opening quote by Robert Pirsig, I find that it is comforting while being vague at the same time. I agree with the quote about not knowing where I currently am but what I’ve done so far seems to make sense to me. I like the idea and I think I need to think more about what I’ve done so far as a computer science student to find what my “pattern” is so I can use the advice Pirsig seems to suggest and apply my own “pattern” going forward.

The topic that the pattern covers is something that makes me think about what I’ve learned as a computer science student as I am reaching the conclusion of my work for the major. In particular, it makes me think back to a conversation I had with Dr. Wurst and especially when he mentioned the fears of not knowing enough as I approach graduation.

I particularly connect to the idea that the pattern mentions of a deadline problem. The deadline problem was something that I thought would happen on Monday with my work on the UpdateGuest project and I wasn’t completely sure if our group (and I) would be able to finish our project before our review meeting. Additionally, I was having a hard time figuring out how Angular worked towards the end as I was trying to finish the issues I needed to for the project to be done. I got past the problem though with the help of my teammates and one awesome article my teammate found which helped us to get our Angular form implementation working.

I think the advice offered in the pattern is important and I agree that it is good to occasionally remind yourself of what you’ve learned and what you can already do, especially when you can’t solve a problem you are working on.

I found the “Retreat into Competence” pattern to be a fitting final pattern to write about as I finish up my work in the software development capstone course and as a computer science student. I am making it a goal to finish the rest of the patterns in the Apprenticeship Patterns book over the summer as I have found the advice to be helpful and I am curious about the remaining patterns as they are frequently mentioned in the current and previous patterns I have read.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Improving as a Developer

Today’s first pattern in Apprenticeship Patterns is “The Deep End”.

“The Deep End” pattern describes how to avoid getting stuck at the same level of being a developer and how to take risks to improve yourself.

As far as the “Context” area of the pattern goes, luckily, I don’t think I’m in a “rut” right now. Currently I’m still learning about lots of new things and tools at the same time and although I would like to make more progress, I think I’m still moving forward.

The “Problem” section makes more sense to me than the “Context” area and I agree, and I would still like to improve my knowledge and keep on learning about the tools I am currently working with. I agree with wanting to have additional projects I have worked on for when I apply for a job and I would like to have these shown on my GitLab account.

I think the part of the “Solution” for the pattern that describes “Waiting until you’re ready” is one of the most relatable parts of any of the patterns so far. I agree with that statement and I feel like I should just start learning new tools or adding work to a project instead of continuously waiting until I really feel like doing it. I feel that I should schedule regular times for learning or working on implementations to help avoid the problem of not feeling ready.

The example provided with Enrique’s email is especially impressive. I don’t think I’m quite ready to do something like Enrique did, however I do think that the email illustrates the success that following the pattern can get you and that there was a lot of value in including it.

Answering the “Action” questions I think the largest project I’ve worked on as far as team size goes is with my current work on the UpdateGuest project. As far as size goes, I think my own personal project might have the most amount of code (although the size may be tied close with UpdateGuest). I think the idea of different project “metrics” is interesting and I think some other useful ones could be total time spent working on a project and how automated the project is as far as CI/CD goes.

I think that the pattern offers valuable advice, especially with avoiding a “rut” and I would especially like to think of more and keep track of the different project “metrics” as I continue to work on old and new projects.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Final Sprint Retrospective

Yesterday was the last sprint review for the semester and the conclusion of my work on the UpdateGuest project (at least as required for my software development capstone course).

During this sprint our team worked on putting the whole UpdateGuest service together.

This sprint I helped to review many of the merge requests associated with my teammates branches and I worked on both making decisions and helping implement the Angular form for our frontend.

Specific issues I worked on this sprint are:

I think our team did a really good job this sprint. As Dr. Wurst commented yesterday, our team did really well this sprint with communicating and looking back at the different issues and merge requests from this sprint, I completely agree. Additionally, I was very impressed and excited about the work we accomplished during Sunday when the team met on Discord and worked together to rapidly implement, review, and merge different features.

I think that some things could have gone better too for our team. This includes improving when we work on our issues and working on issues ahead of deadlines, along with having everyone on the team working on reviewing merge requests.

There are a few areas I think I could improve on personally. This includes improved time management and keeping track of overall project progress. This was almost a problem for our team as we had a very last-minute meeting the day before our sprint review to finish our implementation of the frontend and make it work with the backend. I take responsibility for this and I should have setup a meeting to work on this much earlier than Sunday morning, especially as this was suggested by my teammates earlier in the week. Another area I want to improve on is consistently working on issues. This sprint there was a week where I didn’t do any of the work I needed to do for the project and that undoubtedly didn’t help, along with also waiting too long to work on issues. Finally, another issue I would like to improve on is finding a balance between reviewing others’ work and working on my own implementations. This sprint in particular I found that I spent a lot of time reviewing and learning about my teammates work. While I do think this was helpful and led to more refined code getting merged, I think it led to me spending much less time on my own implementations, which I am not as happy about.

Some of the areas I think our team could improve on if we were to continue working together largely relate to some of the issues I could personally improve on. I think both personally and as a team we could further improve on our ability to refine issues and improve on how we estimate the weights for issues. This problem specifically occurred with the implementation of the Angular form where I think it took a lot more time and had more issues than we originally anticipated. Additionally, I think our team could improve on keeping track of overall project progress for meeting deadlines and maybe work towards setting estimated deadlines in all issues with times and dates for issues to be completed. Again, this would help to avoid a last-minute meeting where a lot of work needs to be done in a single day to finish features (or the project). Finally, I think that everyone in our team could work on reviewing more merge requests so that this work is more evenly split and gives others (including me) time to work on their own features.

Overall, I am very happy with the progress our team made during this final sprint and I am especially impressed with how everyone worked together Sunday to finish all of the features we needed for this project to be in a good and working state.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.