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

twosigma/beaker-notebook#1714

twosigma/beaker-notebook#1615

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

tastejs/todomvc#1212

The next challenge was to run style related tests over the changed projects (jscs/jshint) according to our lint rules

tastejs/todomvc#1288

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

tastejs/todomvc#1464

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.

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.

@samccone