There is a great deal of mythology surrounding the birth and growth of AWS. Tech idustry awe and amazement is mostly justified but generally focuses on weaving together a linear narrative path that was taken that got us where we are:
Internal Problem Identified
Solution Identified and resourced
Aggressive iteration with continual expansion of problem/solution scope such that External stakeholders would see value
These steps are indeed a recipe that an established business could follow to create new high growth businesses but it does not fully explain how Amazon was uniquely in position to make AWS happen. It does not explain why AWS does not happen a lot. More often you see established companies shelving or selling off the fruits of internal innovation without ever capturing its value.
The secret seems to be a willingness to consciously avoid a “great idea – but that is not our business” trap where so many internal innovations go to die. It seems too easy too many times for leadership to do this. Avoid working at such places fellow dreamers and doers.
You can also watch her talk at React.js Conf here:
There are multiple ways to interpret data pointing to relative decline in mobile web usage. There is evidence of massive consolidation around a few key app behaviors vs general web usage on mobile devices but it also seems that evidence of the death of the mobile web is probably exaggerated or at least premature. If app usage of facebook, video, audio and messaging services are stripped out the picture becomes more interesting. As the baseline mobile web experience improves on high traffic sites, the incentive to install “yet another app” for an infrequent yet important use case diminishes. This will be interesting to watch
Bryan Cantrill (VP of Engineering at Joyent) gave an excellent and entertaining presentation about Debugging Production Systems. It is well worth an hour of your time if you work on large distributed cloud stacks in production. Some of the key things I took from the video:
Every failure is sacred. Seek to build a system that properly stores and formats stack traces for future analysis.
Cloud architectures are full of abstraction layers where “ungentlemanly” failures occur. Instead of crashing, things stay up, but performance is degraded.
It is these non-fatal pathologies that are particularly difficult to debug. They often lead to cascading levels of system instability and throw the system into untested states. It is this spiral that is often behind most airline disasters – a recoverable, non critical failure occurs then various failover/automatic systems either over-react or under-react then the airplane becomes difficult to control and systems no longer make sense so serious human error occurs.
When looking at a core dump, you are acting as a scientist and you are testing hypotheses and proving theories with data. When looking at non-fatal pathologies, you are acting as a physician and treating symptoms. Debugging this way makes it very difficult to determine root cause.
The talk ends with a small demo into the capabilities of DTrace. Amazing core level magic is going on there that can get static snapshots, enable transient failures to manifest as hard failures and generally reduce the effort required to gather failure data in dynamic systems.
It is often said that great start-ups are born when the founders are the users and the problem to be solved is going to make that founder/user person happy. You get some important related things for free with that setup:
A very tight and inexpensive user-product feedback loop
Version dogfooding by the same highly invested people during critical early iterations.
The state of mind of an ‘imagined unicorn user’ does not have to be imagined at all but is instead the direct feedback of a real person in the room building the product.
How do large companies create this loop? Is it even possible? It seems to require support for internal skunksworks projects (as opposed to hiring consultants and outside agencies) that is tasked to solve real problems that the company is experiencing. One shining example of such a project becoming a product is the internal Amazon project that is now AWS.
I may love geeking out and working on big complex systems but I also appreciate business simplicity and good content. I have found Scott Allen’s AngularJS courses to be very useful and it turns so do a lot of other people. Scott has found success paring his considerable teaching talent with simple onscreen videos and distributing them on platforms that enable wide on-demand distribution. This is a profitable solo business that does not require running complex propriety stacks – just a laptop, a good microphone and some talent.
I was interested to see that “Senior Web Developer” is the forth unhappiest job in the world according to Forbes. I have had this job several times in several industries. Indeed, these were often dirty, frustrating jobs – especially back when web standards were non existent and IE ruled supreme. But fourth unhappiest of all – really? Have you ever cleaned a deep frier at a chain restaurant or worked nights at a call center? Surely those must be unhappier jobs. Web development is pretty fun these days unless you work at a place that has no soul, no budget or no sense of what the internet is for. ..or is that just me?
Jazz Wax just posted a timely piece on Sonny Stitt on his interesting use of the experimental Varitone or Electric Sax. The goal of this 1965 instrument was to integrate the organic reed vibration sound generation process and electric manipulation and amplification of the sound. The instrument would provide a suite of on-board tools and would “get out of its own way” during performance – no tripping over microphone stands, fiddling with outboard effect patching or trying to double lines with a synthesizer to make a custom “modern” sound. Instead, the musician would have these options built into the instrument itself and these processes would be integrated into act of playing. Sonny Stitt was a daring experimenter and a believer in this idea. He was able to make some interesting music with this instrument despite its many technical limitations.
The overarching goals of the WordPress admin has seemed to me to be similar – integrate the content creation process with the web publishing and layout process such that the tools “get out of the way” and creative workflow is not only not compromised but at times enhanced. These are lofty goals and they are never achieved in one iteration. Many of the problems that were so difficult to solve for the Varitone would be trivial to solve now but others are still persist. I own a digital piano that is in many ways a superior instrument to most analog pianos, yet at times it still is not a real piano and then it fails badly. Technology is not cool in and of itself but only if it improves something. Sometimes complex technology goes largely unnoticed because it is so well integrated into something that someone already does. WordPress 3.3 is an important release because it smooths out a lot of rough admin usability edges, gets out of the publisher’s way more than ever, and makes it more fun to publish stuff. Sonny would enjoy playing with his release namesake I am sure.
An old essay called The Tyranny of the Extroverts resurfaced in my feed reader the other day. It got me thinking about some of the talented and shy developers and musicians I have had the privilege to work with over the years. These are the kind of people who trouble getting past an HR interview because of shyness or awkwardness. It scares me to think that a general gatekeeper might throw a potentially valuable candidate out the door before anyone else on the tech team would have a chance to talk to them because s/he seemed “weird” or “too quiet” or was unable to engage in tedious small talk involving American team sports. I consider myself to be a core introvert who can pass as a quasi-extrovert. It is impossible to be a manager without conjuring some style of extraversion from somewhere. My soul though remains allied to the introvert. The most difficult skill I have ever developed- the piano, was something I worked on and still continue to work on mostly alone. My great uncle was a renowned writer. He wrote alone for hours every day. When a talented software developer tells me s/he wants some time alone in a secret wi-fi treehouse bunker to think something through and bang out an idea or two I am inclined to make that happen.