An interesting post cropped up on Quora
this week, entitled “What makes a good engineering culture?”
Edmond Lau, a software engineer at the question and answer network, said the thought had occurred to him after hearing hundreds of young engineers during job interviews describe what they liked or disliked about the culture of their previous company.
On the basis of those answers, and his own career experiences at Google, Ooyala, and Quora, Lau managed to distill the essence of good engineering culture into a list of Ten Commandments.
The first, he said, was optimization for iteration speed, meaning managers give engineers and designers the flexibility and autonomy to make day-to-day decisions without having to ask for permission. A streamlined process increased work motivation and productivity, said Lau, while cumbersome bureaucracy was kryptonite to ambitious engineers.
At Google, Lau recalled, any user-visible change to search results had had to be personally approved by Google VP Marissa Mayer, a decision Lau deems to have “significantly hampered innovation.”
The second pillar of a strong engineering culture, Lau posited, is a relentless push towards automation as a way to reduce operational burdens on engineers. “Automating solutions and scripting repetitive tasks are important because they free up the engineering team to work on the actual product,” he writes, adding that by ensuring that services are restart automatically after a failure is “the only sane way” to manage complexity at scale.
Third on Lau’s laundry list is building the right software abstractions, keeping them simple and reducing the need for custom fixes. “The growing popularity and reliability of systems like Memcached, Redis, MongoDB, etc. have reduced the need to build custom storage and caching systems,” said Lau, arguing that it was much better than fragmenting efforts over many ad-hoc solutions.
Developing a focus on high code quality with code reviews is also essential, according to Lau, noting that “cleaner code is easier to reason about, quicker to develop on, more amenable to changes and less susceptible to bugs.”
Lau recommends establishing a process for timely code reviews. Knowing that code will be reviewed by others tends to create (positive) peer pressure that should prevent “hacky, unmaintainable, or untested code” from making its way into the workflow.
“Counter-arguments that nimble teams don't have time to spend on code reviews ignore the technical debt that can easily accumulate from poorly written code,” he wrote.
Similarly, Lau argues for shared ownership of code, saying it reduces stress and responsibility for individual engineers while reducing the temptation to feel indispensable to a project.