The architecture is relatively straightforward. At a high level, there’s not too much that’s overly complicated, and I think we prefer it that way: PHP, Linux, and Apache, and MySQL
We want to exploit all of the advantages that come from having a small number of well-known tools. When you have a small number of well-known tools, you can then focus on the product. We don’t want to be doing engineering for engineering’s sake, and much in the same way that you wouldn’t want a carpenter to be overly concerned about what kind of hammer he has — at some point, it doesn’t matter.
One of the things that we’ve done for a number of years is to recognize that if you’re going to solve a problem, and you think you need to solve it in a new and novel way that can’t be solved with the technology stack or the patterns that we already have — then that’s fine, it’s just that we need to be explicit about the operational costs of doing so. Introducing something new and different can bear a huge long-term cost to the organization.
what I want to do is I want to ask the greater population of engineers at the company, “Hey, I’m working on this problem. I think the only way to solve it is by using this brand-new thing that nobody knows about. Please talk me out of this.”
engineers need to have the same [pride of ownership], to say “This is my code; I take responsibility for it, whether it’s successful or not successful.”
are you abstracting away so that you truly can say “I don’t have to worry about this”? Or are you abstracting away because you’re aware of those guts, but want to focus your attention right now in this area. That is what we’re looking for. Post-mortem debriefings every day are littered with the artifacts of people insisting, the second before an outage, that “I don’t have to care about that.” If “abstracting away” is nothing for you but a euphemism for “Not my job,” “I don’t care about that,” or “I’m not interested in that,” I think Etsy might not be the place for you. Because when things break, when things don’t behave the way they’re expected to, you can’t hold up your arms and say “Not my problem.”
Engineering, as a discipline and as an activity, is multi-disciplinary. It’s just messy.
As an engineer who starts day one, I am [not] the best one to know how network protocols at Etsy work, and I’m going to be encouraged to seek out the experts in those domains until I do. And maybe something will break, and then I’m going to learn something new. … I need to continually expect that part of my job is exploring the boundary — what’s the precipice of my knowledge — and keep going.
The promise of things like machine learning is that it paints a picture of the future where software will be able to make all of these decisions and that humans’ judgment will always be faulty. I think that there’s a huge miss there in that perspective. This is the reason we’ve said that we want to take a human-centered approach to engineering at Etsy. We can pretend as much as we want that the algorithms will make everything great and perfect, but that’s only when we view humans as frail, faulty, error-prone, cause of accidents, that sort of thing, and it’s simply false. The fact of the matter is, accidents and failures happen way less often than success. And so to pull back the high-level view, at Etsy, this is not just sort of an empty thing. We want to view engineering as engineering, and not be clouded by rose-colored algorithmic glasses.