Rafblog - Jake Cohen's Blog

Why I like working for Amazon

Ever since the New York Times published an editorial article last year about what working for Amazon was like, I've had people asking me about it whenever they hear that I work for Amazon.

My response is generally the same, that I have personally never seen the sort of toxic management styles and hostile work environments described in the article, and generally have a lot of confidence from having participated in the hiring bar raiser program as well as annual review meetings, that that sort of behavior is seldom rewarded or even tolerated.

There are going to be crappy teams and bad bosses anywhere. That's the reality of life. And yes, Amazon is a highly driven work environment where results are expected (and rewarded, as a matter of fact). But the idea that it's routine to see people crying at their desk is a bit of a joke.

I actually use that as a joke sometimes. If a table or desk isn't precisely level, I'll suppose aloud that it's so the tears can roll off rather than pooling on the top.

Beyond that, most of the things in the article are vast distortions of the reality. Does Amazon perform performance analysis to find and reward its top performers? Absolutely. All top tech companies do this. Does Amazon encourage backstabbing using the anonymous feedback tool? Absolutely not. For one thing, the tool is not anonymous. The manager to whom the feedback is sent knows exactly who sent it, and it is up to them to decide whether or not to share the feedback (and its source) with the person it is concerning.

But the items in this article, and their refutation, is not really why I like working for Amazon. I had worked there for over 11 years before the article came out, and now I have been here for over 12 years. It is the company's relentless customer focus that makes it a satisfying place to work and one that I can be proud of.

Sometimes, it's something we do. For example, taking an existing benefit like Prime and making it better (by adding video streaming, or adding free saturday and sunday delivery, etc).

Sometimes, it's apparent by how we contrast against things that other companies do. Sony recently announced they are increasing their PSN membership fee from $40 to $50 with no additional benefit to the end user. T-Mobile announced they are ending some of their cheaper data plans and thus forcing people to subscribe to the more expensive data plans. Verizon is lowering the monthly data caps on its broadband internet plans and increasing the fees for over-limit usage.

This, I think, exemplifies why Amazon is unique in living up to its customer focus mission. Compared to other companies, who are constantly striving to make more money from the same product offerings, Amazon is looking instead to give customers more benefits. If we can do this at no additional expense to ourselves, so much the better, but we don't let that limit our thinking.

The Art of Emailing Yourself

I've been in the habit over the last few years of using e-mail to keep track of tasks at work. It's basically the simplest of bug tracking tools (apart from a text file) and supports most of the operations you would find in an actual bug tracking tool.

For example,

• The subject line of the e-mail is implicitly the bug identifier. Any e-mail client that groups messages by conversations will automatically keep things organized for you.
• Adding correspondence is as simple as replying.
• You can add attachments as well.

But it has some advantages as well,

• Available anywhere you have access to your e-mail, such as your phone, so it's easy to add a thought as a reply without having to log into your work environment.

Of course this doesn't replace an actual bug tracking system for tracking software bugs or working with a team, but I find it quite effective for tracking tasks and issues when working on something over a period of time.

For example, over the past two days I have been working through a fairly tricky Android NDK issue. Whenever I need to put it down for a bit, due to a meeting, or commuting home at the end of the day, I reply to the e-mail thread I have going with myself about the issue and record my latest progress, thoughts on ongoing technical challenges, and my planned next steps.

This has made it super easy to pick the thread up again when I next sit down to work on it. And since it's in e-mail, if I suddenly have an epiphany while doing dishes or something in the evening, I can quickly add a reply to my e-mail thread rather than having to log into work from my computer or deal with writing down on a piece of paper and then remembering to take that with me the next day.

One of the nice things about working at Amazon

One of the nice things about working at Amazon is how often we get to tackle difficult problems purely for the sake of making things simpler or easier for customers.

I was reading Raymond Chen's blog post about why you can't pin batch files or shortcuts to specific documents on the Taskbar today. This is a well-written article that explains how the Taskbar does things, and thus why this specific use case isn't possible.

But this is an example of using a specific technical solution to drive the customer experience, rather than using a desired customer experience to drive the technical solution.

A customer often doesn't care how things work under the hood - they just want behavior that makes sense and lets them do what they are trying to do.

For this use case, you have to start with what the customer wants, or what they are trying to do, then figure out how to accomplish it. If that means your application model id based grouping isn't the best technical solution, maybe it's time to look for another way to implement it.

A customer trying to pin a batch file or a log file to the taskbar probably wants that shortcut to "always just run this batch program" or "always just open this specific document in the default app for that file type". It may not even be important to the customer that the resulting window stays grouped on this shortcut, but it should also be possible to figure out how to do that.

GWT woes

GWT does some really neat things.

But it also does some really frustrating things. Such as hiding compilation errors behind inscrutable messages about failing to instantiate a class via deferred binding.

For example, if you create a UiBinder class that uses another class that uses another class and so on, and down the line somewhere you've used a Java feature that GWT does not support, such as the implicit <> generics notation for instantiation of a generic typed variable, it will fail at the top level UiBinder class without telling you what failed.

Furthermore, if you try to use such a UiBinder class in another UiBinder class, it will fail to compile that second class claiming that the first cannot even be resolved as a type.

To figure out what the heck is going on, you have to crank the logging level of GWT's compiler way up and sift through pages and pages of spam to find the actual error you're looking for.

Something Google does right

Google has been getting better and better at understanding the intent of what is typed by the user. Going far beyond simple web searches, they started figuring out what the information desired was and bringing that directly into the search results.

For example, searching for "current james bond movie" returns you the title of the current James Bond movie (Spectre, as of this writing) rather than simply giving you results that matched that query.

But they have had this for years, and recently have begun expanding their semantic searches to include things beyond simply fetching information, and this has become so ubiquitous that more often than not, you can just type what you're trying to do into Google and it will help you do it.

For example, I wanted to set an alarm on my phone for 5:30 PM today. So I just searched for "Set an alarm for 5:30", and it showed me a confirmation that it understood what I wanted to do. With another tap, the alarm was set.

The thing I like best about this sort of semantic intent recognition is that it works so well so often that I often just try it first without having to explicitly discover that it is supported.

I hope Google will open this up as a part of Android soon so that app developers will be able to provide hooks for semantic intents. For example, if I searched for "zootopia parental guidance", I might like it to offer to open my IMDb app to the Zootopia page, scrolled to the "parental guidance" section so I can learn about whether it's appropriate for my kids.

Inbox zero! Ahhhhhhhh

PHB No More

After several years of managing teams at Amazon, I have decided to switch roles again. I have moved back into an individual contributor role as a Sr. Software Dev Engineer.

I did this for a few reasons, but mainly it boils down to aligning better with the things I am best at, and with the things I want to get better at. I want to become a Principal engineer eventually. I've always missed the code. I kept my development environment up to date, and participated in department hack days. I also would write bug fixes or the odd small feature, partly because there was a need at the time, and partly to stay connected to the code and keep my technical skills from rusting to oblivion.

Now I am back in the IC role and have some fairly exciting projects coming down the pike for 2016. Since I work in Kindle, naturally their is a veil of secrecy about everything and I can't say much about what they actually are. But they will result in material improvements to the team's product and the team's ability to build better features faster and more reliably.

Given these changes, I have also thought I would restart contributions to this blog, which admittedly have been rather, well, sparse over recent years. I will write about my adventures in the role change and getting back up to speed as a full time developer.

I'm optimistic about what 2016 will bring.

On Switching from Windows to Mac

About two months ago, I made the switch at work from a Windows laptop, which I had used for 10 years at Amazon, to a Mac laptop.

The primary reason for this was the availability of first-class Unix-environment tools for working with and building my team's software product.

Now that I have gotten used to the new environment and worked out all the kinks of the transition, I have some observations on the relative pros and cons for my own use cases of Mac vs Windows.

The pros:

• Battery life - the Macbook will let me do work for at least six hours without plugging in, and I do not need to dim the screen or turn off Wi-Fi or anything. The four Windows laptops I have had over the past 10 years never did more than 3-4 hours without requiring an additional battery or extensive power saving measures like switching off Wi-Fi and dimming the screen to minimum level.
• Mission Control and multiple desktops. This is a really slick feature and I find it makes switching between applications faster than cycling with Alt-Tab or Windows-Tab on the PC.
• Unix environment - just for the heck of it, I wanted to see if Jenkins CI would run on my Macbook like it does on our Linux build servers. It does. I haven't really thought of a use case for this, but the fact that MacOS's Unix-compatibility is this good makes a lot of things really easy.
• The magnetic power adapter connector. It is such a good idea, the rest of the industry should be clamoring to license this. I'm surprised Apple doesn't even use it on more of their own products.

The cons:

• Microsoft's application suite is sub-par on the Mac. Excel is worse, Word is worse, and Outlook is much worse. If you want to run these apps well, you still have to boot a copy of Windows.
• No real docking station support. There are a number of dock-like devices out there, like Henge Dock and a few others, but these basically carefully replicate all of the connectors that would plug into the normal ports on the side of the Macbook, versus connecting to a purpose-built docking connector. You can create a more docklike experience if you have a later Macbook Pro with Retina display and can use the Thunderbolt port for display, USB, and Ethernet all at once.
• Dongle required for external display connection. This actually comes up as a negative issue less than I thought it would. On our team's projector we just keep it plugged into the VGA cable. People with Windows laptops (and VGA ports) just unconnect it first, then reconnect it after.

Overall I'm pretty happy with the switch. I could have a much longer "cons" list before that would change, simply because of the impact of the battery life and Unix environment.

Apart from the Microsoft app suite, most other things do not feel any different. I use Chrome for my browser, which feels identical. Android Studio feels the same. Spotify is the same.

Password security

There are many articles describing how to make a password more secure. They usually suggest using letters, symbols, and so on, to increase the complexity of the password, such as is the case with this article by Apartment Therapy.

There is also an argument that simply increasing the length is the best way to achieve password security, such as described in the vaunted 936th xkcd comic.

However, these techniques only increase the security of the password from an outsider's perspective by making it harder to guess. What about the security of the password when stored on the remote site? The best password in the world is no good if the site itself isn't secure, or if they store it in plain text somewhere.

One giveaway that a site probably stores your password in the clear is when they enforce a maximum length on the field. This probably indicates that they store passwords in a database column and the max password length is the size of that database column.

Secure sites don't store your password in the clear at all. Rather, they pass it through a one-way encryption algorithm such as SHA-1, and store the encrypted value. When you sign in with your password, the password you type is encrypted with the same algorithm and compared to the encrypted value.

To add security, these sites will often add a "salt" value to this algorithm, meaning that even if an attacker steals the encrypted passwords and manages to guess a value that encrypts to the same value as one of the stored passwords, it won't work because the stored passwords are created with a combination of the typed password and the salt value.

So it is useful to have a secure password, but keep in mind the security of the site you are using the password for. If they store passwords in the clear in a database, I wouldn't use that password for anything terribly important.

Movie Review: Burnt Offerings (1976)

(warning: contains spoilers)

Rating: 3 out of 5 stars.

Pro: extremely creepy, doesn't rely on cheap scares.

Con: paced quite slowly, characters don't evoke much empathy.

It was a bit hard to get into this movie for the first six minutes, due to the gargantuan credits that kept appearing over the film.

There is a lot of heavy foreshadowing that goes on in the opening dialogue, and there is a lot of dialogue. The first fifteen minutes of the film, in fact, seems to be little but introductory dialogue with a trio of characters that does not appear in the rest of the film.

The plot of this movie revolves around a dilapidated old house that renews and repairs itself whenever the new tenants get injured or harmed. The rejuvenation of the house is fairly subtle at first, a plant showing new growth, and a dead light bulb that suddenly works again, the cracked mirror that is now whole.

This movie seems to rely more on being creepy than on the gore and scare tactics of most horror films. The scene in the pool where the father snaps and suddenly starts trying to drown his son was one of the creepiest scenes I've seen in a horror movie. A customer review on Amazon.com from the book suggests that Stephen King took inspiration from this novel for The Shining. The pool scene and subsequent events involving the father make this connection quite clear.

As the movie progresses, the wife also begins to show signs of strain, and then it is not clear who is actually losing their mind and who is still sane. The husband sees visions of a creepy character from his mother's funeral, the wife appears to be becoming obsessed with the old house and the supposed elderly resident on the top floor who no one has seen.

It's never really explained why this ghost from the husband's past keeps appearing, but the wife's obsession is explained at the end, and makes a very creepy finale to a very creepy horror movie. If you like The Shining, The Skeleton Key, The Others, and movies like that, this one is right in that same vein and predates them all.