Category Archives: Week 12

The Deep End – Apprenticeship Pattern

In this post, I will be writing about “The Deep End” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This apprenticeship pattern is for software craftsmen who feel that they need more experience and need to be challenged by complex problems and bigger projects. This pattern suggests that these people jump in at the deep end and just go for these challenges.

Waiting until you’re ready for too long can turn into never taking that next step and therefor never moving ahead. Rather than a plateau where you are consolidating your skills, you can end up in a rut where your lack of growth turns into mediocrity. This book suggests when offered a high-profile role, difficult problem, or large project, accept these offers. Even if you don’t feel ready, there is a reason these opportunities are available to you and you should take these opportunities and hold on tight. As the authors stated, “risks are opportunities seen through half shut eyes of fear”. Growth can only happen when you take on scary, challenging jobs. This does not mean lying to get a job you cannot do or not prepared for as you will definitely be in over your head. It means taking the opportunities as they are presented to you.

An action suggested by the authors to help you get started with this pattern is to think about your biggest most challenging projects. Write down the complexities of these projects as a reference for your new projects. Answer questions such as “what is the biggest codebase you have ever built on your own?” and “what is the biggest, most successful project you have ever worked on?” in terms of number of developers and size of the project. Find a certain way to use these questions on all of your past projects to use them as a metric or index and write it down. This will help you gauge where your next projects fall compared to you past ones. Using this chart or diagram will help you figure out which way your career is going and whether you are growing as a developer.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Concrete Skills

The section “Concrete Skills”, found in chapter two in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye discusses the issue of needing some quality that will convince hiring managers to choose you over other candidates. In particular, this issue centers around the question “If we hire you today, what can you do on Monday morning that will benefit us?”. The solution the authors suggest is that one should develop concrete skills. What they mean by concrete skills is abilities that show that you don’t need to be babysat such as writing build files in popular languages or having knowledge of popular open-source frameworks. Skills like these show people like hiring managers that you have something of worth outside the basic skills expected of an entry level position. In the long term, the specific skill doesn’t matter too much as it’s just a stepping stone to the path to journeyman.

A concrete skill isn’t something that I’ve put too much thought into. I guess some could say that skills I’ve learned in class like knowing how to use docker or SQL would count as concrete skills, but that depends on the position I apply to. There’s also the projects and work connected to my GitLab account which I could show to a potential employer. Still, I have this feeling that it won’t be enough since most of my peers have a similar advantage if not more. That’s why I feel that I should do some independent study, not an internship mind you, something that I can do on my own time.

I feel like I could showcase a concrete skill by working on a personal project which I’ve been toying with but haven’t settled on a specific plan. I’d like to make a simple chess program, partly just as an excuse to learn the game but it would also be something to show to say “this is something I’m able to do and contribute”. I don’t know what exact skill this would convey; it could be that I’m proficient in so and so language or I can make a program by myself even if it’s on the simpler side. Despite my lack of direction right now, I feel it’s still worth a shot.

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

Expose Your Ignorance

This chapter’s opening quote was a very insightful one for me. It says: ” Tomorrow I need to look stupider and feel better about it. This staying quiet and trying to guess what’s going on isn’t working so well.” The whole point of this chapter is that there are going to be times when you do not understand what is happening, what you need to do, or how to accomplish the task at hand. This is ok. Even if there are people depending on you to just know the right answer you will not always. You must ask questions and show that you are capable of learning how to do your job. That is how you grow as a craftsman.

“Expose your ignorance” is a pattern I have a lot to learn from. The opening quote talks about staying quiet when you do not know what is going on and that is something I am often guilty of. Just like the author says, I am afraid of looking incompetent. I often feel this way despite knowing I am not yet expected to be a competent programmer; if I were then I probably would not be in this class (I would consider some of my peers to be pretty competent though). As I student I am surrounded by professors who are literally being paid for me to expose my ignorance to, and they are happy to hear it. I am confident all the faculty in the CS department would love to hear more students ask questions and admit they do not have any idea what is going on. Most classes are silent though, especially in online courses. I am not sure if it is from a lack of interest in the course, the difficulties of online courses, or a fear of asking questions (it is probably a combination of the three.)

Moving forward I will really keep this pattern in mind, both as I finish this course and as I go out into the workforce. Not knowing everything does not mean you are not good enough. It simply means you are not good enough yet. Asking questions and actively working to improve shows that you are willing to put in the effort to become better.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

A Different Road – Apprenticeship Pattern

What this apprenticeship pattern talks about is completely different from a typical software architect approach. This pattern talks about what you should do if as you go on the long road and your journey as a software developer, you stumble on something different that you feel would be beneficial towards. It gives an example of how some software developer completely left software development to teach surfing half way across the world. There are many examples and situations as to why someone may not want to be software architect anymore. However, no matter the situation, this pattern talks about how it isn’t a good decision to just burn bridges and forget everything you learned on your journey in developing code and all these other technologies that you put in time to learn. You had many systems that you learned to do things and implemented them in order to do things faster and be able to learn many new things at a faster. Instead of just leaving all this behind, the pattern says to use all that knowledge and move forward to apply it in your new field whichever direction that may be. It is never helpful to just forget everything if you start something new but to learn from your experiences.

This pattern may seem kind of odd to software developers and architects since they want to develop code, but this can be helpful down the line. I would say if there is something you like differently down the road then this pattern will be very helpful. It does not need to be specifically about completely changing fields and you entire lifestyle till then. It can also be related fields in computer science and the direction you want to take. Let’s say you were a software developer for many years, but there comes a time where you are more interested in the big data field and want to make a switch. You feel it will be more beneficial to your life so whatever the reason be, you can still hold on to the principle as a full time coder and applying to the other field. In this way a lot of things are connected and it will be helpful to manage change. The main thing I would say in life is to be comfortable with the idea that you may not be familiar with the change at the moment but you have to trust the path you will take to find those solutions.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Expand Your Bandwidth

For this week’s blog post, I read the section  “Expand your bandwidth” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The main reason this pattern was Interesting was because of a quote that stood to me. It was “[L]earning about what we don’t know is often more important than doing things we already know how to do.” This quote is so accurate. Especially in a technology-driven world, it is always evolving. so, developers must learn new technologies and software’s all the time. It is important to prioritize learning what you do not know. Later in the section author mentioned the overwhelming aspect of learning new information and expanding your ability, it is important to expand your knowledge and experiences in multiple dimensions such as: reading a book, social media, blogs Groups, and other academic resources.

The second half of the pattern talked about how Once you understand how to Expand Your Bandwidth, the next step is to understand when to Expand Your Bandwidth. Developer needs to use the skills you accrued wisely, or you may end up in the state of being become obsessed with gathering and consuming new information, particularly as it becomes easier. This can lead you to  “accelerate your learning, it will slow down your development velocity, and therefore will have diminishing returns if applied for more than a few months.”  I also liked the story that was mentioned after reading Kent Beck’s Extreme programming in which how it inspired the author to expand his bandwidth by attending a local agile software development group and the outcome was getting a new job with the new experiences that was acquired during which changed the career and apprenticeship forever. This pattern has most definitely changed the way I think of learning new skills. I think it is important to expand my bandwidth by taking new opportunities that are out there now. This reminds me of our capstone class, we learned multiple new software’s which did expand our bandwidth and I am thankful that we did get to use much software that is used in the workplace. hopefully, it will also change our careers. 

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Breakable Toys

Having covered recording knowledge in the previous week, and specifically considering the conclusion I arrived at, it was only logical to cover the Breakable Toys pattern next. For those who missed that post, I determined that the best method to keep track of previous knowledge was to use a breakable toy that others could access. This would allow one to both record any information, create a potential feedback loop if others can access this information, and finally just get experience by building and maintaining this toy. But this all begs the question, what exactly is a breakable tool?

These toys can come in a variety of forms that can be decided based on your own interests, but each should be a software project that you will complete on your own. This can range from a wiki or a blog to a calendar or even a video game, but there are some important points to keep in mind about the purpose of these toys. Of course these toys will be helpful in your growth as a software developer, but in order to reach a sufficient level of development on these projects you must maintain your motivation. When choosing a breakable tool to create, ensure that it is something that you know you will enjoy developing further down the line. This may sound obvious, but there are many times where I myself have dropped projects after the initial excitement dies down. Furthermore these toys do not have to be complex, especially at the outset of their development. While it might be tempting to have a vast amount of features to implement in this new project, and it may come from a place of genuine wanting to learn how these work, you should keep in mind that this toy can be developed over a long period of time. Focus first on developing the toy in its most basic form and slowly build on it as your development skill progress, allowing for even further growth.

In summary, these breakable tools should be personal projects in any form that interests you and should be something you return to for further development. This pattern has changed my view from what I said in my previous post, as I was initially going to make a wiki or blog. If I am being honest with myself, making a game appeals to me more than many of the other options for tools that I had listed. I have been playing them for a long time and have always had interest in developing one, especially working on an AI system within the game. Once again I had nothing to disagree with, this was a great read! 


From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Craft over Art

            The learning pattern “Craft over Art” from the Apprenticeship Patterns book is one that cuts out a lot of the fluff. Essentially, this pattern boils down to solving problems as a utilitarian rather than an artist. Concerning a customer’s problem, the pattern says there may be the draw towards making something beautiful and letting the craftsmanship creativity flow, but not if it hinders progress. At the end of the day, the customer is asking for a solution, not a bunch of new ideas. This isn’t to say that artistry in software development should be scorned at all, but moreso that it should not be the focus of one’s work. Utility is key.

            Luckily, I couldn’t agree more with this learning pattern. Although I’m definitely not the most attracted to fancy/beautiful code (I don’t really feel compelled to write code in a way that does anything besides work and fulfill good code standards), I definitely fall into the pit of overcomplication. I see this learning pattern tying in with the YAGNI (you ain’t gonna need it) principle. When fun and complications can come in making a good product or customer solution, then great, but if it gets in the way, it should be cut down. Typically, I think I follow this in that my code is more minimal (really saves time and space when you aren’t attentive in commenting/documenting code lol), but I am still prone to veering off.

            Just recently, I was working on a personal project. It wasn’t anything big or special; it was mostly just to run some simulations and get some example results for a separate but much larger and more important project. In doing this, I thought I could try some new programming concepts and I tried to complicate things on every level. This led to janky, barely useable code which I wasn’t sure why it worked or why it didn’t work. I was having trouble telling up from down and left from right after a good 2 hours spent writing the code. So, I switched things up. I got rid of all the complicated stuff and wrote the code for the program as I had initially thought of it, the same way I could’ve completed it with my level of knowledge freshman year. In 15 minutes, I had completely re-written the code, but it was working and completely understandable. Unfortunately (and sometimes, fortunately), artistry is not what sells in the software development industry.

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

Apprenticeship Patterns: Taking Notes

Yet another post, yet another shockingly related issue addressed by these patterns. The pattern for this week being Record What You Learn, something that is particularly relevant with online learning being the primary method of schooling for most. I have found that, throughout my classes, I have forgotten a significant amount of the minutiae for some of the older projects I have worked on, or even some coding languages I have learned. One way to solve this issue would have been to have a more defined method of documenting what I have learned and worked on, and this pattern has given me some ideas of how to do this.

With a problem as general as this, there are a variety of solutions one can implement. There is the most obvious method of doing this, being to keep a blog about what you learned. The benefits of this are straightforward, as it not only allows you to keep track of any important information, but also allows others to view it. Not only can this help others who are encountering similar problems, it allows others to provide any knowledge they have gained with you. This creates a feedback loop and will undoubtedly aid in remembering this information, as you can also implement changes to any blog posts based on feedback. While this is certainly an effective method, it is not my favorite and keeping a private wiki seems more appealing to me. This, however, has the downside of losing that feedback loop, as it is purely for your own use and maintenance. The option that appealed most to me was to meak a breakable tool that can be used for the record keeping. This allows you to not only record, and potentially share based on the nature of the tool, information learnt but also learn more through the process of utilizing the tool itself.

Everything said in the pattern sounded reasonable to me once again, so nothing to disagree with. If you cannot maintain your knowledge on the subjects you learn, it will slowly decay, so this must be offset. I have realized that, to truly learn this new information, you have to continually engage with it in some manner. Be it through a thoroughly maintained blog or breakable tool, this is the way to retain the learnt knowledge. 

From the blog CS@Worcester – My Bizarre Coding Adventures by Michael Mendes and used with permission of the author. All other rights reserved by the author.

Breakable Toys

 We can all benefit from writing random “toy” programs to push ourselves to the limit by setting artificial limits. — Donald Knuth, The Art of Computer Programming

If you can learn as much from failure as you can from success, you need a relatively private space to look for the loss. In balling acrobatics, a performer who tosses three balls will never progress if he has never tossed five. Those who spend hours picking dropped balls until their back hurts eventually get good at it. The same lesson applies to software, where software workers often need to step out of their comfort zone to try something they’re not good at it. It is by taking bold chances again and again that you improve your skills, that you learn and grow from failure after failure. Just as a three-ball-tossing performer does not throw five balls in a formal performance, software developers often make mistakes in new areas. Software developers also need a safe place to make mistakes. It’s terrible not to have such a safe place to make mistakes. The fear and unwillingness of software developers to make mistakes make them stuck in a rut, unable to learn from failure, and thus makes the entire software development industry staid and stagnant.

Other examples of the “crunchy toy” pattern include games like Tetris and Tic-Tac-Toe. One senior I know has a habit of using every new language he learns to create a game, blog software, and IRC client. The nature of the problem is to build a toy that contains learning something new and provides an opportunity to let you in a special environment to deepen the understanding of hand tools. The environment is not only safe because you are the only or most influential users, and, even to the most powerful commercial products, you still have room to serve you as a user’s needs better.

You still have to remember that they’re just toys, and that’s why they’re supposed to be fun. If they’re not interesting, then when the initial excitement is over, they’ll just become a dusty relic, and you’ll be able to focus your energy on what you enjoy building.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Record What You Learn

The section “Record What You Learn”, found in chapter five in Apprenticeship Patterns by Dave Hoover and Adewale Oshineye, opens with the common saying “Those who do not learn from history are doomed to repeat it”. This section focuses on the practice of keeping some sort of diary to record what you learn throughout your career. Doing so has the benefit of creating a useful resource that can be referred back to at any time. It also has the added advantage of finding like minded individuals by finding common ground in what the both of you have learned. Both authors see these benefits since they also keep records of what they’ve learned. Oshineye uses two instances of the wiki, one public and one private, to share lessons he’s learned with others and give honest feedback to his own progress respectively. Meanwhile, Hoover kept a text file of references and quotes which eventually grew to such a size that he decided to publish it online for others to use. What separates this design pattern from another such as “Share What You Learn” is that “Record What You Learn” focuses on preserving the road you took to mastery so that you or others might learn something new from it.

While I haven’t reached mastery yet, I do generally try to write down what I learn. Admittedly, I partly do so I won’t fall asleep during lectures and I also often don’t go back to older notes. But I still notice some of the benefits like how generally more of the material sticks when I write down notes since I’m paying more attention to the material writing it down. And most of my older notes still exist, either digitally in my hard drive or physically in a stack of note books I keep inside box in the corner of my room. They’re still around and I can access them at any time which is one of the main benefits to “Record What You Learn”. So, when I’m talking to someone and they bring up a concept that I somewhat remember, I can open up my notes and refamiliarize myself.

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