We started off lecture with a quick and not particularly helpful review of yesterdayโs solutions. The only problem Jeff went over from assessment00 was one of the only ones I actually finished, and while Iโm sure he was going slow so that we could follow what he was doing, it made me feel even more like we were not given anywhere near enough time for it. The only other solution he went over at all was for the ghost game, which I never got to and so didnโt really mean anything to me.
The actual lecture was pretty good, though. It covered several things that fell into that uncomfortableย โI know what result to expect from this but only because Iโve seen it before and not because I have any idea how it worksโ category, which was good. I like to know what my code is actually doing, not just what itโs going to output.
I definitely kinda felt like the weaker partner in pair programming today, but not so far behind as to be useless, and I definitely learned a ton, especially about debugging in general and using byebug in particular. We only finished the first part of the first project, but we did spent a huge amount of time on sort of tangentially-related things instead of really pushing to finish more.ย
We were in byebug for at least an hour throughout the course of the day. Iโd barely used it before, so at first I was mostly just watching and taking suggestions, but Iโd be willing to bet that by the end of the day Kyle and I were probably the two most comfortable people in the class with it.
We also made much better use of the TAโs than my pair did yesterday, which is good because thatโs something I felt like I didnโt really take advantage of before. We spent a lot of time talking about vaguely on-topic things like class methods and what attr_reader/accessor actually do, which Iโm still not 100% sure I understand, but I expect itโll make more sense when it actually comes up.
I (I think it was me who actually typed it but Iโm not sure) managed to create a tiny but absolutely ridiculous bug that presented itself as a no method error. What happened was I inadvertently wrote a method inside of another method, which caused the class to not recognize that it had that method available, and it happened that the same method name (display) is a method of the Object class which, among other things, calls the write method on something. So when display was called, Ruby couldnโt find it in the class we were in and went all the way up to the Object class and tried ย to use the display method it found there, which spit out an ugly error when display tried to call the write method in some way that Ruby didnโt like at all. So we got a no method error about a method that neither of us had ever heard of and didnโt seem to be part of our code at all. Our TA was pretty stumped as well until he eventually figured out that our class wasnโt recognizing the display method weโd written for it and then Kyle noticed it was defined in the wrong place. Apparently the next step in debugging it was going to be to start commenting shit out until the code ran again.
Anyways we managed to finish the first part of the memory game like 5 minutes after class ended, which was good because it was enough of a stopping point to feel pretty satisfied with the day. We certainly didnโt get as far as some pairs, but we might have learned more than anyone else.
Also, even tiny little minor successes are really satisfying when youโve been debugging literally all day.