While looking through my blogs, I came across a familiar acronym that I used all the time when it comes to developing software and system. The acronym is called “YAGNI”, which stands for “You Ain’t Gonna Need It” according to the blog “Automation Principles – YAGNI/Premature Optimization, It’s the principle of extreme programming that states a programmer should not add functionality until deemed necessary. The blog takes about how many engineers will spend multiple hours trying to build the “right system” the first time. In some cases, trying to build a flawless system in the first go can be rather difficult to achieve. The problem is that programmers spend too much time worrying about efficiency in the wrong places and having that premature optimization can cause more harm than good. The blog goes over Big- O notation which explains that it does not care about constants but the long-term growth rate of functions. This is a good rule to consider because having to introduce something before a fraction of the code is even written can make a program a lot more difficult to support as explained, it would increase design considerations, the likelihood of race condition, and the ability to troubleshoot. Optimizing certain processes might not lead to any time savings or real optimization. In fact, it could do the exact opposite, a good example that the blog states are when using Python, constructing lambdas and list comprehensions over simple for loops. The blogger has mentioned that in his personal experience he would add non-functional requirements, such as authentication and logging, too early, adding features before needed. With that being said, I remember spending so much time on adding the ability to connect my bank to my finance application, that I didn’t have the time to code the application itself. The blogger talks about network automation which explains more about how networking is all about speed and not creating YAGNI isn’t really in the cards. They would go into detail about real-world examples when it comes to the network automation process, explaining issues about multithreading, in which he explains that overloading the TACACS server with too many requests at once is very problematic, or scaling wide too fast can cause processes to slow down and too much resource utilization, overall, it’s very inefficient. Configuration Generation takes too long and is very inefficient, and with all these in mind, the blogger isn’t trying to not consider tomorrow’s problems but is more in line with building things up as they go.

“Automation Principles – YAGNI / Premature Optimizations” :

https://blog.networktocode.com/post/Principle-YAGNI/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

This pattern explains the benefits of reading real world source code. If you are on an assignment and are asked to write a small component for the project, your most important task should be to read through the code-base and understand as much of the source code as possible, given the time constraints you are under. It is important for you to understand the intent of the application at a high level before studying the code, but then to immerse yourself in how the code works, how it is structured, what design patterns are used, how the class hierarchy work, and which developers were involved in the project. In most cases, it would be a mistake to try to learn all the project’s code, unless it were quite small. Consider understanding the code involved most closely to your intended assignment with the most priority. Most projects you will encounter are medium to large scale applications, and some would take you months to adequately understand.

Try meeting with the developer who wrote code most similar to what you are being assigned , and ask for tips and tricks on methods they used to build their pieces.

If you are asked to write, for example, an android activity that calls REST API’s, look for related YouTube videos, Google documentation, related code on GitLab or GitHub, textbooks, stackoverflow.com posts, and college library references, but most importantly, look directly at the code-base you are working with to find if similar code has been written which can be cloned, modified, and sometimes improved. I have worked on projects where the same basic code had been written more than once! Refactoring an application to remove repeated code, or to consolidated similar code is a huge time saver. There is nothing like management giving you a month to write something, and you come back in two days with it done. This is the type of “magic” you can accomplish if you are observant of the resources that already exist in your project, and the Open-Source world in general.

I also think it is important to read through code you have previously written. If you have resume entries stating you know a particular language or technology, a more than rudimentary understanding of it is really important for your next review or interview. As your career develops, the list of these items will increase, and some will become somewhat obsolete, so it is much more important to understand the most recent skills best. If you can’t recite a paragraph or two on any given entry, I would consider removing it from your resume.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

This pattern describes the benefits of maintaining a reading list of books on Computer Science. It suggests that you list of “Long Lived books” you have already read, as well as listing books you plan to read in the future. It reminds me of a number of books I have read that are essential reading for any developer. I have read “Code Complete”, “Writing Solid Code”, “The C Programming Language” by Kernigan and Richie, and a few others that are truly “Long Lived Books”. It is interesting that these books have stood the test of time in such a strong way, considering the accelerated progression of technologies. Most technical books and periodicals do not fall into this category. An example of this from my own experience is the plethora of books that appeared on the market when OLE, COM, and ATL became popular in the late 90’s. I bought at least 6 of these books, and they became obsolete rather quickly. As soon as a new release of these technologies occurred, a number of relatively poorly written books were pushed onto the market, having been written by authors who were more concerned with “time to market” than quality of information. Ultimately a “Best in Breed” book would appear, but this usually came out months after the release.

Your list should also contain books that you plan to read, sorted in order of importance to what you need to know currently, as well as those that you have discovered fit the category of long-lived books. Strongly favor the ones that have been recommended to you by mentors or peers but do your own research to find others. I have been helped over the years by periodicals. The better of them tended to have the better quality of writing at times of product release than most of the books being pushed at us. Some of my favorites are (were) MSDN Magazine, Microsoft Systems Journal, BYTE, Wired, PC magazine, and Computerworld. Keeping up with the mags was more helpful to my career than any of the books, with the exception of a dozen or so of them.

I kept a list of the books and magazines I had read I thought were important on my CV. This way, I was able to update my reading list whenever I was updating my resume. This kept the list fresh and up to date.

Now that we are exposed to audio books, blogs, podcasts, and YouTube videos, I tend to get most of my knowledge from them than from traditional books and periodicals, but the basic concepts of this pattern stand firm.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern encourages apprentices to record what they are learning, in either a public or private place (or both). Either in a blog or wiki or even just a personal journal. Each has its pros and cons, but in each instance, they allow you to look back and reflect on what you have learned, what you were having trouble with and can give you a map of where you have come from.

While I was reading this pattern, I couldn’t help but think of this blog itself. While at the beginning I thought of this as something I would only ever use for class, I can see myself updating it in the future to be a far more professional blog space where I can record my experiences in my professional career. Even in the past year, I have found myself checking old blog posts about other patterns I read about to form connections between them. Like the Breakable Toy pattern, where I talked about starting a wiki being a good idea. That feeds right back into this pattern, already showing its effectiveness as a tool.

I never really thought about writing being a part of this field, but as someone with an innate interest in writing, and who has gone so far as to minor in it, I am really excited to see that this is a larger part of the lifestyle of other software developers. I hope to be able to continue writing, either professionally or as just a part of my own journey to mastery of the craft. It is something that has always been a big part of my life and being able to do it in conjunction with software development is really important to me. I think that this is as good an outlet as any for that seemingly unrelated skillset.

I don’t think I disagree with any part of this pattern really. I guess if I had to pick something it would be uploading it for everyone, but even then I think that way of doing it has some value, I just think you should have something private as well. Overall, it’s a fairly straightforward pattern and aligns with what I enjoy doing anyway. I’ve been looking into using Obsidion as a wiki-creation software, and I think that it has potential for this sort of activity. Clearly, this is a fairly common practice within the industry and I hope I will be able to find the motivation to keep up with it as my career goes on.

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

Summary:

This apprenticeship pattern deals with a software developer that cannot afford to learn by failure. This software developer may work at a company that must get things correct, and thus cannot experiment and learn from his mistakes. Thus, this pattern recommends the developer to create his version of his work’s program in private, to experiment so he can learn.

I want to say off the bat that I do not disagree with anything stated in this pattern. In fact, the most I’ve learned has been from practicing and failing repeatedly, so I strongly believe that this is a very important pattern for all developers.

This pattern has helped me greatly in my understanding of development. For example, in one of my homework assignments that required me to implement an algorithm that sorts operating system “jobs” by time to process, I wanted to use what is called a “MultiMap”, that is to say, a Hash Map that allows duplicate keys that could then be sorted, by key or by value. After this assignment, I spent hours trying to figure out its implementation, and I eventually figured it out. By following this pattern, I was able to figure out more about Java types, and I taught myself how to use hashing algorithms. 

I find this apprenticeship pattern very interesting. I bring the above example up because what I find interesting about this apprenticeship pattern is that I never thought to apply it to my work projects. There is a lot of information that I’m learning about when I’m working outside of school, and this pattern has indeed changed the way I think about how I will work and what my profession will steer me towards, and vice versa. 

I will try to create a private project with homework or work in which I implement the project differently, and try to see if I come up with any valuable results. There are many things I’ve learned from applying this principle to a few homework assignments or free time projects, but I can feel that this would be very beneficial in trying this with new systems, or alternate pre-existing ones from school or work.

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.

               Many of us have heard or said the phrases “Practice makes perfect” and “Repetition is the mother of all learning.” Though I personally can neither define perfection nor learning, I can say that no one can gain expertise off anything they see once and never apply again in their lives. Even though we may understand a new concept that we learn at first glance, it is when we repeatedly work on it hands on that we can truly experience the nuances that are introduced. Continuous practice is known to help considerably during the learning process, as one works to internalize the knowledge that has been introduced to them. This is also a pattern introduced in the book “Apprenticeship Patterns” by the name “Practice, Practice, Practice”. Though the name of this pattern is rather straightforward, it is important to emphasize what makes this pattern and important component of the learning process.

               Simply put, “Practice, Practice, Practice” is a pattern that is meant to address an apprentice’s potential hurdles that may stem from neglecting to practice their craft hands on and on a frequent basis. As such, apprentices may not have a proper understanding of where their strengths and weaknesses lie, thus their learning reaches a point of stagnation. However, if an apprentice only takes the time to practice what they learn in a work environment, they may end up hindering their own growth since they add the stress of having no room for error on top of learning something new. As a solution to this hurdle, apprentices are advised to find exercises to practice on at their own time and pace and in an environment that treats any mistakes that come up as opportunities for learning rather than signs of imminent disaster. That way, an apprentice can take the time to properly learn and improve their craft. What may also help is communicating with experienced people that can point out any habits that may be counterproductive in one’s learning and provide the appropriate feedback that an apprentice may need.

               With that being said, I want to point out that I have not mentioned the words “programmer” or “developer” when discussing this pattern, even though I believe it is by far, in my own experience, the most crucial pattern stated in this book.  In fact, I personally try to get my peers, as well the people I help at my job, to espouse this pattern and incorporate it into their own learning process. Though I disagree with the notion that “practice makes perfect”, I wholeheartedly believe that actively practicing new knowledge in an environment that allows mistakes can do more to help an apprentice learn in the long run.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.