This weeks second pattern can be considered a bit of a counterpart to the first. The Deep End described going headfirst into a new challenge to get yourself out of a rut and advance your skills. But what happens if you go too far, like the pattern cautioned? What if you bite off more than you can chew?

This is where the pattern, Retreat Into Competence, comes in handy. It is in essence , as the name states, is a retreat from the challenge. If you take a challenge that seems to be impossible or you can not make any headway into, then the wisest course of action might be to simply take a break. Gives yourself a breather, but not just that. You want to not only take a break, but also invigorate yourself and bring back your confidence if you were close to throwing in the towel. So once you retreat, do something you are competent in. Change course for a moment and do something you know you are good at or enjoy. Then once you have realized how good you actually are, dive back into the problem with more energy.

By taking a step back, you can fling yourself back at the problem with much more strength. And by taking a step back and giving yourself some space, that allows you to talk to mentors or others you know that can help you. With advice, tips, and renewed confidence, actually solving the challenge before you becomes much more likely than continuing to bash your head against it over and over again.

Overall, this pattern makes a lot of sense to me. Throughout my life, taking a a respite from something that had me in a frustrated loop of failure, and then coming back, led to me succeeding soon after. This does not just apply to software craftsmanship, it is a pretty universal tip for problems. Retreating can even provide a new perspective that would be impossible to gain with the tunnel vision that usually comes about when focusing on a challenge for a very long time. I have also had times where the retreat becomes me giving up and never coming back too, like the pattern warns. It can definitely be a double edged sword, so take caution.

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 first apprenticeship pattern is The Deep End. The main issue this one is trying to solve is essentially getting into a rut. When one is just competently doing their job for a while, they are not preparing themselves for the next step or improving themselves. They are not advancing themselves as a craftsman, but simply doing a competent job and nothing else. As it states pretty succinctly, bland competence eventually decays into mediocrity .

A software craftsman has to improve their skills and their confidence, they need challenges. By not taking challenges, advancing in ones career becomes difficult. This is something I myself have experienced, especially during my college career. This is mostly due to the varied classes taking up both my focus and time, making it difficult to fully devote myself to advancing my software skills. This fed into a bit of a negative feedback loop where I would get down on myself for not working hard enough on challenging myself or being productive enough, which would definitely not encourage me to do more.

As the pattern states, a solution to this is to simply force oneself into a challenge, that requires ones full attention and learning new skills. By forcing an ultimatum, essentially, where one either grows and succeeds or fails, growing becomes much easier. Also, in my opinion, having a new project in and of itself is a very motivating thing. Something new that you might not even know how to begin solving is very exciting. It is akin to a new toy, playing with it can be much more appealing. It is a bit shallow, but it is true. Also, by being challenged, it can rouse the pride of a software craftsman inside that might have slowly faded in the rut.

I agree with the text, it can be dangerous to go head first into a challenge or big change without any help or guidance. While a big, new project can be a change of pace that allows one to break out of a rut, it can also cause them to fail and further entrench them or worse. It is important to throw oneself into the deep end, but make sure there is a lifeguard present.

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 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.

This is probably the most important pattern I have checked out in the book by Dave Hoover and Adewale Oshineye. The entire pattern is about finding a mentor/master that helps you walk “The Long Road” with more ease. Allowing you to grow and cultivate your skills into tools that will be used for the rest of your life. The authors make sure to note that since our profession is still relatively young, there aren’t many recognized “masters” of the art. However, your masters don’t have to be physically available to you at all times. Maybe you read a book about someone’s life who really interested you and you begin to develop a passion for the things the author enjoyed, that author will be your master regardless of whether you talked to them or not. They may even be deceased!

The authors go on to emphasize that just because you are the apprentice and your master is the master, doesn’t mean that they are the one and all-knowing god of coding.  No one knows everything. Be free to opportunities and don’t only talk to your master, learn from other masters and expand your mind with knowledge. Lastly, this chapter reassures you that there is no real risk to looking for mentors. While it may be difficult, the payoff would be huge for you. The only risk is getting rejected, which really is not that big of a deal. Most top-notch developers had memorable mentors to help them along the way.

This pattern will certainly affect how I go about things in the future. I had never really thought about going up to someone and asking to be their apprentice or “assistant” but I could actually see it working. I could see someone at a new job being a mentor to me but I could also see myself going to volunteer on a separate project outside of work just to get extra practice and that sense of apprenticeship. I really enjoy the thought of having a mentor, so that may be one of my next steps.

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

I chose this pattern because it is in connection with my previous pattern “record what you learn”.  I also find some useful links to expose your ignorance pattern too. It does made sense to me that after you record what you learn, you share them for other people to benefit from your learning; sharing with others will be easy because you already have them documented. You can share what you learn in many ways such blog post, tutorials and one on one or group discussion with people you think might be interesting in the topic. One on one discussion is sometimes embarrassing if your target group already knows the subject but it is good place to start when you find people interesting in knowing what you learnt.  Sharing is not always easy for me because I always feel like someone has already dealt with what I learnt and no one might need it. But I was proven wrong in one of my presentation as what I shared was straight forward and the people like it very much than what they already knew regarding the subject matter. Also, in the mixed of a team I always try to be first to respond to it if only I have an idea of what is being asked because I know how it helps me in understanding the scope of my knowledge better. This boiled to the point that sharing what you learn will not only make you valuable to the community but will also let you stay on top of your field of study.

Besides, the challenging expect of sharing what you learn is the ethical part of it. Sometimes how to re-factor what you learn into your own work is difficult because it is straight forward knowledge and you can’t go around it to make you own.

After reading this pattern, it has reinforced the power of recording what I learn as it will make it easy for me to share what I learn with others. I also didn’t pay attention to the effects of what I shared in the past and after reading this, it has opened my eyes to look out for the legal, political and financial implication to what I share 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 “Sweep the Floor” pattern.  This pattern addresses apprentice software developers that are unsure of their place on a new team but want to contribute to the team’s work and earn their trust.  I chose this pattern mainly because the title caught my eye, but also because I think it could come in handy for when I begin my internship, working on a small development team, in June.  Oshineye and Hoover provide solid advice on how to make meaningful contributions to a team by volunteering to perform simple yet necessary tasks.

Some tasks you can complete to promote the early success of the team might be maintaining the build system, setting up the project wiki, updating documentation, code reviews, etc.  They describe these tasks as residing in the “edges” of the project where there is less of a risk of damaging causing damage to it.  The reason that this pattern is called “Sweeping the Floor” is because it refers to the fact that, while sweeping the floor might seem like a mundane and tedious task, it is necessary to the upkeep of any building – and somebody has to do it.  Simple and/or tedious tasks benefit not only the team but also you as an apprentice, because “chores” are often overlooked in academia but doing them fills the gaps in developers’ knowledge.  Oshineye and Hoover raise an interesting point by saying that education means less than college-graduates might think, because everybody starts at square one when they join a new team and, as a developer on square one, taking on mundane tasks is very helpful.

They go on to explain some of the negative consequences that could occur when applying this pattern in the field.  The first negative consequence could be that you might become the team’s “gopher”, the go-to person for mundane tasks, for the duration spent working on the project.  A second negative consequence that could result could be that you no longer feel confident tackling tasks that aren’t like your regular “sweeping the floor” tasks.  There is also the possible negative consequence that you don’t develop an appreciation for the bigger picture while “sweeping the floor” because you aren’t gaining a wider coherence.  Oshineye and Hoover recommend that developers facing any of these negative consequences refer to the “Nurture Your Passion” and “Unleash Your Enthusiasm” patterns.

To implement this pattern, Oshineye and Hoover advise apprentice developers, who are new to a team, to tackle the tasks that everybody else would complain about.  Not only should apprentice developers tackle those tasks, but they should also approach them with creative solutions to exceed their team’s expectations and make the situation fun and rewarding.  I think this pattern will be a useful reference in my repertoire and I hope to implement it in the field, this summer.

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