Apprenticeship Pattern – Breakable Toys

The pattern “Breakable Toys” can be found here:

This pattern is a little longer than some of the other patterns I have looked over. Long story short, Breakable Toys is a pattern designed to help you learn. Kind of like Be the Worst but is more focused on you as an individual. The problem is that you are working in a company that can’t afford errors to destroy their data/program/whatever (who can afford that?).  However, the other half of the problem is that you are just learning this stuff and need a safe space to practice. You should create your own safe space project that relates to the problem you need to solve in the company, just at a smaller scale. This pattern tells you you need to build these breakable toys from the ground up to learn the insides and outs. Once you have these breakable toys, they are yours forever to use with other jobs and problems.

I thought this pattern was very useful. I was always told that if I want to learn, I have to do. That’s what this pattern is saying. You have to take the initiative and build these projects in order to learn. The best part is, failing only harms your breakable toy, which you built specifically to be broken!

The first line says “If experience is built upon failure as much as success, then you need a more or less private space where you can seek out failure.” (Oshineye, Hoover) I love this first line because it tells you that failure really is okay. That is how you learn. Being successful on the first try only teaches you what works for this situation but not for others. If you fail, you can learn a whole bunch about what doesn’t work and what does work. I don’t think you should intentionally fail, but failing will help you improve your skills and knowledge (so don’t feel too bad). The most important part about failing is getting back up and trying another approach. I could definitely see myself using this in my intended profession. I get worried all the time about breaking things that are important and this pattern gives you a way around that.


Sprint Retrospective Blog 3

This sprint was particularly rough. Every time we were planned to meet, we had a snow day. Communication was lacking at this time because some people lost power and we definitely couldn’t go drive. Not meeting up with the team left me unmotivated because I had questions and errors that I would of benefited from asking the team questions in person. My team is working really well together. We are all included in a group chat where we remind each other of standups, CATMEs, and tasks we need to get done. We communicate often over texting. I learned that communication is key, especially in person. The reason why in-person meetings are important is because it raises the morale of the team and reassures the team that we are making progress. Now that I know this, in person meetings are much more valuable to me.

I will be honest and say I feel a little bit behind after this retrospective. I am not picking up this new framework as quickly as the rest of my team, but I am trying to get to the point they are at in their knowledge. What is great is that my team will share anything with the group that they think is useful. Caleb was able to get a working implementation of PouchDB into the Ampath App which is an excellent start to our task. Once we were all together we tried to store some data and it worked! It wasn’t exactly what we were looking for, yet, but we are just trying to understand how the PouchDB database works. I think our team has been taking the right steps to getting this project done, I am just frustrated that it is only my computer that the errors can’t be resolved. I could of definitely put more time into getting this to compile and I am working on doing that now. I will be proceeding differently by being proactive and on top of tasks. I don’tlike feeling behind, so I am going to correct that from now on.

The reason I feel behind is because of the struggles I am going through to get the dependencies to install correctly. I have tried every method that team members suggest but to no avail. I have tried installing pouchDB first, then all of the other dependencies our project needs. That made the webpack fail to compile. Next I installed all of the original dependencies, ran npm install, then tried to install the pouchDB dependency into the project and the webpack failed to compile again. I have tried almost every combination of these installs and they all made the webpack fail to compile. I became sick of the errors. I cloned Caleb’s directory into a new folder and copied all of his files into my existing project. I then reinstalled all the dependencies into the project and ran it, it worked perfect (without pouchDB), as soon as I installed pouchDB I got a slew of errors. It’s like the pouchDB dependency is removing some of the packages that  I still need and I am working on how to prevent that.

Sweep the Floor – Apprenticeship Pattern

Sweeping the Floor is a saying for doing the dirty work that no one else wants to do. This pattern highlights what you can do to stand out as the new guy on the team and make yourself valuable to them. This pattern was an excellent read, you can read it yourself here:

The pattern makes it obvious, almost every team has a job that no one WANTS to do. I have seen this at my own jobs. Things like cleaning, writing well thought-out documentation,  and even answering the phone are some of the small tasks that people would rather not do. Step in and volunteer to do those tasks. This will enable you to gain trust and socialize with the team so you can get your foot in the door. The authors go on to talk about how there are some negatives to sweeping the floor. However, In my opinion they are all avoidable. These negatives would be getting stuck as the teams scrub (someone who they make do all the menial tasks and never ask more of), or you will be too intimidated to try and step out of your comfort zone. Both of these are avoidable by being more assertive once you’ve gained trust and a place on the team.

I really enjoyed this pattern because it will be extremely relevant to me in the upcoming future. I am applying to (what feels like) hundreds of jobs to try and join a team when I graduate. I know I will have to prove myself and this pattern has given me a way to do it. Take pride in the small jobs and do them well, this will help you make a stand in your team. The only thing about this pattern I didn’t like was the fact that they added consequences to it. I feel like that really brought down the overall inspiration of the pattern. The consequences weren’t on my mind when I was reading the pattern until, of course, I read that part. They should have stressed that you need to be confident in your abilities to learn and continue to try and climb the totem pole.

Overall, the pattern is an excellent inspirational read for someone who just joined a team and are looking to prove themselves. I can certainly see myself doing this in my future jobs.


Sprint Retrospective 2

On Thursday February 15th, Everyone Else (our team) sat down together to talk about what we would be going over for this sprint. We came up with a plan for this sprint to be our research and designing sprint We wanted to figure out what options we had available to us and what kind of design we were expected to create. We didn’t really get too much physical work done that affects our goal to the actual project, however I did get a chance to learn about some things that I hadn’t studied before.

To start, we had a slack message from our friends at AMPath who suggested we looked into PouchDB. PouchDB is an open-source JavaScript database inspired by Apache that is designed to run quickly within the browser. This is exactly the type of thing that we were looking for. Since our overall goal for the class is to be able to have the ability of an “Offline” mode for the medical records app from Ampath, PouchDB would be the perfect way to store data and then sync with the server once you are connected to the internet.

I followed the guide on their website to get the feel of the tool and be able to implement it into code that is already written. You can find the tutorial here:

The first step I had to take to be able to go through the getting started guide was downloading python from . This guide used a python Simple HTTP Server to get the application running but I am sure that it can be implemented into the AMPath application anyways. After installing python (and PouchDB), I downloaded and unzipped the files that setup your “todo list” application (with missing features that you add yourself.) This tutorial helped me figure out how to create a database, write information to the database, show data from the database and manage a user interface. The last step in the tutorial shows you how to set up a two way sync with CouchDB which is the server tool used for this tutorial.

Another resource i used to get more familiar with the framework of Angular2 was Youtube. This video which is 1 hour and 18 minutes long really helped me work through the basics of the Angular2 framework and how to work with the three language (HTML, CSS, and Typescript) together.

In this video, the narrator has you go through steps to set up your own personal website using the Angular2 framework. While it isn’t progress to the actual goal of our sprint, it was an essential part of me understanding the languages and taking some steps to practice writing in the language we will be using for the project.

The team is doing well communicating our ideas. We set up a group chat over texting to remind each other of deadlines and to talk about our progress. Everyone is encouraging each other to get work done. One thing that I think we will be doing differently this week is putting time into the project code and working together more to write code and get some progress done. Since the planning phase is over, we can finally take some steps towards the true goal of this project, an offline module.

Our team has also already accepted the task of working on an offline data storage service, so the information I learned about PouchDB should be very useful in the coming sprints.

Apprenticeship Patterns – Be The Worst

Let’s start out this one with a hypothetical situation. You graduate college with a Computer Science degree. You walk the stage knowing that you have a job lined up. You are excited enthused and ready to learn some new things! Good!

Fast forward 3 years. You are now the person at the company that everyone asks questions and expects quality answers and advice from you. You feel like you have repeated the same thing for the last 6 months.  You have gotten into a routine of doing the same thing over and over and over AND OVER again. Long story short, you only have three years of experience and you have already maxed out your potential at this company.

This is the exact situation that Oshineye and Hoover try to help you overcome with their apprenticeship pattern “Be The Worst”. Obviously, this title is a little misleading but the solution is clear. You want to be the worst developer on a team. Not on purpose but naturally. You should look for a team with developers that are way more experienced than you. You will pick up their good habits and drop your bad ones. They will correct your mistake and teach you efficiently without you even knowing it. The authors have a great outlook on it : “Being in a strong team can make you feel as if you are performing better. The other members of that team will often prevent you from making mistakes, and help you recover from mistakes so smoothly that you won’t realize that you may not be learning as much as you think.” (Oshineye, Hoover)

I enjoyed this pattern because I feel as though I am going to be in that boat myself. I feel as though my first job will teach me a lot but I don’t want to get tied down to one job forever. This pattern actually made me feel very comfortable. For some reason, I had always thought that my first job out of college will be my last. I like the fact that it is acceptable and recommended to leave a job that you aren’t learning from. I like it because I am always trying to pick up new skills and I can’t wait to be fully emerged in the industry! With some experience under your belt, you can open yourself up to new options and jobs that you would have never thought you qualified for. This pattern will be invaluable to me in the future.

Sprint Retrospective Blog – First Sprint

My team’s name for this project is “Everyone Else”. Everyone Else consists of myself (Shane Rookey), Caleb Pruitt, Ben Lagasse, Fuverion Ymeri, and Connor Virzi. The first sprint went pretty smoothly and we learned that we were capable of working through errors and fixing them to get our application running.  We all had issues getting the app running. Most of those issues came from missing dependencies that were supposed to be installed but weren’t (for whatever reason).  After trying “npm install” a couple of times I figured that something happened to get installed wrong because I was getting different errors that no one else was getting.

Specifically, when trying to run npm install  in the ng2-amrs directory i was getting an error that said something along the lines of “Missing package Dezalgo” which was supposed to be installed when I installed all of the dependencies. What I did to fix this problem was erase the entire repository on my computer. I then cloned the repository from GitHub again and installed all of the dependencies AGAIN. Before running npm install, I deleted the package-lock.json file in ng2-amrs directory. Once deleted, I ran npm install and it worked like a charm. After npm install, I was able to run npm start and get the test server up and running.

One other thing I needed to get the test server working was a Google Chrome extension called “Allow-Control-Allow-Origin”. This was required by AMPath to connect to the test server.

You can find instructions for the extension here:

This entire process so far has been an excellent learning (and refreshing) opportunity. I have been familiar with GitHub before, but I have never been a part of a project that is a REAL thing (if you know what I mean). These people we are working with have a REAL business and we are trying to help people make their programs better. It is truly encouraging and fun. Working remotely with GitHub will be good experience for the working world because almost everyone uses version control of some kind.

I have also never worked with 4 other people at once on a single computer science project where we are all trying to work towards the same goal. Its inspiring to have a team and also motivational because you don’t want to let them down. Two people on my team missed a standup for the first sprint but I don’t hold it against them, It is difficult to remember that you need to do something every single day to reach your goal, even if that is just some planning and communicating. I think my team will truly step up and begin to shine once we delve into the more technical work.

Besides getting the test server up and running, we looked over the user stories to see what we were going to be dealing with. For each one we quickly brainstormed what each story might entail regardless of what task we ended up with. I am excitted to continue on with this process and get planning for the next sprint on Thursday.

Apprenticeship Patterns Blog: A Different Road

You can find more information about A Different Road pattern here:

This passage is very quick and to the point. The authors emphasize that you should continue to follow your own map. Even if this new map brings you into an adventure you have never thought about doing. The authors ask just one thing, bring all of the knowledge and processes you’ve learned with you. Being a software apprentice means that you can look at problems from different perspective and use the tools and knowledge around you to excel and progress further. This way of thinking is not only useful in software development, but everywhere else too.

My favorite part about this pattern is that the authors understand that sometimes life can be strange. I enjoyed the example “…Ivan Moore, Ade’s mentor since ThoughtWorks, he described how he went off to a Greek island for six months to become a windsurfing instructor after his first IT job.” (Oshineye, Hoover). I liked this because it was so obscure. Who stops developing software to teach windsurfing? Well that’s the point. Everyone has different values in rewards. Regardless of what you want, someone else may want something entirely different. Maybe that windsurfing job paid HALF as much, but maybe money wasn’t important to Ivan. Instead he wanted to reap the rewards from enjoying life on a Greek island, the experience and the fun. These rewards could have been more valuable to him and you can’t tell him he is wrong.

The authors also tell you that leaving the field for some time could be risky as most conventional software companies see the break as a suspicious gap in your career. However, the authors also let you know that this- shouldn’t be the case. New experiences can help widen the perspective of one’s view. Leading to better understanding, communication, and team work.


I could see this advice being extremely useful in my future. As of right now I want a job in the industry but I could see myself reaching out to different branches of technology. I have a passion and love for digital media and I am even interested in starting my own ecommerce store. I would be able to use everything I know about problem solving, critical thinking and programming to do the best I could in any other job or hobby i might have. Knowing that it is acceptable to explore your options and different opportunities makes me feel more ambitious.