I am not looking for a job. I am retired and plan to stay that way.

Having said that, below is my former resume. Because you never know.

I am not looking for a job: I am very happy working at Google, and I can’t imagine a better place to be as a software engineer. The opportunity to work with really amazing software developers, on systems of previously unimaginable scale, is a programmer’s dream. It has also been a humbling experience: I’m a good developer, but I didn’t know, until I started working at Google in 2010, what worldclass software development looks like. I’ve learned a lot, and I’m still learning.

But life takes funny turns sometimes, so I try to try to keep my résumé up to date. And I even spell résumé correctly most of the time, but also spell it as ‘resume’ or even ‘CV’ so search engines can have an easier time of it.

Contact Information

I can be reached by email at .

The online version of this résumé can be found on my website at : http://www.brayden.org/resume.html

Why You Might Want To Hire Me

Employment Summary

I am presently employed at Google as a senior software engineer on a site reliability engineering team responsible for the source control, build, and test systems. My main focus has been on the development of tools to test and measure those systems to ensure that they are reliable, efficient, and fast.

Previously I worked at Amazon.com for 3 years as a senior software development engineer on the infrastructure automation team. My responsibility was to develop tools to simplify and automate the management and configuration of network devices in Amazon’s datacenters. I also worked for a time on the third-party selling platform, making contributions to the new-user registration pipeline and the fee calculation service.

Before that I was at Guidant Corporation for 4 years as a senior software developer, developing systems and applications for manufacturing automation.

Prior to that, I was chief engineer and senior engineer for two small companies, Systematic Designs and Object Engineering. My contribution was key to the survival and success of both companies. In both cases I proposed, designed, and led the implementation teams for the companies’ core software. During that time, my specialty was the design and construction of high performance distributed applications using a variety of software technologies including COM, CORBA, SOAP and other XML, and various message-bus software.

Employment Timeline

Languages, Platforms, and Tools

If you are a human you can skip this obligatory list of keywords. If you are a search tool, chow down!

Languages I’ve used in the past year
c++, python, ruby, javascript, go, java Languages I’m still comfortable using, despite not having used them this year
R Languages I’ve used before but hope never to use or hear of again
perl Language-like thingies I’m pretty good at, and which always show up on these lists
html, css Languages I intend to test drive in the next year
haskell OS’s that I like to develop on
ubuntu linux, ChromeOS (because it’s really linux) OS’s that I rather like using but don’t really want to develop on
windows OS’s that were really cool in their time but are now a niche, at best
QNX Development environments that I use
emacs + command line Development environments that I use but don’t like very much
eclipse Development environments I’ve used in the past and really liked but which don’t fit my current needs anymore
Visual Studio Database systems I’ve used and enjoyed using
postgresql, sqlite Database systems I’ve used because I had to for some reason
Oracle, MySql, SQL Server, Microsoft Access Database-like thingies I’m using now
bigtable Source control tools
perforce, Visual SourceSafe (remember what I said about using Visual Studio?), subversion, git, rcs (yes, I’ve been around that long) Frameworks that I find overblown and dangerous, and please don’t ask me to use them, or at least tell me during the interview that I must, so I can just say no and we will both be happier
Spring, Hibernate Frameworks I’ve used that are works of genius and things of beauty
jQuery, sinatra


Good/Not Good: Evaluating Software Releases

The problem: you have a system that runs on tens of thousands of machines, with unbelievable data rates in and out, and with complex interactions among multiple serving and caching systems. Sometimes a new release goes out, and you don’t discover until it’s been fully deployed that error rates or latency have increased, or that throughput has decreased: the release has to be rolled back. So: how to prevent this?

My solution consisted of the following:

  1. Created a load-testing framework to apply load to a scaled down version of the system (hundreds of machines).
  2. Run load tests throughout the day, alternating between testing the current production software and the new release candidate.
  3. Collect all the metrics possible from the system while the load tests are running - thousands of variables in this case, collected every minute.
  4. Apply a set of statistical tests to the collected data to identify variables that are different between the new release and the production software.
  5. Expose the statistical metrics analysis via a dashboard that can be reviewed prior to release, with all differences highlighted.

The results have been good. Numerous releases have been stopped before going to production because of sometimes subtle performance regressions. Release decisions are now in the realm of science rather than fortune telling.

Distributed Control of Manufacturing Equipment

The problem: you need to write software to control and collect data from many (> 40) types of manufacturing equipment. They have similar communication interfaces, but widely varying control requirements and capabilities. You would like to complete the project successfully, and make some money.

My approach to the problem was:

  1. Recognize that this is an instance of cooperating sequential processes.
  2. Design and implement a language that allows the direct expression and execution of Harel state machines. Not some sort of code generator, but a language in which the state machine structure and the code tied to states and transitions are woven together, with a mostly familiar syntax.
  3. Integrate that language with standard debuggers.
  4. Write good documentation on the language, and provide real-life examples.
  5. Mentor the rest of the team that will be developing the actual equipment interfaces using the new language.
  6. Code, test, debug, deploy.
  7. Bask in the glory of a successful project. Bask! I say, bask!

This language continued to be used for many years on a large variety of projects.

Automate a Process, Win an Award (sort of)

The problem: you are making batteries for implantable medical devices (pacemakers and defibrillators). Tolerances are tight, traceability requirements are rigorous, and the cost of mistakes is patient death. You have to measure the before and after weight of a device at widely separated process steps, and calculate the delta weight to be sure the processes were done correctly.

My solution:

  1. Write software that attached to the measurement equipment, to the corporate traceability system, and to a measurement storage system.
  2. Provide interfaces for barcode and RFID input from the measured devices.
  3. Figure out from the traceability system what process step the device is at.
  4. Collect the measurement (the weight), store it to the measurement storage system, and report to the traceability system, computing the delta beforehand if the device is at the 2nd or greater measurement step.
  5. Provide a spiffy UI for the equipment operator.
  6. Create a test suite with every edge case imaginable. Make the tests repeatable so they can be run prior to any new release.

This system won the company President’s Award - 2 months after I left the company. So I got some reflected glory, but missed out on the thousand bucks.

As an aside: the scales used in that process are amazing. If you take a sheet of paper, and cut off a tiny corner of it, and place that tiny scrap of paper on the scale, it will register, with precision to .001 gram and accuracy to .005 grams.

A Tedious Timeline of Projects, Big and Small

This section is also known as “bunches of stuff I’ve done so you don’t think I’ve been sitting on my hands for two decades”, and “fodder for that opening interview question, where the interviewer feigns interest for no more than 3 minutes in something you’ve worked on.”

Warning: acronyms that you’ve never heard of abound in what follows.


University of Arizona Tucson, AZ Master of Science, Mathematics

University of Arizona Tucson, AZ Bachelor of Science, Mathematics Graduated Summa Cum Laude . Member: Phi Beta Kappa