📬 The Backlog #197
What makes Google’s corporate culture bad, what makes GitLab’s culture tangibly good, and what your coding culture needs in order to abandon feature branches and PRs.
-
Ex-Microsofter, ex-startup founder, and now ex-Googler Praveen Seshadri has some choice insights into how Google operates as a company. His first-hand account The maze is in the mouse is long but full of observations, that, regardless of whether they’re true, can at least serve as a measuring stick and/or cautionary tale for your own org.
True to his startup background, Seshadri explicitly connects customer-centricity, coding practices, and corporate culture. I’m less dismissive of the MS/Google comparisons in this article than I’d otherwise be, because Seshadri worked at both companies for considerable stretches of time. Interesting. -
Sumeet Moghe’s No, that’s not culture is nominally about the self-defeating shittiness of return-to-office rhetoric, and it certainly contains criticism on nonsensical terms like “our DNA” and “who we are as a company”. But.
Moghe also adds a sizable chunk of serious advice on how to describe a company’s culture in a way that makes it observable: focus on its features, use non-fluffy words to express desired values, and describe value-aligned behaviours.
The article uses GitLab’s (published) values and operating principles as an example and Moghe describes what’s good about that company’s approach. -
I like Richard W. Bown’s advice on How to Deliver High-Quality Software, Faster without Feature Branches — and pull requests! Everyone can be checking in to trunk if you make sure that your testing and automation is as solid as your software design. Bown provides a set of 5 tips to speed up on the side of software creation, rather than on the side of the stage gates, which he suggests reducing as far as possible. And not without considering reality:
“Depending on your required release cadence, taking the responsibility away from developers to manually review Pull Requests doesn’t come cheaply – you will need to invest in automated tests and increased coverage. But the investment will be paid back in terms of speed of delivery of new features, and simplicity without blocking – plus you can still run your more in-depth CI and/or linting/end-to-end testing processes on a schedule if it is still required.”
Have a value-aligned work week and Scrum on,
Thomas van Zuijlen