Category Archives: CS448

The Final Sprint Retrospective

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

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

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

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

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

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

We must learn how to learn.

Learning is ongoing, continual, without end.

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

—Jim Highsmith, Agile Software Development Ecosystems

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

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

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

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

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

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

Retreat into Competence

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

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

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

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

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

Sweep The Floor

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

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

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

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

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

The Tortoise Always Wins

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

—George Leonard, Mastery

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

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

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

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

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

The tortoise always wins the race.

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

Sprint 2 Retrospective Blog Post

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

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

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

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

https://gitlab.com/nanuchi/techworld-js-docker-demo-app
When paired with their “Docker Tutorial For Beginners” has been an invaluable resource to teach myself Docker and use continuously as a reference.

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

Expose Your Ignorance

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

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

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

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

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

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

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.