Coltrane, Queens, 1963. photo by Jim Marshall.

It was back in late 2010 when I began my journey with JavaScript. I had no open source projects under my belt, but I wanted to get my proverbial feet wet. At the time, jQuery plugins were the thing to do, so naturally, that’s what I did. I created a jQuery plugin that was a music player. What was unique about “Swagg Player” was just how flexible (read: complicated) it was. There was seemingly an endless number of options one could employ to tune your player to behave exactly the way you wanted. It was big, buggy, and inefficient but it was mine — my baby. Hell, I even received a few donations from appreciative users.

Fast forward to early 2012; I ended active development but still maintained the project — fixing a few bugs here and there. I even gave the project an extensive refactoring, making code style fixes, increased efficiency, and removed the jQuery dependency entirely. This was pretty big for me. I felt confident that my project could live on its own without needing the crutch of being another jQuery plugin. After a few more updates I decided it was time to retire Swagg Player and I officially ended all development of the project.

I have now been developing software professionally for over 7 years. I wanted to see the progress I had made over the years, so I decided that it was time to rewrite Swagg Player from the ground up. This was not a refactoring this was a complete rewrite. Refactoring software is fine, and in most cases, it’s the best thing to do…but this was different. With a refactor, you start with legacy code, and by extension, baggage. You immerse yourself in previous decisions and assumptions. Before you make changes, you constantly second guess yourself — convinced your previous self wrote this atrocious code this way for a particular reason. When you rewrite a project from scratch, you are not bogged down by these things. It allows you to solve previously solved problems, fix previously fixed bugs. Sometimes you come to the same solutions, sometimes you fix them more efficiently. From my experience, more often than not, those bugs never arise because the developer working on the problem, has more experience under his or her belt.

Some people might think this is a waste of time — why would you force yourself to fix the bugs and solve problems that have already been tended to? It goes against everything we believe in as engineers, but you have to remember this is a self assessment to measure progress. The development process, not the end product, is the important part.

So, what did all of this yield? Before I ended active development of Swagg Player, there were over 1800 lines of code. I have rewritten the project and today it has almost all of its previous features and there are ~345 lines of code. Yes, that’s only ~19% of the previous core code base and I am delighted by this outcome. Obviously I need to continue development and there will be more code to come, but rest assured it will be well below 1800 lines of code.

This is obviously not a scientific experiment, which is good, because it was not intended to be. I performed this assessment so that I could have a better idea of how far I’ve come as a professional developer. I encourage anyone with 5 years or more experience to try this (or a similar) assessment. This process has provided me with a great deal of perspective.

That being said I’d like to announce the relaunch of Swagg Player. It is available for download here.

Follow me @recursivefunk

Update: SwaggPlayer is now Plae.js because I’m no longer in my mid 20’s :-/