Category Archives: Week-15

Apprenticeship pattern: Practice, Practice, Practice

This week I decided to write on chapter five about practice. This pattern really reflects the reality of life. Everything, if we want to master or succeed, we need to practice in order to get better every day. To improve, if you routinely practice something, the likelihood of you doing better on something is higher.

This pattern is telling us the importance of practicing and that the performance of our daily programming activities does not give our room to learn by making mistakes. But taking time to practice our craft without interruptions, in an environment where you can feel comfortable making mistakes. As software developers, we need to practice in order to grow our knowledge and skills. I love how the author says: “The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions.

The importance of practicing is that every day, there is a new thing that we learn, do something a little bit different each time an exercise is performed. As software learners, practice is our best friends, so are curiosity and determination. We can go far and become those great craftsmen if we put up the work and are willing to make sacrifices. Then, we will master and become thos great software development.

One thing that I will always remember is that we should never forget about The Long Road. That we should be patient and accept difficulties, so we can challenge ourselves and master in what we are doing.

In reality, regular exercise for software developers can help improve our brain, memory, problem-solving skills, and overall mental agility. Things that are rarely talked about but necessary in our daily lives, especially when dealing with complex problems such as developing new components, solving bugs, or even having architectural or difficult meetings.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Retreat into Competence

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.

Familiar Tools

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.

Apprenticeship Patterns: Retreat to Competence

                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.


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.

Crafts over art


Craft over art pattern makes an important point about quality over beauty. Pattern points out the ugly truth that “For a craftsman to starve is a failure; he’s supposed to earn a living at his craft.” A scenario like this can happen when the craftsman is not skilled but mostly occurs when craftsman decide to prioritize art over their craft. Craftsman should build a software based on the product owner’s need and not just indulge their desires. It is a craftsman’s responsibility to develop a software that is beautiful. However, this should not be done by sacrificing the utility and productivity of the software. The pattern provides a solution which uses a fifty-fifty line. The craftsman should develop a software which is aesthetically pleasing and feature rich. Creating something that is beautiful and has no use is not craftsmanship, it is a waste of craftsman’s skill and time.

Another aspect the pattern covers is that as craftsman, we need to prioritize product owner’s needs over our own. As craftsman we cannot make excuses of not being in an ideal artistic environment; we need to create a quality product that satisfies the product owner in the provided time frame.

However, craftsman should not do merely do what is expedient. The pattern states us to adhere to our standards even under high pressure. The pattern further explains that based on the product owner’s requirements, sometimes we will need to switch priorities between productivity and cosmetics. To understand, achieve and maintain all our standards, we as craftsman need to understand craft and art are not mutually exclusive but interdependent.  

Why this pattern?

As someone who just graduated and is joining the work force as a software developer, craft over art pattern can be used as a moral compass. Programming is without a doubt a form of art especially if I am working on frontend or User interface. I have been hired by a friend to create a website of his family’s construction company. They wanted a simple website with description of their work, prices, and contact information. I spent hours looking into themes, designs, photos, and live photos and barely any looking into features. After reading this pattern I was able to reorganize my thoughts and let my friend know all sorts of features I would be able to add into his website. He was pleasantly surprised with my suggestions and his family even offered a raise. The pattern helped me stay true to the programming and not get lost in the aesthetics of it all.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

CS 448 Post #8

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.

Apprenticeship Patterns: Expose Your Ignorance

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.

Stay in the Trenches

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.

Sustainable Motivations

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.

“The Deep End” Apprenticeship Pattern

This pattern compares the rigorous process leaving your comfort zone in a programming work environment to learning how to swim in the deep end of water. But it is a little more intense as it explains the scenarios of the water and your ability to swim. There are going to be job opportunities that might in fact be out of your skill level.

There are also jobs that might be out of your skill level but not out of your reach. Meaning, if you can reach the skill level with hard work and determination, you should go for it. Just put in those extra hours for however long it takes at the new job to catch up. But also, you need to be able to recognize your own abilities. If you can’t reach, there expectations consider other options.

The pattern includes strategies on what you should do if you find yourself struggling to keep yourself afloat in an environment filled with deadlines that you are struggling to meet. It really tries to touch on the possibility of the worst. As in, if you were hired and you are struggling to meet project deadlines. What should you do? That is what this pattern really tries to break that down how to take one step back and regain.   

I thought this pattern was extremely thought provoking. And really instilled in my own anxieties about my future in the field. What path do I want to dedicate my next year, my next five years, my next ten years? This pattern changes the “Long Road” into the “Intense River”. And I am trying to figure out what river I want to kayak on. Will I be safe going down an intermediate river? I need to create skills that will allow me to adapt.

This chapter also causes me to address my own faults and indiscipline’s. The Software field the way I see it requires a true passion to get better every day. I am all for that. That is exactly the type of thing I need to do something for the rest of my life. It is extremely exciting, but the severity is certainly no joke. I have a lot to improve on to contribute to some of these amazing things we are seeing today.  

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.