Careers - Timing is a Thing

I am no daredevil, but I have taken risks in my career. The types of risks I am referring to here are the job/role moves I have made to explore opportunities and/or interests. Over my career, I have made some moves that have paid off and others that have not. I have learned from both, but that is a different post. In retrospect, the timing of some of those moves was important. Sometimes, that timing was related to business/market timing. For instance, I have started two companies; the second was the early 2000s tech bubble pop victim. More recently, in AWS, the product I transferred onto was absorbed into another product with a different charter. It was a risk when I moved- I knew the product had challenges. In each case, the timing was a factor. 

Timing is something we can only sometimes do something about. But it's worth considering, especially if you have a low-risk tolerance. You're probably thinking about the timing if you have a low career risk tolerance. A lot. Me? I have a relatively low-risk tolerance, but looking back at my career - I have made a lot of leaps.

No matter how much consideration I have given to the viability of a career change, there are simply things outside of my control. If I could have predicted the first tech bubble crash, I could have made a ton of money, but I probably would not be writing this. Sure, I was crushed at the time when something didn't go my way. After the reorg, I didn't get that promotion because the people evaluating me didn't "know me." The timing was wrong and entirely out of my control. Reorgs happen.

In the end, my career is more about experience than money. I have always had this notion that money is less important than what I am doing and who I am doing it with. So, the timing is something that I see in retrospect, but it is not at the top of my considerations.

What does it mean to lead?

Leadership is always something on my mind; whether personally or professionally I find it an interesting topic to continuously be humble around and strive to improve. 

Leadership comes in so many forms and I find it hard to define. More important than the definition is what leaders actually do is how they do it. There is one thing that I have brought over from my spiritual journey to my professional life that I feel is the key. 

It's not about you stupid. Let me 'splain. The most important thing I continually remind myself is that it's about others. Putting anything else first weakens leadership. First and foremost, people want to feel safe; when people feel safe then good stuff follows. Think about all the ways that this influences outcomes. When people feel safe, they are happy and happy people are capable of amazing things. First, and most importantly, is that happy people create a multiplying effect of creating more happy people.

The times that I think back to when I liked my job the most it was because I was happy, and I worked with a group of people that made it fun; even when it was hard.

It works on my machine

One truth I had to come to terms with earlier in my career was the "it works on my machine" anti-pattern. It's a close cousin to the name of my blog - sometimes words DO mean something.

This was back in the days before Windows (yes there was such a thing) and I was writing a custom TSR (terminate and stay resident) module that we used to communicate with the custom database engine we wrote on NetWare (starting to get a sense of the decade yet?). Long story short there was a problem with the code that prevented it from working on one machine - just one. And it wasn't like it always didn't work, it only didn't work sporadically.

In my arrogance at the time, I was slow to take a look at this issue. My arrogant thinking went like (1) this is the only machine to have the issue (2) I spent a lot of time on this code and especially testing it (3) this code has been running on hundreds of other machines without an issue (4) so it must be something particular to the machine or user. Fast forward a couple of weeks and surprise a couple more people report having the issue. It was then that a colleague and I were talking, and I woke up from the spell - "this is something I need to look into" I finally told myself.

Turns out the issue was an interrupt conflict with a badly behaved driver that was slowly be rolled out in a pilot and very soon would release across the entire org and would impact my, now thousands, of customers. Once I figured this out (which was actually pretty hard to do) - the fix was simple; I just switched to a different interrupt. There were other times when I fell under the spell of my own perfume, each time learning something and making me humbler.

Computers and software have grown much more complex since then. developers have much less control over all the code they are dependent upon. In the example above, I was dependent on the CPU microcode, the BIOS and MSDOS - all of which I had the source code for. I could usually discount the microcode (I only recycled the manual last year) which meant that any issue was either with my code or the few dependencies I had. The lack of dependencies and illusion of control was part of where my arrogance came from. But today there are dependencies on dependencies; it's such a complex ecosystem. And yet developers still have quite a bit of arrogance. 

Why am I writing about this now? This time I was the one user for which the application did not work - last year (mid-2020) it started, and I would constantly send logs and traces to the development team, and nothing would happen. I told them that my fear is that my experience was the "canary in the coal mine" and that either (1) other people are also having the issue and not reporting it OR (2) that at some time in the not-too-distant future it would become more urgent. 

The later was this week.

It now works on my machine.

Personal Air Traffic Control

Last year was a long delivery march at work for me and I had to drop many of the "fun" things I was doing. With that delivery in the rear view mirror I have been exploring some of the things I "bookmarked". Some of them are aviation related since I have a personal interest in the aviation field AND its related to my day job.

Turns out there are lots of ways that aircraft communicate with the ground and that ground uses to track aircraft - like radar and transponders. I have been digging into ADS-B which aircraft use to transmit basic data like GPS location, altitude and air speed. The interesting this is that ADS-B signals are transmitted "in the open" over VHF 1090 MHz.

Long story short - I setup my own receiving station using FlightAware PiAware. It's solution running on Raspberry Pi and a USB receiver that translates the raw radio signals to data. The whole thing is packaged up by FlightAware and they make it super simple to get it up and running.

I have been hacking around trying to get my own Python script to pull the data just to play; but it way more fun just to watch.

Old school gaming

I have been thinking about gaming a bit lately. In some part because of Twitch and it's association with Amazon and because someone on my team is working on a project that they conceived of during a Hackathon and was so cool we decided to turn it into a product. And it involves Twitch.

My history with gaming goes way back to high school. There I was learning BASIC on an Apple II. Monochrome monitor with a built in keyboard and cassette tape drive for storage. My go to computer game was the Star Trek game - an ASCII character based game where you would navigate/fire using a cross (up-down-left-right) pattern on the keyboard (there were no arrow keys yet). Once you typed in your command the program would then execute it and show you the resulting state. This was the definition of an interactive game at this time.

I was so amazed by this that I would beg my parents for a Sinclair ZX80 computer. At the time they cost like $200 - which was about $199 more than I had from my crappy paper route. So I would go grocery shopping with my mom so that I could go into the Radio Shack next door and program away on the TRS80s they had on display. Ironically my parents were willing to drop about the same amount of money on the original Atari game console. Although they bought one so early that the joysticks had not come out yet and all that it came with was the knob/dial controller for Pong.



Fast forward through all the arcade time I spent to when I had graduated and started a real job doing programming. Within a couple years Wolfenstein was released and I was hooked. The cool thing about this game was that if you had a local network you could play with up to four other people. Well it didn't take long for my friends and I to setup our IBM PCs around a kitchen table and start slinging Token Ring cables. More than once we would be missing a Token Ring terminator and have to delay playing until we found one.

The new games rarely hook me the way those old ones did. I am not sure why. The graphics these days are amazing - when I see screen shots from Red Dead II it blows me away. I feel a little like Richard Dreyfus at the end of "Stand by Me" when he writes “I never had any friends later on like the ones I had when I was 12. Jesus, does anyone?”. Maybe this is the embodiment of nostalgia.

What does a TPM do anyway?

At Amazon we have a role called TPM - of which I am one. It's not a role that I was familiar with until I started here.

As I talk to more and more people, candidates and peers my definition/description of this role have drastically evolved. Here are my current ramblings on this.

You may or may not know that Amazon.com (the website) is made up of hundreds (maybe more) of micro-services. Generally a service is owned by a 2-pizza team - that is a team you can feed with 2 pizzas. This creates a challenge for teams that build features that consume those services. And gets even more complex when you consider lineage of services, that is the hierarchy of service dependency.

In past jobs, we used to talk about things like service bus and services directories. These were ways that we were trying to tame service based architectures. In the end these met with marginal success (I am being generous). Actually they were very complex, obscure, hard to keep accurate. I remember spending months arguing over a service taxonomy. Yuck.


At Amazon we don't try to tame this environment. The rationale? It's a Day 2 type of mentality.

If you're thinking like a startup you aren't spending a lot of time trying to organize all your services. You're not trying to stamp out duplication. Day 1 companies are innovating, trying new things, letting things evolve and deprecating the stuff that doesn't "survive".

TPMs have to live in this world and make it possible for everyone else to as well. It is our job to architect technical solutions in this environment. To negotiate with others to get things done. Sometimes it means that we have to get scrappy. Your ability to do this and deliver something great for our customers is what makes a great TPM and what keeps Amazon...well being Amazon.

Sometimes Words Do Mean Something

Sent an email yesterday to a colleague asking for a link to something his team created on the website. A couple of people +1 the ask. The reply was that he was going to put a link to the item I asked for and others (I didn’t) on a wiki. He included a document that has a table with the format the wiki will take, but doesn’t have the data I was asking for.

After an email thread of 6 or more responses - I still don’t have the link.