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.

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.