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

Summary:

This pattern is based on newer programmers that have not had as much experience in the field not having reference to earlier works that were instrumental in the development of the field of software development. The newer programmer will have less reference in understanding the context of how things are the way that they are in the industry, and will be surpassed by his colleagues who know the literature and understand laws and phrases used.

What I find most useful about the studying of classics in a field like software development is emphasis on trends of the industry. Programming languages and projects can come and go, but if classic literature can be used regardless of the time period that is read it implies that there is general education that can be done that transcends simple programming or development.

This apprenticeship pattern has somewhat changed the way that I think. I know that I would probably have to learn terminology that is important to software development, especially when working with teams. This apprenticeship pattern has, at the very least, made me more interested about learning classical literature in the field. Although on the other hand, it seems a bit difficult to me to disambiguate which type of classical book to read, and which type to not read. The pattern references “When you pick up a book and the first thing you wonder is how out of date it is, you’re reading the wrong kind of books”, but I’m not entirely sure how to come to that conclusion. Although I’m assuming that I can gain proper reference via an article.

I do disagree with this pattern a little bit. Studying a lot of classical literature seems to me like a dedication that can take a lot of time and energy. I think if I want to expand my education on classical matters such as Brooke’s Law, it may be more beneficial to read a second hand source that aggregates classical laws and their contexts rather than reading some of the classics cover to cover. While my view here might be ignorant since it is only based on this short pattern, it is the impression that I get from it.

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