Why is modern web development so complicated? A long yet hasty explanation: Part 1!

Modern frontend web development is a polarizing experience: many love it, others despise it.

I am a huge fan of modern web development, though I would describe it as “magical” — and magic has its upsides and downsides:

  • When you understand how to use the magical tools of web development (babel! bundlers! watchers! etc!), your development workflow is speedy, powerful, and delightful
  • If you don’t understand the magical tools of web development, it’s terribly confusing
  • … and trying to learn how the magic works is all-too-often miserable, unless you have someone to help guide you through the tangle of jargon, hot takes, and outdated information on the web

Recently I’ve been needing to explain “modern web development workflows” to folks who only have a cursory of vanilla web development workflows and……

It is a LOT to explain!

Even a hasty explanation ends up being pretty long.

So in the effort of writing more of my explanations down, here is the beginning of a long yet hasty explanation of the evolution of web development:

Part 1: How we got from static websites to babel

– – – – – – – – – – –

Simplest website: Static website

Let’s start from “classic” frontend web development, which I’m going to assume you-the-reader already understand.

In classic frontend web development, we are directly modifying HTML/CSS/JavaScript files. To preview changes, we open the HTML file locally in the browser, and as we develop, we refresh the page for updates.

Development workflow

The development workflow looks like this:

  1. Edit your HTML/CSS/JavaScript files in a text editor like Atom.
  2. Save the file in your text editor.
  3. Open and reload file in the browser.
Edit JavaScript, save file, refresh the page to see updates

Deployment

Then when you want to publish your website to the internet, you simply upload the HTML/CSS/JavaScript files to the internet somewhere.

With a service like Netlify, you can just drag-and-drop the folder containing your files to publish the page to the web.

Here’s an example of the published page: https://sleepy-lichterman-6811cc.netlify.com/

That’s so simple! Why did we make things complicated?!

So if you understand how the “classic” web development workflow works, you might ask: Gee, that’s really simple and convenient. Why did we ever deviate from that?! Why are modern web development flows so complicated?

The short answer: …Ok maybe I have two short answers.

Two short answers:

  • You don’t have to make it more complicated. The “classic” web development workflow is great! And is perfectly sufficient for plenty of needs! You should never add superfluous tooling, or tools whose purpose you don’t understand.
  • But for certain projects you’ll benefit from a more sophisticated workflow. Every tool that you add to your workflow is meant to solve a problem.

In order to understand the tooling for modern web development, we have to understand the problems of web development.

In this long-but-hasty journey, we’ll address each problem individually, starting with an old web dev problem that has existed for decades:.

An old problem: Limitations in JavaScript

Up until fairly recently, JavaScript and the Web APIs had a lot of limitations (for a myriad of reasons that will not be covered in this long ‘n’ hasty post).

To name a few of these limitations:

  • No modules
  • No constants
  • No Promises / async
  • No Array.includes() (!!)
  • Clunky syntax / missing for a lot of common primitives (no for-of, template literals, arrow function syntax, template unpacking…)
  • (Web APIs) Countless DOM operations were needlessly complex (like adding/removing class names, hiding elements, selecting elements, removing elements…)

Browsers are only capable of executing JavaScript, so when there are limitations in the JavaScript language, it’s not like you can just use a different language; you have to work with what you have.

Aside: Difference between JavaScript and Web APIs?

You may have noticed I said “JavaScript and the Web APIs” above. These are two different things!

When you write JavaScript for a web page, any API call that interacts with the web page itself is a Web API (which happens to be written in JavaScript), and not part of JavaScript the language.

Some examples:

  • Web APIs: document and every method on document; window and every method on window; Event, XMLHttpRequest, fetch, etc.
  • JavaScript: functions, const/let/var, arrays, Promise, etc

So for instance, if you’re writing a Node.js server, you’ll be writing in JavaScript, so that means you can use e.g. Promises but you can’t use document.querySelector (nor would it make sense to do that).

An old solution: jQuery & friends

Back in 2006, jQuery was released: It’s a library that helped workaround lot of the shortcomings of JavaScript and the Web APIs.

jQuery includes APIs that help dramatically with common web tasks, like DOM manipulations, async processing, cross-browser discrepancies and resource-fetching.

So basically: All these things were technically possible using old-JavaScript/old-Web-APIS, but they were super annoying, tedious, and often tricky to code – so instead of having every web developer write the same tedious code to e.g. download and process and JSON file, you could instead download the jQuery library and use jQuery’s nice APIs instead.

A new solution: Let’s improve JavaScript itself

A lot of time has passed since 2006, though!

Since 2006, JavaScript and the Web APIs have improved tremendously. (With a lot of help from jQuery and others in paving the way!)

JavaScript is an ever-evolving language. Similar to how software is updated, the JavaScript language itself is updated to different versions.

You may have heard the term “ES6.” ES6 stands for “ECMAScript 6,” and refers to the 6th iteration of ECMAScript. ECMAScript is just another word for JavaScript — the only difference is a colloquial one, in that people usually use “ECMAScript” to refer to the specification itself, and “JavaScript” to refer to the language people code in.

(Btw, that’s another confusing aside and pet peeve of mine: JavaScript is not an implementation/flavor/dialect of ECMAScript; that’s like calling “HTML” an implementation/flavor/dialect of the “HTML,” or, if you’re generous, the “HTML spec.” Either way, it’s wrong! Wikipedia, you’re wrong! JavaScript and ECMAScript are one and the same.)

Anyway! ES6 (released in 2015) is notable because it adds a lot of really language nice features to JavaScript, like const, modules, and Promises. (And ES8 introduced maybe my favorite language feature ever, async.)

In parallel, the Web APIs have also improved tremendously since 2006, like with the addition of document.querySelector, fetch, and little things like classList and hidden.

So instead of using jQuery or other similar libraries, in 2019 we can, for the most part, just use JavaScript and the Web APIs directly.

… sort of!

A new-old problem: Cross-browser support

When there’s an update to the JavaScript language, browsers will also need to be updated to support the new language features. (Same is true for the Web APIs, but we’ll stick to just JavaScript for simplicity for now.)

However, there’s a delay between:

  1. When the language feature is defined in JavaScript
  2. When the browsers have all implemented and shipped support for that feature
  3. When users have all upgraded to the latest version of their browser, usually via auto-updating/restarting your browser (and this sometimes doesn’t happen!).
The dilemma: Do we write using older JavaScript or the latest JavaScript? Both have pros and cons. (This particular code example lifted from here!)

This causes a dilemma for JavaScript developers: We want to use modern JavaScript language features, because these improvements often make it much easier to code certain things. But we also want our websites to work for all users, regardless of when’s the last time they’ve restarted their browser to get the latest updates.

This specific dilemma is commonly solved by Babel.

Babel is a JavaScript compiler that transforms JavaScript code into … different JavaScript code! Specifically, it transforms JavaScript code written using the latest version of JavaScript into the equivalent code written using an older version JavaScript that’s supported on far more browser.

With Babel, we can enjoy the benefits of writing in the latest JavaScript without having to worry about browser compatibility.

Web developers incorporate Babel into their workflow so that they can write the code using the latest JavaScript features without having to worry about browser compatibility.

Aside: Babel doesn’t include Web APIs

For example if you use fetch in your JavaScript, babel will not provide fallback support (this is called “polyfill“-ing) because fetch is a Web API and not part of JavaScript proper. (This decision is being reconsidered.)

So you’ll need a separate solution for polyfilling Web APIs! But we’ll get to that in a later post.

* * *

Back to workflows: Static website + babel

OK, so we’ve now motivated why one might want to use babel. What does a web development workflow with babel look like?

The following is the simplest babel workflow, which people don’t usually use. (That’s because a bundler like Parcel or webpack is more convenient, but we’ll get there another next time!)

Setup

  1. Install* babel
    (*You can follow the CLI instructions here, though it assumes you understand how npm works. And they recommends that you install babel locally as an npm dev dependency for each project, vs globally on your machine.)

Development workflow

  1. Develop your site like a normal static web page.
Example: The src directory is where your vanilla JavaScript lives

Deployment

When you’re ready to publish your website to the internet, you do NOT want to upload your vanilla JavaScript files to the web, because you’ve been using JavaScript features that are not supported by all browsers.

Instead, you want to:

1. Compile your JavaScript using babel, to get browser-compatible code:

This will create the new, compiled JavaScript file in a separate folder:

Example: Babel will generate a second “script.js”, and this one has cross-browser-compatible code

2. Upload the compiled JavaScript to the internet, along with your HTML and CSS:

Compiled JS

…plus your CSS and HTL

Your website will* look and behave the same as in development mode, but users will be served the compiled, babel-fied JavaScript.

(*hopefully! Sometimes there are differences in Debug vs Release builds, but those are bugs!)

Pause to point out: Development vs Release code!

Notice that we now have a separation between “development” code and “release” code:

  • Development code: The code that you write while developing your web app.
  • Release code: The code that you want to run when users visit your web app.

We purposely want to keep these things separate, because:

  • The development code is good for developers, but bad for users
  • The release code is good for users, but bad for developers

In frontend web development, not everyone will uses or needs to use babel.

However! The general pattern of:

  • Writing development code that does not get shown to users
  • and is instead compiled into different release code, that should be shown to users

…is not just common, but is often expected in modern frontend web development.

(Note that having a separate “Debug” vs “Release” build is a general pattern in software engineering, not something new with web development. But it’s especially pertinent to frontend web development, both because of how commonplace it is, and because of how big the difference can be between Debug/Release for frontend web development in particular.)

A short list of frontend technologies that expect this separation between debug and release:

  • npm modules
  • Any CSS preprocessor
  • React/Vue/Angular/any web framework

This is going to be a recurring pattern, so make note of it now!

Next time: npm and bundling

In the next part of our journey, we’ll explore npm modules (what are they and why) and bundling (what is it and why), and how that complicates the workflow.

…coming soon?! Sure, let’s say coming soon!

- - - - - - - - - - -

RichText Code Block: a gutenberg wordpress plugin

Woooo this weekend I made a Gutenberg Block Kit plugin called vrk-richtext-code!!

So it all started because I’m trying to blog more, and to help with this, I wanted to start doing this thing where I blog about new coding/tech things I learn.

Last Friday I was drafting a blog post about Vue.js, and when I wanted to add a code snippet in my blog post, I noticed the default Gutenberg code block doesn’t support any rich text formatting. This was very annoying, because I wanted to highlight a keyword in my code snippet!

The problem

Here’s a video of the problem, where you see rich text formatting is not available for code blocks.

Also, notice that when I try to copy/paste the HTML snippet into a regular paragraph, the HTML is rendered instead of escaped:

So of course that meant I stopped learning Vue.js, I stopped writing my blog post, and instead spent part of my weekend implementing a Gutenberg code block that supports rich text!

The solution

Here’s a video of my plugin in action! See how you can copy/paste like a champion, and you can bold/italic/underline/link to your heart’s content.

You can play around with it and/or download it here:

Making the plugin (a teaser!)

To make a new Gutenberg plugin, in general:

  • I remixed the Glitch Gutenberg Block Kit and did all my development in the remix. This worked really well! The live preview worked flawlessly, and it looks & behaves exactly the same after installation.

As for implementing the RichText code block itself:

  • Oh boy, this was tricky! I used the RichText component underneath the covers, which almost worked out of the box, but the last 10% was absolutely brutal. Getting copy/paste to work was a mess, and HTML entities don’t escape properly yet because of this issue and this issue I just filed against Gutenberg lolol.

I’ll do another blog post with the technical details soon — this took a surprising amount of hackery to get working, which is always fun to share. Plus I’ll get to use my new plugin in my write-up, I’m sure!

Stay tuned!!

(And try out my plugin if you’d like! )

- - - - - - - - - - -

loves2k19: the films by women at animation block party

Yesterday I went to Animation Block Party, and there was a moment where my friend and I got nervous, because the first three shorts they played were of a certain… type. Now I know it’s not impossible for white male animators to produce interesting work, but if you wanted to build a case for it… I mean at least Flex Calibur was fun! And Pine High did some things! And Phantom 52… you know what I’ll stop there!

Anyway thank GOD, the program did include work by women! And they were outstanding: Under Covers by Michaela Olsen and ROSE QUARTZ/FULTON STREET by Sarah Schmidt.

Under Covers

So this will probably be frustrating to read, because a) Under Covers is a short film that you really ought to see knowing nothing beforehand, but b) I can’t find any information on how one can view Under Covers!

AFAICT it’s not available online anywhere… I hope it’s eventually uploaded somewhere? Or becomes available for purchase? Anyway. In the mean time: See if any of your local theaters are screening animated shorts from Sundance 2019? idk!

As I said, I think Under Covers is best experienced with no prior knowledge, so I’ll describe more what it does than what it is.

Often when a film has an interesting storytelling mechanism or is made through an unconventional medium, the story itself is unremarkable. Under Covers has both qualities — it’s a story told through under-the-covers/under-the-bed reveals, in stop-motion — but also manages to tell a weird and compelling story, a celebration of secrets and vulnerability and nakedness.

What’s fun about the film is that it starts out jarringly strange, then somehow by the end, without ever noticing, you’ve been sold on every very-odd part of it. Like 7 minutes later, when all the characters float up into space to orbit a smiling moon, you’re like, “ok yeah! that makes sense.”

It’s also visually v beautiful! Gorgeous colors and materials.

Try to see it somehow! If you can!

Rose Quartz/Fulton Street

On my way home from the event, I looked this one up and I learned that it’s actually a music video commissioned for and by a band called La Dispute.

I think it’s better viewed the way I viewed it, though, as a gorgeous short film with an unexpected soundtrack that just narrowly avoids overwhelming it:

This is such a hard thing to pull off!

The whole thing takes itself so seriously — it’s an intense song, with intense, 0-subtlety kind of lyrics, set to … a cartoon? How does this not become a parody of itself?

And yet it works! The chorus(?) especially is breathtaking.

(Argh this is also something that was truly stunning to see outdoors, at night, on a giant HD projector screen! But a computer screen will have to do as a proxy.)

Honorable mentions

Octane by Jeron Braxton was also extremely cool! I had to go to the bathroom so I missed part of it 😅 ugh should have gone during — nvm.

I’ll also enter this, which is not an animation, but is filmed by me, premiered on Instagram as a story: it was a nice day

- - - - - - - - - - -

“New” job at Glitch, Part 2!

OK I am finally, 3 months later, posting Part 2 of my story: How and why I joined Glitch.

(Check out Part 1 if you haven’t already!)

To recap:

  • I had rejoined Google for a second time, having quit the company once already after a 6-year tenure.
  • After a little over a year, I found myself in a pretty ideal situation at Google: I was on a team that seemed like a great fit in terms of people, project, and promotion opportunity.
  • And despite all this, I quit a few months later!

In this post, I wanted to explain how I came upon the opportunity at Glitch, and why I decided to take it.

– – – – – – – – – – –

On the Geo Assistant team at Google, I had found an opportunity seemed to match almost precisely the type of thing I had set out to find post-Daydream.

So why would I quit?

Google, and the world ablaze

I feel like I can’t talk about working at Google (or working in tech at all) without taking a moment to acknowledge the state of the world.

It’s 2019 and the world is kinda on fire.

We are developing algorithms that discriminate at scale. We have created platforms that allow propaganda and toxicity to multiply and fester. We have Trump, in large part because of the technology we’ve allowed to grow untamed.

Specifically Google’s role in creating this world is both undeniable and significant.

In the face of this: What is my moral obligation?

Maybe you’re rolling your eyes at this question, or at everything I’ve written so far. I hope you’re not! But maybe you are.

And if you are, I want to spend a moment to try to change your mind, to try to explain why it is worthy and necessary for everyone in tech to do some serious introspection, including, probably, you.

What is our moral obligation, as software engineers?

I’ve heard so many excuses to dismiss this question, on the grounds that it’s an impossible question.

Like, “It’s impossible to live an ethically flawless life. So why wrestle over questions that are intrinsically unsolvable?”

If you’re feeling this way, you’re missing the point.

Yes, ethical purity is unachievable. But that means ethical tradeoffs are unavoidable. You are making ethical tradeoffs right now. Do you understand what ethical tradeoffs you are making? How can you understand if you’re not willing to grapple with the question?

Another common reaction to this question is defensiveness, like “who are you to judge me for where I work” — if you’re feeling this way, you are mishearing what I’m trying to say.

When I ask myself, What is my moral obligation, as a person working in tech? Or, Is it ethical to continue working at Google?

These are not judgments. These are questions.

Engineers, I’m urging you all to do some serious introspection about the ethical implications of your jobs. When I say that, I’m not saying, “Shame on you, how could you still work for X, Y, Z” (and if you’re hearing that, why are you hearing that) — all I’m asking is, Do you think it is ethical? If so, why? If not, why not? If you’re not sure, why?

It is valuable to know where you stand.

And of course, when you do figure out where you stand, you may want to make some adjustments.

The answer key

jk

(I mean jk this is not the answer key.)

I haven’t come to any clear answers, obviously. This is expected. Everything’s complicated.

I did at least come up with a very simple moral code while working at Google. It’s not very brave, but it exists:

  • If I continue to work at Google, I will endeavor to do what I can to Fix This Mess, even if that’s very little!
  • However, if I can do more to Fix This Mess outside of Google, I will quit Google to do that instead.
  • And I need to actively search for such a position. Even if that search is very slow! And even if that search does not succeed!

When talking about the ethics of working at Google, I’ve heard a common canned response from other Google employees:

“Well, Google’s not perfect, but at least it’s better than the other tech companies, right?”

I think this stance made a lot more sense in 2009 than it does today. That said, if you’re going to stick with it in 2019, how are you sure that Google is “better than other tech companies?” I mean maybe it is — like I said, this is a question, not a judgement, not a command — but what evidence do you have that this is true? If you don’t have any evidence, shouldn’t you gather some?

To be clear, there are plenty of people for whom Google is the best employment option, by a mile.

It would be different if I were just starting out in my career, or if I had a lot of debt to pay off, or if I were going through some major life stuff right now, like I was a year and a half ago, when I had decided to quit my teaching job and move back to NYC and needed a return to stability.

But those aren’t my circumstances now.

Where I am in my life right now, every day I spend at Google I am choosing to be there. I don’t need the money, I don’t need it for my resume, and I don’t need it for the learning experience.

Given Google’s role in This Mess, I personally felt a moral obligation to, at minimum, actively look for positions where I could do more to Fix This Mess.

…That isn’t doing much!

Dreams

There’s something else on my mind a lot lately. It is the counterweight to obligations and roles, opportunities and circumstance.

What are your dreams?

It’s funny how uncomfortable it is to talk about dreams!

I find it so much easier to talk about constraints and logic and practicality. Given your constraints, the circumstances of your reality, what is your logical next step?

I was in my mid-twenties when I first realized I had never thought about what, exactly, I wanted. I had never considered formulating such a question. What were my dreams? I had no idea.

And how dare I?

The overwhelming privilege needed to pursue one’s dreams. If I were so lucky to be in such a position, would I be allowed to do it? Would it be morally right, to take advantage of such privilege?

I guess it depends on the dream.

I am comfortable distilling my unremarkable moral code into a bullet point list and sharing it with the world; I am not comfortable doing the same for you with my dreams. My dreams are too personal. My dreams I’ve barely summoned the courage to admit to myself.

So for the sake of the story, I’ll proceed in the way I am comfortable:

  • If I were lucky enough to have the immense privilege to pursue my dreams, would I be allowed? Are my dreams morally allowable?
  • Yes

A message in a bottle to the ocean

Finally, the main event!

I wrote all these words and all these words all to give you context what happens next.

The setting: It was December 2018, and my very smart and very good friend found herself unemployed and looking for jobs. She was feeling understandably down about it, and I told her she should come over to my house and we’d spend the day looking for jobs.

(Quick pause to say: My friend now has a great job, and from a job listing from this day!!!)

I wasn’t really in need of a new job. I told you, things were pretty good.

But I had had these misgivings about working at Google, and I had had these dreams I wanted to pursue, so I was like, “OK, let me at least look at what’s out there.”

I updated my resume and looked at job listings.

And, maybe you’ve looked at tech job listings. They’re all kind of the same.

There’s a software engineering opening for a startup that’s building the future of podcasting. There’s a mobile-first, real-time video search engine. There are all the big-name companies, there are all the apps on everyone’s phones, and apps trying to get onto everyone’s phones. And they’re fine, I’m sure.

But also, I’m not so sure.

Are they better than what I have now? Would I be in a better position to Fix This Mess? Do they get me closer to my dreams?

– – – – – – – – – – –

There was one company I had had my eyes on every since it launched in 2017. This company was Glitch.

A lot about Glitch resonated with me. I love the web, I’m fascinated by platforms and open source ecosystems, and I’m passionate about computer science education and with it, the democratization of technology. It seemed like a good cultural fit, too; the company’s values were aligned with my own, and I had heard of a lot of awesome people working there.

I looked at Glitch’s job listings. There were a few developer roles, but I didn’t see anything that was quite the right fit. I thought, maybe I should apply anyway? But ugh, it didn’t make sense to apply for a job that I probably wouldn’t actually take.

I then noticed Glitch had a catch-all job listing, where you could essentially pitch your own role. I thought this would be a good exercise: What is a position that I would be willing to leave Google for? What’s a position I would love to do at Glitch? I wanted to practice asking for what I wanted.

I wrote a pitch and sent it in.

From my perspective, this was a message in a bottle to the ocean; I sent my pitch, had a small “hmm, wouldn’t that be nice” moment, then I promptly forgot about it.

Oops, the ocean responded

To my great surprise, I got an email from Glitch about a month later. They loved my pitch, and they wanted me to build a team around it.

I got a job offer. I accepted it!

In conclusion

I’m not trying to say I have my life figured out, lol.

I have the trademark millennial brokenness. (It comes across in this post, I’m sure.) My career has been a series of educated guesses, every milestone having its victories and defeats. And, like, there’s also the whole thing where plenty of people don’t care for “successful” women, in general. So what advice can I give? What conclusions could I have possibly reached?

As I mentioned last time, I feel sheepish writing about… honestly anything, like I’m some authority figure. I’m not. I’m just trying to do a better job of sharing what I’ve learned (what I think I’ve learned) in case it’s helpful.

With that, I’ll once again distill my conclusions into everyone’s favorite digestible form, the bullet point list:

  • Define your moral code (your best approximation is infinitely more valuable than nothing)
  • Define your dreams (this is hard, this takes time, you might be wrong, your dreams will change, it gets easier with practice, and it is worth doing)
  • Proceed accordingly!
- - - - - - - - - - -

loves2k19: this kpop sub-unit dance cover of lovely

It’s 2019 and I’m on a kpop journey, led joyfully and competently by my friend-coworker-neighborhood-kpop-scholar Ryan Khosravi.

Recently Ryan showed me this video (a mere bullet point in the lecture slides of Ryan’s kpop curriculum) and I can’t stop watching it.

It’s Ten and WinWin from the sub-unit WayV of NCT (look at me, using words!) doing a dance cover of lovely by Billie Eilish and Khalid:

Sometimes I wonder if I’m expressively stunted by never learning how to dance.

Like how sometimes it’s easier to understand someone’s feelings by looking at their face, are there things, thoughts, emotions that are best expressed through dance? Are there things, thoughts, emotions that I feel internally but cannot communicate because they are only expressible through dance?

Growing up, I knew some Korean-American kids who could understand Korean when they heard it, but they couldn’t speak Korean themselves. I always wondered what that would feel like.

Does it maybe feel a bit like how I feel, watching a dancer? Like dancers are able to communicate to me, and in this case something so clear and fittingly lovely, but I don’t have the language to reply.

I’m grateful I at least have this one-way lopsided comprehension, though.

Imagine watching this and not feeling anything!

- - - - - - - - - - -

loves2k19: IG dog bichon_tori

I know that one’s favorite IG animal is neither novel in concept nor interesting to hear about but fml bichon_tori.

Like this is not just some regular cute dog situation:

Not only is Tori a style icon but ALSO HIS LIFESTYLE IS ASPIRATIONAL

Like how is this dog providing me a blueprint on how to live my life?

Style icon, lifestyle icon, fitness icon, relatable legend bichon_tori I do not want to have you, I want to be you, and for those reasons you are most certainly in my loves, 2k19.

Update 6/21: tori in a travel bag

- - - - - - - - - - -

loves2k19: How It Feels by Jenny Zhang

(So I’ve decided I’m trying to catalog the things I love in 2019. (Not necessarily things created in 2019.))

(Starting now. This is the first one!)

This is a thing I love in 2019: How It Feels by Jenny Zhang

How It Feels is an essay on poetry and its place in a culture where, culturally, we’ve decided that emotion is humiliating.

GOSH I love Jenny Zhang. Lately it’s been hard for me to create anything, because I’m perpetually embarrassed by anything I have to say. (Well, not anything I have to say; just anything that, like, matters to me.)

…I’m trying to unlearn this! And this essay is encouraging me to look at my own work with more kindness.

OK Jenny, thank you. I will attempt to be 3% less embarrassed by my existence.

Also this essay is SO beautifully written. Wholly unsurprising if you’ve read Jenny Zhang’s work before but aghghghsdf I can’t help but marvel every time.

Some highlights:

“I found it so incredibly generous — to be just as ugly as anyone but to emphasize that ugliness over and over again, to let yourself be the subject of your art and to take all the pummeling and the eye-rolling and the cruel remarks and the who cares? and the that’s not art that’s just a scorned woman unable to let go.”

“We built our private little world through these mistakes, and like everyone else falling in love we tried to become one entity, impenetrable through our arsenal of inside jokes, through a language that other people could not understand or use.”

“I think everyone wants to make something touchable, but most of us don’t out of fear of being laughable. I’m not saying I’m fearless.”

Read this and improve your life!

- - - - - - - - - - -

New job at Glitch! And why I left Google, again

So, a couple of life updates:

  • I quit my job Google (again)
  • Tomorrow (Monday, March 18) is my first day at a startup called Glitch!

It’s now been a month and a half since I accepted my offer at Glitch. In that time, I’ve had probably ~20 one-on-one conversations with various people to announce and explain my transition.

The question most people want to know is: Why?

The answer: It’s complicated!

It takes a lot of words to explain in a way that feels honest and accurate. It feels a little presumptuous to even write it out, as if my career journey is so interesting. But I also think that career journeys are worth sharing.

As I prepare to make my new job announcement to the Greater Internet (like twitter and facebook and all that), I wanted to write a little something to document my thinking behind this latest career decision, in case it’s helpful to anyone else, including Future Me. (And Current Me, for that matter!)

I think this story has two parts, so I’m going to split this into two posts:

So with that, here is Part 1: How and why I quit Google, again.

– – – – – – – – – – –

Context: My career so far

In order to understand my latest career move, it’s helpful to get some context on my career so far.

Here’s a little timeline:

  • Got my BS and MS in Computer Science at University of Washington.
  • After graduation, I worked at Google for 6 years: 4.5 years in Seattle, 1.5 years in NYC
  • Then I quit Google and moved to California to teach full-time as a lecturer at Stanford for 1 year.
  • In Summer 2017, after finishing my first year of teaching at Stanford, I spent my summer at Recurse Center in NYC. Through my experience at Recurse, I remembered that a) I love programming and b) I love NYC. In other words, I realized that I wanted to be an engineer in NYC again.
  • Therefore I quit Stanford and moved back to NYC to rejoin Google.
  • Now about 1.5 years later, I’m quitting Google a second time to join a ~40 person startup called Glitch!

In summary, my entire career post-graduation is comprised of about 7.5 years at Google, plus 1 year of teaching at Stanford.

(Q: Wait, you taught for a bit at Stanford? A: Yep!)

(Q: How?! Why?! What was that like?! Why did you quit?! A: These are great questions, but that’s an even more complicated story that I will share another day!)

(Q: Also, Recurse Center! How did you like Recurse Center?! A: Love Recurse Center. Strongly recommend it. Will write on this another day, too!)

OK, with that out of the way!

I was planning to quit Google, again, eventually

When I rejoined Google the second time, it was not like I had decided, “OK great, after 1 year working at not-Google, I’ve decided that Google is the only place I want to work, and I will now work at Google forever.”

Rather, in Summer 2017, I realized I needed to quit my job at Stanford and move back to NYC.

Originally, I was planning to do a full job search: I wanted to try to find a tech company that was a better overall fit for me than Google. Instead of working at a massive company to make a small impact on a billion people, I wanted to work at a small company to make a bigger impact on a smaller number of people.

But, I decided not to.

I got some wise advice from friends to “just” go back to Google. Though it’s not perfect, I like Google a lot, and it’s a company I know well. After such a disruptive life change (moving to California! trying an entirely different career path!), it seemed like a good idea to instead focus on regaining stability in my next move.

Plus, if I rejoined Google, I didn’t have to interview again, Google would pay for my moving expenses, etc. etc. It was the logistically simplest path to getting back to the macro-level place I wanted to be.

(Q: Wait, you didn’t have to interview at Google again? What was that process like? A: Another great question that I will explain another day!)

To recap, I was making the following trade-off when going back to Google:

  • Pros: I like Google a lot! I know the company well! I know I can be productive and successful! I have a lot of friends and mentors! I can still learn a lot at Google! They pay incredibly well! Stability!!!!!
  • Cons: I quit Google the first time around for real reasons, and those reasons have not gone away. I know I will almost certainly want to quit this company again, and possibly very soon.

I decided the trade-off was worth it. I knew I probably wanted to work at a different company, but life-wise, the timing wasn’t right to take on that challenge. Until then, working for my old, familiar, comfortable company seemed like the best decision.

Google take 2, Team 1: Daydream

So I quit Stanford, and I rejoined Google on the Daydream (VR) team.

I specifically joined Daydream instead of my old Maps team because I wanted something relatively noncommittal.

I wasn’t sure how long I wanted to be at Google again, so I wanted to join a team that was fun, where I wouldn’t have too much responsibility, but I would still learn something new.

This came with a pretty major downside, and a downside I fully acknowledged and accepted when I had chosen the team: VR was an area where I knew it’d be really difficult to get promoted.

That’s because for my level, the “impact” story would be hard to justify, inherently, due to the nature of VR at Google. Daydream is not important enough to Google for most work in the space to be considered “impactful” to the company. The usage numbers aren’t here, by a long shot.

(Q: What do you mean by “impact,” and why does that matter for promotion? A: Another good question for yet another day!)

These were the trade-offs I was making by joining Daydream:

  • Pros: Fun and creative! I’d learn about VR! Easy 9-to-5 coding job!
  • Cons: No career advancement at Google! But that’s OK because I’m not sure how long I want to be at Google anyway!

That was the plan, anyway.

What actually happened: I ended up working really, really hard in Daydream.

As soon as I joined, I joined the Tour Creator team, where we were trying to launch at Google I/O. I was responsible for the 3D/VR renderer for Tours, on desktop and mobile. It was really awesome but it was hard. We did it, but omg. Lots of late nights and company politics and lots and lots of stress.

I am so proud of what we accomplished with Tour Creator. But post-launch, the trade-offs no longer made sense: I had learned a lot, and technology-wise it was fun to work in VR, but I was under a ton of stress, working long hours, and for what? I don’t really care about VR that much, so it wasn’t personally important to me to become an “expert” beyond what I had already learned through the Tour Creator launch. And then professionally, I was in an area of Google where no matter how hard I worked or what I accomplished, I would never get promoted.

By the time Tour Creator launched, I had been at back Google again for about 8 months.

I had to make a decision:

  • Should I plan to quit Google at the one year mark, and start to do that job search for a “better fit” that I’ve been meaning to do originally?
  • Or should I change teams?
  • If I change teams, should I work for another non-committal, “fun” team where I probably wouldn’t get promoted?
  • Or should I choose a “real” team where I’d work toward a Staff promotion, knowing it’d probably take at least ~1.5-2 years to get there, if not longer?

I decided to go with the last option. I felt like, OK, I’m ready to try going back to Google for real, and I’ll commit to staying here another 1-2 years. I’ll work on classic Google projects and see if I can get promoted. Getting promoted is a worthy thing to do! (It’s diversity work, even!)

Google take 2, Team 2: Geo Assistant

I switched from Daydream to the Geo Assistant team in June 2018.

(Rough definition of Geo Assistant: All Assistant features related to Maps; questions and answers on Google.com related to Maps.)

My time on Geo Assistant went something like this:

  • People-wise, fantastic: The team I joined had really awesome people, some of whom are now dear friends of mine. My manager and skip-level manager were both outstanding and super supportive of me. I also had several wonderful mentors and sponsors at the Staff and Senior Staff level, many of whom I was working with directly.
  • Project-wise, fantastic: My starter project was on the team was a slog, where it took something like 4 months to launch this incredibly minor update to an incredibly minor feature. However, the reason for the slog was due to some major architectural issues, issues that I was able to flag and bring attention to. This meant my small, inconsequential starter project morphed into a much bigger, much more interesting architecture project. Along with that also came a meta-project: If I was able to find and help fix an architecture of one feature, I could then be in the role of finding and fixing architecture issues to make Geo features easier to implement on Assistant.
  • Opportunity-wise, fantastic: This sounded like a super fun role, with broad of scope, working with lots of really knowledgable people across Geo, with plenty of opportunities to learn about architecture of big systems. Plus, great visibility, and great opportunity for impact. My managers and mentors agreed this looked like a pretty promising case for promotion.

So it was February 2019, when I just getting started with this new exciting project that was basically exactly what I was looking for….

And then I decided to quit the company!

More on that in Part 2: How and why I am joining Glitch!

- - - - - - - - - - -

okokokok new blog

I think this is my ~5th attempt in the last ~6 months to try to start a blog again.

BUT THIS IS THE ONE. This blog I will not abandon! I’m optimistic!!!

I’ve decided that this was the problem: I had been agonizing over the logistics of setting up my blog, like: What blogging platform do I use? What theme should I pick?

And I kept being like, “ehhhhhh whatever, I’ll just choose something; the important thing is the writing and not the platform or the theme etc”

Which was the wrong mindset!

I realize now that I will use any excuse to not write, including “my blog looks too nice” or “I don’t like my text editor.”

That means the logistics of setting up my blog—where it lived and how it looked and how I would update it—were actually the most important questions for my blog. I needed to maximize the likelihood that I will blog at all.

With this latest installment of a vrk blog, I’ve arrived at the following conclusions:

  • I don’t like static site generators for blogging. Bleh, I kept trying to use Jekyll or Hugo, but I decided I don’t like either for blogging. I think they’re great for static content (I used Jekyll for my course websites when I taught), but I want a nice web-based editor, and all the basic niceties that come along with that. Like, auto-save. And private drafts! I got tired of having to git commit every time I wanted to save something.
  • I need my own custom theme. I also kept being like, “Ugh I don’t want to write my own theme” so I would settle for some free, existing theme that was ~fine~… and then I would start tweaking with the CSS, and then I’d start modifying the config files, and then I’d start modifying the templates… At that point, it’d be easier and less frustrating to just start from scratch, or a reasonable boilerplate. To be clear, it’s not that my blog looks incredible; rather, I like it to look kinda janky. But it needs to be my janky.
  • Medium was never an option. I mean, Medium taps into the brains of the world’s most insightful writers, thinkers, and storytellers to bring you the smartest takes on topics that matter” Literally the opposite of what I want. This is my blog! Where I write stuff! Stuff that is dumb! I need my blog to be weird-looking and I need to feel free to write bad takes on topics that don’t matter.

And so here’s the setup I’m using for vrk.dev:

  • WordPress install on my own hosting (via Dreamhost 1-click install, on my now 10-year-old Dreamhost account!)
  • With a custom theme that I build starting from Underscores and BMFWS. (Aside: ugh, I really appreciate BMFWS but man I don’t appreciate all the swearing lol. I’m considering creating a clean fork…)

This feels good!