Deepening my comprehension

Ah, I love learning. Especially when my learning is directed by need or momentum. This makes the progress more rewarding, and very meaningful.

My new emphasis of beginnings is a gift that is always there. Consistent, dependable and simple. I haven't coded yet. Because last night I began listening to a book, and then I continued listening today. You may have heard of it.

"The Pragmatic Programmer: Your journey to mastery, 20th Anniversary Edition" by David Thomas and by Andrew Hunt.

Great book. "The Pragmatic Programmer" book is what I need right now in my software journey. As my emotion and mental attitudes align up with flow, I need more technical mastery to go with that flow, and this book seems to fit the bill.

I went to purchase the book yesterday, but then I saw Amazon letting me know I already have the audio version. Huh. Didn't remember buying it. Then I opened the audio book and began listening. Ah right. I do remember listening to this book three years ago, but the time wasn't right. I still was in a shut down state. My physical illness made only a few mental activities available.  Safe to say I could not understand or practice what is in the book. I had to close the book unless I grew more depressed during my past state of being.

Now my time is different. I am ready to learn.

I listened through the "topics" discussing business attitudes, and now I am in chapter 2. Wow. Just a couple topics in, and chapter 2 is giving my mind some implosions. Not only do the principles being taught mesh well with my other, more personal, self-discoveries, I am also learning so much more than what I knew before. Just the first two acronyms are incredibly simple. Yet they are potent in design. I can see where my flow may open up in greater degrees.

The first one is E.T.C. I need to ask myself if the code is "easy to change?" 

Oh man. Simple, yet honestly, a little obvious. We all know hindsight is deceptive. You don't know until you comprehend what has always been simple and concise. In this case, simplicity is about good design philosophy. E.T.C is meant to take a more active role in your thought process, and it adds tangibility to one concept that contributes to resilient and flexible design.  E.T.C is designed to help software last longer and reduce regression over the software's project life cycle.

Anyways. This matches perfectly with my variance. It would be too tempting to go all over the place with my approach, but what if I purposely wrote code that was easy to change? This would take a lot of cognitive load off of me. Vanilla code that works but is intentionally set to be changed later. And the principle of E.T.C can be implemented in a variety of ways. 

Like one of the many examples the authors suggested, push some configuration to a config file.

I will add a couple of my own examples here. I am reflecting and deepening my understanding of E.T.C.

If I am creating a robust API then lean on encapsulation. Good APIs only describe what happens not how. And this makes the underlying methods or functions easy to change. Another example is if I build multiple services behind localhost or HTTP service. Then its easy to design a new module or container that will eventually be swapped out. Because the HTTP protocol is a standard that helps make interchanging easier.

Obviously I haven't fully digested this principle as I just listened to it two hours ago. I needed to write this down now, so the fresh knowledge is recorded. When I go back to this post, I will be reminded of the feeling I got while listening today. And with my feelings comes my sound sense, and my sound sense brings my knowledge, and also varied experiences, back into memory. Absorbed back into the massive hyper lanes of my mind. Where it comes back to life in my head. Like the event just happened yesterday.

Variance is a very important aspect of my work. My original approach is to duplicate functions and create different approaches until I discovered the essence of them all. This is very much still what I want to do. However, if I combine this flow and style with  the E.T.C acronym then I can get a more robust and concise approach. Language enables us to think better, and by building these symbols, we have frameworks that gives us access to different domains. E.T.C is now a symbol for me. And with the other symbols I have generated they are tools in my crafting, coding journey.

There are more details to be worked out in my arsenal. And how I might combine E.T.C with my current variance process.

The next acronym I learned is D.R.Y, or "Don't Repeat Yourself." I have heard of this before, but they explained the acronym in more detail. They said something that caught my interest. D.R.Y is much deeper than writing one function. Its about knowledge. Connecting a task, data structure with one piece of knowledge.

I probably took this further than what the authors intended. I don't know if I am or not, but what I thought about is coding is for humans. And the machine happens to utilize our rich language sets. If "Don't Repeat Yourself" means having only one implementation for each conceptual concept, then I am walking down a path of seeing coding as a greater mirror of language. 

For me, language is very important. Finding new ways languages interact and embrace the world.

The authors started expounding about functions holding knowledge. They gave an acute example of two separate functions that contained exact copies of the same code. However, because these two functions are for two separate purposes, they are D.R.Y. The knowledge attach to these functions are different.

I will give my own example. In Javascript code, for example, I may use the fetch API to request data from an endpoint. Using the fetch API may be similar from request to request. If I "fetch" a video, I might write a function called "fetch_blog_video(url, name, api_key)." And if I am fetching some metadata or tags about my blog, I might write "fetch_meta_tags(url, post_name, api_key)." 

Technically these two functions are similar, and the code might even be 99% the same. Should I combine the two functions into a generic function "fetch_data_from_blog(url, name, data_type, api_key)?"

Maybe this would reduce duplication because of reusing code. Yet if I follow, more closely, to the author's definition of D.R.Y, then knowledge and concepts are a very important aspect to "Don't Repeat Yourself". 

What are the concepts I want to call from my blog? One overarching generic concept named "blog data?" Or do I separate the concepts into "video", "image", "post writing", etc. I think I prefer multiple subsets of concepts than one generic concept. As always with principles, D.R.Y is applied differently depending on the situation. I just need to focus on the concept and meaning behind D.R.Y. Then the magic of writing and coding appears.

Learning about D.R.Y and E.T.C has deepened my understanding of language and computers. We are working with symbols not the wires in the computer. Well we are, but the programming domain here is about being language centric. The realm of languages connect and refine all things in existence. I know I am getting dramatic here. I just love writing. If my code is about writing concepts, then D.R.Y and E.T.C will help me ensure my process is language centric. Writing is very powerful.

Update:

After I published this post, I resumed listening to the book. And within five seconds I realized my error. Writing in this blog is very helpful. Writing my thoughts helps me comprehend and catch my own thinking patterns. And possible mistakes in comprehension while learning.

Rubber Ducky method, right?

In my javascript example, is where I believe my error in thinking is. 

I could just write one function for the code that connects to the blog. This processes the API key and other possible configurations. Then I write more specific functions that utilize the connecting function to do more specific fetch requests for the blog.

I need more time to get my head straight here. I wanted to write this update fairly soon. 

I believe the authors were intending to highlight the occurrence when you have two functions that perform unrelated tasks but have almost the same code in their function body. Keeping them separate is good idea because they are unrelated.

Like if I have fetch for a blog data, and then fetch for weather data, the code might be very similar depending on how I write it. However one is for the blog and one is for weather data. Separate purposes.

I might write an even more generic function that just focuses on connecting to similar API. This may happen if the weather API happens to be very similar to the blog API. Hypothetically.

It seems the DRY principle is meant to be a practice that we get better intuition for. Like in my case today. 

I have not finished the chapter that covers DRY yet. I may learn more things as I finish the chapter. 

Anyways. I wanted to provide an update to this particular post.