I was a bit cranky when I left work today, because I wasn’t able to track down the problem I was working on. I spent hours looking for the solution(s) to some outstanding JRuby issues with jarred gems, (one related to spaces in directories and one related to nested jars (like Hpricot and Limelight both have). And I got nowhere. Nothing to show for my efforts. I went down a ton of paths, tried logging, and added stack traces, but to no avail. The solution exists in the code, but the codebase is large, and I just wasn’t able to wrap my brain around the problem. And that sucks.
But in every situation, there’s an opportunity for learning. Eventually, on the way home, I relaxed and looked for the lesson in my failure today. I didn’t fix the issues, true. There’s no metric that I know of that says something positive came out of my work today. But I introduced myself to most of the filesystem-related components of the codebase, and I saw the mappings JRuby provides from Ruby methods to Java methods. (Annotations to the rescue for those Ruby methods like
= whose names would be illegal in Java!) I really internalized some keyboard shortcuts in IntelliJ. I learned a new trick where you press Command and hover over a method call to see information about it and the object it’s defined on.
Most of all, I learned what not to do when presented with a big codebase and a specific-sounding problem. I just jumped in, looking at the first place I saw referenced in the issue comments, and logging things, working at a micro level basically all the time. It wasn’t I got home that I realized I needed to step back and look at what was really happening on a larger scale – the context. I should have realized my problem during the day when I tried to explain the problems I was having and couldn’t really do so – next time I’m having these kinds of frustrations I’m going to pull the old rubber-duck trick (explaining the problem to a rubber duck or other inanimate object). If I can’t, something needs to change in my process.