Posts from 18 November 2014
-
Today's partner: Marc
Today was the day of the first assessment. It went well—I was less nervous than when I did the practice assessment, which I guess is the point—but I ended up tripping on the same edge cases as I had doing the practice. Derp.
(Technical gore ahead: I was writing a
sortmethod per the instructions, specifically bubble sort—I know, I know—and wrote a helper method to implementbubble_sort!that was called bybubble_sort. Somewhere along the way I started getting wrong argument errors—0 for 1 or 1 for 0, depending on what I was doing at the time—and it took me ten minutes to see that I had been checking the function signatures for errors, when it was the call out to the helper method that was causing the problem.)I felt guilty for finishing early since it seemed like most everyone else was still working, but looking around it seemed a couple people finished earlier than me. Sure enough, looking at tumblrs, another student finished absurdly quickly—the specific student I expected—and really, I ought to have been just a bit slower than him.
A lot of students have that moment when they first enter a highly selective program where they realize they're can't easily be the best anymore. I've had enough time in life to get used to that idea, but really there's little enough excuse for me not to push harder to get better. Having a decent target to reach has helped my typing speed (compared to just typing gibberish in a typing trainer) but I still have to test my assumptions about what a method can handle and what it returns too often for comfort. What I'd like, by the end of this program, is to be in the running as the "best" student and not just coast on … whatever it is that's gotten me this far in life. That will take work, and prioritization.
As any regular reader of this blog will be able to understand, most of my biggest demons are of my own creation.
We spent the entirety of the rest of the day working on Minesweeper. I can tell after a solid week that one of the critical pieces of Pair Programming is how well or poorly the personal dynamic plays out. Historically, I haven't been one who can easily convince another to adopt my priorities. This is another thing that I think raw competence can help with: people will listen to someone who seems to know what they're talking about, especially if they have easy confidence, even if that person doesn't actually know what they're doing (until, of course, that person is revealed as a sham). Further, sometimes the people you have to work with really want to go in one direction when you wholeheartedly believe that another route will bear more fruit. Wrestling with this sort of thing can be exhausting, because either you defend your idea and "win", or you realize the other person has the better idea and concede your point. Either way, you've expended a lot of mental energy.
I'm not saying, mind you, that my partner was particularly difficult to work with. I have had some amazing pairings so far, but today was one of those days where we each had an idea for what needed to happen, and we were pulling in different directions—vectored off from one another just enough that it was a challenge to move forward.
We got where we needed to be by the end of the day. The game worked, we had a somewhat clean data model, and our logic held up. We were even able to add some extensions—we changed the symbols used from rough ASCII to some nice Unicode that I think was much more readable on-screen. But toward 3:00 or so I began to think we ought to order T-shirts that say "Don't worry about that; we'll refactor later." Were this a production codebase, we'd have accumulated a lot technical debt today. Compare this to most of the projects in the first week: my style was much more comfortable and easy to read, with only a couple places (typically method chains) where I could benefit from some cleanup, and I think that's a direct consequence of having a solid idea of where we needed to be and the route we would have to take to get there in the first thirty minutes of class.
That is to say, all of our problems can be traced back to an overall bad approach to architecting the solution, specifically the separation of class responsibilities and the mechanism for passing certain objects. Prototyping, or figuring out a full schema earlier on, may have helped protect us from some wild goose chasing, but as Fred Brooks said, when solving a new problem teams should design a throw-away system first, because you're going to throw the first one out anyway. (See also: Annie Lamott's "Shitty First Drafts")
It's not easy to see your own failings, but looking around some common ones that others demonstrate include a resistance to learning skills that are not core to the "purpose" of a course (the purpose being debatable—I've been at enough colleges to know that what's on the final is a small fraction of what a student needs to learn), stubbornness about one particular approach (kill your darlings!), not being able to listen to others at all, not telling others what you're doing because it's obvious to you, not giving people the benefit of the doubt… to some small extent each of these has manifested in my time here, and I'm on the lookout for those times when I, myself, am guilty of these. Small sins can be hard to see.
It was a good day, overall. I love the people here, but the difference in energy level between a good day an an average day is really noticeable. Still, every day so far has been far better than any day of work or school until this point.