An Attendee Apart: An Interview With Keith Chu

We recently launched An Attendee Apart, a program that rewards you for attending more than five An Event Apart conferences. And no one knows more about attending multiple AEAs than seven-time attendee Keith Chu. We recently prevailed upon Keith to share the saga of his web design career so far, along with a few of his favorite An Event Apart memories.

Hey, Keith! When/where/how did you get your start in web design?

My fascination with web design started in the mid-1990s when I first used Tripod's Homepage Builder. I remember discovering the source code, trying to figure out how the buttons I pressed did things like underline text and create images. And when I put that code in Notepad and dragged it to a browser, something magical happened: I had made a web page!

There was something so special and compelling about web design. You could create works of art and complex interfaces in real-time by typing a few lines of code. The CSS Zen Garden and Hillman Curtis' Flash Web Design were influential examples of that. It was so empowering to know that when I saw other people create amazing things, I could create them too.

After college, I moved out to San Francisco and worked as a Java developer by day, freelance graphic/web designer by night. It wasn't until a year later that I felt confident enough in my portfolio to interview for a position as a web design engineer. The day I landed that job was one of the best days of my life. I was finally able to do what I love full-time.

What do you mean when you say “web design engineer?”

A web design engineer is someone who specializes in front-end development, but also has an eye for design and proficiency in back-end development. Web design engineers are often asked to liaise between product managers, designers, and back-end developers, so they need to be fluent in all those disciplines to be effective.

For many front-end developers, a typical process is: (1) receive comps, (2) prototype, (3) pass prototype to back-end developers to implement. For web design engineers, a typical process is: (1) work with designers on comps, (2) prototype, (3) implement, or work with back-end developers on implementation, (4) write tests.

You also refer to yourself as a “culture hacker.” What does that mean?

Culture hacker came out of a resumé redesign. I wanted to find a succinct way to communicate not only what I do, but also what kind of colleague I am.

At the time, we were undergoing Agile training at work and I had an a-ha moment: sharing best practices for working and adjusting standups/sprints to accommodate a team's needs are attempts to optimize work culture, much like someone might try to fine-tune website performance. When I saw that it led to more communication between teams and higher-quality work, I was hooked. I wanted to find other ways to improve how my team worked.

In my mind, a culture hacker is someone who sees a team's culture as fundamental to its performance and endeavors to iteratively optimize it. When engineers think about work, their thoughts go to the product and features they're building. Culture hackers see the development of the team's culture as essential to doing great work.

“Culture hacker” is the best way I've found to convey what I'd be like as a colleague. If people understand the connotation, it's worth a thousand words; if not, it's a great conversation piece.

How do you bring those approaches to bear on your job at Square?

When I started doing web design, I didn't have a good grasp of how product development happened. I had no insight into the design process. I didn't get why the features I prototyped lost some fidelity in implementation. This siloing led to a lot of miscommunication, compromised work, and frustration.

I've since learned that understanding design/implementation details is essential. Every day at Square, I have the privilege of working closely with people who are amazing at what they do; in that environment, the most important thing I can do is constantly ask “why?”

If I'm not sure why every element of a design exists, I can't grok what problems it's trying to solve. If I'm not involved in implementing my own interfaces, I won't see how much more complex it is than “drag-and-drop.” Knowing what lies on the periphery of what I'm building allows me to work smarter, and craft better products, which I do at Square.

To that end, I have regular sync-ups with my teammates—over lunch, or a walk, or a cup of coffee. We find this makes it easier to speak frankly and to empathize with each other. A lot of great ideas come out of those conversations.

What exactly is it you do for Square, day-to-day?

I lead front-end development on Caviar, a food delivery service that Square acquired a few months ago. Most of my time is spent making the web product more useful, usable, and responsive. The rest of my time is spent figuring out the best ways to do that.

You worked at Autodesk for many years. Were there any unique challenges to working for a company that produces 3D CAD software?

Definitely. The products that Autodesk creates help people construct buildings, design cars, and bring animated movies and games to life. Crafting a website you'd expect from a design-focused company, filling it with tons of product information, and getting out of the way to showcase some truly stunning customer work is a tall order.

The biggest challenge I faced in my role at Autodesk, however, was working within a homegrown CMS called “WAM.” It was this beastly, powerful, internal web tool, built around the time IE6 was the new kid on the block. Building a new feature for it was often very CSS Zen Garden-y; we couldn't change any of the HTML, but we could add something small like a top-level class. Then, with only CSS, existing components, and a stick of chewing gum, we'd try to make it pixel-perfect across all of our supported browsers.

It was a tremendous experience that taught me a lot about working within constraints and building a product for a massively diverse audience.

You've attended more An Event Apart conferences than, well, anybody. Thank you! Why do you keep coming back?

The standout aspect of An Event Apart is its one, well-structured track. I know Eric and Jeffrey put a lot of work into crafting this, and it shows. There's no better multi-disciplinary conference. The speakers and presentations are consistently best-in-class.

Even though the event has gotten larger every year, it still feels right-sized. I can mingle with the regulars and meet a ton of new people in the industry, all without ever feeling lost in the crowd. The post-talk downtimes have led to some particularly memorable conversations.

Also, the food is stellar.

Got any particularly funny or memorable AEA moments you can share? We can change names to protect the innocent, if necessary.

I was so star-struck at my first couple of AEAs, especially during presentations from two of my web design heroes: Doug Bowman and Jason Santa Maria. Their talks helped me realize that great design is the by-product of creative problem solving, hard work, and courage.

My most memorable AEA moment was probably when Andy Clarke walked straight out of the set of Mad Men and onto the stage. He gave a fantastic talk about CSS animations and transforms, using elements from the Mad Men intro as demo-fodder. I went out and bought a fedora after that event.

Very nice. Thanks for everything, Keith!