Apprenticeship -- Week 3

You ever get physically tired from cramming stuff into your brain? I've been reading so much lately that I've needed to get up and take snack breaks.

My goal for these past few weeks has been to develop an understanding of objected-oriented programming and demonstrate my new knowledge by writing a tic tac toe game in Ruby. At the beginning of this week, I felt comfortable writing in Ruby. TDD exercises, katas, and tutorials while reading Sandi Metz really helped. It was a great feeling to not see Ruby as a foreign language. However, I'm still working towards a better understanding of what constitutes OOP design and how it can help me write code that is easier to maintain.

My previous posts detailed a few daily insights and challenges, but I'm going to attempt to write weekly posts going forward.

Monday

I did a few RubyMonk tutorials, but this day was mostly dedicated to translating the board responsibilities to methods. I'm so glad that I discussed my plans with my mentor prior to implementing. He pointed out some overarching issues and guided me towards thinking about what information each object would be in charge of sending. This helped me to define my tests and consequently write code. I was on a roll!

Tuesday

I committed to git the tests and methods for my board class. Somewhere in between Ruby podcasts and commits, I attending a talk on a book called Presentation Patterns. The presentation was really interesting. Specifically, it touched on the phases of preparation and delivery: the motivation behind giving a talk, creating and organizing ideas, building a talk, preparation methods, and delivery. One of my personal goals is to speak at a meetup group and a small conference in 2019, so I'm looking forward to picking up the book for more details.

Wednesday

Byron recommended that I open pull requests for new classes and major refactors. I opened a PR for the tests and methods for my rules keeper class. I made additional commits throughout the day based on Byron's review notes.

Thursday

I had a Donut session with Himalee, an apprentice at the London office. We talked about our backgrounds, our current projects, how we learned about 8th Light, and how we first started coding. I think there is a common thread among developers; we all seem to have this curiosity itch that we must satisfy and it just carries us along through challenges. After my Donut session, I had a second pairing session with Cyrus. I was confident in my board and rules classes. I figured they would be safe from major deletion. I was wrong. He suggested that I follow a (given, when, then) framework to define and meet goals. So we defined a couple of stories using the framework. After writing tests/code, I gave a demo of the feature. Of course it was a super quick demo, but it's nice to get in the habit of coherently presenting features to clients.

Friday

In regards to coding, I feel like no matter how comfortable I think I am, I'm always riding on an oscillating curve. One day, I'm confident and the next day, I'm lost and confused. I attempted to implement some of the review suggestions from Byron, but I kept getting stuck. This concept of relationships among objects kept tripping me up. Someone asked me to explain the proper contents for a class. This is what I came up with: Classes serve to do one goal and methods contribute to that goal. A class is essentially a group of related methods set out to complete one thing together. A class does ONE thing and methods together define how that one thing can be done. But what is that one thing? If I have a rules class that is in charge of telling whether or not there is a draw or winner, is it too much to ask that the rules class also house winning combination patterns? After all, the combinations will change depending on the game type, which will consequently change the win/draw requirements. Should I make a winning combo class? I ask this because I don't want any methods or objects to accidentally tamper with the combination data. Byron mentioned that if objects weren't allowed to hold any state, it could lead to classes upon classes of single methods, which is extreme. He suggested that I think about what information should be public and private in terms of which information would need to be accessed by other objects. He recommended that I keep the combinations in the rules class as private information, but make a public method for access.

Aside from my woes with OOP design, today I witnessed the graduation of two apprentices. It was the coolest thing ever and involved every person in the office dropping what they were doing to high five or handshake the graduates ... in a single file line. Gosh, this place is so cute.

Learns for this week

• Git commands: git log, history, git reset --hard "commit ID#", git push --force, git tag
• Visual unifying themes for presentation delivery (super cool)
• Sprout methods for friendly refactorization
  
  Challenges
• Thinking of programming in terms of the messages that are sent between objects
• Thinking about what a class needs to fulfill its purpose
  
  Opportunities to solidify learns
• Explain what OOP is
• Explain the values and tradeoffs of TDD