My Experience With Amazon at DevDays


I was at DevDays yesterday; and during my time there I frequented the Amazon booth.  The same Amazon that Steve Yegge worked at.  The same Amazon that has essentially revolutionized online shopping. The same Amazon that… Ok, I’ll stop drooling now.  Amazon == programmer mecca. It ranks right up there with Google, Microsoft, and Fog Creek Software.  If you’re a programmer you want to work at one of those places.  It’s the Ivy league of programming careers, and about as tough to get into.  I had a ‘conversation’ with Joel Spolsky via twitter recently, and if I remember correctly an interviewee had no less than 6 interviews to determine whether or not he was ‘good enough’ to work at Fog Creek software.  I imagine the distribution of failure would scare most people away.

Act I: Epic Failure

So I went up to the Amazon booth and checked out their trivia questions.  The first one had to do with a variation of the fizz-buzz problem, and I recognized it for what it was.  But I was nervous, and the big Amazon (not a pun) guy with a goatee (BAGWG) was staring at me, so I stammered out something like: Well the ++i would evaluate to one higher the first time through. I botched it because I was studying the trees and didn’t pay attention to the fact that the forest would burn to the ground.  The answer was that while the problem accounted for either fizz (4) or buzz (5), it logically did not account for what would happen if there was a multiple that happened to have both fizz and buzz as factors (like 20). 

One of the PHD students that was hanging out with Rick Schott and I solved it (both Rick and I concentrated on the trees); and the exchange itself was somewhat funny:

BAGWG (to me): So you think you know the answer?

Me: Well the ++i would cause it not to iterate through…

BAGWG (interrupting): Doesn’t matter; any other ideas?

PhD Student: It won’t print anything anytime a number is a factor of both 4 and 5.

BAGWG (Turns so his back is towards me and separating us from the PhD Student): Have you ever thought about working for Amazon?

Rick and I looked at each other and walked away, dejected.

Act II: Victory Strikes Back

A little later, still smarting from missing the obvious, I walked back to the table and saw they had listed a new problem.  Essentially it was a problem where you had x,y coordinates defined, and you had to figure out based on the code shown whether or not the rabbit would get the carrot.  The answer is that no, the Rabbit would not because the carrot was hidden beyond the bounds checked by the code. I explained as much to the PhD student and Rick (who were coming to the same conclusion), and they told me I was wrong. 

I was, because I had used the word bounds to describe ‘out of bounds‘ instead of physically located outside of the array, which it was not.  Knowing that I had the answer correct this time, and remembering to use the correct terminology lest I get interrupted, I went up to the Amazon booth and chatted with another gentleman from Amazon (trying feverishly to avoid BAGWG, he was intimidating), and he gave me a Ninja for getting the problem right and asked me if I ever considered working for Amazon.I swear the Ninja is Laughing at me

Have I ever considered working for Amazon?


Of course I have. Who hasn’t?!?!?!

I didn’t say this to him, though — I just nodded and he proceeded to ask me if I knew anything about EC2. I was still high from hearing the first question, so I stammered a question out that made it sound like I’d never even heard of Amazon and then proceeded to bolt from the table out of horror for my brain shutting down right when I could have had a networking session with the hiring manager for Amazon EC2

I swear the recently-won ninja in Rick’s shirt pocket laughed at me.

Act III: The Return of Defeat

The final question of the day (I’m recalling from memory) was about biased coin flips.  Specifically, let’s say you had a boolean method that acted like a coin flip and returned true or false and did so so that it was evenly distributed.  How would you construct a replacement method so that it would generate true only 31.416% of the time.  My thoughts were that I could get close with the following hacky code that I wrote just to test it out quickly:


       static void Main(string[] args)
            Dictionary<int, bool> Flips = new Dictionary<int, bool>();
            Flips = flipCoin();
            int TrueCount = 0;
            int FalseCount = 0;
            foreach (var item in Flips)
                if (item.Value)
                else { FalseCount++; }
            Console.WriteLine(“True : ” + TrueCount);
            Console.WriteLine(“False : ” + FalseCount);

        private static Dictionary<int, bool> flipCoin()
            Dictionary<int, bool> _Flips = new Dictionary<int, bool>();
            bool result;
            Random rand = new Random();

            for (int i = 0; i < 1000; i++)
                result = rand.Next(2) == 0 ? true : false;
                if (result)
                    result = rand.Next(2) == 0 ? true : false;
                    if (!(result))
                        result = rand.Next(2) == 0 ? true : false;
                _Flips.Add(i, result);
            return _Flips;

But that returns True about 33% of the time, give or take, so I knew this solution wasn’t correct.  I kept thinking about the Monty Hall problem and thought maybe that was related somehow, but I couldn’t figure out how.  I figured I could try a naive implementation of Rand() by keeping a ratio of true/false so that over a series of rolls, the probability would end up being 31.416%; but I also knew instinctively that that was wrong. What’s funny is that when it comes to matters of probability, lots of people get it wrong, including Blaise Pascal.

Something the BAGWG said to another passer by is still bouncing around in my head: It’s an easy one-line change.

I have no idea what that one-line change is; but I will figure it out.  It’s probably something really easy; something that once someone tells you you realize the piece you were missing.  It is driving me nuts because I know I should be smart enough to know the answer, and I don’t — and that bugs me.


But there is a chance!

I’ve been staring at the Amazon business card they gave me; both because I want to go download a barcode library and decode the barcode on it, and also because I really really want to submit my resume.

There are lots of reasons why I shouldn’t:

  • I can’t even figure out a simple probability problem
  • I’m just now learning Emacs
  • I’ve never even written a compiler
  • I’ve never used pointers in a production application

Reasons I should:

  • Not trying is much worse than trying and failing
  • Between ‘slim’ and ‘none’, I’ll take slim any day
  • Because that’s what I’d tell other people to do

To Be Continued…


Note to any employer (present or future): If I work for you, it’s because:

  • I like the work.
  • I like what I do.
  • I like where I work.
  • I like the people.
  • I like bullet points.

However, if Amazon or Google or Fog Creek Software or any other company that was universally recognized as a great place to work as a programmer contacted me and subsequently offered me a job, I’d probably put in my notice and leave.

It’s nothing personal.

Why would I leave? It’d probably have to do with the Joel test.  It’s the Ladder Theory for programming: we’re always going to go to the place that scores the highest on that test. One way to  keep good programmers is to score very highly on the Joel Test, the other is to hand out Porsches. I think the former is less costly for you.

Review: Stack Overflow DevDays – Washington DC

The Venue

DevDays at DC was held in the State Theatre, and it (as a venue) was suited for the information portion of the show, but wasn’t well suited for the ‘networking’ sessions that were held during breaks and during lunch time. The seats were set up in rows and there just wasn’t a lot of space for individuals to congregate in numbers greater than 5.


The Venue didn’t have beverages set up for us pre-show; which was expected due to the tweets the other venues’ attendees had made. There was music pre-show, as well a twitter feed with Stack Overflows DevDays countdown. The sound was high quality and the presentation of the venue prior to the keynote was of very high quality (considering).

Joel Spolsky – Opening Keynote

Once the opening video played (which, by the way, was perfectly cued to start with the closing of Drive In, Drive Out by Dave Matthews Band), it was apparent how much quality was put into the production of this show. The Video was high quality (though the part where it paused was a glitch) and the production quality of the video was apparent. They put some serious dough into making this look and sound good.

Once Joel came out he spoke with his usual wit; and it put the conference in the right ‘mood’. I won’t add too much other than to say that he is well versed in presenting and it was worth the price of admission to hear the subject matter. Other attendees had a problem with him touting FogBugz and having conspicious advertisements, but I don’t see a problem with that. If he were advertising for Microsoft, I’d be surprised; but he’s advertising for his own companyThat’s his Job.

Dan Pilone – iPhone

Production Note: Dan’s opening onto the stage was ‘rushed’, and it took a minute for the mic to catch up with him. I realize it was only a day conference and the price was cheap, but they probably should have worked on the ‘handoff’ better between speakers. This happened throughout the day, and while it wasn’t anything more than a ‘glitch’, it otherwise marred a perfect production (how it flowed, etc).

Dan’s talk on the IPhone hit the the true side of the ‘marketing’-speak. To paraphrase him: You’ll get rich if you make a great app, or if you’re a rapper. I would have liked a more technical presentation; but he didn’t have time for that. Given the time he had, he used it well, and it did whet my appetite for more. I may pick up his book on the subject to see what’s next.

He skipped the parts on Objective-C (presumably because they would have bored the hell out of half the room); but it would have been interesting to know how it diverges from other C-Based languages (other than the syntax is completely different).

I commend him for his presentation skills; he knew his subject matter and he was skilled enough in his environment to work around any glitches that came up. That’s hard to do when there are 200 geeks waiting for your next breath.

K Scott Allen – ASP.NET MVC

Hearing K. Scott Allen speak on ASP.NET MVC was a treat in of itself. He went through little more than the basics, but even for someone who’s worked on ASP.NET MVC for multiple projects, I still learned some stuff (notably the T4 Templates, which seek to make the “Magic Strings” strongly typed); and he even threw in some of the goodies from ASP.NET MVC 2 Preview that I hadn’t had a chance to play with yet.

Production-wise; it’s tough to give a talk without upsetting some geek somewhere. I’m sure there were quite a few Ruby on Rails guys that were just jeering at the ASP.NET MVC talk. That’s ok; we jeer at you when you’re not looking too (I kid, I kid). He probably couldn’t have changed much on it other than to have a fully ready-to-go expansive site that worked out MVCs muscle. I wouldn’t expect that for an hour talk, though.


Even if the rest of the show was a veiled advertisement for FogBugz, I still would buy FogBugz for my development team. Just looking at what that software can do is a testament to the developers at Fog Creek Software. I don’t care if you’re open-source or a Microsoft guy, that software is good. I’m talking yummy.

Lunch – Networking Session

The only ‘fail’ of the day. Not lunch, but the networking session that accompanied it. The Venue just wasn’t set up to house more than 5 people standing around; and the most interesting section (the one I wanted to hang out in – Startups) had 8 developers crammed into the opening for that section; with 15 more trying to hang out around it. It wasn’t happening.

Lunch was yummy and precisely what you’d expect for a $99 dollar conference.

Bruce Eckel — Not On Python

I loved Bruce Eckel’s talk. Didn’t learn a damn thing about Python (Because he didn’t teach anything on Python proper) but I learned the evolution of languages; which is quite important. You have to know why something is the way it is to be any more than a simple user of a tool; and his talk helped reinforce that point. Unfortunately people were offput because he didn’t just talk about Python, so there were grumblings from the masses.

He did make one point that I disagree with; and that was the reason Google was going to Python was because of the advantages it holds over Java (he spent a lot of time railing against Java. It’s ok, he wrote a book, he can do that); but I wanted to point out that while Google does use Python, they use Java too.

Jonathan Blocksom — Google App Engine

Informative; but light. He couldn’t do the walkthrough of his GAE site for whatever reason. Still enjoyed the talk; but don’t know enough about the subject matter to know whether or not it could have been better.

Richard D Worth – JQuery

Some people left during this part of the presentation, for whatever reason. Maybe they thought they knew JQuery, maybe they had to beat traffic (no way, not at 4:40 in the NoVA area); but they missed out on a truly awesome presentation. He introduced and went through JQuery and the various ways to ‘correctly’ use it, and in the process we got to play with and a site that tests JQuery Selectors. Fricking amazing.

Bottom Line

Well worth the price of admission; the topics were interesting. I would pay more if they would host it in a larger venue, or if they’d host it in the same size venue but actually make the area conducive to networking.

I also posted this review here, on

What are your Daily Hits?

In the book My Job Went to India (And All I Got was this Lousy Book), Chad Fowler writes about what developers can do to improve their craft.  There are 52 tips, and they range from positive gems like Be the Worst (#8) to other positive gems, like: You’ve already Lost Your Job (#43). 

All kidding aside; this book is chock full of tips meant to help us improve our craft, and it’s even gotten a facelift as The Passionate Programmer.

One such tip is The Daily Hit (#20):

As with most tasks that are worth doing, becoming a standout performer is more likely with some specific and intentional work.  When was the last time you went above and beyond the call of duty? Did your manager know about it?  How can you increase the visible instances of this behavior?

James McMurry, a co-worker who’s also a good friend, told me very early in both our careers about a system he had worked up to make sure he was doing a good job. It struck me as being remarkably insightful given his level of experience (maybe it’s a hint he got from his parents), and I use it to this day.  Without warning his manager, he started tracking daily hitsHis goal was to, each day, have some kind of outstanding accomplishment to report to his manager — some idea he had thought of or implemented that would make his department better.

Simply setting a goal (daily, weekly, or whatever you’re capable of) and tracking this type of accomplishment can radically change your behavior.  When you start to search for outstanding accomplishments, you naturally go through the process of evaluating and prioritizing your activities based on the business value of what you might work on.

Why daily?

Tracking hits at a reasonably high frequency will ensure that you don’t get stuck: If you’re supposed to produce a high per day, you can’t spend two weeks crafting the perfect task.

I’m guilty of trying to be perfect. When I sit down to implement code; I (very often) try to get the code working perfectly. I spend a lot of time fully implementing when I should be prototyping.  the daily hit is a way of prototyping instead of fully implementing a feature, and sometimes I wish this book came with a rubber mallet to beat me with when I forget its lessons. Do you keep track of your daily hits?

If you don’t know what your daily hits are, neither do your manager.


Bad Actors in your Code

During my time in the Army, I used to get rankled when I’d see Television or Movies portray soldiers.  Generally, they’d get something wrong; and usually, it wasn’t just something minor.  It didn’t usually bug me when it was clear they weren’t trying to get it right. It bothered the hell out of me when it looked like they tried to get it right, but failed in some way that could have been prevented if they would have spent $1000 and hired a military consultant for a day.

The same thing bothers me about naming in source code.  Well, not the military part, but the ‘bad acting’ part. Names that don’t do what they say they do, or names that don’t even mean what you think they mean.  These ‘gems’ can slow down development time and reduce the level of understanding from all team members. For every new person you bring on to the team, that’s another person that has to make the mental leap from what a word means to what it is used for in your application.


Here are a few bad names I’ve seen in source code recently, and they are all from commercial applications.

timeout  – Describes how old a file should be before it’s deleted

narrative – Refers to the ‘help’ field for a form or page.

nounset – where noun can be anything, like ‘bird’ or ‘category’ or ’email’ or ‘password’. The suffix ‘set’ is added to it to denote a ‘set’ of that noun. In some cases, it refers to a ‘template’.

That’s just a few; and there are more out there, probably in the application you work on.

What’s so wrong with bad naming?

Let’s say you have a new developer come onto your team. it doesn’t matter if this developer is just out of college or if he’s a 10 year veteran. He now has to learn what those words mean.  He then has to apply those names to the intent behind them, and daily has to remind himself of what they mean, since they aren’t used in their normal context.

Here are some possible solutions for the ‘naming problem’.

timeout  – fileAgeInMinutes

narrative – instructions

nounset – nouns, or nounTemplate (This can also rely on the fact that in databases, a table is considered a collection of things; adding ‘set’ is redundant).

It’s easy to change the name of something before it’s in use; but what happens when it’s in use?

Great question — one I don’t have a definitive answer to.

If you’re king of your particular hill, then you decree that the name is changed.

If you aren’t, then all you can do is raise awareness and push to having it changed in all parts of the application in the main branch, and make it an architecutural change for the next relief. It’s important to keep documentation up to date (preferably in source code) so that new developers know that in the ‘old’ version, it was called something different.

What are your thoughts? How do you deal with ‘bad names’ in Source Code?


Refactor Your Wetware: Review

Pragmatic thinking and learning coverI’m addicted to books. I like to read them, I like to collect them, I like to immerse myself and bathe in them.

Ok, strike that last part.

Generally I buy programming books, and since this book was sitting in the programming section, I figured I was safe.


Refactor Your Wetware: Pragmatic Thinking and Learning is a book that teaches you something within the first few pages and doesn’t stop until the book is closed.  It goes in depth into our methods and modes of learning and expounds upon them not only with well written ancedotes, but with research and practical examples.  From topics such as the Dreyfus Model to how our Right brain can solve problems when we’re not thinking about them, Refactor Your Wetware covers it.

Perhaps the biggest thing I learned from this book was the effect that our Right brain has on our problem solving ability.  When he couldn’t solve a particular problem, Benjamin Franklin would take a nap with ball bearings in his hand; and once he fell into a deep sleep the ball bearings would  fall and wake him up.  It was this moment when his Right brain was at its most active, and it would help visualize the answer.  This ancedote and more attest to the virtues of the right brain.

But Refactor Your Wetware doesn’t stop there. In true programming fashion, it deals with how to debug your brain and methods to remove bias from your every day thought.  It effectively covers methods of learning and retaining information with proven processes.  If you’re a knowledge worker of any sort, this book belongs on your bookshelf.