2015 - Reworking my process
In 2015 I had the opportunity to work with some really remarkable programmers who gave me the freedom and trust to not just blindly implement feature after feature or fix as many bugs as possible, but rather to question why a feature is needed, or what the origin of a given bug was.
With this trust, I took the opportunity to explore the origin of problems instead of just applying a patch and moving on.
Beaker Notebook
For the majority of the year I worked hand in hand with @scottdraves on an interesting and very complex piece of software http://beakernotebook.com/. As with any software at a given scale, memory and performance, and "feature debt" became serious issues that had to be dealt with.
Beaker Notebook was actually the reason I started to deep dive into performance, and profiling, because I wanted to understand what was actually causing slowness and wanted to present valid before and after numbers on my work, not just a blind "this makes things faster" comment.
Since the project had some unique challenges, It actually was the impetus to create two new OSS projects which directly helped fix and identify performance related issues.
https://github.com/samccone/scrollin - A leak free performance focused scroll util
https://github.com/samccone/drool - automated memory leak detection and analysis
TodoMVC
During mid 2015, I become involved with TodoMVC working alongside @passy, @sindresorhus, and @addyosmani
After working on the project for a few months, I noticed a significant amount of churn in our review process, from style related nits, to the difficulty around running integration tests locally and on CI… So I made solving these specific problems a priority for me.
The first step was to make our integration tests run on CI over the projects that had been changed. http://samsaccone.com/posts/testing-with-travis-and-sauce-labs.html
The next challenge was to run style related tests over the changed projects (jscs/jshint) according to our lint rules
It was during this time that I was becoming more aware of memory issues, Initially I was manually auditing each framework, and working with the maintainers to fix the leaks.. however it was clear that there were significant costs and disconnects when trying to explain the leaks and when helping others to reproduce the leaks locally.. so I implemented a suite of automatic memory tests for every PR on TodoMVC
These automatic memory tests not only caught a significant number of memory issues in popular frameworks 
tastejs/todomvc#1337 (comment)
tastejs/todomvc#1297 (comment)
But also uncovered some interesting behavior around how the undo buffer operates inside of chromium. https://code.google.com/p/chromium/issues/detail?id=516153
Performance cont.
As the year progressed and my interest in memory profiling and debugging increased I started to do more memory/performance deep dives into popular tools and libraries to see If I could help fix or identify performance related issues. The goal of this work ideally being to help spread the profiling mentality and show others how straight forward profiling can be.
Material Design Lite:
google/material-design-lite#761
npm3 Perf:
Atom Editor Performance:
Talks
Between my normal job and OSS work I was able to put together two talks that I was fortunate enough to get accepted at JSConf and DotJS.
Recreating the dialup modem (special thanks to @fcanas for giving me a crash course in DSP)
https://www.youtube.com/watch?v=UKa20yPzGbU
Dealing With Garbage
https://docs.google.com/presentation/d/1uom69F6NGURHhrox1Ma50NW1nOKqdxRr0dKDNENwi6Y/edit
TLDR:
Over the year I learned that identifying the root issue, is typically the hardest part of any given issue.
I learned that helping others with hard, unattractive problems is a great way to grow and build trust.
And I learned that hard work is the only shortcut when it comes to solving difficult problems.
Here it to 2016, and thanks to everyone that helped me grow so much in 2015. 