2 ms·
My current project is confidential, but one from 2013-2014: We had a bunch of UXR that showed that people liked iPhones because of the fancy snappy animations,
by nostrademons 5y ago
My current project is confidential, but one from 2013-2014:
We had a bunch of UXR that showed that people liked iPhones because of the fancy snappy animations, and our execs really wanted to bring that to Google's webapps. At the time, there was this big perception that mobile web sites were slow and clunky and you absolutely had to go native app to get smooth 60fps transitions. I did some profiling with the Chrome profiler and found that the bulk of time was spent in layout & reflow, and that one single reflow would blow your entire frame budget and then some for 60fps on mobile. So then I went to the Chrome GPU team and got a quick tutorial about exactly which operations were handled on the GPU (basically just transform and WebGL, at the time), and put together a visual language that basically involved rendering portions of the webpage to GPU textures and manipulating them only with 2D transforms, which could be GPU-accelerated. The work later formed the foundation for how Material Design was implemented in Search.
As a side note, I learned a lot about how browsers work under the hood with that project, and one of the things I learned is that the entire premise that React was sold with was false! At the time, the big selling point with React is that "DOM manipulation is slow, so we create a virtual DOM that's fast and then diff the changes to the virtual DOM so we make only the minimal set of DOM changes we need." Except that every major browser by 2013 used a dirty-bit system for DOM manipulation, so changes to the DOM are actually quite fast (roughly the speed of a couple pointer manipulations in C) as long as you don't trigger reflow. And you can trigger reflow with any one of about 2 dozen method calls, as well as automatically when you return from a Javascript script fragment, so basically every Angular and JQuery website was triggering multiple reflows per event. React was fast because it was declarative and didn't let you execute user code until it was done batching up all DOM manipulations, it wasn't fast because of the virtual DOM. And I believe there have been re-implementations of the React API that do away with the virtual DOM and they are equally fast (oftentimes even faster, since they're simpler and don't need the DOM diffing), but at this point React is popular because it's popular and everyone knows the API, not because of any purported performance benefits.
- Impossible 5y agoWhat about this project made it L6? Is it because it was a high priority for execs? Is it because you had to get a lot of buy-in from external team(s) in the Chrome org?
- nostrademons 5y agoIt's the combination of it being an exec priority + the industry consensus at the time being "It's impossible". If you deliver a high-priority project that any engineer can glance at and have an immediate idea how to solve, that's L4 work. (Say, you're shuffling data from protobuf to a bunch of Javascript on screen.) If you deliver a high-priority project that most engineers are declining to work on or saying "It can't be done", that's L6 work. If you deliver a high-priority project and then publish it externally and then the rest of the industry actually says "Woah, this is revolutionary and really valuable to us" and then Doug Cutting clones it over at Yahoo and releases it as open-source and spawns a whole sub-industry, that's L9 work. This is all for IC engineering. I actually prefer to think of the ladder in organizational terms which also encompass management, but the sub-thread here is specifically interested in what it takes to be an L6+ IC.
- faizshah 5y agoThanks this is really illuminating, how did you find projects like this? Where did u get the visibility to be able to find problems like this that were priorities for leadership?
- nostrademons 5y agoIt was quasi-assigned to me (I had the option not to work on it, but management would've been disappointed with that). Management thought of me specifically because I'd built a reputation as someone who could tackle difficult projects, particularly those surrounding browser UI. I'd worked on the last 3 visual redesigns of Google Search (as the first engineer of the 2010 one, a consultant for the 2011 one, and the tech lead of the 2013 one), plus I started the Authorship project within Search, plus I'd done a bunch of little visual easter eggs like the [let it snow] holiday one (also a project that many people thought was impossible because it was started after the last binary push of the year). Management takes note of who delivers; it takes a while to get noticed, but once you are you get all the high-profile projects.