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.
237 lines
10 KiB
237 lines
10 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
|
|
description: null
|
|
# * account making service
|
|
# * PB: account creation tool (x3) + shutdown
|
|
# * Spot: Gaiamaker
|
|
- 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
|
|
description: null
|
|
# * Web wallet testing
|
|
# * Helped organize team fun events on Whisky
|
|
# * PB: Guice wiring and integration testing support
|
|
- 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
|
|
|