working around a framework

After an intense first week of working on a new project, I am now feeling much more comfortable project, but reaching this point took a bit longer than I had originally expected. One of the reasons why I had a longer than expected ramp up was that I had to learn the quirks and domain specific language of a new framework. While the framework was not a new programming language, it did come with its own domain language that was a bit clunky, and was hard to follow for a few days. In order to understand the new framework we were using, I drew the relationships of each object and how they interacted with each other on a sheet of paper. This greatly helped me to visualize how I could find and reference certain objects from within the program.

After I got fully ramped up on the project, I began to tackle more difficult problems, and along with more difficult problems, many of the solutions to these problems were not well documented in the framework documents. This lead me to develop a new strategy for figuring out the more complicated framework issues, and by using this new strategy, I was able to find some fixes that were not well documented by the framework writers. Now when I encounter an issue, instead of first going to the docs to look it up, I go to the framework github page and search the repository for the object or method that is troubling me. Using this strategy instead of just reading the docs has allowed me to uncover undocumented default values, strange rescue values, and undocumented methods.

Having the opportunity to work on this project has given me a great opportunity to learn how to work with a large framework, and how to come up with elegant solutions when working with a rigid framework.