Engineering Culture

"The product experience of Duolingo actually changes multiple times per day for each user... they care a lot about the clock speed of the company... they were really, really tight about it."

"When I joined, all project management was just in GitHub, just commenting on poll requests and even marketers in order to augment or upload a blog post, you'd have to commit and deploy it. So there was no breaks given for folks that didn't want to touch code and stuff like that."

"CS is about system thinking, using coding to solve actual problem and problem solving will never go away because what AI can automate more stuff. The problem is just get bigger."

"I learned the most throughout this process is that Conway's Law can be really, really powerful. So it's the law that basically says you ship your org structure. So what you're organized as in terms of teams, in terms of collaborating groups and your operating model matters a lot to what you build."

"A lot of engineers think that code quality is important to building a successful product. The two have nothing to do with each other. ... It really has very little to do with how well it was architected because the flip side of that Google video... supported more formats, it supported higher resolution... YouTube had none of this. It just had the one or two minute quick video thing and it's far and away, blown away its competition."

"I'm typically interested in the stuff that you might not read about in the traditional media, but us techies really care about... I wrote one about Facebook, one about Amazon, and I tried to talk with mostly software engineers to get a sense of how these companies work from a software engineer and engineer manager perspective."

"I eventually joined the design team... a big part of what I did there was create this function called design engineering... The person who can think of the UX design it and also build it and launch it."

"We have a ritual every Friday, we had it this morning, called Demo Fridays. And so it's very important to create the space for people to step out of that comfort zone and use AI. So us giving permission to people to build and ship things is part of that cultural backdrop that makes these things possible."

"Switching also helps build that knowledge redundancy in your company... have multiple owners of a system. So not only one person is that tower of knowledge that owns that one system... pairing and switching pairs and test-driven development... this kind of redundancy built safety into our systems."

"I really believe everyone could learn how to be a software engineer if they wanted to... Everyone can learn how to be a versatile kind of unicorn product engineer/designer hybrid in the AI-native era."

"In a world where you're constrained by the amount of GPU capacity that you have as a researcher... each new researcher that you add is actually a net productivity loss for the research group unless that person is up-leveling everyone else in such a profound way."

"We've been able to get away with not a ton of process yet on the engineering front... by hiring people who I think are really excellent... hiring people that are level-headed... people who are less focused on external validation, more focused on building something really great, more focused on doing really high quality work."

"The team that works in the most futuristic way is the Claude Code team. They're using Claude Code to build Claude Code in a very self-improving kind of way... they would do very line by line pull request reviews... And they've just realized Claude is generally right... so can you use a different Claude to review it and then do the human almost acceptance testing."

"DevOps is not a toolchain you buy. Marketing teams labeled toolchains DevOps because they wanted your money. DevOps is a set of capabilities. They're technical capabilities. They're architectural capabilities. They're cultural capabilities. They are lean management practices that predict speed and stability."

"DevEx is developer experience. And when we think about developer experience, we're really talking about what it's like to build software, day to day, for a developer. So the friction that they face, the workflows that they have to go through, any support that they have. It's important because when DevEx is poor, everything else just isn't going to help."

"One way to talk about it is kind of three key things that have components that are important of themselves, and they also kind of reinforce each other. Flow state is one of them, cognitive load is another, and then feedback loops are another."

"Every designer codes. And I don’t just mean HTML. I mean, like running the app locally, going in to the place where that view is rendered to make that thing look the way that they want it to look... I mean, really codes, every designer."

"It's really worth having an AI researcher, AI security researcher on your team... having that research background really helps. So I definitely recommend having an AI security researcher or someone very, very familiar and who understands AI on your team."

"It was certainly the case that I was welcome to weigh in on the game design or the marketing... but my job was to build the software on time with high quality, period. And if I did those things, I'd be rewarded. And if I didn't, I would not be successful."

"It's so important that you're using your own products. And I think we're in a very lucky position where all of us can get creative around using Figma in some way... one of the first things I did when I arrived was we were a little bit more of a memo culture, and I was like, you know what? We should be a deck culture because we can build those decks in Figma, and just that act alone allows you to encounter a lot of issues and for you to get familiar with it."

"Pair programming... is the most underutilized management tool in engineering, bar none. ... The throughput limiter is not hands-on keyboard. It's not like we're both sitting there and the limiter is like us trying to get through the keystrokes onto the screen. The limiter is where is the good elegant solution?"

"One of the ways that we've kind of thought about Devin in building Devin is really allowing engineers to go from bricklayer to architect, so to speak. A lot of it is just getting to the point where you can do the high-level directing and you can basically specify things exactly how you want."

"Our whole team is only like 15 engineers a year. We use a ton of Devin when we're building Devin. Most folks on the team are definitely working with up to five Devins at once, and so Devin merges like several hundred pull requests into production in the Devin code bases every month."