Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

A great time and place to ask about diversity and inclusion

Monday, July 18th, 2016

whiteboard code

There isn’t a single day going by right now where you can’t read a post or see a talk about diversity and inclusiveness in our market. And that’s a great thing. Most complain about the lack of them. And that’s a very bad thing.

It has been proven over and over that diverse teams create better products. Our users are all different and have different needs. If your product team structure reflects that you’re already one up against the competition. You’re also much less likely to build a product for yourself – and we are not our end users.

Let’s assume we are pro-diversity and pro-inclusiveness. And it should be simple for us – we come from a position of strength:

  • We’re expert workers and we get paid well.
  • We are educated and we have companies courting us and looking after our needs once we have been hired.
  • We’re not worried about being able to pay our bills or random people taking our jobs away.

I should say yet, because automation is on the rise and even our jobs can be optimised away sooner or later. Some of us are even working on that.

For now, though, we are in a very unique position of power. There are not enough expert workers to fill the jobs. We have job offers thrown at us and our hiring bonuses, perks and extra offers are reaching ridiculous levels. When you tell someone outside our world about them, you get shocked looks. We’re like the investment bankers and traders of the eighties and we should help to ensure that our image won’t turn into the same they have now.

If we really want to change our little world and become a shining beacon of inclusion, we need not to only talk about it – we should demand it. A large part of the lack of diversity in our market is that it is not part of our hiring practices. The demands to our new hires make it very hard for someone not from a privileged background or with a degree from a university of standing to get into our market. And that makes no sense. The people who can change that is us – the people in the market who tick all the marks.

To help the cause and make the things we demand in blog posts and keynotes happen, we should bring our demands to the table when and where they matter: in job interviews and application processes.

Instead of asking for our hardware, share options and perks like free food and dry cleaning we should ask for the things that really matter:

  • What is the maternity leave process in the company? Can paternity leave be matched? We need to make it impossible for an employer to pick a man over a woman because of this biological reason.
  • Why is a degree part of the job? I have none and had lots of jobs that required one. This seems like an old requirement that just got copied and pasted because of outdated reasons.
  • What is the long term plan the company has for me? We kept getting asked where we see ourselves in five years. This question has become cliché by now. Showing that the company knows what to do with you in the long term shows commitment, and it means you are not a young and gifted person to be burned out and expected to leave in a year.
  • Is there a chance for a 4 day week or flexible work hours? For a young person it is no problem doing an 18 hours shift in an office where all is provided for you. As soon as you have children all kind of other things add to your calendar that can’t me moved.
  • What does this company do to ensure diversity? This might be a bit direct, but it is easy to weed out those that pay lip service.
  • What is the process to move in between departments in this company? As you get older and you stay around for longer, you might want to change career. A change in your life might make that necessary. Is the company supporting this?
  • Is there a way to contribute to hiring and resourcing even when you are not in HR? This could give you the chance to ask the right questions to weed out applicants that are technically impressive but immature or terrible human beings.
  • What is done about accessibility in the internal company systems? I worked for a few companies where internal systems were inaccessible to visually impaired people. Instead of giving them extra materials we should strive for making internal systems available out-of-the-box.
  • What is the policy on moving to other countries or working remotely? Many talented people can not move or don’t want to start a new life somewhere else. And they shouldn’t have to. This is the internet we work on.
  • What do you do to prevent ageism in the company? A lot of companies have an environment that is catering to young developers. Is the beer-pong table really a good message to give?

I’ve added these questions to a repo on GitHub, please feel free to add more questions if you find them.

FWIW, I started where I am working right now because I got good answers to questions like these. My interviews were talking to mixed groups of people telling me their findings as teams and not one very aggressive person asking me to out-code them. It was such a great experience that I started here, and it wasn’t a simple impression. The year I’ve worked here now proved that even in interviewing, diversity very much matters.

Photo Credit: shawncplus

Things not to say on stage at a tech event

Wednesday, July 6th, 2016

cringing woman

This is also available on Medium

This is not about a post about trigger words or discriminatory expressions. There is a lot of information about this available, and even some excellent linting tools for your texts. It is also not about unconscious bias. Or well, maybe it is. Learned bias for sure.

This is a post about some sentences used in technical presentations that sound encouraging. In reality they may exclude people in the audience and make them feel bad about their level of knowledge. These are the following sentences and I’ll explain in detail how to replace them with something less destructive:

None of these are a show-stopper and make you a terrible presenter. There may even be ways to use them that are not confusing and destructive. This is language, and in some cultures they may be OK to use. I’m not here to tell people off. I am here to make you aware that something that sounds good might make people feel bad. And that’s not what we’re here for as presenters.

As a presenter your job is not only to give out technical information. You also need to inspire and to entertain. Often you overshoot the mark by simplifying things and trying to hard to please.

It is important to remind ourselves that we can not assume much of our audience. The room might be full of experts, but the video recording is also going out to everybody. Explaining things in a simple fashion is not dumbing them down. It may actually be the hardest task there is for a presenter.

It is stressful to be at an expert event. As an audience member you don’t want to appear less able than others. As a presenter, it is worse. Presenting is a balancing act. You neither want to sound condescending, overload the audience, make people feel stupid, appear too basic … and, and, and…

I’ve heard the following expressions at a lot of events and I always cringed a bit. Often they are OK, and no harm done. But,to improve as presenters it may be a good idea to be more conscious about what we do and what effects it can have.

“This is easy…”

We often try to calm down the audience by making what we show appear simple. The problem with that is that what is simple for us might still be confusing to the people in the room. Add peer-pressure to that and people will neither speak up that they don’t understand, nor feel empowered. The opposite applies – by saying something is easy and people failing to grasp or apply it, we make them feel stupid. If you make me feel stupid, you may inspire me to get better. But I don’t do it for the right reason – I do it out of guilt and self-doubt.

The worst way to use “this is easy” is when you rely on a lot of abstractions or tools to achieve the easy bit. Each of those could be a stumbling block for people applying your wisdom.

Replacements:

  • “Here are a few steps how to achieve this…”
  • “By using these tools, which are all well documented, you can…”
  • “The way to get this done is…”

Using these you send people on a journey. They don’t tell them that the end result is already a given. Who knows, they may find a way to improve your “easy” one.

“I’ll repeat quickly, for the few of you who don’t know…”

This expression just fell at a conference I attended and it made me cringe. The presenter meant to be encouraging in a “hey, we all are already on board” way, but it can come across as arrogant. Even worse, it already singles out those who do not know, and makes them feel like they are under a spotlight.

If the intention is to do a quick intro on what you want to build upon, it is better to phrase it as a reminder, not a “you already know, what am I doing here”.

Replacements

  • “Just as a reminder, here is what $x is about…”
  • “As you may remember, $x is about…”
  • “We’re building this using $x, which is…”

This adds your repetition into the flow instead of being an excuse.

“Everybody can do that…”

If everybody can do it, why do I listen to you? Also, if everybody can do it, how come I never managed to? If you use this you either present something basic, or you over-simplify a complex matter. The latter can appear to be empowering; you take away the fear of approaching something. But, it backfires when people can’t use it. Then you exclude them from “everybody”. And that hurts.

Replacements:

  • “If you know your way around $x, $y and $z, you should find it easy to…”
  • “Once you managed to do that, you’ll find it makes the rest of your work easier…”
  • “It is a very effective way to work, if it works for you, tell others about it”

This again makes it a reminder and a starting point of a journey. Not a given that is redundant to repeat.

“$x solves this problem, so you don’t have to worry about it”

Hooray for your product – it solves everything. Now buy it and impress people with wisdom you don’t have. And feel worse when you get praised for it. This is a classic sales pitch which works with end user products. As a developer you should always worry about what you use in your products as each part can become an issue. And it will be up to you to fix it.

Replacements

  • “$x solves the problems around $y, so you can build $z”
  • “$x was created to make $y easier and is used in production, the results are encouraging…”
  • “Here are the steps you can do by hand that $x does for you…”

Pop open the hood, show how your product works. Don’t sell all-healing remedies.

“As everybody knows…”

Common knowledge is a myth and relies on your environment, access to information, time to consume news and the way you learn. Presenting something as common knowledge may make people think “so how come I ever heard of it?” and stop them in their tracks.

Replacements:

  • “This has been around for a while and was explained wonderfully in $x ($x being a resource you link to)”
  • “Tests have shown that $x is a given for a lot of solutions (point to research, give proof)”
  • “I base this on the fact that $x, as proven many times by… (and add a list a resources)”

“Citation needed” is a wonderful way to say something and prove your point. You show people that you did your homework before you make an assumption. And you give those who did not the tools to do so.

“This is just like we learned in school…”

This assumes everybody went to a school with the same curriculum as you. A lot of people have not. This is especially destructive when it applies to knowledge that was part of a Computer Science degree.

Replacements:

  • “This has been part of Computer Science teaching for years, and for good reason because $x”
  • “This should look familiar to anyone who went to a similar school as me, and for those who didn’t, there’s truckloads of information available online about it”
  • “You might remember this from school – now you see how it can be applied in a real job. Who knew?”

A lot of people create the web. Not all took the official path.

“That’s why $y(your product) is much better than (competitor) $x”

This is common in advertising, especially in America. You show off your product by making others look worse. This is pointless and only invites criticism and retaliation by others. As a tech presenter, you should know that the other product is also built by people. Final decision of what gets shipped are not always based on technical merit. It is a cheap shot.

Replacements:

  • “Here’s how to do that with product $x, we took a different path and here’s why…”
  • “There are many solutions to this. We found that some were lacking a feature that made us more effective, which is $x”
  • “You can use whatever makes you happy to achieve $x. We added the following, as we found it was missing…”

Showing you know about your competition prevents questions about it. Showing how they differ allows people to make up their mind which is better instead of you telling them and hoping they agree.

“This can be done in a few lines of code…”

The amount of code has become a contrived way of showing how effective our solutions are. Almost always the “quick and small solution” blossoms into a much larger one once it is used in production. It makes much more pragmatic sense to tell people that this is inevitable, and praise the small starting point for what it is – a start.

Replacements:

  • “As you can see, starting this is a few lines of code. I simplified this to show here, the source code is available at $x”
  • “For now, this is all that is needed to achieve this. No doubt, you will need to add more to it, but it is a starting point”
  • “By abstracting some of the issues out, we can cut down our code to a few lines”
  • “As we rely on functionality of $x, this means our implementation can be very small…”

A lot of times, this solves our own issue of showing only a few lines of code on a slide. Instead, let’s write understandable code that we explain in sections rather than one magical tidbit.

“If you want to be professional, do $x”

People have different opinions what a “professional” is. Whilst we worry about quality and maintenance, other people put more merit on fast delivery. The state of the art changes all the time, and a sentence like this can look silly in a few weeks.

Replacements:

  • “$x, $y and $z are using this heavily to deliver their products. Here are some case studies that show the positive results…”
  • “Using $x gives you a starting point you can rely on and makes it easier to explain to your replacement how to take over the product…”
  • “The benefits of $x are $y, which makes it a professional tool to use…”

You achieve professionalism with experience and by learning about new thing and retaining them. Things people say on stage and define as “best practice” need validation by professionals. It is not up to you as a presenter to define that.

A quick check

There are more unintentional destructive expressions. Read through your talks and watch your videos and then ask yourself: “how would I feel listening to this if I didn’t know what I know?”. Then remove or rephrase accordingly.

Our market grew as fast as it did by being non-discriminatory of background or level of education. Granted, most of us grew up in safe environments and were lucky enough to have free schooling. But there are a lot of people in our midst who came from nowhere or at least nowhere near computer science. And they do great work. I’d go so far as to say that the diversity of backgrounds made the web what it is now: a beautiful mess that keeps evolving into who knows what. It is anything but boring. There is never “one way” to reach a goal. We discovered a lot of our solutions by celebrating different points of view.

Photo by alyona_fedotova

My closing keynote at Awwwards NYC 2016: A New Hope – the web strikes back

Monday, June 20th, 2016

Last week I was lucky enough to give the closing keynote at the Awwwards Conference in New York.

serviceworker beats appcache

Following my current fascination, I wanted to cover the topic of Progressive Web Apps for an audience that is not too technical, and also very focused on delivering high-fidelity, exciting and bleeding edge experiences on the web.

Getting slightly too excited about my Star Wars based title, I got a bit overboard with bastardising Star Wars quotes in the slides, but I managed to cover a lot of the why of progressive web apps and how it is a great opportunity right now.

I covered:

  • The web as an idea and its inception: independent, distributed and based on open protocols
  • The power of links
  • The horrible environment that was the first browser wars
  • The rise of standards as a means to build predictable, future-proof products
  • How we became too dogmatic about standards
  • How this lead to rebelling developer using JavaScript to build everything
  • Why this is a brittle environment and a massive bet on things working flawlessly on our users’ computers
  • How we never experience this as our environments are high-end and we’re well connected
  • How we defined best practices for JavaScript, like Unobtrusive JavaScript and defensive coding
  • How libraries and frameworks promise to fix all our issues and we’ve become dependent on them
  • How a whole new generation of developers learned development by copying and pasting library-dependent code on Stackoverflow
  • How this, among other factors, lead to a terribly bloated web full of multi-megabyte web sites littered with third party JavaScript and library code
  • How to rise of mobile and its limitations is very much a terrible environment for those to run in
  • How native apps were heralded as the solution to that
  • How we retaliated by constantly repeating that the web will win out in the end
  • How we failed to retaliate by building web-standard based apps that played by the rules of native – an environment where the deck was stacked against browsers
  • How right now our predictions partly came true – the native environments and closed marketplaces are failing to deliver right now. Users on mobile use 5 apps and download on average not a single new one per month
  • How users are sick of having to jump through hoops to try out some new app and having to lock themselves in a certain environment
  • How the current state of supporting mobile hardware access in browsers is a great opportunity to build immersive experiences with web technology
  • How ServiceWorker is a great opportunity to offer offline capable solutions and have notifications to re-engage users and allow solutions to hibernate
  • How Progressive Web Apps are a massive opportunity to show native how software distribution should happen in 2016

Yes, I got all that in. See for yourself :).

The slides are available on SlideShare

A New Hope – the web strikes back from Christian Heilmann

You can watch the screencast of the video on YouTube.

Progressive Web Apps and our regressive approach

Tuesday, May 31st, 2016

Tractor at airport
Custom made, cute, but not reusable

In the weeks following Google IO there was a lot of discussion about progressive web apps, Android instant Apps and the value and role of URLs and links in the app world. We had commentary, ponderings, Pathos, explanation of said Pathos after it annoyed people and an excellent round-up on where we stand with web technology for apps.

My favourite is Remy Sharp’s post which he concludes as:

I strongly believe in the concepts behind progressive web apps and even though native hacks (Flash, PhoneGap, etc) will always be ahead, the web, always gets there. Now, today, is an incredibly exciting time to be build on the web.

PWAs beat anything we tried so far

As a card-carrying lover of the web, I am convinced that PWAs are a necessary step into the right direction. They are a very important change. So far, all our efforts to crack the advertised supremacy of native apps over the web failed. We copied what native apps did. We tried to erode the system from within. We packaged our apps and let them compete in closed environments. The problem is that they couldn’t compete in quality. In some cases this might have been by design of the platform we tried to run them on. A large part of it is that “the app revolution” is powered by the age old idea of planned obsolesence, something that is against anything the web stands for.

I made a lot of points about this in my TEDx talk “The Web is dead” two years ago:

We kept trying to beat native with the promises of the web: its open nature, its easy distribution, and its reach. These are interesting, but also work against the siren song of apps on mobile: that you are in control and that you can sell them to an audience of well-off, always up-to-date users. Whether this is true or not was irrelevant – it sounded great. And that’s what we need to work against. The good news is that we now have a much better chance than before. But more on that later.

Where to publish if you need to show quick results?

Consider yourself someone who is not as excited about the web as we are. Imagine being someone with short-term goals, like impressing a VC. As a publisher you have to make a decision what to support:

  • iOS, a platform with incredible tooling, a predictable upgrade strategy and a lot of affluent users happy to spend money on products.
  • Android, a platform with good tooling, massive fragmentation, a plethora of different devices on all kind of versions of the OS (including custom ones by hardware companies) and users much less happy to spend money but expecting “free” versions
  • The web, a platform with tooling that’s going places, an utterly unpredictable and hard to measure audience that expects everything for free and will block your ads and work around your paywalls.

If all you care about is a predictable audience you can do some budgeting for, this doesn’t look too rosy for Android and abysmal for the web. The carrot of “but you can reach millions of people” doesn’t hold much weight when these are not easy to convert to paying users.

To show growth you need numbers. You don’t do that by being part of a big world of links and resources. You do that by locking people in your app. You do it by adding a webview so links open inside it. This is short-sighted and borderline evil, but it works.

And yes, we are in this space. This is not about what technology to use, this is not about how easy it is to maintain your app. This is not about how affordable developers would be. The people who call the shots in the app market and make the money are not the developers. They are those who run the platforms and invest in the companies creating the apps.

The app honeymoon period is over

The great news is that this house of cards is tumbling. App download numbers are abysmally low and the usage of mobiles is in chat clients, OS services and social networks. The closed nature of marketplaces works heavily against random discovery. There is a thriving market of fake reviews, upvotes, offline advertising and keyword padding that makes the web SEO world of the last decade look much less of the cesspool we remember. End users are getting tired of having to install and uninstall apps and continuously get prompts to upgrade them.

This is a great time to break into this model. That Google finally came up with Instant Apps (after promising atomic updates for years) shows that we reached the breaking point. Something has to change.

Growth is on mobile and connectivity issues are the hurdle

Here’s the issue though: patience is not a virtue of our market. To make PWAs work, bring apps back to the web and have the link as the source of distribution instead of closed marketplaces we need to act now. We need to show that PWAs solve the main issue of the app market: that the next users are not in places with great connectivity, and yet on mobile devices.

And this is where progressive web apps hit the sweet spot. You can have a damn small footprint app shell that gets sweet and easy to upgrade content from the web. You control the offline experience and what happens on flaky connections. PWAs are a “try before you buy”, showing you immediately what you get before you go through the process of adding it to your home screen or download the whole app. Exactly what Instant Apps are promising. Instant Apps have the problem that Android isn’t architected that way and that developers need to change their approach. The web was already built on this idea and the approach is second nature to us.

PWAs need to succeed on mobile first

The idea that a PWA is progressively enhanced and means that it could be a web site that only converts in the right environment is wonderful. We can totally do that. But we shouldn’t pretend that this is the world we need to worry about right now. We can do that once we solved the issue of web users not wanting to pay for anything and show growth numbers on the desktop. For now, PWAs need to be the solution for the next mobile users. And this is where we have an advantage over native apps. Let’s use that one.

Open questions

Of course, there are many issues to consider:

  • How do PWAs work with permissions? Can we ask permissions on demand and what happens when users revoke them? Instant apps have that same issue.
  • How do I uninstall a PWA? Does removing the icon from my homescreen free all the data? Should PWAs have a memory management control?
  • What about URLs? Should they display or not? Should there be a long-tap to share the URL? Personally, I’d find a URL bar above an app confusing. I never “hacked” the URL of an app – but I did use “share this app” buttons. With a PWA, this is sending a URL to friends, and that’s a killer feature.
  • How do we deal with the issue of iOS not supporting Service Workers? What about legacy and third party Android devices? Sure, PWAs fall back to normal HTML5 apps, but we’ve seen them not taking off in comparison to native apps.
  • What are the “must have” features of native apps that PWAs need to match? Those people want without being a hurdle or impossible to implement?

These are exciting times and I am looking forward to PWAs being the wedge in the cracks that are showing in closed environments. The web can win this, but we won’t get far if we demand features that only make sense on desktop and are in use by us – the experts. End users deserve to have an amazing, form-factor specific experience. Let’s build those. And for the love of our users, let’s build apps that let them do things and not only consume them. This is what apps are for.

Google IO – A tale of two Googles

Monday, May 23rd, 2016

Google IO main stage with audience

Disclaimer: The following are my personal views and experiences at this year’s Google IO. They are not representative of my employer. Should you want to quote me, please do so as Chris Heilmann, developer.

TL;DR: Is Google IO worth the $900? Yes, if you’re up for networking, getting information from experts and enjoy social gatherings. No, if you expect to be able to see talks. You’re better off watching them from home. The live streaming and recordings are excellent.

Google IO this year left me confused and disappointed. I found a massive gap between the official messaging and the tech on display. I’m underwhelmed with the keynote and the media outreach. The much more interesting work in the breakout sessions, talks and demos excited me. It seems to me that what Google wants to promote and the media to pick up is different to what its engineers showed. That’s OK, but it feels like sales stepping on a developer conference turf.

I enjoyed the messaging of the developer outreach and product owner team in the talks and demos. At times I was wondering if I was at a Google or a Mozilla event. The web and its technologies were front and centre. And there was a total lack of “our product $X leads the way” vibes.

Kudos to everyone involved. The messaging about progressive Web Apps, AMP and even the new Android Instant Apps was honest. It points to a drive in Google to return to the web for good.

Illuminated dinosaur at the after party

The vibe of the event changed a lot since moving out of Moscone Center in San Francisco. Running it on Google’s homestead in Mountain View made the whole show feel more like a music festival than a tech event. It must have been fun for the presenters to stand on the same stage they went to see bands at.

Having smaller tents for the different product and technology groups was great. It invited much more communication than booths. I saw a lot of neat demos. Having experts at hand to talk with about technologies I wanted to learn about was great.

Organisation

Feet in the sun watching a talk at the Amphitheatre

Here are the good and bad things about the organisation:

  • Good: traffic control wasn’t as much of a nightmare I expected. I got there two hours in advance as I anticipated traffic jams, but it wasn’t bad at all. Shuttles and bike sheds helped getting people there.
  • Good: there was no queue at badge pickup. Why I had to have my picture taken and a – somehow sticky – plastic badge printed was a bit beyond me, though. It seems wasteful.
  • Good: the food and beverages were plentiful and applicable. With a group this big it is hard to deliver safe to eat and enjoyable food. The sandwiches, apples and crisps did the trick. The food at the social events was comfort food/fast food, but let’s face it – you’re not at a food fair. I loved that all the packaging was paper and cardboard and there was not too much excess waste in the form of plastics. We also got a reusable water bottle you could re-fill at water dispensers like you have in offices. Given the weather, this was much needed. Coffee and tea was also available throughout the day. We were well fed and watered. I’m no Vegan, and I heard a few complaints about a lack of options, but that may have been personal experiences.
  • Good: the toilets were amazing. Clean, with running water and plenty of paper, mirrors, free sunscreen and no queues. Not what I expected from a music festival surrounding.
  • Great: as it was scorching hot on the first day the welcome pack you got with your badge had a bandana to cover your head, two sachets of sun screen, a reusable water bottle and sunglasses. As a ginger: THANK YOU, THANK YOU, THANK YOU. The helpers even gave me a full tube of sunscreen on re-entry the second day, taking pity on my red skin.
  • Bad: the one thing that was exactly the same as in Moscone was the abysmal crowd control. Except for the huge stage tent number two (called HYDRA - I am on to you, people) all others were far too small. It was not uncommon to stand for an hour in a queue for the talk you wanted to see just to be refused entry as it was full up. Queuing up in the scorching sun isn’t fun for anyone and impossible for me. Hence I missed all but two talks I wanted to see.
  • Good: if you were lucky enough to see a talk, the AV quality was great. The screens were big and readable, all the talks were live transcribed and the presenters audible.

The bad parts

Apart from the terrible crowd control, two things let me down the most. The keynote and a total lack of hardware giveaway – something that might actually be related.

Don’t get me wrong, I found the showering of attendees with hardware excessive at the first few IOs. But announcing something like a massive move into VR with Daydream and Tango without giving developers something to test it on is assuming a lot. Nine hundred dollars plus flying to the US and spending a lot of money on accommodation is a lot for many attendees. Getting something amazing to bring back would be a nice “Hey, thanks”.

There was no announcement at the keynote about anything physical except for some vague “this will be soon available” products. This might be the reason.

My personal translation of the keynote is the following:

We are Google, we lead in machine learning, cloud technology and data insights. Here are a few products that may soon come out that play catch-up with our competition. We advocate diversity and try to make people understand that the world is bigger than the Silicon Valley. That’s why we solve issues that aren’t a problem but annoyances for the rich. All the things we’re showing here are solving issues of people who live in huge houses, have awesome cars and suffer from the terrible ordeal of having to answer text messages using their own writing skills. Wouldn’t it be better if a computer did that for you? Why go and wake up your children with a kiss using the time you won by becoming more effective with our products when you can tell Google to do that for you? Without the kiss that is – for now.

As I put it during the event:

I actually feel poor looking at the #io16 keynote. We have lots of global problems technology can help with. This is pure consumerism.

I stand by this. Hardly anything in the keynote excited me as a developer. Or even as a well-off professional who lives in a city where public transport is a given. The announcement of Instant Apps, the Firebase bits and the new features of Android Studio are exciting. But it all got lost in an avalanche of “Look what’s coming soon!” product announcements without the developer angle. We want to look under the hood. We want to add to the experience and we want to understand how things work. This is how developer events work. Google Home has some awesome features. Where are the APIs for that?

As far as I understand it, there was a glitch in the presentation. But the part where a developer in Turkey used his skills to help the Syrian refugee crisis was borderline insulting. There was no information what the app did, who benefited from it and what it ran on. No information how the data got in and how the data was going to the people who help the refugees. The same goes for using machine learning to help with the issue of blindness. Both were teasers without any meat and felt like “Well, we’re also doing good, so here you go”.

Let me make this clear: I am not criticising the work of any Google engineer, product owner or other worker here. All these things are well done and I am excited about the prospects. I find it disappointing that the keynote was a sales pitch. It did not pay respect to this work and failed to show the workings rather than the final product. IO is advertised as a developer conference, not a end user oriented sales show. It felt disconnected.

Things that made me happy

Chris Heilmann covered in sunscreen, wearing a bandana in front of Google Loon

  • The social events were great – the concert in the amphitheatre was for those who wanted to go. Outside was a lot of space to have a chat if you’re not the dancing type. The breakout events on the second day were plentiful, all different and arty. The cynic in my sniggered at Burning Man performers (the anthithesis to commercialism by design) doing their thing at a commercial IT event, but it gave the whole event a good vibe.
  • Video recording and live streaming – I watched quite a few of the talks I missed the last two days in the gym and I am grateful that Google offers these on YouTube immediately, well described and easy to find in playlists. Using the app after the event makes it easy to see the talks you missed.
  • Boots on the ground – everyone I wanted to meet from Google was there and had time to chat. My questions got honest and sensible answers and there was no hand-waving or over-promising.
  • A good focus on health and safety – first aid tents, sunscreen and wet towels for people to cool down, creature comforts for an outside environment. The organisers did a good job making sure people are safe. Huge printouts of the Code of Conduct also made no qualm about it that antisocial or aggressive behaviour was not tolerated.

Conclusion

Jatinder and me at the keynote

I will go again to Google IO, to talk, to meet, to see product demos and to have people at hand that can give me insight further than the official documentation. I am likely to not get up early next time to see the keynote though and I would love to see a better handle on the crowd control. It is frustrating to queue and not being able to see talks at the conference of a company who prides itself at organising huge datasets and having self-driving cars.
Here are a few things that could make this better:

  • Having screening tents with the video and the transcription screens outside the main tents. These don’t even need sound (which is the main outside issue)
  • Use the web site instead of two apps. Advocating progressive web apps and then telling me in the official conference mail to download the Android app was not a good move. Especially as the PWA outperformed the native app at every turn – including usability (the thing native should be much better). It was also not helpful that the app showed the name of the stage but not the number of the tent.
  • Having more places to charge phones would have been good, or giving out power packs. As we were outside all the time and moving I didn’t use my computer at all and did everything on the phone.

I look forward to interacting and working with the tech Google. I am confused about the Google that tries to be in the hands of end users without me being able to crack the product open and learn from how it is done.