Last week I had an excellent conversation in Brooklyn around the effects of automation on jobs. One idea I found useful to share was the distinction of High Road and Low Road employers used by Thomas Kochan at MIT Sloan. The two roads are between employers who provide a supportive environment for employees, and ones who treat employees as a cost to minimise. The examples used are often Wal-Mart (on the low side), and Costco or Market Basket (on the high).

In the dark and distant past I used to give talks on search. I had an interest in information retrieval generally and drifted into some of the popular libraries and services of the time. One popular choice was Solr which is based on the Lucene library. I also tried, and was impressed with, Elasticsearch: a newer Lucene based tool, but with a much easier to use API.

Running a developer product or a developer relations team means making trade-offs about where to invest time, money, or focus. Being able to attach values to developers can make conversations easier across different business functions, and allow more direct apples to apples comparisons of things like the potential value of activities.

Developer services are an umbrella term for any kind of pay-per-usage developer product, usually provided as a hosted service. The majority of AWS, Google Cloud and Azure services fall into this bucket, as do numerous others. It is a relatively simple model, pay for what you use, but it has a host of challenges to building a great, sustainable business.

In this post, developer platforms means multi-sided markets where one of the sides consists of software developers. Platform businesses are immensely powerful drivers of the modern tech landscape— pretty much every notable tech company has at least some aspect of a platform business in their DNA.

Thinking about developer products means thinking about developers. What is different about software development as compared to other professions or interest groups? In particular, what needs to be considered when building tools and services for developers?

DevRel, developer advocacy or developer evangelism teams are a part of almost every recent developer-services success. Many DevRel people are hired for their functional responsibilities (we need someone to do X), rather than how they fit into the business.

Serverless, with all the attendant ambiguity on what that means, tends to be discussed from the perspective of people who build services. This often leads to a focus on the differences between serverless and previous generations of infrastructure. Specifically, we talk about how the provisioning, balancing and so on have been made utility, as compute, storage, hardware and bandwidth had been in previous generations of technology.

Back in the dark ages I wrote a blog post on using Google Sign In to authorize a server from an Android client, and provided an accompanying gist with an example Activity in it. Recently, someone point out to me that gist was quite out of date, so I updated it to use the latest and greatest Google Sign In APIs on Android, with very pleasant results.

Very quick post on a problem I’ve seen a few people hit where they are upgrading a Firebase.com project which uses Google Sign In on Android.