Retreat into Competence is an apprenticeship pattern that focuses on the idea that when you find yourself in a situation where you are overwhelmed with new information, it is alright to withdraw back into something you are more comfortable with. By doing this you allow yourself to gain back your mental composure, and gives you the opportunity to reflect on how far you’ve come as a developer.

I believe this apprenticeship pattern is incredibly true and helpful, as I have frequently found myself in situations where I do not feel confident in my abilities and as a result I get overwhelmed and stop being productive. When I first started my internship last summer, I was expected to use Python as the primary language. Up until that point I only had limited experience with Python, so I had many moments when I felt like I was in over my head with trying to learn a new language and also meet deadlines for the projects I was working on. During those moments I would often get a pretty bad case of imposter syndrome, and start believing that I wasnt good enough for the job. What helped me push through this was a similar technique to what is taught in this apprenticeship pattern. Whenever i felt overwhelmed with a certain aspect of the project, I would go back to a part of that project I felt comfortable with and work to improve on what I already built. By doing this I was able to stop the mental block, and by working on familiar material I felt like I was making progress. This in turn helped me figure out issues I was having with other parts of the project and slowly push through them to finish everything up.

Since I have used this apprenticeship pattern in the past with success, I am almost certain to use it again in the future. Since I just graduated and am about to start my new career, I am sure plenty of situations will pop up where I again feel overwhelmed. When those situations arise, I now have a strategy I know will work, and I can rely on it to help me get through whatever issues might come my way.

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

Any project that doesn’t retread at least some old ground for you is one where you can’t effectively gauge how long it will take. This is the problem the authors identify in this pattern. The solution offered is essentially to have a set of tools you’ve already mastered and to get at least one of them in whenever working on something unfamiliar.

One pitfall the authors mention is the possibility of your tools becoming obsolete. If you’ve mastered something, it can be pretty uncomfortable to give it up, especially when the new alternative is something completely unfamiliar. This is why I think it’s always a good idea to be on the lookout for things to add to your toolbox.

Speaking of, I want to actually come up with a proper response to the action section in this one, for a change. The authors basically just ask you to reflect on what your toolbox is. I have a specific project in mind, which is a small game I’ve wanted to make for a few months now, but haven’t been able to with school.

Here are the relevant tools I’m familiar with:

• The JavaScript programming language
• The OpenGL standard (kinda)
• Krita (an art program)
• LMMS (a DAW)

The authors suggest five tools, but I can’t really think of another one that makes sense for this project. I think coming up with this list was clarifying in that it made me realize that I’m not entirely comfortable with most of the tools I want to use for this project. The project, for reference, will be a short narrative-focused game where a character walks around and talks to people. It will be embedded in a web page, which is why I’m using JavaScript.

JavaScript is probably the thing I’m the most comfortable with on that list, although only because I feel pretty good about procedural and object oriented programming in general. The other three things I’ve mostly only really dabbled in, particularly LMMS.

Something else I noticed writing this list is that there’s quite a lot that’s going into this project that isn’t covered by a straightforward list of tools, even if I were to take away all the non-programming parts of it. I think it highlights the fact that just learning the tools, while necessary to get things done, isn’t sufficient. You also need to apply them creatively.

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

                Today marks the last blogpost I will make about “Apprenticeship Patterns” by  Dave Hoover and Adewale Oshineye. To finish off this series of posts over the past few months brings us into the unknown, of what is yet to come and may not even be revealed until the last second. Many of us reasonably fear the unknown, anything that cannot be controlled in our lives is unpredictable and may at time overwhelm us. This is exactly what this book has been attempting to get the reader to reconcile with and it is evident in the pattern “Retreat into Competence” that they realize just how overwhelming it is to venture into the unknown. Having a place to return to and gather yourself before venturing once more unto the breach is an important tool but should not be a crutch for your lack of knowledge in other areas.

                One might be an experienced Java developer and comfortable with the language and its many quirks and features, however they will one day be met with another language or toolset that is completely foreign such as REST APIs or C++ and C code. This is the rollercoaster of apprenticeship where the thrill of learning and the terrors of facing your vast ignorance coalesce. This however is all part of “Walking The Long Road” As described by Hoover and Oshineye. This vast ignorance is something you must expose and confront if you are to grow as a craftsman. (You can read more about exposing your ignorance here)  

                One of the most important things to overcome as a software developer is the fear of the unknown and sometimes one can benefit from retreating to something they know and returning with a fresh pair of eyes to their previous roadblock. Taking a break to refactor some Java code can be beneficial if the REST API portion is stumping you. However it is important to note that this tool must be used responsibly and not as a reason to avoid exploring new avenues that reveal your ignorance. Becoming an expert in something you already know is tempting however there is a risk associated with such expertise as the industry will eventually leave that technology behind for bigger and better things. Once this has happened you will find yourself in a situation where you know nothing about other technologies being used and even worse, have nothing to fall back on to recompose yourself should you being to feel overwhelmed.

                With this in mind, I would like to challenge the readers of this post to explore a new avenue of software development. Explore a toolset that you either have not used or, even better, have little experience with due to being overwhelmed the first time around. If possible attempt to either adapt a piece of software you created in another toolset or take a tutorial and create something new out of it. Learn its intricacies and, if necessary, take a break and return with a fresh pair of eyes after working with a more familiar tool for a while. Even if it is a small program, it will deepen your understanding and help to thin the overwhelming veil of ignorance that makes learning something new so daunting.

Bibliography:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

I wanted my last post to be about a pattern from chapter 6, and I chose Dig Deeper, which is about dealing with complex problems and to learning as much as you should. It builds upon previous chapters by talking about how you can run into issues by learning just enough to handle some problems but not others, and having just “superficial knowledge of a thousand tools”. At this level where some people will be at, there is much more that they can learn, and as the name of the pattern says, they need to dig deeper into the technology and tools that are out there. This sounds like retreading previous patterns about growth and learning more, but this pattern specifies the difference between the learning that has been talked about before, and going deeper into the knowledge that we have growing. Instead of just learning how to solve problems and read designs, this pattern is about understanding how these are created and why they are the way they are. The pattern put it best when it stated “depth means understanding the forces that led to a design rather than just the details of a design”.

I selected this pattern in particular not just because it adds on the idea of going deeper into what we are learning, but because the pattern goes in depth on this idea. It talks a lot about how this can be beneficial to you and how you can dive deeper into what you already know and having a full understanding of what you are working with, both what you are working with and how they came to be. In recent years I have been trying to use something similar to this method when it comes to other topics, trying to understand why something is the way it is, like with psychology and seeing how people act but wanting to know why someone may act a certain way.

Knowing the how and why of something is the key to understanding it. You can see and recognize that something exists and can deal with it without fully understanding it, but trying to understand it can not only help you learn more about what you are dealing with, but it can help you come up with an alternative and possibly better way to deal with it.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

The ‘confront your ignorance’ apprenticeship pattern talks about what to do when you have discovered a gap in your skillset that you need to fill for your daily work. Though you have identified this shortcoming, you aren’t sure how to begin overcoming it. Hoover and Oshineye recommend selecting a single skill, tool, or technique and working actively on your understanding of it. This can be done in any number of ways, such as by reading introductory articles or constructing breakable toys. You should choose a learning method that works for you. Once you are satisfied that your knowledge has been sufficiently filled in, you can decide to either continue pursuing this topic or move on to another gap in your knowledge. This pattern should be used in tandem with the ‘expose your ignorance’ apprenticeship pattern. Confronting your ignorance in public as well as private encourages an environment that is more tolerant of failure. Focusing too much on developing your skills in private may pull you away from your actual work, and it may become an issue for your team. On the other hand, focusing too much on the ‘expose your ignorance’ apprenticeship pattern may become obnoxious to your team members and prevent you from doing anything meaningful about your lack of knowledge. At the risk of coming off as either arrogant and unwilling to work or passive and unwilling to learn, you must strike a balance between these two patterns.

I think this apprenticeship pattern is really interesting. I have always found it useful to study topics that I feel I am weak in private; it’s nice to be able to focus on learning in a space I don’t need to worry about how that lack of knowledge makes me look. Learning in private can only get you so far, however. It is important to also communicate with people with more experience and who can help you better understand the topic you are pursuing. I think as Hoover and Oshineye suggest, this pattern would be especially useful when employed alongside the ‘expose your ignorance’ apprenticeship pattern. I do agree that these should be used within a reasonable amount. There is no point in expanding upon a skill if it is going to ruin your daily work.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The ‘expose your ignorance’ apprenticeship pattern addresses the issue of you not being completely comfortable with the technologies your work requires you to work with. Your impulse may be to lie to a customer in favor of appearing competent, but you should curb this impulse. Instead, you should be honest and open about your knowledge or lack thereof and focus on your ability to learn. Asking questions is a good way to let people know that you are both needing and willing to learn. Asking questions of your team may also help your team recontextualize and reunderstand their own knowledge. Your goal should be to expand your knowledge to a variety of topics, especially while you are still new to the profession, rather than focusing on becoming an expert in a handful of technologies. It is important to be able to recognize areas in yourself that could use improvement. It is similarly important to expose those areas and work on learnig from them, rather than hiding them.

I think this apprenticeship pattern has some very useful advice. I think it is great advice to admit your knowledge in an area is lacking and use that as a chance to learn. Hiding your lack of knowledge in an attempt to save face and spare your pride is unwise and will succeed only in stunting your learning process. This is something I try to work into my daily life. I used to be very scared about coming off as incompetent for lacking in a given area, but I find it is much more rewarding to admit that I am weak in an area and use that as an opportunity to expand upon my knowledge.

The only thing I disagree with is the action that Hoover and Oshineye suggest taking. I don’t know if posting a public list of things you don’t understand will help you better yourself, I think it is just going to make you look weird to your coworkers. I think it would be more useful to keep a private list of things to work on, and just keep that list in mind in discussions with others in case the opportunity to develop your knowledge presents itself.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

The pattern I’m looking at for this post is titled “Stay in the Trenches.” The problem outlined here is that success in programming has a tendency to pull you away from programming. The authors quote Pete McBreen, who says “as soon as a person stops practicing, her mastery fades.” This is a pretty succinct description of the problem at play here.

In this pattern we are introduced to a new skill, which is using increasing positions of authority to construct your own work environment in such a way that you don’t fall out of practice. It’s something I had really never considered. Even though I’m used to being complimented on my programming skills, I had never really imagined stable work in software development at anything more than an entry level. In retrospect, I’m not really sure why.

Unlike some of these patterns, I think this one is a lot harder to disagree with. It doesn’t offer many opinions on what honing your craft entails, only noting that you need hands-on practice to stay good at the job, and exploring ways of staying in that practice.

I appreciate the suggestion to leave an inflexible workplace rather than continue on while your practical ability atrophies. I’m not really sure if I’m on the same page with the authors most of the time, but this sentiment in particular is one I am pretty strongly on board with.

The only thing I’d add is that I think it’s a little narrow minded to think just of one’s own development of their craft as an individual negotiating with various employers. Aside from making it easier to negotiate, another benefit of organization between software developers that I think would benefit them uniquely is that it could be an enormous opportunity for the refinement of software as a craft in general.

Rather than the same debates happening over and over on an individual scale, we could come to shared conclusions and move forward as an industry. It would also be nice to have proper training the way most trade unions have, rather than kind of soaking things in on your own alongside a college course or some random tutorial you found online.

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

In this section, we recall that the best motivation for programming is enjoying the activity itself. However, real life work conditions tend to get in the way of this enjoyment. The solution proposed here is essentially to stick it out for the sake of your long term goals.

I liked the quote from David Hoover at the end. I think it’s a pretty apt description of what it’s like to have fun doing meaningful work. I also really liked the brief description of Obie Fernandez’s career, in which he became much more successful and talented by diversifying his skills. As someone with a lot of different ambitions, I find it pretty aspirational.

As far as how this has changed my thinking, I’m not really sure how to or even if I want to integrate this idea into my career. This is mainly because I don’t really know what I want to do, exactly. I think I might want to generalize it a little more.

My takeaway then would be to have more general goals that guide the specific ones. I don’t think that’s really a good way of explaining it but I don’t really have anything better.

What I mean by that is trying to connect general things I want, like financial stability or a reputation for talent, with actionable goals and actual things I can do. I tend to struggle with tunnel vision sometimes. It usually takes some thought to recall that the class I hate isn’t just what I do day to day, but also part of my degree. While I think what I’ve said above sounds kind of trite, I do feel like this section has helped clarify my thinking.

I’m also not sure if I agree with the dichotomy the authors give here, of writing easy, fun code versus writing difficult, but financially rewarding code. It seems pretty backwards to me. Personally, I think solving difficult problems is the most important and most rewarding thing a programmer does. When I imagine a terrible, unrewarding software job, I imagine one with no difficult problems. A position where the only thing to do is stitch together various APIs with no room for creative solutions or much thought at all.

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