You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
281 lines
13 KiB
281 lines
13 KiB
---
|
|
roles:
|
|
- id: bazel-configurability
|
|
image: jobs/google/bazel.png
|
|
name: Software Engineer # III
|
|
team: Bazel Configurability
|
|
company: Google
|
|
startDate: 2016-07-15 # vague guess - this was around when I would have
|
|
# started getting to work on reviewing configurability
|
|
# changes and getting up to speed on this team
|
|
endDate: 2019-10-04 # dead on, this was my last day at Google
|
|
shortDescription: >
|
|
Optimizations and flexibility for multiplatform builds for Bazel projects.
|
|
description: >
|
|
Primary expert for _configuration trimming_, a major overhaul of Bazel's
|
|
multiplatform support to save time and memory for users by collapsing
|
|
equivalent nodes in the build graph.
|
|
achievements:
|
|
- id: feature-flags
|
|
description: >
|
|
Designed and built a feature flag system for Bazel, used by ~50
|
|
Android teams within Google, with more asking to be enabled weekly.
|
|
- id: whitelisting
|
|
description: >
|
|
Designed and built a mechanism for controlling rollouts of Bazel
|
|
features, which was quickly adopted by other subteams within Bazel.
|
|
- id: attribute-refactor
|
|
description: >
|
|
Refactored Bazel's attribute support, prompting a code owner to
|
|
describe the result as "so much better it hurts."
|
|
- id: test-trimming
|
|
description: >
|
|
Sped up developer build/test switching, saving 2min+ reanalysis on
|
|
each switch, adding up to an hour or more of wait time saved per
|
|
engineer over a day's builds.
|
|
- id: tagged-trimming
|
|
description: >
|
|
Implemented manual trimming to get Android developers
|
|
reduced memory use immediately, saving multiple GB of memory
|
|
per build and avoiding OOM conditions.
|
|
- id: tagged-trimming-rollout
|
|
description: >
|
|
Built a fully automated Python-based migration tool for and consulted
|
|
with users to roll out manual trimming, saving hours of tedious manual
|
|
corrections per project.
|
|
- id: auto-trimming
|
|
description: >
|
|
Researched the automatic trimming problem and wrote over 60
|
|
pages of design documents proving the viability of trimming and the
|
|
tradeoffs of different options.
|
|
- id: trimming-prototype
|
|
description: >
|
|
Built a TypeScript/Angular2-based prototype to gather data on the
|
|
tradeoffs of different trimming algorithms with real builds and
|
|
integrated a prototype into Bazel.
|
|
- id: bazel-u
|
|
description: >
|
|
Ran multiple talks for the Bazel team about trimming and feature
|
|
flags, consulted with individual developers across teams, and received
|
|
a peer bonus for my expertise.
|
|
- id: trimming-metaphors
|
|
description: >
|
|
Wrote an easy-to-read introduction to the complexities of trimming and
|
|
received a peer bonus describing it as "one of the best docs I've read
|
|
at Google."
|
|
- id: bazelcon
|
|
description: >
|
|
Solicited experts for BazelCon 2018, coordinated rooms day-of, and
|
|
made office hours work despite last-minute loss of venue. Received a
|
|
peer bonus from the head organizer.
|
|
- id: personal-postmortem
|
|
description: >
|
|
Wrote, gave a talk on, and received a peer bonus for a document
|
|
speaking frankly about emotional safety on the team.
|
|
- id: team-culture
|
|
description: >
|
|
Proposed improvements to team culture, ran meetings on the subject,
|
|
consulted with management and gathered feedback from team members.
|
|
- id: kotlin
|
|
description: >
|
|
Consulted with the Kotlin team at Google about the possibility of
|
|
using Kotlin within Bazel.
|
|
|
|
- id: bazel-release
|
|
image: jobs/google/bazel-old.png
|
|
name: Software Engineer in Test # II
|
|
team: Bazel Release Process
|
|
company: Google
|
|
startDate: 2013-09-15 # rough guess, since I was still working on Wallet in
|
|
# Q3 2013, but had fully transitioned to Bazel by
|
|
# Q3 2014 - but it hadn't gotten cold yet
|
|
endDate: 2017-06-15 # did I truly ever stop working on the release process?
|
|
# however, this is around when it stopped being my job
|
|
shortDescription: >
|
|
Migrations, stability, and features for the internal release process of
|
|
Bazel (a.k.a. Blaze).
|
|
description: >
|
|
Local expert on Google-internal release and testing tools, primary expert
|
|
on the release process for the Google-internal version of Bazel (a.k.a.
|
|
Blaze).
|
|
achievements:
|
|
- id: testability
|
|
description: >
|
|
Updated old release Bash scripts to allow for testing of changes
|
|
without risking the stability of the release.
|
|
- id: autorerun
|
|
description: >
|
|
Automated the rerunning of all tests across Google's continuous
|
|
builds, saving sheriffs the time and hassle of manually checking the
|
|
results and starting reruns.
|
|
- id: documentation
|
|
description: >
|
|
Thoroughly documented the existing release process and all changes
|
|
being made to it and presented this information at a team summit,
|
|
received a peer bonus.
|
|
- id: sheriff
|
|
description: >
|
|
Consulted with sheriffs and acted as a go-to backup sheriff during
|
|
especially difficult situations. Received 4 peer bonuses for different
|
|
key moments of help.
|
|
- id: redesign
|
|
description: >
|
|
Designed a new version of the release process using more modern
|
|
infrastructure, avoiding version desync problems and allowing better
|
|
testing.
|
|
- id: tooling
|
|
description: >
|
|
Automated release of sheriff tooling to developer workstations,
|
|
preventing use of out-of-date utilities and making diagnostics during
|
|
release significantly easier.
|
|
- id: release
|
|
description: >
|
|
Fixed, documented, and added checks for a rarely used process,
|
|
avoiding regular misunderstandings about how the process works.
|
|
- id: mentor
|
|
description: >
|
|
Mentored a new team member in Python and internal release tools,
|
|
guided him through implementing the redesign and becoming the new
|
|
expert. Received a peer bonus.
|
|
- id: bazel-android
|
|
image: jobs/google/bazel-old.png
|
|
name: Software Engineer # II
|
|
team: Bazel Android Support
|
|
company: Google
|
|
startDate: 2013-09-15 # same as Bazel Release Process
|
|
endDate: 2016-11-15 # vague guess - this is around when my focus shifted to
|
|
# configurability full-time, since before that I was
|
|
# doing configurability as a side job and Android as a
|
|
# primary job
|
|
description: >
|
|
Built features relating to compiling Android apps within Bazel.
|
|
achievements:
|
|
- id: aidl
|
|
description: >
|
|
Fixed a long-standing bug in Bazel's AIDL support, correcting
|
|
incorrect builds, and migrated all Google Android projects, saving
|
|
teams time and bugs.
|
|
- id: native
|
|
description: >
|
|
Upgraded Bazel's Android native code support to allow for automatic
|
|
compilation within Bazel, avoiding the need for users to implement it
|
|
in a separate system.
|
|
- id: jack
|
|
description: >
|
|
Added support for the Jack and Jill compilers to Bazel, allowing the
|
|
Jack team to instantly test their work across the real projects within
|
|
Google.
|
|
- id: snapchat
|
|
description: >
|
|
Consulted with a major App Engine client and helped their developers
|
|
get set up to use Bazel for their Android app. Received a spot bonus.
|
|
- id: google-tooling
|
|
image: jobs/google/google.png
|
|
name: Software Engineer in Test # II
|
|
team: Internal Tooling
|
|
company: Google
|
|
startDate: 2013-02-15 # rough guess, since Jon mentioned my work on the tool
|
|
# in Q3 2013
|
|
# which was after I started the UI work in Summer
|
|
# which was after I'd been invited to start working on
|
|
# the project around midway through Q1
|
|
endDate: 2017-12-18 # dead on, this is the day I got a peer bonus for
|
|
# helping with turning this down
|
|
shortDescription: >
|
|
Built and maintained parts of a test-account creation service.
|
|
description: >
|
|
Built and maintained parts of an internal test-account creation service
|
|
which was used by several teams throughout Google for easy isolated
|
|
integration testing. At its peak, it created and deleted hundreds of
|
|
accounts every minute.
|
|
achievements:
|
|
- id: wallet-profile
|
|
description: >
|
|
Installed a new account template on the account creation service,
|
|
allowing users to create Google accounts which already had Wallet
|
|
accounts set up.
|
|
- id: dartui
|
|
description: >
|
|
Rewrote the existing hacky Javascript-and-jQuery UI for an internal
|
|
user in clean, well-tested Dart, allowing for fully automated
|
|
push-on-green releases.
|
|
- id: maintenance
|
|
description: >
|
|
Investigated bug reports, coordinated with other teams and remained
|
|
on-call to keep users' tests running. Received three peer bonuses and
|
|
a spot bonus.
|
|
- id: shutdown
|
|
description: >
|
|
Received a peer bonus for assisting with the shutdown and migration to
|
|
a newer service owned by the account team.
|
|
- id: wallet-testing
|
|
image: jobs/google/wallet.png
|
|
name: Software Engineer in Test # II
|
|
team: Wallet Web Frontend
|
|
company: Google
|
|
startDate: 2011-07-18 # dead on, this was my start date
|
|
endDate: 2013-09-15 # same as with the Bazel Release Process start date,
|
|
# since they're the same day
|
|
shortDescription: >
|
|
Built and maintained test infrastructure for the Wallet web frontend.
|
|
description: >
|
|
Embedded test infrastructure support for the Wallet web frontend team,
|
|
working with related teams and fellow software engineers in test to make
|
|
sure developers can quickly and easily write and run tests.
|
|
achievements:
|
|
- id: integration-suite
|
|
description: >
|
|
Built and optimized a full-stack in-memory integration test, cutting
|
|
time-to-results 75% and allowing integration testing to run in the
|
|
continuous build for instant feedback.
|
|
- id: smoke-tests
|
|
description: >
|
|
Wrote an adapter allowing tests written for in-memory to be used on
|
|
the staging and production sites for fully automatic release
|
|
testing, halving the build cop checklist.
|
|
- id: fun-events
|
|
description: >
|
|
Organized fun events and wrote fun recruitment emails for the team,
|
|
keeping spirits high and the team close.
|
|
- id: guice
|
|
description: >
|
|
Received a peer bonus for teaching teammates how to work with Guice
|
|
wiring and the innards of the integration test infrastructure.
|
|
- id: agora-games
|
|
image: jobs/agora.gif
|
|
name: Software Intern
|
|
company: Agora Games
|
|
startDate: 2010-11-04 # or thereabouts, this is when I was interviewing
|
|
endDate: 2010-12-04 # as recorded in a livejournal comment...
|
|
# Agora Games: Ruby web testing
|
|
- id: star-analytics
|
|
image: jobs/staranalytics.png
|
|
name: Software Intern
|
|
team: Star Task Builder
|
|
company: Star Analytics
|
|
startDate: 2010-04-15 # very approximate, got my IP phone/laptop around then
|
|
endDate: 2011-05-15 # ish, I stopped this around when I left school
|
|
# Star Analytics C# frontend
|
|
- id: misc
|
|
image: jobs/blocks.svg
|
|
name: Hobbyist
|
|
team: Other (personal, school, side jobs etc.) Projects
|
|
startDate: null
|
|
endDate: null
|
|
# ## Personal projects
|
|
# * Personal blog website using Eleventy + Netlify
|
|
# * Anki plugins for Japanese study
|
|
# * Personal Docker server for mail and nextcloud
|
|
# * Discord bots
|
|
# * Assortment of handmade Minecraft plugins, self-run server
|
|
# * PDF page-identification and splitting C# utility for helping at the church
|
|
# * Python/GTK+ based rental property payment tracking
|
|
# * Javascript based dice roller for MSN+
|
|
# ## RPI projects
|
|
# * Python OpenGL-based game
|
|
# * Rails based task management project: https://github.com/thoughtbeam/flagship_tasks
|
|
# ## Regis projects
|
|
# * C SDL-based game
|
|
# * Python/GTK+ based assignment tracker
|
|
# * Python based encrypted chat program
|
|
# * Java based student chat program
|
|
|