Engineer Q&A: Spencer Wilson, Client Engineer, San Francisco
This post continues the summer 2018 Q&A series, an effort to introduce the world to the Engineering team at Optimizely. If you missed it, consider checking out the introductory post by our VP of Engineering. If you’re interested in joining the team, we’ve over a dozen openings in SDKs (SF one and two), app backend (SF and Austin), distributed systems (SF and Austin), management (SF and Austin), and more.
Tell us about yourself! What’s your name, what do you do at Optimizely, and how long have you been here? Tell us a bit about your trajectory to get here.
I’m from the east Bay Area, where I was fortunate to grow up with ample access to computers (thanks 🙏, Mom and Dad!). When I was 13 or 14 years old I remember being at a Boy Scout summer camp and seeing a counselor on his laptop during some downtime, typing the word printf in a monospace type on an all-black screen. It was captivating! The pure aesthetic of it imparted some magic for sure, but there was more to it than that. Beneath the surface of these machines we all enjoyed, it seemed to me, lied some language that — if one only knew the proper incantations — could be used to… well, I didn’t know what they could be used for, yet. I didn’t know anything, other than that typing words into a “command prompt”, having results come back at you, and knowing that you wrote the instructions underlying it all was thrilling as heck.
If one googled “how to program” in July 2008, I assume what turned up was C tutorials, because that’s where I ended up. For context this was about two years after the initial release of jQuery, six months before Python 3, and ten months before Node.js. My first program was Basic Math Assistant:
From there programming was an on again, off again hobby, with periods where I drew considerable inspiration from the Nintendo Wii homebrew scene (blog posts like this, or WiiBrew, or spectating on IRC) and video game system emulators like Dolphin. Ultimately, the only nontrivial program I wrote before university was OpenSearch, a CLI utility to do “relative searching”: given a search pattern of bytes, scan a file for a byte sequence whose interrelationship matches that of the pattern. For example, “acb” matches “xzy”. Old games often stored their text uncompressed and used mostly-8-bit, non-ASCII character encodings; relative search is effective at reverse engineering such encodings, which is particularly useful for “translation hacking”. A hacker might take, say, an English-only game and patch it to be in another language. This way, some games that were only released in one region of the world could reach a wider audience.
Experiments with programming continued, but I also became enamored with mathematics and physics during high school. I took a detour in university studying electrical engineering, but was constantly more interested in my computer science-friends’ courses than my own. Halfway through year three I changed majors to computer engineering, and about two years later started full-time at Optimizely. All told, I’m very grateful that I’ve wound up in a profession that feels “right” to me so relatively early in my career.
What are you working on this quarter?
What’s unique about engineering at Optimizely?
One thing that’s totally cool and almost surely unique is that our head of engineering (Bill Press, who authored this series’ intro post) runs a weekly meditation group in the office.
Another thing I appreciate is that our Product, Engineering, and Design organizations share a desire to live up to some of the company’s cultural values. Some of those values are ownership, integrity, and transparency, and they all come through daily in neat ways.
Ownership, as I see it, means that we’re encouraged to identify issues, drive them to resolution, and take pride in a job well done. It also means that we strive for things to always have clear, unambiguous owners, because there’s nothing more sad than an abandoned or forgotten system. It’s valuable, even in a simple logistical sense, to have a point person or team for everything. Though this isn’t to say that I only stick to working on the systems that I “own”; at our size there’s still a lot of cross-pollination that naturally occurs as priorities evolve. I mentioned that I originally mostly contributed to the Web client, but lately have been helping out with Full Stack. I’m shaping up to be more of a generalist than a specialist, so this flexibility is really nice, particularly when paired with a management team that understands the added value of having peoples’ work aligned with their interests.
By integrity we mean intellectual honesty, things like admitting when you don’t know things, admitting mistakes, and preferring finding the truth over winning an argument. One of my favorite things is when folks post in our #engineering Slack channel owning mistakes that have far-reaching effects (e.g., blowing through a Sentry quota or merging an automated test that fails sporadically). For me, it feels like it really encourages a culture of understanding and security, where mistakes are acceptable and learning opportunities (see Infinite Hows, it’s great), and that we actually are one team — something that can easily be said, but requires a plethora of organizational habits to be in place if it’s to have any hope of ringing true for employees.
Transparency has clear ties to the above (who owns what, how mistakes happen, etc.), but also applies in the sense of such questions as: how do prioritization decisions get made? How is the business doing overall? Where are we excelling and where do we have room to improve? I hear from friends at other tech companies in San Francisco that such information is not easily available, and reaching outside of their sphere of familiarity to find it is likely to be fruitless; leadership is less accessible, and work is so distributed that a lot of boundaries between teams are totally, frustratingly opaque. I’m sure that we owe being able to pull off transparency, at least in part, to our moderate size, and preserving this and other values will surely take concerted effort as we continue to grow.
Lastly, I want to mention how neat having a diverse team is. In particular, diversity of backgrounds and personalities is very cool. I work with people that took much more interesting paths than I did to be here (like Jess, Derek, and Lauren), and their unique experiences and perspectives are constantly teaching me new ways to think about problems, balance work and life, and be a good teammate.
What advice do you have for people trying to break into your role?
I’ll address students here, since I was one not too long ago.
If you’re going to job fairs, don’t open the conversation with “So what do you guys do?” My first manager told me months later that I stood out from the others at the fair simply by demonstrating I’d done a modest amount of research before talking to them. Feels kind of like a low bar, but I suppose that’s the reality if the company isn’t yet a household name.
Thanks for reading. We’ve got some great work ahead of us, and if you’d like to be a part of it, we’re hiring!