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 pattern also dealt with a very important aspect in our everyday activities as an apprentice. I will say feedback are necessary because they do not just correct me but they also guide me to explore new directions and track specific causes to my failure. Even though, we got positive and negative feedback, I  strongly believe if you are able to accept them regardless of what kind they are and do a thoroughly assessment of yourself, they can be useful to you. Sometime, you might believe yourself and try counter defends yourself by explaining as to why you did something to a criticism instead of accepting it as a feedback. Getting feedback that enable you to figure out what to do more or less is very important to your success. I have drawn a lot of ideas from this pattern that I think will go a long way to help me stay focus in the software development industry.

For instance, I will be very mindful of what could come of me if I am in the teams where my skills are above average or below average. I will be very careful not to think I am the best when encounter with such situation. I will also not down grade myself too much to the extent that it will destroy me because I am the less skill among the team I am working with; it will give me the opportunity to extend my tentacle and learn more to catch up with them should that be the situation.

I really like the ideas discussed in this pattern. Because, as a newcomer, I am bound to face some shocks regarding feedback I will receiver but with this pattern’s ideas in mind, I think these shocks could be turn into something useful that will help me assess myself. I wasn’t even aware of some of those techniques for obtaining feedback such as test driven development, Exams and certifications that have been discussed in this pattern until I read it. Before reading this pattern and if I haven’t come across it, I will just assume I didn’t meet the standard a company might want if I am not offered a job after attending an interview. I wouldn’t bother myself to do a follow up to know why and what I need to improve on. The ideas in this pattern are really going to help me in the future.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

This week, I will be writing a reflection on the “Reading List” pattern.  This pattern addresses developers who are proficient in their first language but feel that the amount of knowledge to be learned about the language is growing at a faster rate than they can acquire it.  I chose this pattern because I have been visiting book stores to shop for software development literature.  While I feel proficient in a language, I have yet to encounter this worry of an expanding knowledge-base that I’ll never fully acquire.  I do, however, plan to begin putting a reading list together as I continue preparing for my internship in the summer.  Regardless, Oshineye and Hoover provide sound advice on how to manage the books you plan to read and how to reflect on your past reading habits.

Their first piece of advice, ofcourse, it to create a list of the books you plan to read.  This is useful in that it allows you to plan out a kind of strategy that will allow you to learn incrementally and notice patterns, trends, and gaps.  As a side note, they also suggest that you make your reading list public to open the possibility of receiving suggestions for future reading while also allowing others to follow the same plan you did.  They recommend that you treat your reading list as a priority queue, as it will help you realize that some of the books on your list might actually not be worth reading.  To initially create your list, choose books that will broadly cover the area that you are studying, and then subsequently drill down on individual topics as you filter out the ones you find most important or interesting.  I found these tips helpful and will likely use them when I head to the bookstore soon.

They conclude the pattern by describing the kind of action you can take to begin implementing this pattern in your own life.  They recommend listing the books you are currently reading in a text file, and then progressively update the list as time goes on.  As long as you maintain the text file, you will be implementing the pattern.  I began my list today, with Clean Code and Apprenticeship Patterns being first and second in the queue.

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

In this apprenticeship pattern, the authors present a context in which developing software professionals are “spending a lot of time exploring blind alleys.” They then describe the problem by saying that the software apprentice is “walking along a path” but having trouble being prepared for “what’s around the corner.” In other words, they are describing the difficult task all software apprentices face when trying to learn new skills and master their craft. The authors then go on to remind the reader that every software developer who is considered to be a “master” in the field, has walked the same path and knows exactly what that path entails.

For the solution to this problem, the authors suggest that software apprentices “seek out” those that are considered to be masters who are further along on “the long road” and attempt to learn from them. However, this suggestion comes with some warnings. They point out that as an apprentice it may be more difficult to spot the true master craftsman in the field. To counteract this concern, the authors advise that apprentices ” be supervised by a series of mentors who possess varying degrees of mastery.” Additionally, they remind the reader that “no one knows everything” so it is ill-advised for an apprentice to be under the assumption their mentor is infallible in terms of their software development skills and expertise. By upholding this mindset, the apprentice may be able to recognize their mentor’s weaknesses without feeling like they have outgrown their mentor.

The authors also address the issues and concerns that coincide with reaching out to more experienced professionals within the software development field. They recognize that this task may seem extremely intimidating to most apprentices due to fears of rejection or being seen as “strange” by a potential mentor but they assure the reader that these risks are low when compared to the payoff of being mentored by someone who is much further down “the long road.” The authors also provide testimonial from a developer named Dave in which they illustrate these payoffs. Dave reminisces on the time he “uncharacteristically” approached a more experienced software developer named Wyatt at a conference and later went on to exchange emails with him asking to be mentored. Wyatt agreed to become Dave’s mentor and the two went on to meet periodically throughout a year. Dave describes his interactions with Wyatt as “pivotal in (his) progress” in becoming a skilled practitioner of agile development.

After reading this I plan on taking the authors’ advise by “lurking” on message boards and community web pages with the intention of finding potential mentors and valuable information regarding my particular field of study within computer science.

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.

I have to say I did not fully agree with this particular apprenticeship pattern. The authors reiterate their views from the other patters here by explaining that software apprentices should shy away from promotions that involve managing others rather than maintaining positions that heavily involve writing code. The specific context of the problem in this pattern is that you are being offered a promotion that will “pull you away from programming.” The promotion in question is one in which you may receive higher pay but will involve much less technical skills and require less programming.

I understand that the authors are trying to encourage readers to stick with programming in order to enhance their skills and write better code but I think that at some point in one’s career it is important to consider roles that involve management. Part of the reason I say this is because if good programmers never become managers than developers in the field will end up with lousy managers that aren’t understanding when it comes to handling difficulties a team of developers might face. Also, just because you take on a role that involves managing people doesn’t mean you’ll never write code again. For instance, many developers have side projects, such as open source projects, that are unrelated to their work which allows them to continue to hone their craft of software development.

I agree with the authors that developing software professionals should always continue to work on enhancing their skillset but I don’t agree on their anti-promotion/ anti-managerial outlook. Skilled developers occupying the role of manager may prove to be good mentors for those working under them. Furthermore, many projects can benefit from having someone with a strong background in programming making the important decisions. These decisions can range from architecting the project, choosing different tools and/or programming languages to use, and assessing whether applicants are a good fit for the team. If the only people managing teams of developers are those with little experience in programming then the teams could really suffer by not having the right personal with the right expertise and not having all the necessary tools/information they need to be successful.

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.

The Be the Worst design pattern seeks to solve the problem of an apprentice’s learning rate leveling off.  Perhaps this is because they have outgrown their team or organization.  Perhaps this is because they are still working through things alone.  Either way, Hoover and Oshineye have a solution in mind.  They suggest that the apprentice seek out a team where they are the weakest developer, so that as many team interactions as possible can lead to learning, and other team members can help them to avoid pitfalls.  They do note that this is somewhat selfish, and the apprentice should be willing to take on whatever menial work comes up in order to balance their lack of experience or skill.  It also means delaying leadership positions or switching jobs and companies for the sake of craftsmanship.

This pattern really speaks to me.  It’s a position I expect to find myself in this summer as I work as an intern.  I will be the least experienced member of my team, and part of my job is to learn as well as to contribute value.  I expect that I will end up with some of the less-desireable work, but that I will be able to learn from my colleagues and that learning will improve my job prospects in the future.

I also have found Being the Worst member of my team to have contributed best to my learning in the past.  As I’ve changed schools and spent more time in school, that position has been less and less frequent.  I don’t mind leading teams if I feel confident in the subject matter or the technology, but I would prefer to be on the less-experienced end of the spectrum.  This isn’t because I want to dodge responsibility; it’s because that’s where I’ve found I do the most real learning.  It also helps me a lot, both in productiveness and confidence, to know I can rely on more-experienced team members to help if I run into problems.

In the future, I want to find more opportunities to Be the Worst (either in classes next semester as I finish my degree, or at work) at least for a while longer.

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