Knowing something is possible does not make it easier, it just makes it more frustrating when it doesn’t work the first few times. This even goes for things you already know how to do. Putting the pieces together is much more difficult than the design. It’s true that a good design can help the pieces fit together seamlessly, but ‘bad’ designs can have the simplest implementations. Then what makes the design ‘good’ isn’t the ease of implementation, it’s the reliability, impact, and extensibility of the completed system.
Debugging and refactoring go well together. I spent the past few days bug hunting near the end of a release, and I took the opportunity to address all the todo comments as well as buggy behavior. A task that started off as simply removing a library that wasn’t being used anymore lead into a more serious refactoring of the database interface that exposed a few latent bugs. During the long build cycles, I again tried to go through the Learn You A Haskell For Great Good, but I found that I just wasn’t absorbing it without the ability to test it out.
For my annual review I had to recall what I’ve done well and where I need improvement. Previously I used my notebook with my //todo lists and debug ideas to evaluate what I was working on and how well I did. This worked great when my projects were small enough in scope that I had design and debugging notes for each part that I accomplished. It was easy to see when and where I had problems and then address those issues accordingly.