February 19, 2014
Don't group your problems
At some point in the early afternoon, I got a to-do list. I had the project manager in a screen share showing me the problems she was seeing, and in another window a tech lead giving me feedback on a Github pull request. They were all mostly linked to this one component, so with three new items on my list, I thought, hey, I can refactor this and take care of all of them.
By mid-afternoon I was hopelessly mired, with a new template taking a ridiculous number of arguments, and at the same time Not Working At All, and I couldn’t figure out which of the several parts I had in the air was causing the problem.
Instead of bulling through, though, I finally learned something. I stopped, and threw away all the changes I’d made. I looked at just one item on the list, the pull request feedback. It was just changing some IDs on some tags. I changed the IDs and updated the pull request. Simple.
Next item. A status indicator shared between windows wasn’t cleared if one window was closed while in an error state and another one was opened. I had been trying to reset it on window close in my Brand New Super Component, but instead I figured out how I could essentially initialize it on window open without touching the existing component. (In the process I learned a little about how to call controller methods from a route in Ember.js, which was a bonus.)
Now I had two items cleared off the list, and I was free to fix the third in any way that worked. And, yes, I created a new component slightly different from the original one, but now I only had to solve one problem, so my new one was not as ambitious and didn’t require as many complicated changes. And it worked.
We’re gonna make an engineer out of me yet.
February 4, 2014
It turns out that exercism is an interesting illustration of a classic social-software platform: scaling.
The mechanics of exercism work like this: you submit your first exercise solution. Then you wait for feedback, and iterate. Once you’re satisfied with your solution, you can mark the exercise finished, and once you’ve marked a solution finished, you can start giving feedback to others on that solution.
If you’ve submitted a solution to an exercise, you can start another one in that language, even if you’re still iterating on the first one. This makes a lot of sense, because it turns out that you may be waiting a while for feedback. Essentially, there’s no barrier to joining the site and starting to do exercises, but because you need to have completed an exercise (possibly iterating three, six, even ten times on it) before you can start critiquing others, every exercise is almost guaranteed to have a much higher number of programmers submitting solutions than programmers reading and critiquing.
This can get pretty frustrating for a beginner. I sat on my first Ruby exercise for almost a week with no feedback until I got some. I iterated, and waited another four days until I got a “looks good” which I took as enough reason to mark it completed. (My submission for the next exercise has been sitting for six days without feedback.) I have three Coffeescript exercises waiting for critique, and one each of Ruby and Coffeescript waiting for me to start working on solutions.
The only way around this is for those of us who’ve finished any exercises at all to provide as much feedback as we can to others, and try to increase the pool of readers that way. I’m making an effort to provide as much feedback as I can to others working on that exercise, but probably what I’m doing is creating more work for whoever has completed the next exercise. The Ruby community is clearly larger than Coffeescript - whenever I look there seem to be around 70 active Ruby solutions waiting for feedback, but often there aren’t any Coffeescript solutions. So if I want others to be reading my Coffeescript, I need to be critiquing theirs…
ETA: And after I hit publish, I look at Twitter and see they’re aware of the problem.