Jim's
Tutorials

Fall 2018
course
site

Trying to teach ruby, sinatra, rails and how everything hooks together has been an interesting experience. I’ve found that explaining things like loops and control flow is often pretty straightforward but explaining how everything fits together in a collection of objects or in an MVC framework is often a bit more challenging for me to make crystal clear. I think that I don’t tend to be a very visual thinker and leslie is, which meant that there was sometimes a bit of breakdown in communication and i struggled to draw the proper connections. I can also often be imprecise with my wording, which gets rather confusing rather quickly.

For instance when leslie was working through creating a blackjack game it was hard for me to be clear about how all the objects were hooked together. It took awhile to drill down into syntactical things like, to access your deck object, you need to create an instance of a new deck with deck.new then you can call methods from that object. Or, if you want to be able to see the cards in your hand you need to create a method to show them or have an attr: reader at the top of the object file (So that’s what that does!). Or whenever you see an instance of an object with a period after it in ruby you are calling a method that you defined in that object. We’d have conversations that would go like... Okay, so I have this new deck, how do you get cards from your deck into your hand?… well, you pass them as arguments into the constructor for the hand object… what? Well… what that means is you take your newly instantiated deck object and call your deck.deal method to return a card, then you pass that card to the constructor of your hand object… okay ill try that… (writes code in her deck object) … why isn’t this working? … Well, you can’t construct a new hand inside your deck object… well technically you could if you import your hand object but I think you want to put that logic in your game.rb file… Oh… why didn’t you tell me that?!

We had a similar experience when we drilled down into sinatra and MvC frameworks. I found it easier to explain how to write the logic to save and extract the data than to create a clear picture of what every piece of the file structure was doing. I’ve found it helps people to have a really clear idea of what each piece of a framework or application is there to accomplish and I have a tendency to gloss over those details and launch right into just putting the thing together. Often-times I’ve found confusion stems from these kind of details and It can be hard to take a step back and figure out what somebody is actually confused about when they ask a question.

I think I also have a tendency to over-explain and give too much context when simple explanations would suffice. For instance, one of the sinatra applications we were putting together involved taking some data that was stored in hash and accessing it using a couple models. When asked why those models were necessary I launched into an explanation about how models are typically used to store dynamic information in databases rather than simply access a static hash stored in it’s own object file. I then explained why they were necessary in that context, then tried to draw a parallel as to why they would be useful right now to access and organize the static data. This just served to add complexity before basic understanding, which I think is always the wrong approach.

Overall trying to explain things to someone has been a positive experience. I find myself able to way more clearly articulate coding fundamentals - particularly around objects, and calling/passing arguments to functions. It also helped cement my understanding of MVC frameworks and I got a lot of practice helping debug code and/or explain how one might theoretically make it work. Being able to explain things is a great way to cement your understanding and my inability to articulate certain things helped me fill in some holes. Overall it was a great experience and I think we both learned a ton!