Moving away from Google+

Post one in a series on migrating away from Google+.

So, here we are, at the crossroads.

Google+ is being sunsetted. Aww, bollocks! Let’s use the appropriate terms: terminated, decapitated, shat upon, no fucks given about, or to refer to it in classic Google style: ABANDONED. You can quote me on that. All of it. Why, Google, WHY!?

I don’t know about you, but I am really going to miss Google+, as it has been the only place that I’ve felt at home in social media. No ads, good moderation tools, and easy to find people and topics to follow.

Photo by on

What to do?

The G+ shutdown is inevitable, so let’s get on with figuring out what to do next. I’ve spent some time looking around, and exploring my options. There are a number of considerations: Do you want to host it yourself? What level of functionality do you need? Do you need it to be readable on mobile? Do you need it to be able to import old content? How does it integrate with others? How is the visibility? Can it be searched?

Continue reading “Moving away from Google+”

Google wants to kill the URL!

Google wants to kill the URL!

“I don’t know what this will look like, because it’s an active discussion in the team right now,” says Parisa Tabriz, director of engineering at Chrome. “But I do know that whatever we propose is going to be controversial. That’s one of the challenges with a really old and open and sprawling platform. Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck.”

Considering all the tracking crap that is attached to URLs, I tend to support the idea, although it is hard to envision how this will be done.

#google #url #chrome #browser

Does Google listen in on your life?

Does Google listen in on your life?

“Google retains a copy of the recordings to improve its software. The company is trying to be the opposite of sneaky. It provides a detailed history of every recording it has on the user’s “My Activity” web page.

Each recording or set of recordings is presented on its own card.

The recordings are listed by date and service (for example, “Assistant,” “Google App” or “” On the left you can see the text version of your command, which is a link that, when clicked on, takes you to Google Search results for those words. On the right you’ll find a “play” button, so you can listen to each recording. A “more options” menu on the top right of each card enables you to delete any recording.

It’s unlikely for a recording to happen by accident. From a phone, for example, the phone must be unlocked and the recording begun by specific user action, such as pressing the icon. On a Pixel phone, the user can set up automatic listening mode by changing the default in settings to enable the “Trusted Voice” setting. That makes the phone listen for the “OK Google” command…”

Learn more from Mike Elgan:

#AI #Google #OkGoogle #GoogleHome #Computer #Microphone

My Job Is To Meet Expectations

This is a reply to the article Your Job Is Not to Write Code by +Laura Klein. 

It IS my job to write code. That code has to meet the expectations of the end users, the product manager (PM), the Quality Assurance Manager (QM), the support team, and myself.

The PM has to set the bar. Functionally and performance wise. If the PM leaves it up to me to decide what the code should run on, on what kind of hardware, that PM is not filling the role. The PMs are the ones that set the targets.

In a proper development team, it is NOT the developers job to test that the code runs on all variants of hardware. This is where you have testers, and a PM and a QA Manager (QM) that define the bar of what is acceptable function and performance in accordance with the specification you created.

The developer may be given his/her own test machine which can be used for “worst case” scenarios, but it is the test team that has to validate on a decent sample set of environments.

I might be a hired hand, and probably do not know all there is about the trade that the software is developed for, nor do I know the clients or how they actually use the software. Over time, I might learn this, but only as far as the PM lets me.

It is my job to think of the what-if’s. Actually, writing code is all about what-if’s. However, it is the specifications that decide the scope of the what if’s.
Should I recognize different number formats? Date formats? International characters? Right to left text? What should the default value be when a calculation fails due to a division by zero? What should the correct behavior be when a criteria is not met? All these things are about specifications defined by the PM according to the needs of the clients.

When I “check in code”, I should NEVER EVER check it into production. I should push it to a proper staging environment, and write roll out documentation, then the test team should roll it out on a test environment, validate that it works, refine documentation and then hand it to the support team for rollout to production.

If the PM did not ensure that there is proper QA, it is that PM that is responsible for the shitty code in production. If the product doesn’t do what the customer expects, it’s the PM that did not write proper use cases and proper specifications and operational parameters, and it would be the PM that did not ensure that the QM had created the necessary test cases and functional specifications.

My skill is not customer management. My skill is not necessarily to know the business that the client is in. My skill is to transform various degrees of incomplete specifications into something that resembles what the customer wants, within reasonable time, and with a reasonably high quality.

The PMs are the ones that defines what the customer wants.
The QMs decide if what I wrote, meets that definition.
The support team will be the ones that verify that the definition actually was complete and correct.

Good software meets expectations. Good software is a process. Good process depends on team work. Team work depends on a certain degree of separations of roles. Roles are defined by responsibilities.

My role as a developer is to write code that meets expectations.

In some companies, these roles may boil down to just a few people — or even just a single individual. The roles are still there. The responsibilities are still there.

If the CEO doesn’t understand or care about these roles and allot the necessary time and/or resource — that company will be fighting fires, playing blame games, and losing clients.

Your Developer
Lars Fosdal