The first major product I helped Amazon launch was the Amazon Cloud Player web version (CPWeb). This was the first Cloud Player product to launch and was focused primarily on Mac and Windows browsers (ie. Firefox, Chrome, IE, Safari). Later followed the Android, iPhone, iPad, and Desktop (Mac and Windows) versions (and even more like Sonos and beyond) – of which I only helped with the Desktop version. I also helped launch the companion Uploader product, and later became the Importer product as it is today.


Before I get too far into CPWeb, I helped with some smaller features when I first joined. At the time of joining, there was only an MP3 Store and a Downloader product. I never worked on the Downloader product (although I’ve done oncall support for that product). I was part of the Store team when I joined.

I helped introduce smaller improvements like an updated sample player. The sample player at the time was kind of ugly (a grey thing) and had become buggy over time as it was enhanced. Also when I joined, if you went to the MP3 store front page for instance where they list various grouping of music, you could play 3 or 4 different samples from that page and all would play over each other (this is because there’s actually more than 1 team building samplers for these pages – it wasn’t all controlled and coordinated by the MP3 Store team). Major fail.

My task wasn’t to solve that problem, but rather to update the look of the UI on the detail pages (album pages or track pages). However in doing so, I made the forward thinking design decision to create an interface to this player that would allow multiple samplers to play nicely with one another – meaning only 1 song plays at a time. It was a minor addition, but held a lot of potential benefit, and once it was on the detail pages, and other pages we contributed to, I would be able to sell this feature to other teams and have them integrate with that interface. Today, that’s moved forward and you can play multiple samples without them playing over top each other. Minor, but important, and these are the kinds of things I did before CPWeb.


Back to CPWeb, I was so lucky to join the SF office when I did. A project like building a new product for a large company like Amazon doesn’t come around often (amazingly, I got to do 3 major new products in my 4 years there), and I was there building it from the ground up. Also, I was excited because this is a product I actually wanted myself. While I love Apple products (I’ve owned multiple MacBook Pros, iPhones, and an iPad – not to mention having them at work too), I haven’t been particularly fond of the Apple music products (and still am not fond of them), and really wanted something cloud based so all my devices were instantly connected to all my music without having to configure anything (install a product, fine, but nothing more than that).

To be clear, I worked on the client side of the product, not the service side. All the cloud kind of stuff is really a service thing and not so much a client problem, although we of course collaborated to make sure what we needed in the client could be done with what the service provided.

The cool thing for me with CPWeb was really that I got to architect the whole thing. It was a little scary because I’d never worked on a full client side product like this before. As fortune would have it, though, on a team of 3 client side engineers, I was the most experienced in JS development, so I was able to take lead on this based on my limited experience.

Actually, that’s not quite true, James Pine first took lead as the senior engineer on the team, but he ended up leaving for Google after the start of the project, so it was really down to me and Steven Bougon (one of my all time favorite engineers to work with). However, me being the newest member on the team, I was given smaller tasks generally (like the updated sampler), and Steven was working on a larger project (more time consuming), so I was freer to take on something like this.

While I’m now a highly experienced (proven track record of success) client side dev, I’ll admit that at the time if you were to interview and hire someone for doing that work, you probably wouldn’t have hired me. I just happened to be in the right place at the right time, and have just barely enough know how to get the job going. Plus, part of being a good software engineer is flexibility to (successfully) take on new areas of development with the same or similar principles you would apply elsewhere – principally evaluating tradeoffs and balancing business and engineering needs, and secondly, good engineering practices and principles.

So Steven was stuck on another project for 3 months, and I had basically free reign to do what I thought best. My primary goal was learning the standards that others used in building these kind of products, so I started with a lot of prototyping and learning type of work. I bounced a lot of my ideas off of Steven and also my engineering manager Emily Butler (best manager I’ve worked with anywhere). We also hired a couple more client devs for the product, but most of the foundational work was done by the time they came on board. Even with Steven being freed up, I tended to guide development (as much because I was most familiar with the code as anything else probably).

My goal was always to be open on any development work as we were making many tradeoffs in an area where we had limited experience, and I was as inclusive as possible on development decisions. By today’s standards, there’s a lot missing from the framework and components that make up the product. For instance, the newer Desktop product is far more refined, cleaner, and more powerful to develop again (thanks to the lessons learned from CPWeb, Uploader, and Importer work along with work by other teams in the division). But by that day’s standards (some 3 years ago), I like to think it was a job well done.

It had its flaws, but as much as possible we tried to acknowledge the flaws and weigh them against the customer and business needs. It had a lot of flexibility in a couple areas and not so much in others, but I tried to engineer more in the areas that 1) we thought would change the most, and 2) the areas we knew the most about. I hoped that the areas that were under engineered could be refactored later (with not too much difficulty hopefully) when we knew better or more about them.


I didn’t actually stick with CPWeb development till launch. I switched projects to the Uploader product as it was later decided that we couldn’t launch CPWeb without an Uploader product too. It wasn’t enough to provide a cloud based web product if customers didn’t have a way of getting their past purchases into the cloud too. I’ll delve more into this product in the next post, but I definitely took what I’d learned in the 8 or so months I’d worked on CPWeb, and made a better development framework with the Uploader.

It was an exciting product as no other major company had a product like this out – we beat Apple and Google to this. There were startups out there doing online music products, but they focused mainly on radio style music products and not the ownership model Amazon was pushing. Also, while many startups like Pandora and Spotify have a lot of potential, Amazon with it’s millions of daily customers is able to have a more immediate impact on digital music.

CPWeb was a blast to build. As the team grew, we were still relatively small including both client side and service devs. There was definitely a sense of community that I enjoyed, and launching CPWeb and the Uploader was a fun process. We all pushed hard before launch time, and I think everyone enjoyed that push. This is one of the few times I’ve really felt connected to a product and felt like the extra effort was itself rewarding once we hit launch.

In the end, there wasn’t a ton of fan fair in the media in my view. It was still fun to read whatever came out from the media and from users, but if anything there was more written about what the other big tech giants might do as opposed to what we did. The media seems far more inclined to hype Apple, Google, Facebook, etc. than Amazon it seems. Partly because Amazon doesn’t operate by drumming up media I think as opposed to quietly satisfying customers. At times, it can be annoying when someone at another major tech company sneezes and it gets written about, and then there doesn’t seem to be as much commotion with even major happenings at Amazon (at least not in the area I was working…yeah, I know they can’t stop writing about Amazon drones it seems…). But then again, Amazon stock has grown by something like 330% from the time I joined unlike a lot of the more often discussed companies, so I’m happier having a bigger piggy bank than having more media attention.