For this week’s blog I decided to write about the chapter “Record What You Learn” from our textbook of software apprenticeship patterns. The context of this pattern is that you learn the same lessons/ideas/things over and over and over again but you never seem to retain the information or you retain it for a short period of time and then forget it. I personally find this to happen to me every so often. Sometimes in class we will learn a lesson and I will not retain the information and when it comes time to use the information we learned or to prove our knowledge of the subject on a test or examination or project (some form of graded material) I will draw a blank. This is extremely frustrating because most of the time I know that we have learned this topic and that I was in that lecture but somehow someway I have forgotten what that thing we learned is. The problem being set up by the book is this; You don’t learn from history or historical mistakes and you are doomed to this repetition of failure due to your lack of discipline to take notes or record what you learn in a way that you wont forget it. The solution to this problem is rather simple; record what you have learned. Do it in some way that sticks with you – a way that makes sense for you. Two different people might have two different ways of remembering information. Maybe I can write notes down in a journal from lecture and be all set whereas my classmate (let’s call him Jim for the sake of conversation) can’t retain information from reviewing basic lecture notes. Maybe in order for the information to stick with Jim he needs to do it hands-on a few times. Once he does it himself physically he will remember how to do it because he knows he’s done it before and has the confidence he’s done it correct in the past. I hope to improve my retention of knowledge by finding more avenues to retain my information as opposed to just relying on lecture notes.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

A good amount of the Apprenticeship Patterns that I see when choosing one to write my blog post about have contexts, situations, and descriptions of people who are confident in their programming abilities, have a defined role on a development team, and are eager to get in the meat of the problem.

However, this context does not describe me very well. I am not confident in my abilities as a programmer yet, I do have an apprenticeship opportunity, but I have no defined role or job title, and I am nervous to tackle important complex tasks because of my inexperience. Thankfully I came across a pattern which describes my situation pretty well.

The “Sweep the Floor” pattern is for people like me who are unsure of the team and vice versa. People who want to contribute to the meaningful work in order to grow their skills and find a defined place on the team, but have only just began their position in the group. This context really spoke to me and pretty much read my mind without my thinking it.

The solution they provide is so remarkably simple that I’m surprised I didn’t think about it before to put my mind at ease. The authors suggest that in order to gain trust and find your place in the team is to in the beginning “volunteer for simple, unglamorous, yet necessary, tasks.” Hence the pattern’s title sweep the floor. If I can’t contribute to the main problem yet, then I can demonstrate my usefulness by handling tasks that are either tedious, not fun, or otherwise that the team does not want to do.

“Typically, you’ll want to focus on the edges of the system where there is less risk, rather than the core where there are usually many dependencies and lots of complexity”. This quote from the authors gave me a lot of clarity about what steps I can take in my internship to make myself known and actually be useful to the company.

However, they do highlight a risk about applying this pattern which I know all too well from other jobs I’ve had in the past; if you constantly are taking the ugly tasks nobody wants to do, there is a risk the group will want to keep you doing the boring, menial tasks. I have had this happen to me to the point where my coworkers would jokingly call me what translates to “Cinderella boy”. To mitigate this risk, the authors suggest to advocate for yourself and look for every opportunity to prove that you can produce quality work on a higher level.

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

          The “Rubbing Elbows” pattern is described as a way be able to branch out and meet other developers instead of working alone. The book talks about how productivity and learning can understandable plateau if you constantly work alone. The best learning experiences come from balancing private learning with team learning whether that be in a large team or simply coding with another person. It allows you to learn things that can only be understood when you and another person have a shared goal in mind. There are little quirks that you can pick up when working with someone that a mentor may leave out or find trivial to teach due to the small scope of learning it provides but over time these quirks can add up. This being said, there are also negative effects of this pattern to watch out for. An example would be to not pick up bad habits that your partner may develop or have. Another example is to make sure to not fall behind on your part of the work because it then hinders your partners learning progress as well if he has to pick up the pieces behind you.

          I found this pattern to be understanding of solo programmers and shows them a way to learn more through working in teams. It showed that working in groups and teams can build communication skills and increases exposure to several coding styles. I found that when the book mentioned pair programming as an example, I got much more interested in the topic. The idea of switching off coding seems very interesting to me and makes me want to learn more for an experience programmer. I want to incorporate this mindset in my work environment to learn better from my peers. The pattern did a good job on the negatives as well by going into subconsciously learning habits that aren’t good for you. This can be helpful to keep me mindful that some habits should be avoided or corrected to increase proficiency at the language. I agree with this pattern very much as it has taught me to value pair programming much more and has instilled a new interest to find a coding buddy to learn off of.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

This week, I will be discussing “Kindred Spirits” from Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. It is intuitive to surround yourself with people that are likeminded, trying to achieve the same goal. I wanted to read this section to know if I was going around it the right way.

I went into this wondering if they meant having good relationships with coworkers and classmates. It is always valuable to have a friend to ask for help, but it is not the whole picture. It is something that needs to be actively pursued.

The authors recommends joining or creating a group to foster your interests.  It seems that I am somewhat on the right track. I feel that I am pursuing this in my extracurricular activities. Currently, the only computer science group that I am actively engaged in is the Worcester State Computer Science Club (Re:coded, I think the official name is).

It encouraged me that the club they mentioned, Extreme Tuesday Club, boasts hundreds of members but usually has only a dozen or so people that will show up to a meeting. It seems that we have about the same ratio of members showing up to an event, with a few dozen members and a handful of “irregular regulars,” as the authors calls them.

Going forward, I would like to play a bigger role in leading our workshops. I have helped come up with some of the ideas for the last few, but I have largely been learning as I have been going along. This may not be the worst thing, as one of the apprenticeship patterns that I have read (but have not written about) is “be the worst.”

There was one quote that stuck out to me, which was, “If your group becomes large enough and energetic enough, it will sustain itself even when you are not there. That’s when you know you have a community.” I really hope that I will help it grow enough to this point so it will continue after the leaders and I graduate soon.

The thing that stood out to most was the advice to always continue to ask questions that shock the community. Something that I did not think about was what the tendency that group-think might develop. I think I do a good job of not allowing this, but I sometimes feel guilty when I don’t feel like a “team player.” This gives me permission to continue to do this, but less apologetically so.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

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