Author Archives: Shane Rookey

Apprenticeship Patterns – Find Mentors

This is probably the most important pattern I have checked out in the book by Dave Hoover and Adewale Oshineye. The entire pattern is about finding a mentor/master that helps you walk “The Long Road” with more ease. Allowing you to grow and cultivate your skills into tools that will be used for the rest of your life. The authors make sure to note that since our profession is still relatively young, there aren’t many recognized “masters” of the art. However, your masters don’t have to be physically available to you at all times. Maybe you read a book about someone’s life who really interested you and you begin to develop a passion for the things the author enjoyed, that author will be your master regardless of whether you talked to them or not. They may even be deceased!

The authors go on to emphasize that just because you are the apprentice and your master is the master, doesn’t mean that they are the one and all-knowing god of coding.  No one knows everything. Be free to opportunities and don’t only talk to your master, learn from other masters and expand your mind with knowledge. Lastly, this chapter reassures you that there is no real risk to looking for mentors. While it may be difficult, the payoff would be huge for you. The only risk is getting rejected, which really is not that big of a deal. Most top-notch developers had memorable mentors to help them along the way.

This pattern will certainly affect how I go about things in the future. I had never really thought about going up to someone and asking to be their apprentice or “assistant” but I could actually see it working. I could see someone at a new job being a mentor to me but I could also see myself going to volunteer on a separate project outside of work just to get extra practice and that sense of apprenticeship. I really enjoy the thought of having a mentor, so that may be one of my next steps.

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

Sprint Retrospective 5

This sprint was not a complete success. We wanted to have some code pushed and maybe make a pull request to AMpath. However, our progress was delayed due to our inexperience in writing angular 2 methods and testing them effectively. I learned that testing code in a language you haven’t studied can be exceptionally difficult to grasp. I am still trying to work out the uses for toBe(), toThrowError(), toEqual(), and how the expect works in the test suite. Writing the method for the code seemed easy enough and I think I have the correct code, however it is hard to confirm when testing isn’t going smoothly. I understand that writing tests first would have been the correct way to do this, but I can’t write tests for code that I don’t know how to write. Therefore, I had to learn how the code worked and look at the API for pouchDB (which you can find here to ensure that I was using the correct calls and what-not. If I could restart this sprint, I would spend much more time on learning how to test in angular (sense that is the most frustrating part to me) rather than writing the code. At first, I was coding a method that was too complex, with the help of google I was able to finish my updateDoc method (as far as I know).

Our team is working well together, I think we could do a little bit better helping each other remember to do our standups and evaluations. Besides that we work really well together. I think we are all contributing equally to the project, so there is no problem there. As a team we feel as though we could have gotten this sprint completely finished in the allotted time if we had prior knowledge of testing in angular. However, it is what it is. Our next sprint will most likely focus around testing the methods we have created and tweak them to try to perfect them.

Our sprint plan was to finish this module, obviously that didn’t happen. Each of us was responsible for writing a method and Connor was responsible for testing. I wouldn’t blame Connor for the tests not being done because he still has to learn the testing procedures for angular as well and if he has to write a test for each of our methods, that is bound to take some time. So each of us has been pitching in and trying to debug together. This means that our sprint goal will most likely be extended to next sprint as this really is the last step to finishing off the Offline Storage Module.

I am interested to see what will happen when we (our entire class) conglomerates the code and tries to piece it together. I can imagine that some snags will occur and it won’t be very smooth at all. We will have to assign different people to test different parts of the entire offline module to ensure that everything is compatible with each other.


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

Apprenticeship Patterns: Nurture Your Passion

I chose this pattern this week because I really need to work on growing my passion for the craft. I need to sit down and find something I love and make a correlation to software. This pattern taught me different ways to nurture and grow your passion so that you can dive deep into complicated projects, for fun. The authors mention 3 other patterns to help you grow your passion. These other patterns are Kindred Spirits, Study The Classics and Draw your own map. These three patterns will help you take the next step to loving the software craftsmanship.

My favorite excerpt form this passage was:

“To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This might mean you leave work while the rest of the team stays late, that you walk out of a meeting that has become abusive, that you steer a cynical conversation toward constructive topics, or that you refuse to distribute code that doesn’t meet your minimum standards. The result could be that you get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong.” – Adewale Oshineye, Dave Hoover

Basically, the authors are saying to stick to your code and don’t let yourself be abused. If you or your skills are being abused in the work place, it can greatly damage your passion for working on software. You want to stay positive and continue to love what you’re doing, it is the only way to cease your passion from leaving.

As I mentioned before, this pattern is important to me because I need to work on finding my passion. It isn’t always easy to sit down and work on a fun project just for the hell of it, but this pattern shows me that it truly is invaluable. All you need is time and patience to further your knowledge and skills of the craft. Developing a passion is something that I have been trying to do with school projects and what not but it needs to be more. Being passionate about a project would just be a kickstarter to become passionate for every step of software development.


You can find this pattern here:

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

Sprint Retrospective Blog 4

Our team, Everyone Else is making good progress with our first module. Sense we are solely tasked with creating the offline data storage module, we had to narrow our view. We had been worrying too much about how the other modules would work with ours and didn’t focus much on just creating the offline storage module. After our meeting today, we could tell we were more focused on our task and our task only. Connor created a flowchart on Balsamiq showing the flow of the data and where we stand in the whole project. Basically we just need to create the place to store data with appropriate methods and let the other groups do their legwork. I noticed myself going to ask questions to the team that really had no relevance in our current progress of the project. Instead of focusing on getting ANY items stored, we were worried about storing the CORRECT data. Realistically, we just needed to do tests with any JSON Object to ensure that it would work. That is what we are focused on now, getting our module working and worrying about the perfection later.

This sprint was a real confident booster for me. I finally sorted out all of my issues with the application. In case you find yourself in a situation where your app won’t  build properly, I highly suggest trying “npm rebuild” in your project folder.  This reloaded all of the dependencies I had previously installed and ended up working after the first try, even with pouchDB installed!  I still feel slightly behind on knowledge, but working with my team I am learning more every day. I think if we had previous experience with this language, we would have a much easier time with it. However, for our team never working with angular before, I think we are making very good progress.

I am now in a position where I feel comfortable adding to and testing the project. The angular learning curve is steeper than I had expected but I am slowly making progress with it. I would be lost without my teammates. They helped me figure out the errors and save my project file. While I was struggling getting my code to run, the team had already taken a couple of leaps forward. We created the actual service and have a basic test implemented. We officially moved out of the research phase and are getting into the production of code. We each have our own method we need to implement by next meeting and I feel as though our progress will speed up tenfold.

I am in charge of creating the “put” method for our database so that we can easily add information into the database that we created.  Caleb, Fuverion, and Ben will be writing the other methods. Connor will be doing the majority of the testing. With the tasks broken down into different jobs we should be able to efficiently finish this module pretty quickly and show it to AMPath for improvement.

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

Apprenticeship Patterns – Dig Deeper

This pattern relates to my situation almost perfectly. The authors assume that you are an undergraduate who has knowledge of one or more languages. However, the way we learn to use tools is not always the best way to get a deep knowledge of the tools we are using. The authors say that this knowledge is superficial. It is superficial because you have to look up what to do every time a new bug arises. This line sums it up pretty well, “what’s even worse is that because your knowledge is so superficial, you’re not even aware of how little you know until something or someone puts you to the test.” (Oshineye, Hoover)

I am a little different than the people they are directing this pattern to because I am aware of how little I know in the grand scheme of things. Besides that, the solution to this problem is not cutting corners. Don’t take those shortcuts that will help you finish the project 15 minutes quicker, learn to grind through the hard work and come out with the rewards of Deep Knowledge of tools, technologies, and techniques. I have spent a lot of time being frustrated with my own programs and this pattern helps open my eyes to how many shortcuts I must have taken. To truly understand everything about what your working on you need to develop the deep knowledge and the work ethic needed to get there.

My favorite part of this pattern was some of the advice the authors give. “Find out who first came up with the ideas and understand the problems they were trying to solve.” (Oshineye, Hoover) This has never really crossed my mind (I know, sad). I never thought to go all the way back to the origins of the problem. This will definitely be useful to me in the future. Another piece of advice that I always fail to follow is “when you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge.” (Oshineye, Hoover) I find that sometimes when on a time schedule or you are picking certain things from a tutorial, you feel like you don’t have time to fully go through tutorials and learn everything about the guide. While sometimes this is true, it’s more than likely an excuse to get the project done quicker. I will be diving more into tutorials rather than taking them at face value for their code.

Overall, I think this pattern is great for apprentices. It goes to show that many people take shortcuts and if you do the same, you aren’t building your knowledge the way you should.

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

Apprenticeship Patterns – Concrete Skills

One day you will find yourself at an interview with a software company for a programming position. You need to show the employer that you won’t be a wast of their time and that you can be useful on day one. In order to do this you must have a set of Concrete Skills to do basic tasks that the team needs to get done. You must sharpen and hone your concrete skills and prove to them that you can be helpful on day one.  Oshineye and Hoover say, “examples of concrete skills include writing build files in various popular languages, knowledge of various popular open source frameworks like Hibernate and Struts, basic web design, JavaScript, and the standard libraries in your language of choice.” They also go on to tell you that having a deep understanding of your first language will help you accomplish these concrete skills. Once you have your concrete skills, you can work on learning your way to a journeyman.

How do you grow your concrete skills? The authors suggest looking over the CVs of the people you look up to or the people who know the skills you want to learn. Jot down their skillset and work towards learning them. This way, you are learning relevant information and working towards helping the company. The authors also stress going through your own CV regularly and updating it.

I really liked this pattern because it is directly related to my situation. I feel as though an employer will have to take “a leap of faith” (as the authors say) and hire me relying on my concrete skills to at least help a little bit on the first day. I need to sharpen and hone my concrete skills so that I have something to show my future employer. I will especially be practicing making toy programs that I can bring to an interview to show off my skillset.

What skills do you need? Looking at the CVs of employees that are already working at the company would be a good start to generate ideas.

One thing to think about is that each company is a little bit different, they didn’t mention this in the pattern, but I think it would be useful. Having these concrete skills especially helps in small startups that need the workforce actually working all the time. On the other hand, most BIG companies take your skill set and begin to work on it with professional training. If you feel as though you need to build up a resume, training through a big employer will certainly help more than being confused on a startup team that doesn’t have time to train you.



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

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.

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