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

This week I read the pattern “Create Feedback Loops”. I thought that this pattern was the most one of the most practical of the ones that I’ve read so far because there are so many ways that this could be applied. I also think that this is one of the most crucial patterns that everyone should apply because it has the power of significantly shortening the time it takes to learn, as well as pointing out any potentially catastrophic errors in the way that things get done.

A great thing that this pattern was able to do was telling us some mechanisms that are available for acquiring this feedback. The ways of getting feedback included test driven development (TDD), using type-checked languages, as well as just simply asking a colleague. Of those provided, my favorite is TDD. I am a huge fan of TDD because it gives you instant feedback letting you know that the functionality is implemented correctly, but even more important than that, it lets you catch regressions even faster. I find that TDD is even more effective when someone else has written the tests, and when there are negative tests cases written as well. Fortunately this is something that nearly every tech company practices so I will not have to convince anyone of it’s value. The method of getting feedback that can be the most daunting is asking a colleague or boss, but it can be very valuable. It can be difficult to honestly assess yourself (as this pattern stated), so having the opinion of someone else can help give you a more true vision of your performance. When it comes to asking another for their opinion, the author hit upon a very important idea which is essentially that the given feedback must be “useful”. So if the feedback that you receive is negative and there is no way to grow using this feedback then it is absolutely worthless.

I agree completely with this pattern, and it is one that I intend to use throughout my career. The learning potential using this pattern is extremely high, and if applied correctly will lead to extreme success!

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 Apprenticeship Pattern “Draw Your Own Map”, it explains the importance about creating and managing your career path once you are exposed in the software development environment. A couple of key points that the pattern states are:

1. Your manager, professors, or colleagues are not in charge of where you position your career as a software developer.
2. Your are responsible for your destination and goals.

These couple of points emphasizes the concept of a software developer’s individuality. It is true that within the software development field, everyone is a programmer and creates many different types of software. It is up to you as an individual to take steps towards what you aspire to do and become within this field of development. One quote that stood out to me was this one below that talks about your vision of goals versus the employer’s vision for you.

“If you find that your vision of yourself is not in accord with your employer’s vision for you, and there doesn’t seem to be a way to reconcile the differences, examine other opportunities to see if they’re heading in the desired direction. Remember, there isn’t one single path that all apprentices follow. Instead, successful apprentices follow paths that share a certain family resemblance. These resemblances do not happen because apprentices are inexorably shepherded into making the same decisions by their mentors. They happen because each apprentice, consciously or not, chooses their route through life based on an overlapping set of values.”

I agree with this idea because it seems like it will be the most realistic to me once I start working for a company that may not have the same vision for my career as I do. This idea also will allow me to change the way on how I would manage my goals and career paths while working in the field. I will continuously plan and weigh options that would be available to me out there in the software development field since there are many companies and employers to work for. It goes back to the concept of leaving your current job for a better one because it does not meet your intended needs or it doesn’t help you grow in the field. For me, I’d like to work for a place that respects my needs and aspirations. As a future video game developer, I want to have that luxury of being able to grow into a successful video game developer and there would be nothing more  important than that.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester 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 will be writing a reflection on the “Dig Deeper” pattern.  This pattern addresses developers who feel that feel that they only possess a superficial knowledge of some of the technologies, tools, and techniques utilized at their workplace.  The problem that arises, in this scenario, is that the developer begins having trouble with maintenance of his or her code because it was written with only superficial knowledge that is likely to be forgotten.  I chose to reflect on this pattern because I really like the advise that Oshineye and Hoover provide about how to truly immerse yourself into the learning process and transform your superficial knowledge to deep knowledge.  I also agree that having a deeper understanding of the everyday things in your life can be incredibly beneficial in a number of ways.

The primary importance of deep knowledge is that allows you to explain the inner workings of systems you work on, which will distinguish you from colleagues that are unable to do so and show others that you are more proficient in working with that system.  I recently had an interview for an internship and many of the questions I was asked were related to my contribution to and understanding of past projects.  The recruiter got back to me a short time after the interview and informed me that I ‘knocked the interview out of the park’ and I was offered the position – I accepted!  Oshineye and Hoover explain that deep knowledge can also act as a safety net in that you can refer back to how you gained your deep understanding in that area to gain confidence about learning something new.

They recommend that developers ‘dig deep’ into the tools and technologies involved in the project they’re working on, until they have a deep understanding of how those tools and technologies work and why they are being used.  One of the ways somebody can dig deep into something is by getting their information from primary sources.  Primary sources understand the problems they were trying to solve.  Another way somebody can dig deep is by looking at tutorials and guides regarding the thing(s) they want to learn, and asking themselves if there are underlying computer science concepts behind what you they are learning.

I think this pattern will prove to be a useful piece of knowledge in my repertoire.  I will try to apply it regularly in my career and I strive to become a person who truly understands the tools and technology utilized in the software I am working on.  I have used this pattern and seen it work, first hand, and I hope it will lead me to more success in the future.

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

This pattern also captured a very important issue that is often ignored. As a newcomer, you need someone to guide and coach you to get grounds in the field. We sometime failed to understand that only what is learned in class can’t take us to the field. The outside world has its own convention of doing things and a newcomer need somebody who is already in the field with experience to guide him. There are so many benefits for having a mentor. Working alone is the hardest thing you could face in the outside world and having someone as a mentor walking with you side by side or sitting with you face to face could save you a whole lot of time spent trying to figure out how to dealt with certain problems. Even though it sound very simple to say find a mentor, it is usually challenging to get someone who is willing to accept you as an apprentice.  Even though the writer talks about the field being young and which we can’t tell who is a master craftsman, I don’ think that is a problem. Because, no matter the situation is, those who are already in the field will have some experience that a newcomer doesn’t have. The issue here is everybody readiness to share what have been learned. Most people don’t want to share their knowledge with others because they feared their jobs would be taken from them. They also forget the fact that when you teach other of what you know, it helps you remember it all the time. In fact, it sticks in your mind forever. With regards to this problem, if you are fortunate to have many people mentor you, you will definitely gain enough knowledge to keep you going in the field. Another thing that every apprentice needs to know is that nobody knows everything and though the master has more experience than he has, they might both be learning certain things together. Regardless of whatever challenges I might face in the industry, with this whole ideas in my mind, I think I can survive in the industry.

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

At first glance, I thought this particular apprenticeship pattern seemed a bit absurd. The reason I say this is because I couldn’t imagine why anyone would actually want to “be the worst” in terms of skill level and knowledge on a team of seasoned software developers. However, after reading the rest of what the authors had to say in this pattern it started to make a lot of sense. This pattern reiterates some of the ideas presented in other patterns such as “The Deep End” and “Stay in the Trenches.” Essentially, the authors explain that it is more beneficial to be a “small fish in a big ocean” rather than a “large fish in a small pond.” What this means is that by taking on more difficult projects and/or working with more experienced developers you will provide yourself with more learning opportunities and walk away with a number of invaluable skills that you will pick up from your more experienced colleagues as well as your own personal experiences.

The authors note that this idea might seem crazy as it clashes with cultural norms that seem to advocate the idea that one should try to obtain the highest-paying position with the most superiority as soon as possible. They talk about how adhering to this cultural norm can curtail ones own self-development process by getting stuck in a position that lacks any real challenge. Another thing in this pattern that I found encouraging was the testimonials from various software developers describing their own experiences of “being the worst.” While you’d think that being the least skillful and/or knowledgeable team member would be an undesirable experience, all of the testimonials in this pattern seem to illustrate positive experiences of self-improvement and success.

At the end of this pattern the authors suggest that software apprentices should try to reach out and observe teams that operate at a high skill level in attempt to “be the worst” but in way that guarantees personal-growth. I think this apprenticeship pattern has provided me a new sense of confidence going forward. I’ve learned that it is completely fine to “be the worst” in a team of experienced software professionals because when you are, you have the largest number of learning opportunities that help push you further down the “long road” of becoming a true software craftsman.

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.