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: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch04s05.html

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.

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

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.

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

You can find more information about A Different Road pattern here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s08.html

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.

At the end of the pattern the authors give you an action. All this is, is a suggestion on what to do if you are experiencing something like this problem in the pattern. The authors ask you to “write down some of the other jobs you think you would enjoy doing. Find people who are doing those jobs and loving it. Ask them what they love about it and compare that to the things you love about software development.” (Oshineye, Hoover)

At the end of the day, you should really be doing what you love and what rewards you, the best way you see fit.

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

Following this link will bring you to the apprenticeship pattern called “Expose Your Ignorance”: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch02s05.html

I really enjoyed this apprenticeship pattern because I have always been a strong believer in asking questions. That is what this pattern is about. Asking questions to people who have more experience, sharing the ideas you have and telling them when you do not completely understand.  I also enjoy the emphasis on exhibiting learning ability. I think that the most important part of working is improving yourself and never limiting yourself to the information you might learn.  Being open minded is important to learning. You always have to be looking for another way to solve a problem and work around obstacles. Without proactively learning you will fall behind in no time.

One thing in the pattern that really made me think about my process of learning was the paragraph that starts with “Expertise is a by-product of the long road we’re all on, but it is not the destination.” I never really thought about it that way. I always thought that expertise was my goal, but it doesn’t have to be. Going deeper into the passage, I think what they’re trying to say is that expertise is something earned int he process of learning. As long as you are capable of learning well, expertise will come to you in time naturally in something that is required or interests you.

One thing that I thought about while reading this pattern was “what about those people who hate questions?” In my opinion, I think that someone who gets irritated by (good) questions are close minded and don’t have much to offer. While they might have expertise they probably don’t have the skill to relay their information and therefore get frustrated.  Unfortunately, sometimes those are the only people you have for guidance and you may need to look elsewhere for extra help. Of course this pattern doesn’t take into account the person who you are asking question to and I didn’t expect it to, but it is something to think about.

This pattern has opened my eyes to the true learning process. Both parties learn from someone asking questions, so don’t be afraid to Expose Your Ignorance. I know I will be exposing my ignorance more!

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: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye opens up with a really great hook that makes you want to dive deeper. The book, so far is extremely simple and easy to read. The authors do not overwhelm you with too much information. It feels like they are talking to you rather than telling you something. I like the medieval inspiration of guilds, masters, and apprentices. It brings me back to the days where I wanted to be a blacksmith apprentice (in 5th grade we went to Old Sturbridge Village which sparked my interest in blacksmithing). I never became one, obviously because there are no blacksmith masters around. Anyways, just the word apprenticeship gives me a feeling of being useful (or at least learning to be useful) and I enjoy the thought of having a master to teach me the crafts.

My favorite line from this chapter was “Our goal here is not simply to hand people a rule book, but to give them the ability to create new practices for new contexts, which in turn drives the discipline of software development forward.” This is important because even the most skilled of teachers can learn things from students that think differently. Giving us the tools to make our own decisions is what we need to continue developing new and better technology.

The authors include a bulleted list of values that describes the phrase software craftsmanship. Some of the most important values being:

-Growth mindset. The author accurately explains that failure is just momentum to try again. Keep learning and growing from your mistakes an you will become very powerful.

-Adaptability. Recognize that the world is changing around you and just because you think it is right, doesn’t mean it is.

-Open source sharing. Share what you know rather than hoarding it. This will help progress software development as a whole.

-Manifest Destiny. Go out and create your own opportunities rather than waiting for someone to give them to you.

-Learn form your environment. Swallow your pride and ask for help from people around you. They have the knowledge and skills to advance your skills.

The authors go on to explain what it means to be a journeyman, master and an apprentice.  As an apprentice you should always have the attitude that there is a better and faster way to do things. You should continuously absorb information from the people around you and use that information to your advantage. A journeyman is an apprentice that might switch between masters and relay ideas off each other. They are focused on enlarging their portfolio and working to become a master. A Master is the all powerful leader of the three. A Master retains all responsibilities from his journeymanship, with the added responsibility of furthering software development as a whole. He/she does this by teaching and continually learning.

The phrase apprenticeship pattern does not mean that this book will teach you how to become a software designer. The patterns are simply a guide to bring you to the next level and get you better at what you want to do.

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

First Blog post for the capstone!

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

In class we did a group activity which had us work together in teams of five and conduct a software technical review. In a software technical review you have a specific role in which you must fulfill specific duties. There are four roles. The producer, review leader, recorder, and reviewers.

Producer–  The producer is the person who created the work that is being reviewed.

Review Leader–  The review leader schedules the review meetings, prepares materials for meetings, conducts meetings, and writes the review report.

Recorder- The recorder’s job is to take notes of what is being said. They also document anomalies, decisions and recommendations.

Reviewer– The reviewer(s) job is to prepare an individual reviewer issue sheet that is given to the review leader before the meeting. The sheet contains all of the issues that the reviewer found with the code.

There are three different types of software technical reviews. The walk through, technical inspection and an audit.

Walkthrough- A walkthrough is an informal meeting with the producer and the colleagues. There is little preparation and little documentation.

Technical Inspection- A technical inspection is a formal process and includes training.  There is sufficient and budgeted preparation time and the team ic very carefully selected.

Audit– An audit is a review that is held by an external group. The purpose of audits are to ensure that you are conforming to standards.

Why would we waste our time with such a complicated process when we could just look for faults individually? Well, there are many good reasons why we hold reviews and why the process is so important.

Reviews push developers to communicate with one another, it gives an opportunity to train new employees, it helps management report progress in the business, you find defects, it builds team morale and it gives the customer reassurance that the product comes out the way it should.

Going into your first review is probably nerve wracking. If you can remember the proper review etiquette, you should be golden!

Be prepared– There is nothing worse than an unprepared team member

Be respectful- it is the golden rule after all. Review the product not the producer.

Avoid discussions of style- Not everyone likes the same thing you do, as long as it is not wrong leave it be.

Provide minor comments to producer at the end of meeting 

Be Constructive- help others, don’t bring them down.

Remain focused- identify issues and don’t try to solve them yet.

Participate- Do not try to get the spotlight, it can be annoying.

Be open- the results of the review should be available to the entire organization.

My source of information was our class slides, but you can learn more about software technical reviews here:

http://www.softwaretestinggenius.com/understanding-software-technical-reviews-strs

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