Engineering, Culture and Tools
As an engineer, I’ve always been flummoxed by the word “culture”, esepecially as it pertains to corporate entities, especially those of the tech variety.
When someone asks you, “What’s the culture like?”, or “Is this candidate a good culture fit?”, what do they mean, and how do you answer them? Phrases like “work hard, play harder”, “move fast”, “risk-taking is rewarded”, “dynamic and collaborative” (who isn’t?) sound catchy and look good on recruitment pages, but are meaningless. What is it then? A list of rules? Some pre-requisite mental and attidudinal posture for blending in and functioning well in the company?
Culture cannot be spelt out. Almost all attempts to do so result in bland lists, which, if followed, would not resemble the real culture at all. Good cultures are self-propagating and strong, in that new hires quickly ingest it by osmosis without needing someone to tell them about it. The greatest cultures even transcend their own companies, and their own era, jumping from generation to generation. The biggest example of this is how even current-day Silicon Valley culture is very close to the that of Fairchild Semiconductor, which in turn was largely the creation of a single person–Robert Noyce.
Interviewers and candidates often talk about “culture fit”. This is a negative filter. Interviewers aren’t looking for people who are just like them–most reasonable people should be able to inculcate a reasonable culture just fine–they’re looking to weed out people who are inflexible or otherwise indoctrinated enough to reject the learning-by-osmosis that takes place when one first joins an organization.
But here’s the thing: amorphous as it is, culture makes things happen. It does have a real impact on how products are built, and which ones are built. I like to think of it as the bass player in the band. They are the most underrated member of the band. But when there’s no bass, the whole thing sounds off somehow, and you can’t put a finger on what exactly is missing. Culture is like that. Its presence in a place is taken for granted until you go somewhere else where the culture is different, or missing. It took me a while to figure this out. And then I realized why a select circle of seniors (in accomplishment, not necessarily in age) were constantly tending to it.
Which makes it all the more important to get a better handle on what exactly it is.
For engineers, there are two types of culture. The culture of the company as a whole, and the culture of the engineering organization within it. In true tech companies, the two are essentially the same. The entire company’s culture is ultimately dictated by what makes it tick. Some companies are sales driven. Others are product driven. And some are truly tech/engg driven, where cool things are built by smart people, and then someone thinks about how to make money off it. Don’t jump to the conclusion that the last one is great. The purest example of that was PARC, and while it gave the world the defining elements of the computing age, the entity itself could never stay financially solvent.
And then there’s engineering culture. It turns out, this is much simpler to pin down, but there’s so much fog around the world “culture” that it gets lost.
The engineering culture is simply the set of behaviors positively reinforced by the tools and processes of the organization.
If code review is a pre-requisite for submitting patches, then you have a culture that encourages clean code, early bug-catching and knowledge-sharing. If code reviewers insist on tests for new code, and there are tools that make it easy and fast, and documents that explain clearly how to do it, then you have a culture where testing is ingrained. Note how self-reinforcing things like this are. If your code was put through the scrubber by reviewers, you too will do the same with code that you review. And that’s a good thing. That’s what keeps standards high. This is beautifully meta too—the culture is defined by software, in a sense.
I was in two minds about how much of the engineering tools of Google I could describe in detail, but it turns out ex-Googler Mike Bland has written a series of five posts that goes into the coding and testing culture and tools at Google in excrutiating depth. It is a splendid case study of how engineering culture is established, changed and propagated.
A teaser:
This is the fifth—and, finally, final—post in my “whaling” series about the high-level conceptual and cultural challenges the Testing Grouplet and its allies faced, and the knowledge and tools that eventually spread throughout Google engineering that removed the infamous “I don’t have time to test” excuse. This post discusses the specific tools the the Testing Grouplet, Testing Tech, Build Tools and others developed to improve development and testing efficiency and effectiveness.
The first post in this series focused on high-level cultural challenges to the adoption of automated developer testing that emerged as a result of day-to-day development reality. The second post in this series focused on the fundamental object-oriented programming issues which formed the core of most of Google’s testability challenges—and solutions. The third post in this series covered the basics of how automated tests should—and should not—be written. The fourth post in this series described the collection of processes employed by Google for ensuring software quality—including, but not limited to, automated testing.