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.

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.

For this weeks topic, something I that I chose to learn more about and get a better understanding behind of is YAGNI; which stands for You Aren’t/Aint Gonna Need It. To supplement my understanding for this topic, I watched a small conference video about a Software Architect, Ian Thomas, who gives a talk about the importance of YAGNI in real world environments. Throughout the talk some of the main points were that YAGNI reduces costs, and he also gave fixes or solutions for promoting YAGNI in work environments; and he also gives examples from his experience to better explain the importance of YAGNI.

Throughout the talk, I enjoyed some of the quotes and references he brings up because I thought they were powerful and changed my perspective of the software industry. In his introduction he brings up a Uncle Bob quote, which was ‘the number of developers in the world doubles every five years’; and then he points out that means half the developers entering the markets have less than 5 years of development. This is actually a worrisome quote when considering that one of the less experienced developers may be working on an airplane or automobile system that I may use in the future; however, Ian brings up this point because it ties to another reason for promoting YAGNI. This benefit of YAGNI is making material easier for new hire ups to understand and pick up; he refers to this as carry costs improvement.

Out of the other costs benefits he covers, he says that reducing carry costs is an important benefit of YAGNI often not acknowledged; it is also one I was not aware about. Carry costs may refer to the impact given from writing a new feature and when YAGNI is not upheld this often means that a new feature is overly complex, which would mean that it would take someone too much time to read before adding on or working in conjunction with that feature; this would also make it harder for new hire ups to pick it up. It appears that the code smells needless complexity and obscurity are byproducts of the absence of YAGNI in code.

Rather Ian mentions something important to think about when writing a new feature. A recurring theme that he brings up is thinking about the future; and so think, about writing/refactoring in a way that it’s not going to be too hard to write later on because you’ve taken the time to leave it in a good state now. And the quote he used for this was “it’s better to do a simple thing today and pay little more tomorrow to change it if if it needs it, than to do a more complicated thing today that may never be used anyway”.

And his takeaways to keep up YAGNI were narrowed down to keep things simple, to change things in small increments and also test them so you get to understand how the system is working and what you’re doing for your customers. Also he advises having courage in being able to stand up and explain why you are doing something and need to take the time to do it.

Link to Video Below

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

The pattern “Stay in the Trenches” talks about how you should avoid climbing into management or other positions that don’t involve coding when offered them. The pattern suggests that you suggests alternatives, such as pay raises and other incentives that can be offered to you, if a person is offered a job in management or another job that pulls them away from coding. The pattern also talks about how taking a management job can lead to loss of skill when it comes to programming since it wont be a daily occurrence for the person in management. The pattern talks about how a person should, as the name suggests, stay in the “trenches” or in a position that involves coding directly and where they can continue their craft. The pattern hopes to convince people that they should focus on excelling in their passion of coding and find other ways to be rewarded for their work, instead of pulling a person away from coding.
I feel like this pattern makes a great point that was discussed in the pattern “Practice,Practice,Practice”, which is that when people don’t code for a while, then they will most likely see a drop in their coding abilities and lose most, if not all, of the progress they have made. I think it’s important for any person in the computer science field to do things that interests them the most, either with the work they do, a side project or both. I can see myself continuing side projects of my own as a hobby even when employed in a coding job to not only further my skills, but to do things that I find interesting, fun, or both. I don’t fully agree with this pattern and believe that if offered the opportunity to get into a higher position in a field I’m interested in, I will, most-likely, take the opportunity as a chance to further my career and myself as person. While coding will always be one of my passions, I can not stop myself or hold myself back from trying to reach higher and higher goals in my career and life.

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

With the final sprint of the semester underway, I have had to learn several new technologies for our LFP microservice over the semester. This has led me to obtain only the necessary knowledge to move forward in the project. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman,by Dave Hoover and Adewale Oshineye, has a pattern that addresses this problem: “Dig Deeper.”

“When you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge. Your goal should be to understand the historical context of the concept and whether it is a special instance of something else.”

The apprenticeship pattern, “Dig Deeper,” discusses the downfalls of having a shallow knowledge base and the need for obtaining a deep knowledge of how the tools and technologies work. There are several advantages to having this level of understanding, including: improving confidence, providing a starting point when joining a new team, and improving interview skills. The pattern refers to programmers with this knowledge as “cathedral builders.” These “cathedral builders” can debug, decompile, and reverse-engineer code. The best way to obtain this knowledge is to read specifications and familiarize yourself with debuggers.

The need for this pattern’s practice is like the need to learn history. Learning the history of a tool or technology will prevent repetition of previous mistakes and illuminate the reasons for the inner working’s current state. In addition to learning the history, it is important to dive into the different layers behind the tech and learning how the system works as a unit.

I realize my current understanding of the technologies I have been using for our LFP microservice is shallow and now, I have a direction I had not thought of looking into yet, debuggers.

A problem I have with this pattern is deciding where to start, as any time used to dig deeper is time that cannot be used for learning a new tech. This problem will likely resolve itself, though, once I decide upon a career path. For now, I can just dig deeper into our LFP microservice’s technologies: MongoDb, Node.js and its packages, angular, docker, and all the testing frameworks.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.