Day 4

Day four was a good day, I am starting to become much more capable of working myself. The first few days, I needed help with instruction and onboarding, but now I’m in the groove of my schedule. Going forward, I will be having weekly monday meetings with Gina to discuss the previous weeks work I did and what I will do the following week for my apprenticeship. Overall it is a great system that allows me to learn at my own pace. And if I’m ever stuck, I can always reach back out to my mentor for guidance.

I continued what I worked on yesterday. I did Euler problems 5-7, and practiced my Clojure Kata problem. Each time I practice this Kata I go through each test and understand how each test makes sure the code I created is robust and handles all edge cases. I find this style of test driven development to be incredibly useful as I continue to become used to it. I find ways to break my code in ways that I would not have found in the past. Ultimately it allows me to find and fix bugs quickly. I also redid my kata today to be in Clojure and changed my approach to reference one of my Euler problems and alter it a bit. The code works great, but next I have to prepare to present this to everyone else in the company on Friday. Part of that will be deeply learning my process, and then practicing how I will convey my thoughts while put in the spotlight.

The Euler problems I did today were somewhat challenging but today more of the challenge was on my approach and the concepts, rather than getting Clojure syntax right. One of the problems I found a solution, but it takes incredibly long to calculate. It has a O(m*n) processing time, but m gets exponentially larger with each increment of n in my solution. There is likely a more elegant and efficient solution that I would like to explore later this week.

I also watched an Uncle Bob video on extracting functions to smaller ones whenever possible. I noticed I could follow that process better, so today I was mindful about making sure each function I wrote did only one task and was accompanied by a number of tests on that function. I found with this approach, I had much more robust code because I was testing smaller crevices of my code instead of just seeing if one or two big functions gave the expected outcome. It also made my code much more readable too.