By taking a practice as a core value, they are implicitly stating that it is the One True Way to do things, which means that anyone NOT doing it the One True Way is doing it wrong (to the point that they refuse to hire anyone unwilling to toe the line). I wonder how these people would feel entering a company whose One True Way is waterfall development? Because up until a decade and a half ago, that WAS the One True Way.
I think this is a good point. There's definitely a risk of dogmatism when we start defining ourselves through a certain process.
I wanted to use the post to explore how a process like pairing influences company culture. I don't mean to imply that the process IS the culture.
I think it's fine, and probably very helpful, for development teams to be opinionated about process. But opinionated is not the same thing as dogmatic.
I mentioned this in a reply to comment on our site, but we also worry a little bit about creating a monoculture and groupthink. We try to fight this by leaving room every week for people to spike things out on their own in open dev time: https://www.braintreepayments.com/braintrust/walking-the-tal...
In our interview process, we want developers who like writing software, and want to improve. Asking about side projects, software topics they're researching on their own, languages they're playing with, seems to be a useful thing to focus on. Or at least, I tend to like candidates with good answers to those questions. That's a monoculture I think I'd actually like.
I tend to think that design by committee, even with a committee of two, reliably produces inferior results. So when really novel work is necessary a much better way to put two people on the same task is to have them both take a crack at it independently and then come back together to see what works best. Sometimes competition is the best form of collaboration.
I agree, I dislike "design by committee". However, sometimes you get to work with those magical, rare people who are both seasoned architecture gurus and have very good social and speaking skills. Working with these kinds of people is an absolute joy -- I will learn more in an hour of watching a skilled developer program than I will from a month of reading online material.
Braintree's core product is a payment processing gateway. If we go down, get hacked, or introduce serious bugs, our customers can't run their businesses. As I said in the article, we pair for almost everything, and we find it helps us write great software that stays up and stays secure.
I should have focused on the distinction between the size of companies -- that seems like a more accurate framework. I suppose I meant "performance" in the sense of low-level algorithm efficiency rather than high-level scalability and reliability. A misuse of the term on my part.
Now, if you're writing novel code, new algorithms, working with big data, or writing performance or security critical software, then I can see how the heads-down approach might be more effective. For these projects, maybe understanding the whole system is less critical than, say, programming your component to be 100% optimized.