You are currently browsing the monthly archive for January 2014.
The final product I helped launch for Amazon was the Cloud Player for Desktop, Mac and Windows (CPDesktop). I’m most proud of this product. It has a lot of quality built into it, although, I definitely wouldn’t call it perfect. It looks good, works well, and has a lot going for it as far as the codebase goes. This product gained a tremendous amount from the previous 3 efforts of Cloud Player Web, the Uploader, and the Importer and was built from a point of experience rather than experimentation like the other products. It also borrowed some things from a companion team (including stealing the engineers from that team), and is a quality product from the ground up.
CPDesktop primarily plays the music you have in the cloud and as well as on your computer. It can download the music you have in the cloud to your computer. You can also create and edit cloud and computer playlists to name some of the main features.
After v1 launch in the US only, it’s now lives in 7 different countries (US, UK, DE, FR, ES, IT, and JP). Lastly, we added a store for sampling and buying music right there. I didn’t work on the store of the product, but included screenshots of it anyway:
View with track details and opened sidebar
Grid view without sidebar
Showing an artist with a fancier header view
Some download action in the sidebar
Hey Mom, I can speak Japanese! (Language options let you change the language on the fly)
Search. This is actually v2 of the search UI. I actually liked v1 search display better, but we collapsed the tabs into 1 row (when it was previously 2 lines), and the v1 search UI didn’t work so well with the much improved, collapsed tab row.
These are from of the store portion.
Store front page
Store detail page
My second major product at Amazon was the MP3 Uploader, which later became the Music Importer. This started off really fast as we needed a quick solution to launch with the the Amazon Cloud Player, web version (CPWeb). I actually had to interview and pick a crew of contractors to do this with me at the start because we didn’t have the head count at the time to use Amazon engineers.
The basic product would be built in Adobe Air – you have to install that when you install the Uploader. A couple other engineers had made this decision before I took over the project. That decision definitely enabled us to get started quickly, but had a number of drawbacks including the supporting debug tools were useless for us and many people just hate Adobe Air/Flash – especially Mac users. The main use case for the product is scanning of a user’s computer for music files that can be uploaded, and most important in that process is recursive file scanning, which is why we couldn’t just do it in the browser.
This was tough because we needed to move quickly to not delay the CPWeb launch. Thankfully, I’d learned a lot from doing CPWeb, and made a few improvements to the Uploader framework based on that experience. I didn’t have time to play around and test ideas like I did with CPWeb, so I had to choose those improvements carefully so that I was sure there’d be a positive improvement. I’d like to post some pictures of the Uploader, but it’s already been replaced by the Importer, so I don’t have access to it anymore.
The next goal after launching was actually to work on the replacement product since v1 was partly only intended to support the launch of CPWeb and not live long after that. Knowing the challenges and good parts of CPWeb and the Uploader, I was playing with new ideas for a better, larger product which eventually got wrapped into the Cloud Player Desktop product, but that took a couple years to actually come to fruition. Thankfully, the Uploader product was solid enough to go through a couple major enhancements including the major refactoring to the Importer version.
By the time the Importer was on the schedule, thankfully, we hired Brandon Skeen to the team. Brandon was a life saver frankly, and a tremendous help in everything. Till I left Amazon, he stayed one the first people I’d go to for bouncing ideas off of, and he was great at improving an idea or showing me a better alternative.
The main addition to the Importer product was allowing ‘instant importing’ of music discovered on the user’s computer. The product would still upload if the file wasn’t importable, and the UI was much improved. A major piece that users might not remember, but was a lot of work were device registration (device limitation) flows. We also internationalized the product at this point, although, it didn’t go international with import launch as that came a little later. By then, though, the product had been handed to another team to support while Brandon and I (and others we added to the team) worked on the Cloud Player for Desktop product full time finally (more on this in the next post).
Import was a major pain actually and required a lot of service development in connection with client side changes from the Uploader to the Importer with a very challenging deadline on top of it. I’d actually say 2 of possibly the worst experiences of my work career happened at the end of this process and leading into the start of the Cloud Player Desktop work (we’ll see if I ever post about those experiences, but definitely not now). CPDesktop is probably my biggest engineering achievement to date, though, so from major lows to major highs.
In the end, the Importer effort was a success for all the struggling, and had a lot of learning experiences to draw from for the next (and final) product. I’d been working for a while before Import, though, developing ideas and prototyping, and then also on and off during Import (and Brandon was helping lot in this too), so I was rev’ed to get cranking on what I was sure would be the best product and codebase possible. I saw the Desktop product as a possible high water mark for my career, and I think it is – although, I hope to crush it at Jut 🙂
To close, some remaining screenshots of the Importer product:
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.
4 years. During school times that’s the equivalent of getting a degree. 4 years of high school – high school diploma. 4 years of college – bachelors degree. Now, I’ve completed my 4 years of Amazon – my own degree of craftsmanship.
When I joined, the digital music division of Amazon in SF, it was about 15 people. It was actually called A2Z Development center then, and we couldn’t sport the official Amazon name. At least not until Amazon started collecting taxes in CA that is.
Now that I’m leaving, it’s I think around 250. Tremendous growth – obviously meaning a lot of investment from Seattle – and during it all we launched a plethora of products. I experienced a lot, but now it’s more akin to Amazon proper (Seattle) than the ‘little SF office that could.’ So I’ve bid ado to my friends there, and very excitedly head back to a small environment with the startup Jut.
I’ll be making some posts on products I helped launch. I’ll probably keep the posts pretty dry because Amazon is kind of draconian on their information sharing, but it’s always nice to share accomplishments of work past, so that’s what I plan on doing.