A few days ago I posted a graph I found some time ago that jokingly explained the benefits of subtitles in movies and tweeted about it.

Good #a11y features are beneficial for lots of people. pic.twitter.com/2RMnTzseey

— Chris Heilmann codepo8@toot.cafe (@codepo8) June 28, 2021

The tweet went wild and so far has 35 answers, 290 retweets, 1,500 likes and 150,000 impressions. I love that the answers are all about people’s experiences with subtitles and why they choose to turn them on. These range from selfish reasons like being able to only pay half attention to the movie, to people trying to get linguistic nuances and utterly sweet things like being able to watch something without waking up a baby.

Personally, I am a huge fan of captions and subtitles. First of all, I learned English using them. Growing up in Germany, TV is dubbed and you normally don’t get the option to have subtitles. Growing up in the 80s also meant that there was no interactive TV, so all you got was what was on offer. Weirdly enough, one show that wasn’t dubbed was Monty Python’s Flying Circus, which instead came with German subtitles. This was great, as I could listen to the original audio and learn the meaning at the same time. Even more importantly, I learned about pronunciation of the words, not only their meaning. We learn the phonetics of a language by repetition and if you get a native speaker as the source, that’s an excellent start.

As this was a state channel (all of them were back then) they offered subtitles as an accessibility feature, and it was paid for by the taxes we pay to get access to TV and radio. They were meant to help people who are hard of hearing but were a great way for me to get started learning my first foreign language.

And this is what accessibility features should be in my book: necessary for some, but also beneficial to all. Now, with captions and subtitles, we have a problem. Good ones are expensive, and they seem to be a massive overhead for videos we provide.

However, we also live in amazing times where video platforms create transcripts of videos for us. On YouTube, for example, you only need to define the language of the video and some machine learning product will create a transcript for you. Even when you don’t add alternative text to images, many platforms like Twitter and Facebook will create some automatically generated description added as an “image may contain:” alt attribute.

The problem with those is that they are often full of misunderstandings and not necessarily well structured. The good news is though that most platforms also allow you to export automatically generated transcripts and edit them. Most video hosting platforms also have in-built editors that allow you to verify and tweak the transcript to fix these issues. It is still quite some work to do that, but really worth the effort.

Using these features has a few benefits.

• You can add the transcript not only to the video player but also as a text to the document. This allows visitors to search the video and find what they are looking for. As most video players allow you to jump to a certain time stamp you can link different keywords to certain times and thus allow people to only watch what they need rather than having to scrub through or watch the whole video.
• Some video players even offer a transcript search that makes the video as searchable as an text document.
• Having a transcript also allows people to use their browsers to translate it to their language and thus at least get an idea what you are talking about.
• Search engines can index the transcript and make your web product show up in search results even when people didn’t search for videos.

This kind of thinking is what I try to apply to any accessibility work that I do. We need to make our work accessible anyways, so we may as well try to find ways to make everybody benefit from it. Simpler language, easier interfaces, not overloading the user with lots of information or not using lots of animation means all our visitors have a quicker way to consume what we offer. Accessibility to me means hard-core usability. You make it work for extreme cases and thus make it better for everybody. And by thinking like that, accessibility work isn’t a chore or something we need to do to be legally compliant, but it is a quality feature of our products.

If you want to learn more about how I approach accessibility and how you can test for and fix the most obvious issues using only the browser you already have, you can check out my Tools for Improving Product Accessibility class on Skillshare.

Last week my former colleague Si Jobling interviewed me for his Make life work podcast about working from home, in different time zones and how to optimise your workflow.

This also tied in nicely with Tools and Tips to Optimize Your Workflow as a Developer class and I shared how this one got prepared and recorded.

It was great fun talking to Si again and catching up on the parts where our career crossed – working for Yahoo UK.

I got a cold email asking me to write a blog post about “Seven things you can’t do in React” for exposure on a “leading technology blog”. I sent them my proposal, wish me luck…

1. Boil the perfect egg
2. Connect to your inner child
3. Reach that itchy part on your back
4. Compose a sonnet to woo the ladies
5. Make your dad proud for once
6. Worship Imhotep and bask in his glory
7. Appreciate the Song Thrush’s mating cry

Often you will be part of meetings where people show demos of what your product could look like in the future. These are brain-storming, visionary meetings that can have great outcomes. The idea is to not think in boundaries but in benefits for your users and customers. The longer you work in a certain company and the higher you climb on the career ladder, the more of these meetings will be yours to attend and to organise. I am currently a Principal Program Manager. This means my gaze should be a few years down the line. I’m expected to lead the company to a bright future and anticipate needs of future customers.

This is great. It is wonderful when your employer realises that your experience is an asset. Even better when the company expects your pace of work to slow down as you get older and you’re not supposed to “hustle” but reflect and guide instead.

But there is one problem.

Every inspirational, blue-sky, brainstorming meeting or demo session has a person that keeps disrupting the flow. A battle-hardened, highly experienced developer with lots of memories of how things failed in the past. A person who a lot of people look up to and whose input counts as important. The even bigger problem is that this grumpy old person lives inside my head.

When you’ve been working for a long time in a certain market you accumulated a lot of information. You learn things at first, you take some on as positive and discard others. You see things fail, and you often don’t see any effort to analyse why they failed. Then you blame the part of the failed project you controlled – the technology. And this can lead to a bias where you discard anything remotely similar as failure in the making.

It is a problem when your knowledge and experience becomes a barrier. You know what worked in the past and of course this is the thing to do. All these newfangled things seem flaky and overly complex. They also expect users to embrace technology in a much faster pace than you remember them to do. Hot new interface ideas or content strategies feel like things you heard many times and never added up to any success.

It is important to understand that this is a destructive way of thinking. That’s why I keep telling the old man in my head to shut up and listen instead.

There are a few things that help me with that.

• We tend to see the past in extremes. We either remember good experiences as excellent or bad experiences as abysmal. We even block quite a few out and the longer in the past something was the more unreliable our feeling about it is.
• I’ve seen technology change over and over again. I’ve seen things succeed I considered pointless and things I was all for fail to gain any public interest.
• I’ve often been part of experimental technologies that were too early in the process. Computers weren’t fast enough, people didn’t have the devices or connectivity needed. And just when I discarded them as a learning experience the market moved on and – with a few tweaks – they became a success.
• I’ve learned from failures. I accumulated some knowledge on the way and learned what not to do. Who am I to not allow younger colleagues to get the same insights?
• We live in a wasteful market. A huge part of our market is a series of short-term successes that fade into oblivion to be replaced by the next hyped product. This appears wasteful, but for years I realised it is not worth complaining about this. It is what it is – burning money is part of an ever growing economy. This can soon reach a tipping point, but that is not a reason to be stingy upfront. This isn’t only about money, it is also about code, work time and short-lived products. Some will fail, and that is OK. You can’t win it all.

It is tough to let go and start thinking in a “what if not everything is shit” way. It is fun though to plan ahead and describe a future product your users deserve. A product that focuses on outcome and functionality, unencumbered by your experiences. It is OK to dream without your experiences being a party pooper. A vision that inspires younger people to get creative and have their own experiences. It is their job to deliver this vision, after all. They will be a lot better at finding technical solutions that get them there than you would. As the solutions you cherish and love worked for you, but may not be as useful as you think they are now.

I’m happy to muzzle the grumpy old man in my head, and I hope that will prevent the people who work with me to ever having to deal with him.

I have a new class on Skillshare where I am teaching how to be a developer that is easy to work with in a world of home office, geographical and temporal distribution and how to communicate across departments.

You can check the introduction video here:

Here’s what I am covering in the video:

Our world has changed. We are working differently right now and a lot of engineers have a problem getting their information heard and getting their output documented.

I’m Chris and I’m a Principal Program Manager, but I used to be a developer for over 20 years. I’ve worked in the last ten years from home with distributed teams all over the globe. In this class I want to explain to you how to optimise your workflow as a developer, how to be understood and how to work together with people who are not in the same building as you.

As a program manager, my main job is to make sure a product succeeds. That means I have to think about how it grows, how it works, and how it can be delivered in a certain amount of time. This means I had to manage and optimise my workflow to get the information that I need without me having to be somebody who’s working on the code all the time.

I’m covering a few things:

• How to set up your machine to make sure that you don’t make mistakes that are avoidable.
• How to change your setup for the new, distributed world that we live in right now. Most of the time we’re not only developing, but we are in video meetings. Something we should consider how to make ourselves more effective in.
• Version control, making sure that everything you do will be retained somewhere and you cannot make mistakes and lose your work.
• Online collaboration, how you can build things that other people can collaborate with and work on while you’re in bed or you’re you’re not being available at the moment.
• Helping others how to document and promote your work. How to give people access to what you do so they can document it and tell other people about it without having to be part of the process.

The skills I hope you can take away from that is communication, because I found in my career, no matter how good a developer you are, sooner or later, it will come down to the soft skills. You need to make sure that people understand what you do so people can add their information and give you opportunities to succeed in your career.

One of the things I learned as a developer is that my code is not the most important thing, but how I bring it to people. How much information I give around my code and how I allow other people to do their job based on my work. This is much more important than the code itself.

That is something that was hard to swallow for me as a developer because I love coding more than writing about my code. But at the same time, it made my career.

So hopefully it will be a skill that helps your career as well.

I’m excited for you to take this class because I want the next developer generation to start embracing the new world that we live in. It’s not that we’re actually sitting in an office next to a senior developer anymore and learn everything from them. We are all distributed and we’re all working in different places.

And this is a freedom we actually fought for and we should embrace. It is a great opportunity for you to be somebody that’s easy to work with, although you are not physically present. And that’s something that you can learn in this course.

In this class, we don’t have one example in the project gallery just to copy and learn from.
Instead, the class should inspire you to do some changes to your code. You’re going to learn about different things that you can do to it to make your code easier to contribute to and easier to understand for everyone out there.

So take a look at it. Take a look at what I’ve done, disagree with it or like it, and come to the discussion boards to talk about what you have learned from this class and what other things you have found that we missed out on.

The class takes about half an hour all in all and is free with a subscription to Skillshare, something you can try out for free for a week if you sign up. Click the following image or take the class here