I don't have anything to say about James Damore's so-called "manifesto" that these two fine writers haven't already said.
Former Google engineering executive Yonatan Zunger wrote a pretty great piece on what it means to be an engineer, and why Damore's naivety about it undermines his claims about why there might be fewer women in tech:
Essentially, engineering is all about cooperation, collaboration, and empathy for both your colleagues and your customers. If someone told you that engineering was a field where you could get away with not dealing with people or feelings, then I’m very sorry to tell you that you have been lied to. Solitary work is something that only happens at the most junior levels, and even then it’s only possible because someone senior to you — most likely your manager — has been putting in long hours to build up the social structures in your group that let you focus on code.
It's not surprising that Damore's writing feels compelling to a great many men at Google, as it has a deceptively non-confrontational, quasi-rational tone. Cynthia Lee, a lecturer in Computer Science at Stanford, wrote a good explanation on why there has been so much backlash in response to the memo despite its seemingly agreeable surface nature:
To be a woman in tech is to know the thrill of participating in one of the most transformative revolutions humankind has known, to experience the crystalline satisfaction of finding an elegant solution to an algorithmic challenge, to want to throw the monitor out the window in frustration with a bug and, later, to do a happy dance in a chair while finally fixing it. To be a woman in tech is also to always and forever be faced with skepticism that I do and feel all those things authentically enough to truly belong. There is always a jury, and it’s always still out.
When men in tech listen to the experiences of women in tech, they can come to understand how this manifesto was throwing a match into dry brush in fire season.
At a tiny Japanese comfort food restaurant, J. and I are the last couple left, both stuffed, leaning back, can't-eat-another-bite. A tiny, friendly Japanese woman—the chef, I think—appears at our table to refill our water and tea.
"How is everything?"
J. is startled, glances at the chef and then back down at her half-eaten meal.
"Really good!" I say.
J. immediately takes another bite of her chicken, swallowing with a pained expression. The chef chuckles and says, "Good, good!"
J. keeps eating. The chef beams for half a second, satisfied, then walks away.
J. sees me watching her eat regretfully and turns bright red, afraid to glance over her shoulder to see if she can stop. I grin from ear to ear—but I give her no hints.
One of the most important qualities for effective programming in large codebases is good writing ability—not writing code, but writing prose for other humans.
Undoubtedly, this is not a surprise to long-time industry veterans (after all, we don't often program in machine code anymore), but it's a quality I often find is overlooked by engineers that arrive straight out of college. Those that I see write the cleanest, most maintainable code are those who write prose well, whether in documentation, in emails, or in their everyday lives.
Many aphorisms about writing style translate fairly well to coding. Consider the following selection of principles from The Elements of Style by Strunk and White:
"Place yourself in the background," and "Do not overwrite." The best code does its job honestly and without obscuring its meaning with the author's "style." If code is so obviously stylized, it is probably written poorly. Exploiting all of the obscure bells and whistles of a language makes for brittle, obscure code.
"Work from a suitable design." Plan ahead and make deliberate design choices. Choosing the right architecture makes a huge difference in how cleanly or how tortured your code will read.
"Revise and rewrite." Or in the words of Fred Brooks in The Mythical Man-Month: "Plan to throw one away." Your first solution will take longer than expected, have problems you didn't foresee, will likely have code put in the wrong places, and have abstractions drawn at the wrong lines. Write a second draft.
"Use definite, specific, concrete language." Vague names like
callbackare useless in much application code. Use more specific, concrete, and informative synonyms like
"Omit needless words." We need not be obscurely terse—we aren't counting characters for source code anymore—but concise, simple code is best. Use abstractions and language features to remove boilerplate and focus on core logic.
"Express coordinate ideas in similar form." Similarity in structure emphasizes similarity in idea, allowing readers to pattern match and understand your code more quickly. Beware, however, the limits to foolish consistency. 1
"Keep related words together." Save your reader from having to jump around different files and switch contexts to follow lines of logic. It is tiring and difficult to do, even with the help of an IDE. Use tools like promises, monads, and other abstractions to write code in linear, readable progressions that would otherwise be fragmented.
"Prefer the standard to the offbeat." Be idiomatic. Follow the standard styles of a codebase and language community. Don't vary for the sake of variance.
And one more aphorism from journalism that I think applies to programming:
- Don't bury the lede. Document up front. Put public methods and interfaces at the top of a file, not halfway down past implementation details (when possible). Your code should read like a newspaper article: headline to start, the main gist at the beginning, and then more gristly details further down if the reader is hooked and interested.
Still not convinced? See how much of The Swift API Design Guidelines reads like advice for writing prose.
"A foolish consistency is the hobgoblin of little minds" -- Emerson, Self Reliance (1841)↩