Apprenticeship Patterns: Unleash Your Enthusiasm

I thought this section of Apprenticeship Patterns presented a fascinating take on how newcomers might fit in with their more experienced counter parts when entering the professional world of computer science. The authors describe the role an “apprentice” might want to take when working in a team of seasoned computer scientists. They explain that it is common place for newcomers to “fly under the radar” and not speak their ideas due to lack confidence in their ability to be a contributing team member. They point out that while every team may differ, teams typically benefit from having team members of varying skill levels, even “apprentices.” The authors also cite a study involving aircraft carrier crews that showed that it is healthier for teams to consist of people with different degrees of skill and experience and found that newcomers played an integral role in the team dynamic. Finally, the authors propose that newcomers should in fact “unleash their enthusiasm” in hopes that their excitement will rub off on other team members as well as keep other team members on their toes through asking many questions on why things are the way they are as well as presenting fresh ideas.

I honestly found this particular pattern to be extremely relatable as I am currently a newcomer in a security team that is made of individuals who have varying degrees of skill level, experience, and expertise.  When I first started, I admit that I was a little intimidated by all the tools that were being used not to mention all the acronyms being thrown around in meetings that I had never heard of before. However, I feel like that feeling of being overwhelmed pushed me to want to learn more about security and obtain the same kind of knowledge possessed by my coworkers while at the same time applying the knowledge I have acquired throughout the course of my college career. I also feel like I really lucked out because of the willingness of each of my team members to answer my questions and give me advise. After reading this pattern I think I will ask questions and speak up more confidently at work because now I know that it is important to bring a fresh perspective to a team.

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

Whoops, I Picked the Wrong Theme

After spending many hours attempting to accomplish what I thought would be a relatively simple task, I decided to change the theme of the the Massachusetts HOSA website. Although my post last week went into detail about the many reasons that I originally chose to use the Trusted theme, there was one problem that became obvious to me as I attempted to adjust the size of the image slider the displayed on the homepage of the theme. While I expected these kinds of edits to be as simple as adjusting the size of a div container, it turned out that the theme used more complex embedded functions and jQuery to make the theme responsive. This responsive nature made it difficult to edit the size of the image slider and set it to a smaller, constant size.

It was around this time that I began to question whether or not it was worth my time to continue debugging and teaching myself how the Trusted theme set up the slider. I decided to instead look for a similar theme that may be easier to edit. I found the Consulting theme and found the slider to be much easier to edit. I was able to set the maximum width for the slider at 700px while still allowing dynamic resizing for responsiveness and support for mobile devices. Unfortunately, this nullified all of the changes that I had made to the Trusted CSS files that brought the site into compliance with the HOSA style guidelines. I did, however, discover a far more efficient way to edit the Consulting theme that I kicked myself for not thinking of earlier. First, I used Chrome’s Developer Tools to find the color code that I wanted to change. I then used the “Replace All” tool in TextMate to change all occurrences of the that color code with the desired color. Overall, the second time around for customizing the theme was far smoother and more efficient than the first.

From the blog CS@Worcester – ~/GeorgeMatthew/etc by gmatthew and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Stay in the Trenches

Most people view promotions as a good thing. It means you are moving up in the world. More importantly, it means that your peers and managers feel you are doing a great job. It is always a great feeling to get reassurance that you are good at what you do. Not to mention that promotions often come with a raise. However, in the eyes of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye a promotion isn’t necessarily a good thing…

The pattern Stay in the Trenches discussed in Apprenticeship Patterns isn’t about finding the quickest way to the top of the ladder. It focuses more on becoming an expert at your craft [AP]. Promotions often mean you are one step closer to management or are going to be in management, which also means that you are one step further removed from development [AP]. Now, not everyone wants to be a lifetime developer. I certainly don’t know if want to be. But for those who do want to truly master the craft of software development, then a promotion isn’t necessarily a good thing.

If you choose to not accept/avoid promotions, there are some other ways to be rewarded/compensated [AP]. They suggest finding a company that is flexible in allowing you to stay on as a developer [AP]. Perhaps you can find technical leadership roles such as a lead engineer [AP]. By taking on this type of role it may allow you to still receive a raise if that is what you are looking for, so it can be the best of both worlds. However, some may not even want to take on a role like this as it is an additional burden that can take you away from your work.

Personally, I feel this strategy is easier said than done. If you are good at what you do, promotions are going to come. If you turn down too many of them you’ll more than likely be looked down upon. Even if the company is ok with you staying in your current role, at the very least you are going to take on more responsibilities. Often times those responsibilities aren’t strictly development related so they will pull you away from what you want to truly do. Now I’m not saying adhering to this strategy can’t be done. What I am saying that following this strategy to a tee is something I feel would be challenging to do. The more experience you have, the more “jobs” you are going to be asked to take on whether you intend to or not. If you want to follow this strategy and can actually pull it off, then more power to you.


Link to pattern in book:


From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Thoughts on “Confront Your Ignorance” apprenticeship pattern

This pattern seeks to solve the problem of skill gaps that are making daily work more challenging.  The authors propose that software apprentices suffering from this issue attempt to actively learn the missing pieces.  This could take different forms — they suggest reading tutorials/FAQs, constructing small low-stakes projects, and/or involving other people that are either experts in the area or trying to learn the same thing.  They also suggest keeping a list of these skill gap areas, and crossing them off as they’re sufficiently learned; this goes hand-in-hand with adding to the list as your learning exposes additional gaps.

This approach to learning really resonates with me.  My preference is to actively seek out knowledge, and I tend to learn best through hands-on practice.  I’ve already used a less formalized version of this when I taught myself Python: find a skill (in this case, a programming language) that I would like to learn and then give myself a project to work on that forces me to learn and use it.  There are three major additions (on top of the formalization) that I can take away from this pattern:

  1. Involve other people, whether they are experts or fellow learners.
  2. Don’t overuse this pattern to the point where it causes problems for others; I only have so much time.
  3. Balance learning with introspection.

The first point leads to the creation of a learning community, and extends both the resources and benefits of learning.  I know that I have a tendency to want to do everything myself, and while independence isn’t bad it’s also important to not always be reinventing the wheel.  I also enjoy sharing my knowledge, and it makes sense for me to seek that out in a more mutual way.

The second point is also something I run into often, and partially extends from the first.  I really like to build things from scratch and see how they’re made.  However, that tendency can also lead to excessive use of time and energy for what should be a simpler project, or the preference for my own solution over another (quite possibly better) one that’s already been written and vetted.

The third point encourages me to set up a cycle of learning and introspection; crossing items off of the list and then adding more to the bottom.

While actual checklists are not a tool I particularly enjoy using, this pattern has leaned me towards perhaps keeping one (and actually updating it).  That, I think, is where I’ve found the most value in Confront Your Ignorance.

From the blog CS@Worcester – orscsblog by orscsblog and used with permission of the author. All other rights reserved by the author.

Sprint 1

Team Retrospective – Sprint 1


I think this was a very important sprint because it introduced me to my teammates and it also showed me a little bit of what I can expect from my team during this project. During this sprint, we were to learn about angular tests and how to implement them, clone the project that was to be worked on, run the project and ensure that it built successfully and also make sure we were able to log into the program and kind of get a feel for the program’s UI ( User interface). Most of these tasks were accomplished and throughout the process, I was able to learn a bit more about my team. There were a few that reached out to us when we had issues and others even stepped up sent group messages text messages to ensure we were on track and slack messages when they came up with solutions and answers we didn’t have. Also I made sure to emphasize on creating a good working environment and a relaxed atmosphere for every one to feel comfortable and casual. I accomplished this by starting conversations and asking how everyone was doing whenever we had team meetings. Overall, I think we have a really good group and can get a lot accomplished this year because although there is some room for improvement, we already have pretty good team communication. As for actual work that was done, I think there was a very steep learning curve that had to be covered. I remember in previous classes, we did projects with angular and typescript but the tasks that were completed didn’t go into details as much as this project does. I think one of the issues that stands out the most is all the issues I had with the various angular dependencies. But luckily, one of our teammates was pretty comfortable with angular and was able to offer help when i needed. There were times we contemplated building the project on one system and making sure it was running there, then we were going to clone it into our team’s repository and get everyone to pull from that repository. This we hope was going to eliminate most of the error but we were wrong and after many research, we figured doing it independently on each machine would expose us all to many things that would be helpful to know. It would also add to our already limited angular knowledge.  Overall, it was a good sprint and I think most of what we set out to do was accomplished and I know lot more angular that I did a few weeks ago. Looking forward to the year!

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1


For this sprint retrospective there isn’t much to talk about because we were just going over the basics of how we are going to work together and setting up the server for our team to work on. During the sprint meeting we talked about the little things that we would like to change. Such as how we can change how our trello board works such as we put up all of the things we need to do and then put our names on the corresponding things we had done and did. Next, we talked about how we are going to push any of the code that we will be doing ourselves onto the git hub and when we should do it. We all decided to push it whenever we meet at least for now since we are still getting to know how each other works as a team. Finally, we went onto the google doc at the end of the meeting and just talked a reviewed the stories for ng-amrs. Just trying to keep ourselves ahead of the curve and started talking about how we can do this project. Throughout the week I just worked on the assignment leading up to setting up the server and getting to know my team more. Some of the things that did help me out throughout the sprints are the slack board and my teammates. For now I don’t see any issues working  with my team they are all great people and we are testing the waters of how we should be coordinating how we work and what we should do.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective – 14 February 2018

Over the past two weeks, I experienced my first sprint with my fellow teammates. Although it was introductory in nature (as were the tasks we actually completed), I feel that it gave me a solid understanding of what to expect in the upcoming months, and in my eventual career.

The first sprint consisted almost entirely of setup tasks; each member of the team installed Webstorm, connected to AMPATH’s test server, familiarized ourselves with JIRA, set up a Trello board, among several other things. The bulk of our communication throughout each of these tasks consisted of troubleshooting, particularly when trying to get the ng-amrs build working properly on our machines. There were a few different fixes we came to, but in general, it seemed that each of us was having the issue of a file not being found. We each worked out with each other how to find that specific file, and the build worked fine once we’d each done so. As a result of the fact that we each found different methods of resolution to this, however, we have also agreed as a group that we should exclude these files (which, thankfully, were only styles) from our commits to the project.

A teammate and I each forgot to submit responses for one of the scheduled standup meetings. Fortunately, the reason for this was that it had been such an insignificant period of time due to the prior completion of tasks, and nothing of value was left out of any report.

In future sprints, I believe that the familiarity that this preliminary sprint provided our team as a whole will serve us well. Having already discussed the user stories provided by AMPATH with the others, I am excited to get to work on this application. For me, and for the other members of the group to my knowledge, this is the first product I’ll be putting into the real world. Although the idea of this being my first work to have real consequence is daunting, I believe that we as a team will be able to deliver not only a satisfactory final product, but one which exceeds expectation. If we can keep up the kind of groove we had going for these two weeks, it might even be a smooth project – imagine that.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.