This apprenticeship pattern seeks to solve the problem of the apprentice that wants to seek out and join a skilled team to contribute to and learn from (also, it pays the bills).  However, a truly novice software developer may lack the skills needed to contribute, and faces (perhaps fears) rejection.

The writers offer a solution and an action item to assist it.  The solution is to develop and maintain concrete skills, items that can go on a resume, get through HR filters, and convince a hiring manager that it’s worth it to take a shot on the otherwise unproven apprentice.  These include picking up new languages and technologies, and most importantly writing a project in them, especially if it’s something the apprentice can put on a repository site or their own personal site for potential employers to look at.  The action item (short of finishing a half-dozen personal projects) is to look at the CVs of skilled proffessionals, and to figure out which skills they have that the apprentice could learn.  This goes hand-in-hand with keeping one’s own CV up to date and figuring out which parts are likely to catch the attention of hiring managers.

I think that the development of concrete skills is one of the more valuable things that I’ve gotten out of my education, and I wish that I’d had more opportunities to develop some.  I think it’s really important for students to have opportunities to create projects that push not just conceptual learning, but force the development of concrete skills because they’re the best tools for the job.  I have also been lucky to have an employer that’s willing to let me work on software projects for the business which has given me a lot of experience as well.  I would add to this pattern a suggestion to find an external source of pressure to create a project that works and looks professional.

This is, I think, a pattern that seems obvious and is harder to put into practice than it might appear.  It’s easy to commit to doing things by looking over a CV and developing a list of skills, and harder to actually get them done.

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

The apprenticeship pattern is another helpful one for the future. It is very similar to the other pattern talked about this week, but unlike the last one this week, Sustainable Motivations, it does not apply to the project we worked on over the last semester. Sustainable Motivations had to do with keeping ones motivation when faced with a task that did not cater to any of the reasons a programmer would be interested in programming. A project that is tedious, vague, or furstrating. This pattern, Nurture Your Passion, has to do with ones working environment instead.

In the real world not only are there hostile projects, but also hostile working environments. Corporations that do not care about you, or software craftsmanship. Ones that have abusive managers, demoralizing hierarchies, cynical coworkers, and project death marches. Things that kill a software craftsman’s passion in the their very craft. Things that can make them into one of the same people that contribute to that environment, even.

How does someone keep up their passion in the face of this? The answer is again looking to the future, as it was for Sustainable Motivations. You must look at the Long Road before you and visualize your road map for the future. You then have to see the conflicts between your current situation and the future one you want, and deal with it.

Your future may not align with the corporations, but you must do what is best for you. Project death marches that kill your passion? Stop playing along, leave early, at normal business hours. Do not fall prey to the hero mentality that will cause you to burn out in a couple of years, this is supposed to be a lifelong journey. Steer cynical conversations to positive and helpful topics. Try and steer unproductive meetings to something productive. Leave abusive ones. Work on making your hostile environment less hostile, and if you can not then leave.

The future they desire is what one should base their decisions on. You should never o off your Long Road unless you want to. Being pushed off of it is something that should be avoided at all costs.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

This weeks pattern, Sustainable Motivation, is actually is very appropriate given the project I and my team have been working on over the last semester. Though it probably would have been more helpful to have read this pattern much, much sooner in the semester. However, it will still be helpful in the future, so better late than never as they say.

Most people who program do it because at least on some level they enjoy programming and writing code. Thinking up solutions to interesting problems, implementing your ideas and thoughts into reality, solving a problem that is actually real with your own hard work, all of this motivates many people who get into programming. Also those that love technology and get excited at the prospect of using and learning more uses for it.

However, becoming a software craftsman and getting into the professional software developing world has its down sides. Mainly that most projects that others are willing to pay you to do are projects that someone needs to be payed to do. A project that is noting but tedium instead of problem solving. Or a project with very, very vague definitions. The gist of it being a project most people would not want to do normally.

Real life projects are not always glamorous. They can be frustrating, annoying, tedious, and just plain demoralizing. To the point that it might make some consider quitting, even those that are in the profession for nothing but the money. The key to overcoming this is to sustain your motivation.

The best way to do this is to consider the Long Road ahead of yourself. Just imagine the future before you and where you imagine yourself being. By doing this you can keep your motivation by focusing on a further goal than just completing the demotivating project before you.

While the project we have worked on this past semester was not exactly demoralizing, it was very frustrating. It involved attempting to learn many things I previously did not know. The process of constantly running into more new concepts every step of the way was frustrating, it felt like my progress and momentum hit a speedbump many times throughout. Despite that, progress was made, knowledge was gained, and at the end of the semester my motivations for becoming a programmer remain. I am still on the Long Road.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

This week I also read the pattern “Record What You Learn”, and this is a pattern that I am not anywhere near doing correctly. I think that this problem is useful, and though not as significantly as the others, still one worth implementing. This pattern is essentially asking you to take notes and record all of the things that you’ve learned throughout your journey. Taking notes does help in learning, but its real power comes when you actually go back and review these notes. The author alludes to the previously mentioned by suggesting that we keep our notes in a medium that we are more likely to access and interact with. Often times notes are taken in a subject specific notebook or application, the problem with this can be actually going back to this material to review it since it may lack that personal touch. This problem can be alleviated by storing your notes in a personal wiki, journal, or blog, the key being that this medium is personal and that it is something we interact with often.

The author emphasized the idea that your notes should be a “nursery, not a graveyard”, meaning that these notes should be a source of progress and growth and not stagnation. Even if you go through your notes daily, if you are only trying to memorize what is in your notes rather than trying to gain new insights and making new connections with them your time could be better spent doing something else. The other great benefit of having these notes is the fact that they act as some sort of wiki for you. The author mentions this and I have seen the truth in that myself. There have been times when there was a problem/bug that I could not figure out and the solution required multiple different things to be done, when I originally learned to solve the problem it may have taken me hours to gather all of the resources and information, but after storing all of those steps in my notes, I do it in minutes. Taking notes can often be too mundane and boring to actually want to do but this pattern has really showed me that it’s worth powering through it. By recording what you learn you have a detailed history of your grown, your own personal archive, and source of future ideas and innovations and because of this I will definitely try to apply this pattern as well throughout my career.

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

This pattern is all about taking a step back, a deep breath, and fighting through the struggles you might be having. The authors talk about the roller coaster ride that an apprenticeship can become. They include advice about what to do when you feel like you aren’t making any progress and how to fix the situation. Essentially, I think the authors wrote this pattern for people struggling to learn new technologies. It can be scary to jump into a project that you had never been familiar with before and  the authors provide a confidence booster to help you bounceback. The authors say to set a time limit for yourself to go back and practice the things you already know and are comfortable with, once that time limit is up, go back and try to work through the new problems you might be having. Build up your confidence and keep the forward momentum going.

I didn’t find this pattern to be as immediately useful as some of the other patterns, however I chose this pattern because this situation can happen to anyone. I am sure that it can be very easy to become overwhelmed with a project that you are not entirely comfortable with. However, I don’t necessarily agree with retreating, even if it is only for a short time. I find that being resilient and stubborn can help you fight through your issues, spending consecutive time working on something can help you break through the obstacles that you didn’t think you could. I don’t really understand the actions the authors say to take:

“Pick something self-contained that you know really well and reimplement it. For instance, Ade likes to implement caching algorithms because they can range from the trivial to the highly complex. They also allow opportunities to reinforce his intuition about design and algorithmic complexity.”

For example, it is great that he likes to implement caching algorithms but what does that have to do with the project he is working on, assuming that it has nothing to do with caching? Going back and doing something you’ve done many times can certainly help build confidence but I also think it might be too much of a distraction to try and be productive. Overall, I think not giving up is the most important part of succeeding. If you need a break you could ask someone (like a mentor) to help you learn the process.

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

This week I read the pattern “Practice, Practice, Practice” and the focus of this pattern is pretty obvious. An expected theme that I came across when reading this pattern was the importance of practice itself, but the author went beyond that and specified the type of practice that is most valuable. The technique of practice that is optimal is said to be “deliberate practice” in which “ a mentor would assign you an exercise based on her understanding of your strengths and weaknesses…”. This method of practice is good because the exercises that you are practicing with match your skill level and most important of all, you are receiving feedback. Depending on your performance, this mentor would then decide whether or not increase the difficulty of the exercises. I can see the value in practicing like this, a big thing stopping me and many others from going back and practicing is how boring and mundane it is and this method ensures that you are amply challenged.

Another aspect of practice that the author mentions that you don’t often hear about is relaxation. The author says “if you aren’t relaxed you’re not going to learn from the practice”, in my experience this could not be anymore true. The practice that you are doing should be relaxing, it should be done without a deadline in an environment where you can break things without consequence.That brings me back to the level of challenge once again, this is because the practice should be done at a difficulty where you can learn but not too difficult that you get frustrated. Having learn how much being relaxed helps in the learning process I intend to use this going forward. The goal is to get to the point where you enjoy your practice sessions if you do not then you should likely change how you are practicing, and if that still fails then it could be because you don’t really enjoy the thing you are practicing.

The other major point that the author hit upon was feedback, this topic has been addressed in other patterns throughout the book and this is because of how important it really is. Yes it is true that practice makes you better, but practicing the wrong this will make you better at the wrong thing. Feedback is important because it makes sure that while you are practicing you are doing things right and developing good habits.

This pattern has reinforced to me the importance of practice, but more than that it’s showed me the importance of CORRECT practice. I plan on implementing this pattern not only throughout my software career, but on any skill that I want to develop in the future.

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

In this pattern, the authors discuss the importance of building what they call “breakable toys.” The context they present is one in which the apprentice needs an outlet for failure, so to speak, because in order to gain the experience needed to excel in the software development field they must make mistakes and learn from them. This can be difficult in a professional setting as management and other superiors may not be expecting failure from the new apprentice. Hence, making mistakes in the work environment can have negative repercussions. While it’s impossible to avoid failure in the computer science field, it can be somewhat contained by adopting this pattern and breaking things in a low-stakes environment where the only one effected by failure is the apprentice himself.

The authors stress the fact that the only way to progress in the software development field is to make lots of mistakes and even just flat out fail sometimes in order to learn and grow as an individual and as a software craftsman. The authors advise apprentices to make breakable toys which resemble what they might be building at work. This allows the apprentice more flexibility in design and a lot less stress when compared to the professional setting. One example of a “breakable toy” the authors suggest for apprentices is putting together a wiki. They go on to show that by taking on this type of project the apprentice can learn new things about a variety of topics ranging from “HTTP, REST, parsing, web design, caching, full-text search, databases, and concurrency.”

I have to say I certainly agree with the authors after reading about this pattern. Even before I read this I have been experimenting with “breakable toys” of my own. When it comes to learning new things within the field, I am a very hands-on learner so building things and breaking them are a must if I hope to gain new useful skills. Since I work in Security, some of the side projects I have going on at the moment are things like building my own firewall and deploying a Security Onion instance within my home lab in order to gain first hand experience regarding best practices for Network Security Monitoring.

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.

This is the first pattern in chapter 5 of Apprenticeship Patterns which focusses on how to address the steep learning curve associated with picking up new programming languages and/or practices. The context the authors present in this pattern is one in which the apprentice has acquired a set of “basic skills” that must be improved in order to become a journeyman. They describe the problem as being that the basic skills held by the apprentice are insufficient for high-level projects that require a more extensive knowledge base and/or skillset. The authors use the analogy that up to this point the apprentice has been sipping information through a straw but the time has come where they must drink from the fire hose of information.

As a solution, the authors suggest apprentices should “expand [their] ability to take in new information.” To do this, the authors advocate for apprentices to not just read books pertaining to knowledge they seek to gain but rather utilize a number of resources in combination with the reading to increase retention and understanding. Some of things they suggest are signing up for Google Reader and subscribing to software development blogs, following “luminaries” on twitter, subscribing to online mailing lists and answering people’s questions, as well as physically or virtually attending technical conferences. The authors note that when the so-called fire hose of information is turned on it can be difficult for an apprentice to get other work done as most of their time will be taken up by the process of ingesting a plethora of new information. Hence, they recommend that this pattern should not be used for more than a few months otherwise it may have yield diminished returns by decreasing an apprentice’s development velocity.

I found this particular pattern to offer some highly valuable advise in terms of how to really push my development career forward. I think that I can actually put this pattern to practice after graduation as I am moving into a position that requires a strong understanding of python programming. Up until this point in my career, I would describe my python programming skills as being basic but in order to excel in my position I will need to acquire a deeper set of skills. After reading this, I decided that when I start my new job I will try to put my mouth to the fire hose information, so to speak, in order to gain essential knowledge and put myself in a position to excel.

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.