The Sledgehammer – Version 2.0

March 24, 2012

Once More, With Ominous Glowing

Filed under: Technology — Tags: — Brian Lutz @ 10:57 pm

Shockingly, my desk isn't completely disastrous right now. Just mostly disastrous.

If you work with computers on a daily basis as I do, there’s a good chance that you do a lot of typing.  Even without taking the various Blog posts that I write into consideration, I end up writing a shockingly large number of things on a daily basis, be it e-mails, bug reports, message board posts, or any one of a number of other things that, for one reason or another, happen to need to be typed.   Even with all that I would consider the amount of typing that I do to be fairly moderate when compared to what some people who type things for a living might do on a daily basis.  Regardless of the actual quantity of stuff that I end up typing on any given day, the last thing I want to deal with is a bad keyboard.  I’ve gone through a number of the blasted things over the years, some of them quite good, others just plain terrible, most of them simply not memorable enough in either direction to remember much about them.  Most recently, I’ve spent roughly the last 20 months using one of the more mediocre ones, one purchased for all of $16 at Fred Meyer around 10pm one night when my previous one (which I had spent a fair bit of money on) quit working on me roughly five minutes after the warranty ran out. 

I actually wrote a Blog post about the topic back when I first purchased the keyboard that went kaput, in which I discussed the process of trying to find a new keyboard among a sea of mostly identical (and mostly mediocre, if not actively stupid) choices.  I’ll avoid rehashing the whole thing since you can just go read it if you want, but the short version is that shopping for keyboards is confusing as heck.  Granted, I wouldn’t call myself a keyboard snob or anything like that (your mileage may vary on that one) but I do tend to be a bit picky about the topic.  For example, I avoid wireless keyboards entirely, mostly because there’s just no point in having a wireless keyboard when it’s highly unlikely that it’s going to be used anywhere besides on top of the desk where it resides, and all that a wireless keyboard really does for you in that scenario is make you change the batteries every so often.  I suppose if you’re trying to stockpile a large number of dead batteries for some nefarious purpose that you do not wish to disclose to the rest of us until it’s everlastingly too late that might not be a bad thing, but for those of us not plotting assorted villainy with ordinary household items that just sounds annoying.  I also prefer keyboards that are as free of extraneous functionality as possible (especially the dreaded F-Lock key,) since mostly the extra stuff just gets in the way and none of the added functionality ever seems to get used anyway.

That said, I must admit that the last time I was shopping for a keyboard at any time other than late at night at the only place that was open, I might have gotten myself slightly distracted by bright shiny objects than I should have.  As you can see from the post linked above, I ended up with a Logitech G11 “gamer” keyboard, which didn’t really make it any better for gaming than any of the other stuff that I have used over the years, but it did come with one advantage:  It had bright shiny blue LEDs under the keys, which kind of looks cool.  Which is about all it did well really;  practically from day 1 I found myself annoyed by the thing, which had a tendency to squeak and rattle while I was typing.  For the most part I just put up with it, but ultimately the thing lasted just a little bit more than a year before several keys mysteriously decided to stop working and basically turned the whole thing into a shiny blue paperweight.  As noted above, a field expedient replacement had to be obtained at a fairly late hour in the evening, with the intent of replacing it as soon as possible.  Which turned out to be nearly two years later, meaning that the $16 el cheapo replacement keyboard lasted nearly twice as long as the $70 fancy blinkenlight keyboard it replaced, and is still in working order now to file away as a backup just in case this one decides to bite the dust at an inconvenient time.  Not that I’m expecting this type of thing to happen on a regular basis, but it never hurts to have a spare around, right?

It’s not like I haven’t been meaning to replace the thing though.  On my occasional trips to Fry’s I’ve made a point to take a walk through the keyboard aisle in an attempt to locate something that isn’t stupidly designed and/or horrendously expensive, and have invariably come up empty handed.  There are definitely some nice keyboards out there that fit all the criteria I’m looking for, but the things have a pesky tendency to come with $120 price tags, which is definitely pushing it in the price department.  Sure it’s something that I’ll be using constantly, but mostly the extra money seems to buy extraneous features I’d never use.  I’ve noticed that a lot of the so-called gamer keyboards like to cram a half zillion extra buttons on the things, then design the stuff so it requires a rocket scientist to figure out how to use any of the blasted things in your games.  Not that I’d use them anyway; I try to make a point of avoiding anything that would require an extra driver to get it to work.  But finally earlier today I found something that looked halfway decent, was reasonably good to type on, had backlighting, and didn’t cost an arm and a leg (just an arm really,) so on a bit of an impulse buy I finally got myself the new keyboard you see above.  So far it’s at least 27%(Note: completely made up statistic)less annoying than the last couple of keyboards that I’ve used, and it has the added feature of being able to choose from three different colors for the backlighting: blue, red and purple (which seems like kind of a silly color for a keyboard, but since it’s basically just the red and blue together, might as well throw it in I guess.) 

I haven’t quite figured out which color I prefer at this point, so I keep switching between them in order to try to figure this out.  Color switching is accomplished by means of a button up in the top right corner, which naturally leads to some bad ideas.  Throw in a few glowsticks I happened to have lying around the house for some odd reason, some gratuitous misuse of a flashlight and an automatic blinkenlight setting on the LED on the back of my phone, and we’ve got all the ingredients for an impromptu keyboard rave.  I apologize if this happens to be the stupidest thing you’ve seen all day, but it had to be done.  Enjoy (or stare in bewildered amazement, your pick) and remember that drugs are bad kids.


March 17, 2012

Random Thoughts: A Sampling of Some of My Recent Bad Ideas

Filed under: Random Stuff — Tags: — Brian Lutz @ 3:19 pm

I’ve been back to work for nearly three weeks now (thus now doubling the amount of time I have spent working at Amazon over the course of my long and vaguely industrious career,) and I think by now I’ve mostly gotten used to the commute.  Getting to and from Amazon’s South Lake Union campus was one of the main concerns I had with working there, but they actually do a pretty good job of dealing with this, providing a set of shuttles to and from the Downtown Bus Tunnel that solve the last-mile problem involved with getting there and back.  These shuttle rides to have an occasional tendency to involve exposure to potentially hazardous doses of NPR, so I really need to invest in a good pair of headphones so I can conveniently live in my own preferred echo chamber, thank you very much.  I’ll refrain from ranting in too much detail on the topic (after all, I do prefer to keep this particular Blog as free of politics as possible) but I’m guessing that there are plenty of experts out there who recommend starting your day off with something a little bit more uplifting than vague simmering rage.  In spite of that, I’m actually quite enjoying the work I’m doing there, although you won’t be hearing much (if anything at all) about it due to the various non-disclosure agreements involved.

One thing I have found with the new job is that, unsurprisingly, spending an hour and a half  (give or take fifteen minutes or so) commuting every day does tend to cut back on one’s free time a bit.  And then on top of that I’m finding that a good chunk of the remaining time is taken up by my social life (still a bit shocked that I managed to end up with one of those at some point, but I don’t think I’m complaining too much,) which leaves me a little bit short on content at the moment.  I’ve actually got a post from the cruise back in January that I still need to write, but in the meantime, Random Thoughts are the last refuge of the scoundrel.  Which makes me a scoundrel, but what else is new?

– A few weeks ago while trying to watch some TV, I found that things seemed to be just a little bit off.  Based on what you see above, I’d have to say that either children’s television has seriously gone downhill since the last time I checked, or I had something seriously messed up with my cable.  I’m guessing the real answer was somewhere in between the two, but that’s another post.  Anyway, in addition to misplaced channels, I had some channels that weren’t displaying at all, which seemed to suggest a problem.  A call to Comcast to  report the issue ended up turning into an ordeal that ultimately lasted more than a week while I tried to get everything sorted out.  At first, the issue was suspected to be with the Cablecard in my Tivo, but a support call that lasted nearly an hour and a half found that for some odd reason the card that I had was still registered to my old address, and could not be added back into the system for some reason.  This required a trip down to the Comcast office in Redmond to swap out the old card for a new one that would actually talk to them (sort of).  After acquiring and installing the new card, I quickly figured out that it didn’t seem to be working either, and couldn’t get it to pair with either the Tivo or the newly acquired TV tuner card in my desktop PC. 

By the time all was said and done, it took a half dozen calls and/or online chat sessions with support before anyone could figure out that the card I had acquired from the local Comcast office hadn’t been registered in their system, therefore making it a vaguely decorative paperweight that might be able to put a few shiny numbers up on a screen every once in a while.  Once that was sorted I could finally pair the card and watch TV again…  Which put me right back where I started, with missing and misplaced channels.  For now, I’m just going to assume that most of the stuff I’m interested in is still where it’s supposed to be, but I’m dreading the inevitable half dozen more support calls I’m guessing it’s going to take to get everything sorted out.  In spite of the ordeal, I’ve got to say that Comcast has been surprisingly helpful and not nearly as difficult to work with as their reputation might suggest.  Granted, it’s still a company that still doesn’t advance much past “Necessary Evil” status for the vast majority of their customers, but I’ve got to give them credit for putting up with some of my various cable-related dramas over the years.  It might still be nice if I could find some kids shows where the Cat in the Hat isn’t suspected of possessing drug paraphernalia by the time I have kids of my own, but I’m still working on that one.  At this point, it’s anybody’s guess which will be first:  children, or cable that works.

– As far as I’m aware, I haven’t used up my monthly allotted “complain about the weather” Blog post, so I might as well get it out of the way now, mostly because I have no idea what’s been going on with the weather lately.  Yes, it’s still late Winter, and I shouldn’t be too surprised that the weather might be a bit odd at times around this time of year, but lately the weather seems particularly schizophrenic.  This past Thursday seemed particularly moody, as at different times throughout the day I witnessed the usual background sprinkling alternated with torrential rains and nearly clear skies.  Not to mention at various times there’s been snow and/or hail thrown in the mix just for good measure.  According to the weatherman, over at Sea-Tac Airport (where the weather station of record for the Seattle area is located) there’s been at least 1/3″ of rain every day for the past eight days now.  I’d say that the impending arrival of Spring might put an end to the madness, but I’m pretty sure that it doesn’t mean a blasted thing from a meteorological standpoint.  Oh well, at least the scenery might get a little better when the blossoms start showing up.

– The combination of snow outside while I’m writing this and the 12 Hours of Sebring streaming live on ESPN3 (which happens to fit rather conveniently on my recently acquired second monitor) is making it hard to get much accomplished today.  Not that I have a whole lot that I need to really accomplish today anyway, but it’s not like this is exactly motivating me to go out and get any of that nothing done in any sort of hurry.

– This morning, I managed to sleep in until 9.  There was a time not really all that long ago when that would have been my “normal” wake-up time in the morning.  I guess that’s one of those things that people who live in reality have to deal with every so often.

– I think I’m going to have to do a reinstall of Windows on my system soon, things have been acting up quite a bit lately and I’ve had updates that just won’t install for some reason.  I suppose I can’t complain too much, this system (and the last one I replaced with this one) have been far more reliable for me than a lot of the other ones I used to own.  I could claim that it comes with improved skills in building these things, but I suspect that the actual answer has something to do with ditching AMD processors for Intels.  Not that I necessarily want to be supporting the proverbial 800-pound gorilla in the market here, but it seems like the stuff is a lot more reliable.  Then again, it’s been years since I last used an AMD-based system, so who knows how these things are these days?

– Lately, for some reason I seem to be watching a lot of the show Storage Wars on A&E.  It’s a reasonably interesting show, but I I can’t help but have the nagging feeling that I should feel guilty for watching it for some odd reason.

– When all the various distractions involved are taken into account, it’s taken me roughly eight hours write this post.  I suppose I should finish it off now before I get distracted aga- Oh look, a bunny!

– Oh, and by the way, WordPress’s spell checker is still mind-numbingly stupid.  No, I did not misspell “4”, thank you very much.

March 11, 2012

The Basics of Software Testing: How Well Does Your Software Really Get Tested?

Filed under: Quality Assurance, Technology — Tags: , — Brian Lutz @ 1:14 am

(Note:  This post is part of what I plan to turn into an ongoing series of posts describing some of the basics of software testing.  Although there has been a lot written on the subject of testing over the years, I have found that a lot of it is, to put it nicely, not particularly user-friendly.  Boldly ignoring the adage I saw on a recruiting poster at Microsoft once saying you should work for a particular team because you never want your Mother to understand what you do for a living, what I intend to do here is explain, in a nutshell, how software gets tested, how the results of that testing get dealt with, and generally what the role of a software tester is in the development process.  I’m trying to keep the jargon to a minimum here, but I apologize in advance if this gets just a bit too technical.)

In our modern society, it can be very easy to take things for granted.  Take, for example, your household appliances.  Most of the appliances found in a typical modern household are items that just a hundred years ago were either years from being invented at all, or very expensive and difficult to attain for most people, with the tasks they perform requiring significant quantities of manual labor to perform.  In particular, it could be an all-day project just to do the laundry by hand in days of yore before washing machines were invented.  In our modern age, this once laborious task has been reduced down to throwing your clothes in a machine with some detergent and maybe a bit of bleach, setting a dial and walking away and throwing it in another machine when the buzzer goes off at the end of the cycle.  In fact, about the only time most people are going to give much thought to the process of doing laundry is when something goes wrong, such as when the machine breaks down for one reason or another, or when an imbalanced load creates a vibration in the machine that can shake the entire house.  In the same vein, the previous apartment I lived in before I moved to Downtown Bellevue provided me on a couple of occasions with firsthand experience with the joys of a hot water heater developing a leak at 8:30 on a Sunday evening and soaking the surrounding carpeting.  Can’t say I ever paid much attention to it before that one happened.

By the same token, much of the software that runs not only our computers but also an ever-increasing number of other electronic devices found in a modern household tends to fade into the background for most users 99% of the time, and only really gets noticed when something goes wrong or proves incapable of doing whatever that the user is trying to use it for.  When things start breaking, it’s easy for the average user to jump to conclusions and blame a lack of testing on the part of the developers for their present woes.  Although in some cases that assertion may not be entirely unjustified, it’s often a lot more complicated than that.  It’s been said that there is no such thing as a completely bug-free piece of software (with the possible exception of one of the “Hello World” programs that you tend to find on the first page of a beginning programming book,) and as programs continue to get more and more complex, there’s more and more things that can possibly go wrong.  Naturally, this also means that more and more things will, in fact, go wrong at some point.  And by the time all the development and testing is done and the software goes out the door, it’s inevitable that a few things will have slipped through the cracks, no matter how much testing gets done and how many testers you have hammering on it. 

What might be a bit less obvious to the average user is that there will also be a number of bugs in any product that were identified and filed by the testers, but were not fixed in the final product.  Some people might find it shocking that software would be shipped with the full knowledge that there are bugs in it, but it’s really just a natural part of the process of developing software, and 99% of the time, it’s nothing you would ever notice anyway.  I’ll most likely save the subject of how bugs are found and how they’re dealt with for another post, but when it all boils down, it mostly boils down to prioritizing things and making sure that the limited development resources on a project are being used in the most efficient manner possible, and at times a bug fix will prove to be more trouble than it’s worth.  For a novice tester this can be a difficult concept to understand at first, but over time they will learn to pick their battles and know what they might need to push back on and what they should just let go.  In short, not all bugs are created equal.  In a future post in this series, I plan to go into a bit more detail on how bugs are handled within the software development process, but in general, there’s some process of sorting and prioritization (commonly known as triage) that takes care of this aspect of things.

That said, when a product (or in most cases, a smaller portion of a much larger product) gets handed off from the developers to the QA team, how does it get tested?  Although a lot of the details are going to be dependent on the specific item in question, ultimately the approach is going to be similar no matter what you’re testing.  It is for this reason that a favorite technique of technical interviewers interviewing candidates for test positions is to specify some random item, and ask the candidate how they would test it.  Although most of the time this ends up being some sort of software component, there’s no reason this has to be limited to software, and on a number of occasions I’ve been asked how I would test completely random items ranging from vending machines to those misting systems they use to spray water  on the produce at your friendly neighborhood grocery store.  You’ll find in an interview for a technical position like this that the interviewers are looking less for “correct” answers to this problem than they are looking at the thought process that goes into it.  For even the most mundane and utilitarian of items, it should be possible (and expected) for an experienced tester to quickly devise a plan for testing many different aspects of that item, including functionality, performance, stress, real-world usage, globalization, and a number of other situations that particular item may be involved in.  Although the product in question is often something that has little to no relevance to the product that the tester is ultimately going to end up working with, the methods will be similar, so this still makes a good illustrative example.

When it comes to actually testing software, the approach here is going to be similar but at the same time somewhat different, and in my experience tends to be largely dependent on what is being tested, and where in the development process you happen to be joining.  For example, if you’re joining a project that has been in development for quite a while and which already has a test team in place, chances are that a lot of the groundwork of test plans, test methods and test cases will already be in place, and the duties of the tester will be largely in maintaining the existing base of test cases, running test passes, and (if applicable) working toward automation of the existing cases.  On the other hand, if a tester is joining in on a project that has had little to no testing done on it prior to his or her arrival, chances are that the tester is going to be doing a lot more of the foundational work of creating the test plans and the test cases on which the future testing will be based.  Not all the testing will necessarily be this structured though.  As with above, I intend to go into more details on how test plans and test cases are created in a future post.

Another common type of testing that takes place is known as ad hoc testing, which is basically the “bang on it with a hammer and see what breaks” type of testing that most ordinary people will think of first when the subject of testing software  comes to mind.  This can either be directed, where the tester is focusing on certain areas or certain features but still isn’t working from formal test cases, or undirected, where the tester is basically just messing around with things to see what breaks.  Even on a project with well established test plans, test cases and automation in place, there is still benefit to be gained from this less directed form of testing.  In my own experience, I have found that a good session of ad hoc is not only a surprisingly effective way to get started on something, as not only does it frequently catch a number of bugs and give the developers something to work on fixing while I’m in the process of establishing more formal tests, it’s also a good way to become familiar with the product and start planning for more formalized testing later on in the process. 

Although ad hoc tests can be a good way of  identifying a decent quantity of bugs quickly, they do come with some disadvantages.  For one thing, an experienced tester might be tempted to dig into deep dark corners of the product and try to find some really arcane bugs.  Scenarios like this are what’s known as edge cases, and represent the types of situations that are going to be encountered rarely (if ever) when real-world users start using the product.  Fixing these more arcane bugs will generally be a low priority for the developers, as they will often have far more important things to be working on.  Even so, the benefits of ad hoc tests tend to be worth the effort that goes into them, and on large software projects it’s not uncommon for what’s known as a “Bug Bash” to be scheduled somewhere in the development process.  A Bug Bash is basically a period of time set aside where developers, testers and even project managers all get together and just bash on the product (with varying degrees of direction, usually more generalized than specific) to try to dig up as many bugs as possible in a certain period of time.  Some places even go so far as to turn this Bug Bash into a competition with prizes for whoever finds the most or the biggest bugs.  This can be a useful tool for getting different sets of eyes on the product, and perhaps getting a bit out of the tunnel vision that testers can sometimes develop in the course of testing things.

Of course, a piece of software in development is a moving target for testers, and as a result, it is a necessary part of the development process to run the same sets of tests frequently to make sure that not only are things working the way they’re supposed to as they get developed, but also to make sure that further development on other areas of the product isn’t breaking existing functionality or introducing new bugs into existing components.  As a tester, running the same sets of tests over and over repeatedly tends to become incredibly tedious.  This is where automation comes into the picture.  Automation is another subject that will most likely get its own post later on, but in a nutshell, automation is the process of using a piece of software known as a test harness to automatically control the functions of the software being tested.  Since the vast majority of test cases that will be run in the process of testing a product are going to be specific sets of actions with  predictable expected results, this means that the test harness can be programmed to perform these actions automatically and verify that the resulting output of those actions matches what is expected, assigning a pass or fail result to each case based on this.  Having the software being able to essentially test itself can greatly reduce the drudgery involved in running the repeated test passes necessary in development, and is especially useful for the set of high-level tests that gets run for each build to make sure that it is acceptable for testing (known as Build Verification Tests, or BVTs.)  Although automation can greatly reduce the workload of the testers, there are limitations to what can be tested with automation.  For example, user interfaces tend to be a lot more difficult to automate compared to lower-level components like APIs and webservices, and it is virtually impossible to fully automate the testing of a piece of software because of the sheer complexity involved in most software projects these days. 

There are a number of off-the-shelf products on the market that can be used to create automated tests, but in my experience I’ve found that a lot of the places I’ve worked tend to reinvent the proverbial wheel when it comes to test automation, and it’s surprisingly common to see automation for a product being handled by a proprietary test harness made specifically for that product.  Because of this, the process of automating tests can require far more programming than testing.  Most test automation is created by a group of engineers known as Software Development Engineers in Test (commonly abbreviated to SDETs) who tend to exist in a bit of a fuzzy space somewhere between the development team and the test team (usually closer to test than development though,) and who spend a majority of their time programming automation tools and creating the automated tests that will be used.  In fact, it is not uncommon to find development teams where all the testers are SDETs, and comprehensive knowledge of software development and programming languages is an expected prerequisite to qualify for the work in addition to the usual test experience.  This isn’t to say that any project manager in their right mind is going to rely exclusively on automated testing to verify the quality of their product; in most cases this means that you have people who are wearing both the developer and the tester hats as needed.  There are quite a few other types of tests that take place in a software development cycle (such as performance testing, stress testing, internationalization testing, unit testing and others,) but the ones you see above tend to account for the vast majority of testing that happens on a product under development. 

As discussed above, people tend never to notice all the work that goes into testing a piece of software until something goes awry, at which point they invariably suspect that no matter how much actual testing took place, there obviously wasn’t enough of it.  And yet in spite of this perception, testing is a fully integrated part of the software development process, just as important to the success of a product as the developers who do the actual development work are.  As I continue with this series of posts and try to explain in more detail how software gets tested, I hope to give a little bit more visibility to the role of testers and just how important the work they do is in ensuring that the average user rarely has occasion to pay much attention to the software they are working with.  It’s a nerdy job, but someone’s gotta’ do it…

March 1, 2012

When You See a Fork in the Road, Take It

Filed under: Random Stuff — Brian Lutz @ 11:31 pm

When I lost my job back around the middle of January, I was admittedly a little bit disappointed.  Not so much about the fact that I suddenly found myself to be unemployed, but because I was really enjoying the project that I had been working on at the time, and the end of my employment at Motricity meant that I wouldn’t get to see it through to completion.  Well, that and the fact that in all likelihood I would be losing my easy three-block walk of a commute, but that was just gravy.  Over a career that had consisted mostly of contracts at Microsoft prior to this, I have had all sorts of various experiences with being shown the proverbial door with little to no warning.  That said, I’d have to say that the process was handled about as well as could be expected given the circumstances (I was far from being the only person in the office making an unscheduled departure at the time,) and when all is said and done, I really don’t have anything to complain about.  The time I spent there definitely had its ups and downs, and it’s unfortunate that the ever-popular “Circumstances Beyond Our Control” happened to conspire to bring this to a not completely expected close, but this was definitely a good opportunity while it lasted.  I got to work with good people, the benefits and vacation time were nice, the projects were interesting, and all in all I consider the time I spent at Motricity to be a very positive experience.  But as with quite a few other things in life, it was time to move on, whether I intended to or not.

Fortunately, years of Microsoft contracts with the tendency to end either expectedly or unexpectedly have taught me well to save up for a rainy day and generally avoid going overboard on spending money, so fortunately when these particular circumstances came around, I was well prepared for them, which left me (somewhat unusually) in the position of not really needing to be in any particular hurry to get back to work at the time.  On top of that, I also happened to have a nice little vacation scheduled (and most importantly, completely paid for) just a bit more than two weeks later (I still have a Blog post or two I need to get out from that trip,) which is always a nice thing to have regardless of the circumstances.  It was definitely a nice trip, although it wasn’t without its share of ups and downs (mostly a result of rough seas and an outbreak of Norovirus on the ship,) but I’m thinking that the next time I take a trip like that I should seriously consider having someone at or near my own age to bring along.  But as things do, the trip came and went, and ultimately it was time to return back to dry land and face reality once again.  But thanks to the aforementioned planning and saving, it wasn’t quite so much the usual cold hard crash back to reality I usually seem to end up with when this type of stuff comes around.

Another thing that has come with years of contracting at Microsoft is the fact that for better or for worse, I seem to have accumulated a fair bit of experience with job hunting during that time.  To be honest, it’s really not the type of thing I’d necessarily like to have as much experience with as I do, but it does tend to come in handy every so often.  One thing in particular that’s stood out from this experience is the importance of not burning bridges unnecessarily.  It’s been said that the people you meet on the way up the proverbial ladder are inevitably going to be the same people you’re going to meet on the way back down.  While I don’t care to speculate too much about which direction in that equation I seem to be trending in, I’ve definitely found that having a good network of people who you’ve worked with or associated with over the years can definitely make things easier when circumstances head off in one of these semi-unexpected directions.  One of the more interesting phenomena I encountered during this time was the fact that I had to do hardly any job searching at all.  Quite a few things found their way to me via the network of people I’ve worked with over the years, and ultimately it was out of some of these years-old contacts that I came up with the job that I began earlier this week.

To make a long story short, I am now on another contract at Amazon, working on stuff that I’ll refrain from discussing here at this time due to various non-disclosure agreements.  Although I have spent time (sort of) at Amazon before, this is the first time I have worked at their still relatively new South Lake Union campus, and even though it does bear at least some superficial similarities to Microsoft, there’s some notable cultural differences involved as well.  Perhaps the most noticeable one is the fact that most Amazon buildings permit employees to bring their dogs with them to work.  Not that I plan to try this anytime soon though.  I suspect that trying to bring Imola and Minardi to the office would somehow turn into a recipe for disaster…  Well OK, maybe Minardi might be OK, but you hardly ever see one without the other, and I’m pretty sure Imola would be sure to be on her worst behavior the whole time, and I don’t think trying to separate the two would work out too well.  But I digress.  Of course, working in Seattle again does mean that I had to give up the cushy three-block walk to work I had at my last job and join the 96% or so of the working population that actually has to commute to work, but the job over at Motricity was just one of those situations where all the right circumstances fell into place to make for an unusually easy commute.  That said, the commute isn’t too bad (the fact that Amazon provides their own shuttles from the bus tunnel certainly doesn’t hurt) and I’m sure I’ll get used to it soon enough.

As I have frequently noted here on this Blog and to people I discuss these things with, I find that one way or another things always seem to work out for me.  In my case, it frequently seems to happen much more in the “or another” category, but I suppose that’s still better than things not happening at all, right?

Blog at

%d bloggers like this: