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! 

Source: 

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

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.

            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.

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.

For this week’s blog post, I read the section  “Record What You Learn” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The section started with a quote by Atul Gawnde in which it states: “You should not also underestimate the power of writing itself….You can lose your larger sense of purpose. But writing lets you step back and think through a problem” This reminds me a lot of myself because I am usually the one that never writes anything down, Instead I will believe that I can remember it. However, later I forget it. As I get older, I realize that recording something is useful, for example, if we are doing a project sometimes it is a good idea to draw diagrams and analyze through writing which helps to organize and plan it out. The section mainly talked about the practice of keeping a diary or a journal that will be useful throughout your career. The author also mentioned avoiding falling into the trap of just writing down your lesson and forgetting them, which I have done several times.

Keeping a journal of what you learned and going back to read it regularly will help you review the materials and give you a vital resource to draw upon. I read in an article that Psychology research and learning experts suggest writing things down leads to better learning. When I think about it, it is quite true at least for me I learned better by writing the materials down. Another interesting insight I read on the section was “By reviewing your journal, you can switch your past and your present around to generate your future” This is such an amazing quote and I hope that from now on I can keep a journal and look back at the things I have recorded. This pattern changed the way I think, it has given me new insights and inspires me to start jotting down my thoughts. I hope Over time these entries help to write an article or even a book regarding the journey of my life.

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