We spent a long time in Google Developer Land coming to terms with the fact that Google don’t really engineer in the same way and on the same scale as most other developers.
At Google, we use a load of fancy tools that are different from the fancy tools available in the community — think version control, build, code hosting and discovery, testing, continuous integration, and everything else you would imagine a well-oiled code shop like Google to have. These tools exist for good reason and they help all of us Google engineers to do our jobs, but they can be a serious hindrance when we are building developer products.
So will you forgive us this inexcusable brainfart, please? In the past we have made bad assumptions about what developers find easy and what developers need. “Well, it was easy for me.” is worryingly easy to map falsely to “So it should be easy for everyone” when our tools and motives differ. We needed to rethink that, and we did.
“Be the Zeroth Customer”
These days, we adhere to the motto “Be the Zeroth Customer”. We realized that unless we entirely simulate the 3rd party development experience of say, an Android developer, we can never fully identify the pain points of being an Android developer. And until we identify these points, we cannot fix them. As a nice by-product we get a load of sample code — yes, that sample code you can get on GitHub initially served to prove out API surfaces and to ensure their fitness for purpose.
“Feel the developers’ pain”
Literally, we should feel the developers’ pain. That sour taste when things don’t work together; the rising anger; the ultimate question “did they even try to use this themselves?”. We get to use Google developer products first. We get to build awesome apps like the I/O Android app. We get to enjoy that pain. And ultimately, we get to to fix what needs fixing. Hate-driven design, anyone?
“Solve real world problems”
Nobody writes “Hello World” and gets paid for it. We have often been guilty of producing sample code that was “Hello World”. It is always useful to take a single API and focus a sample entirely on that, as it is the best way to demonstrate. We have been guilty of only shipping these standalone samples in the past, and again we are trying to improve. I/O Android App, UAmp, Santa Tracker, FriendlyPing, Topeka and other apps have demonstrated how our various technologies work together and with existing stacks.
I am confident that this approach will have a sustained positive impact on the Google Developer experience. We have a long way to go, sorry.