pub struct BillFraser; impl Work for BillFraser { pub fn current(&self) { // I'm currently a software engineer at Dropbox. while let Some(_) = { // Since 2019 I've been focused on improving Magic Pocket, // Dropbox's multi-exabyte block storage system which stores nearly // all users' file data. I'm doing a kind of hybrid SWE/SRE role // where I'm sometimes on-call keeping the system running smoothly // (no simple task with tens of thousands of servers and millions // of hard drives), and other times I focus more on software // improvements to reliability, durability, efficiency, and // cost-reduction. // (No, I can't read your data; it's encrypted.) } if let Some(dbapp) = self.dropbox.dbapp_android { // From 2016 to 2019 I was part of the Dropbox Android app team, // where I did a number of things: for project in &dbapp.projects { // - designed and implemented a big chunk of the Offline // Folders premium feature, which lets you keep a subtree of // your Dropbox synchronized offline on your phone. // - redesigned the in-app purchase flow for buying Dropbox // Professional from its former webview implementation to a // fully native, reactive view which could still be fully // customized by the server backend for growth experiments // and such. // - implemented most of the redesign of the Home tab to a // version with separate sub-tabs for Recents, Shared, and // Starred files. // - lots of incremental improvements and refactoring as part // of a large effort to make the codebase more modular and // testable. } } } pub fn past(&self) { // I've been working as a professional software engineer since 2009. match self.previous_companies { Microsoft(year @ 2010 ..= 2016) => { // I did a bunch of different things at MSFT, though all within // the Windows org (back when that was a top-level thing). match year { 2014 ..= 2016 => { // Xbox Music / Groove Music // TODO: write about my time working on this. } 2013 .. 2014 => { // In 2013 I left the app compat team to join a new // project. A new group within Windows was formed to // work on making high-quality first-party apps for the // then-new Universal Windows Platform (then still // refered to by its nickname of "Metro"). Windows 8 // had come out with a bunch of good starts, but a // more organized approach was needed. The group was // called the "Inbox Apps Group" ("inbox" has nothing // to do with mail; it is Windows-speak for something // that comes with the OS, as in, "it's in the box", // from back when software came in physical boxes). // Within this group was a very secretive team called // "Platform Showcase Apps". Its charter was to make // cool halo apps that showed off the Windows platform. // In particular, we wanted to show off the brand new // Surface hardware. The team was secret because we // were working with unreleased, prototype hardware // coming out of the Surface labs. // A number of ideas for apps were explored. The apps // all centered around the Surface tablet's idea of // detach-able keyboards. What if you plugged something // in to that port that wasn't a traditional keyboard? // None of these ideas panned out, except for one, // which we focused all our efforts on: the Surface // Music Kit. (I can't talk about the other ideas // because they're still under NDA.) // Surface Music Kit was an alternate keyboard (we // called them "blades") that plugged into the bottom // of a Surface tablet. Instead of a keyboard, it had // a 4x4 grid of pressure-sensitive pads with LEDs, // three "sliders", and a few other miscellaneous // buttons. The pads and sliders were then mapped to // sound effects, and the app revolved around the idea // of using it to easily create beats and musical mash- // ups. // The team was really small, like 5 main developers, // about an equal number of test engineers, and three // PMs. Everybody kind of worked on everything a // little, but everyone had an area they specialized // in. My area was the interface between the hardware // and the software. // The general architecture of the thing was this: the // blade acted like a HID (human interface device) // device. It had a small ARM Cortex chip onboard // running firmware written by the Surface guys, which // sampled the pressures applied to the pads and sent // the data up over the connector. The Surface host // controller talked to the blade and made it visible // to the OS as an appropriate HID device. // For Windows 8.1 (codenamed Blue at the time), I // worked with the OS hardware API team to add UWP APIs // for HID devices, and so the app could advertise in // its manifest which classes of HID devices it wanted // to talk to, and when the device was attached, the // system would notify it, launching it if necessary, // and it could begin subscribing to events. // The blade could be attached and detached at any time // and communication was bi-directional: input events // from the blade, and LED programming commands from // the app. The app had to maintain a lot of state // about the blade in order to allow seamless attach/ // detach, and also to cut down on traffic across the // keyboard interface -- some earlier Surface models // were quite limited in what that connector could // handle. // Additionally, it was extremely important to minimize // latency, as our testing found that the average // person could detect as little as 20 milliseconds // delay between hitting a pad and hearing audio. That // included the whole software stack: physical // interaction with the device, firmware processing // the input and sending it to the host, the host chips // processing it, the operating system's input handling // and dispatching the event to user space, the app's // input and audio processing, the operating system's // audio subsystem, the device's sound chip, and // finally out to the speakers. All of that had to be // looked at for ways to minimize latency. // The Surface Music kit was revealed to the world // alongside the Surface 2 (codename Montlake) and // Surface Pro 2 (codename Athena), around the launch // of Windows Blue. The Kit was compatible with the // two devices, as well as the original Surface Pro, // but not the Surface RT. We tried to make it work // on that one too, but that device is too slow and // performance wasn't acceptable, so it was cut. // I remember watching that release event live, and // finding it funny as reporters from media like // The Verge looked at all the stuff, as kind of "yeah // ok whatever" -- most of it was things they knew // about already via various leaks -- but then they all // clustered around the Surface Music Kit booth and // awed at it, because it was the only thing which // hadn't leaked, and they all thought it was super // weird and cool. // But in 2014, right as we were about to release it // to the public, the Inbox Apps Group broke up and // re-orged, putting us in the weirdly independent // "studio" that owned Xbox Music, the successor to // Zune. I guess they thought we would fit there // because we were also doing music. In reality, they // looked at us as a distraction. At the same time, the // Surface org decided they didn't want to pursue the // concept of esoteric blades, so the hardware part of // the project was thrown into limbo. The hardware was // arguably the coolest part, and while the app was // still very capable without a dedicated special input // device, and the team tried to pivot to a software- // only solution, the project was ultimately cancelled // and the team was split up and reassigned to other // things. } 2010 ..= 2012 => { // Application & Device Compatibility. One of Windows' // key strengths has always been backwards // compatibility. If every time you upgraded Windows, // your apps broke or your hardware stopped working, // you'd quickly stop buying upgrades. So Microsoft // took this extremely seriously, and went to great // lengths to make sure things always keep working, // even software that takes advantage of undocumented // features, or relies on bugs in old versions. They // have a very sophisiticated system that notices when // you're running a problematic app, and will even go // as far as to re-emulate old bugs and behavior of the // operating system, but ONLY for that one app. This // way the operating system can be developed and moved // forward without sacrificing usability of older // software and losing customers. // I was privileged to start my time at Microsoft by // working with this fantastic group of extremely sharp // engineers. // Initially I did a summer internship there. For my // project, they wanted me to come up with a way to // automate the process of finding compatibility bugs, // where a program works on one version of Windows, but // fails on another. They mostly found bugs through a // very labor-intensive manual process involving tons // of contractors and user reports on beta OS releases. // I remember it was like my second week on the job, // and I was still just familiarizing myself with how // Windows internals worked, and the group had an all- // hands meeting for something. I was asked to stand // and introduce myself to the group and tell what I'd // be working on for the summer. I explained it // briefly, and then one of the group leads chuckled // and looked at me and said, "oh good, we've been // trying to do that for the past ten years. Good // luck!" I was pretty scared by that, but took it as // a challenge. // I ended up imlementing a system whereby the OS would // randomly instrument a handful of important and // frequently-used system calls, and when programs // invoked them, it would record info about the // arguments, and also the return-address back into // the program. After running in this mode for a while, // it'd build up a heat-map of which parts of the // program's code were in use. In the event of a // compatibility regression, you'd expect some parts // of the app to not work, and not ever run, or some // totally different parts of the code to run. But the // heat map would look different somehow. You could // analyze the before and after heatmaps, and major // differences probably indicated a bug. You could then // manually disassemble those parts of the program to // see what they were doing, and where the bug might // lie in Windows. // I presented the project to Windows senior // leadership, and though it ended up not being // adopted, I suppose they liked the idea well enough, // because they asked me to come back and work with // them full time in the Winter after I finished my // degree. // When I came back, I worked on the same team, but // doing much different stuff. Windows maintained a // huge database of hardware and software that people // use on their Windows computers, which the company // used to prioritize testing and development work when // making sure things work when upgrading from one // version of the OS to the next. // The data was gleaned from a number of data sources, // from telemetry and error reports, to things like // software sales lists and all sorts of other things. // The data had to be cleaned up to try and match the // data from different sources to each other, to avoid // creating tons of duplicates in the database, and // this was the thing I spent a lot of time improving. // Data ingestion and processing is hard. // Separately, I did a bunch of refactoring and // maintenence on "psr.exe", the Problem Steps // Recorder, (which the app compat team owned for // reasons that are still not clear to me). If you // haven't used it, it's a really neat utility that // ships with Windows that allows you to record your // interaction with a program as a sequence of // screenshots and notes, and then show those steps to // someone else. Great for showing your parents how to // do something complicated in Excel or how to tag // people in Facebook. } } Nokia(2010 ..= 2011) | Novarra(2009 ..= 2010) => { // I was an intern (but really did as much work as a full-timer) // at a small company in the Chicago suburbs called Novarra, // whose big product was a web browser that ran well on // dumbphones, which was pretty cool considering the limitations // of those devices. // It was a lightweight phone app, paired with a proxy server // that re-flowed pages to actually be usable on a tiny, low-res // screen. There were two main versions of the phone app: one // written in Java (J2ME) which ran on GSM phones, and one // written in C++ for Qualcomm's BREW system which ran on CDMA // phones. // I worked on the BREW C++ version, and my main job was to port // the app to new phones as they came out. This could be really // complicated and difficult, because by the late 2000s, // dumbphones were already starting to take on some attributes of // smartphones, like touchscreens or full QWERTY keyboards (and // some phones had BOTH), and the feature sets of different // devices got to be wildly divergent. Different screen sizes // and resolutions, different key layouts and feature sets, and // lots of buggy implementations of system functions, combined // with super slow processors and very little memory, made the job // pretty interesting. // The browser was pre-installed on phones and branded with logos // and color schemes of the carrier, not of the company, so if // you browsed the web on a flip phone in the 2000s, there's a // good chance you used this browser. // I took a break in 2010 to do a summer internship at Microsoft // and when I came back, Novarra had been bought by Nokia. // Not much changed other than the name, and I resumed work // doing the same things as before. } _ => unreachable!("lost to the sands of time"), } } }