Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

Some things you can do to make it easier for people in other time zones to work with you

Friday, May 31st, 2019

I work as a remote employee with most of my team being 8 hours time difference away. Here’s a few things that help me a lot and I helped people with to ensure our working together is most effective.

  • Keeping meetings with people in the same time zone as you to the middle part of the day allows people to meet with you in sensible times on their end. Often they need to contact you in your morning or evening.
  • Shared online documents are an amazing way to get feedback and empower others to work on them when you are not available. Sending a document as an attachment to an email is just asking for trouble. All doc suites have tracking enabled, so you can see and undo changes.
  • Things you need input on need to be accessible to the people you want it from. A shared document that requires the person you want to collaborate with on to request access is at least an 18 hour loss. When sharing, it is imperative to ensure the share is available.
  • Any meeting should have notes of the most important points and action items for the people involved and the ones who couldn’t make it. It’s adorable that we have video recordings of meetings but nobody wants to scrub through and hour of video without changes.
  • Anything only mentioned in conversation might as well be lost. Ensuring that there is a written proof what was said and done is a great way to avoid confusion. Having a note taker in meetings is incredibly useful.
  • Keeping the banter to a minimum is great. There is nothing cute about sitting at 10pm in your office listening to your colleagues talk about the latest local sports event or any other thing only applicable to your office.
  • Explaining acronyms can help avoid a lot of confusion. Having a resource to point people to what certain acronyms mean in your company is excellent. Things can lose meaning across different cultures.
  • Connection requests are only working when they are detailed. “Contact Jessica in the $xyz team for more info” is so much more useful than “The $xyz team does that, you should contact them”.
  • Communication requests should be as detailed as possible. “There was a date and time missing for the meeting and where should we host the document” is useful when you get it at 8pm. “Can you quickly jump on a call” is not. It is terrifying.
  • Anything vague can easily sound ominous and sinister when you get it in the morning or late in the evening. Keeping the need for a meeting without a doubt and explaining expected outcome helps people start the meeting calm and focused.
  • Having fallback contacts is a godsend. “Hey, I need this from you. If I am not available, Jeff (email) or Jessica (email) know about this, too, so I copied them in here in case I am not available”
  • Setting an OOO and your status on Teams/Skype/Slack makes sure people don’t get a false hope that they could ask you something.

How !important are we?

Tuesday, May 28th, 2019

One of my favourite parts of CSS is the !important exception. It is a wonderful metaphor of the oft cited problem between CSS and JavaScript developers.

  • As a CSS developer, you know to avoid using it. It makes things too important and hard to overwrite.
  • As a developer that has to write CSS and doesn’t want to look deeper, it is the way to make CSS do what you want it to.
  • As a CSS developer finding it in a code base, it means someone wrote it that probably shouldn’t have.
  • As someone who doesn’t know CSS as all, !important means “not important”.

And this is what I want to write about today. What is important and what isn’t? I feel we lost our ::focus.

I’ve spent the last 20 years on the web as a professional. I built products, contributed to libraries and tools. I wrote my blog, talks and recorded screencasts. I helped others do the same. Through all this time, I thought of my efforts worth-while as the open web is an amazing thing to support. I love the web. I love how it empowers people and gives them a voice. I love how it gives people a new chance for a second or third career when things didn’t go as planned.

But I am tired of the constant bickering and false sense of importance we still have as web developers. When you open any social media channel these days you encounter all kind of fights:

  • JavaScript vs. CSS
  • Frameworks vs. VanillaJS
  • Brevity vs. maintainability
  • Tooling vs. low barrier of entry
  • Client vs. Server vs. Isomorphic
  • Mac vs. PC
  • Native vs. Web
  • Mobile vs. Desktop

We love to bicker about what people use and how they build things. We discuss what colour scheme they have in their editor of choice and which one is the most professional. We stay in our bubble and poke at each other and its walls from the inside. Not realising how petty and weird this is. Sure, it is rewarding to talk to your peers and find flaws to improve. It is also easier than talking to people who aren’t us. Or doing a reality check on what people use the web, mobiles and computers for. What is driving people? What do they expect from our products? What is a real issue, and what is a straw-man we keep erecting to tell people off for not following “best practices”? And – even more important – how much of an impact do we as frontend developers still have? Are we trying to optimise our own little world to the n-th degree as we don’t want to admit that we are not running the show?

Let’s recap how amazing the frontend world has become:

We should be high-fiving and congratulating each other on how far we’ve come since we wrote in textpad and FTPed our files to a live server. We should be concentrating on making this community better, more inclusive and welcoming. We should improve the tools we use and contribute great ideas from the past. Sure, it is frustrating to seeing a repetition of old mistakes. But didn’t we also learn by trial and error? It seems presumptious to expect people to learn our wise ways before creating something. And it is downright deluded to think developers hired to create a product get the time to really learn the craft first.

Instead of celebrating how far we’ve come we seem to be still in some weird competitive mode. When people release the smallest amount of code they use, we rejoice in throwing out truisms at them:

  • “This doesn’t work if the data you put in isn’t perfect!”
  • “This doesn’t perform when you have a lot of data!”
  • “This could be written much shorter!”
  • “This doesn’t work in old browsers!”
  • “This should be done in technology x and you use y!”
  • “This is not accessible!”

These are all excellent points and a perfect product should have considered them. On closer inspection these are knee-jerk reactions designed to make us feel good. Do any of these stay applicable when you look at the context of the product? Or are they a perfect scenario we keep chasing as our end goal? Shorter code that is harder to read and maintain might not be the best idea. What does “this is not accessible” even mean? To whom? Under which circumstances? You can easily remove one barrier for a certain disability or condition and involuntarily create a barrier for others.

There are no winners

If you zoom out far enough, you can always make a true statement that makes the original creator look bad. And you look clever and caring about the web and people. You win. But who loses?

We all lose in the long run. The original creators lose as they get painted as people who don’t care or didn’t think it through. Spectators, especially people new to market, also lose. Their first impression is that anything public is ripped to shreds. That can discourage them to show their work – something we always cherished as a part of the open web.

I’d go as far as saying that even you don’t win anything. Yes, you appear the better person, but you also get discouraged by everything you see. You don’t feel like a part of a group of professionals that evolve over time. Instead you feel like you keep having to repeat the obvious as people don’t listen or try to get better.

The odd thing is that we don’t even realise how much time we spend complaining about the work of others. Time we could use to do things, to create things, to learn things. Time to encourage others and to give feedback to prevent mistakes from happening. It is a spiral of unhappiness and “it could be so much better” thinking. It is not fun being the person who knows better and sees mediocrity wherever you look. It is also called being a snob.

The web is a mess

There is no doubt that something, somewhere goes wrong. It is baffling to see that even with the amazing stack of tools and development products the web is a total mess.

The web is slow and big. According to a research by Katie Hempenius based on HTTPArchive, 90% of desktop web sites load 5.8MB of data.

To make matters worse, this is an upward trend.

It doesn’t look rosier when it comes to accessibility. A research by WebAim that the one million most visited sites have glaring accessibility issues.

results of the webaim research detailing the failures of websites, ranging from low contrast to empty buttons

Add to this the almost weekly reports of data leaks and security problems on the web and we have something we should be pretty angry about. This is not the web we want. This is not the web we talk about when we bash “best practices” around each others’ heads.

Where do things go wrong?

A lot of talks and publications currently lament the over-use of frameworks. We talk about developer convenience overruling quality and performance of the final product. And there is of course something odd about using a 2MB JavaScript framework when the final product is a static page.

This is most of the time not the fault of the developers of these products, though. We love to paint the picture of the arrogant code-bro. A person who wants to always use the newest and coolest with plain disregard of the end user. But I am not sure that this group is as big as we make it out to be. Or maybe the few that are there are loud and annoying enough to become a distraction.

We actually don’t have much insight into what caused a product to be the way it is right now. And often we over-estimate the value we as web developers have in this. Yes, in 2001 it was up to the web developer to care about browser compat and clean markup. But even then we didn’t have full control over what ends up in the browser. Often we didn’t have to battle the browser, but the shortcomings of the CMS or framework used to render out HTML.

And this has not changed. When we talk about the web at events, in magazines and blog posts we often make the assumption that we control our stack.

How we perceive the web to be, HTML, CSS and JavaScript

In almost all projects I worked on in my career things looked different though. Many other players are part for the creation, deployment, publication and maintenance of our products.

How many more people are really involved in creating a web sites

A third party web

This is obvious when we see that one of the biggest offenders when it comes to performance of web sites are third party services. Often these aren’t added by the original web developer, but by all kind of other players. Marketing, DevOps, SEO, everybody has a special toy to add to the page. As Paul Calvano of Akamai discovered 27% of web sites are 90-99% third party content.

Patrick Hulce has an excellent interactive visualisation of this data at third party web today.

Third party code size visualisation

How much do different 3rd party scripts affect page performance? Based on HTTPArchive and Lighthouse data the median is 199ms extra, the minimum 47ms and in the worst cases third party code add up to 3 seconds of delay to the page rendering.

An assembled web

The web of today isn’t crafted by hand but assembled from existing building blocks. I’d go even further and say that this has always been the case, and many enterprise sites running on non-optimised framework and CMS output back me up there. Now have more sophisticated building blocks and they tend to get hungrier on resources year over year. If it runs on our fancy phones and laptops on fat connections, it is good enough to ship. This should worry us – and it does – but the market has moved on.

Sadly the focus of many a web product these days isn’t accessibility, performance, security and interoperability. It is getting the thing out as soon as possible. First to market beats quality and maintainablity on any ledger. As we assemble our products from building blocks, they become discardable and replaceable when the next cool toolchain comes around.

We have a plethora of packages, libraries and frameworks to choose from that make our lives easier. If your focus is to cut down on engineering cost and to roll out your product as quickly as possible, using them is a no-brainer.

A victim of it’s own design

The web is a great platform to not care about quality. It is defined as forgiving to developer error – it is one of the main design principles of HTML.

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

Browsers aren’t allowed to break the web. We have decades of ill-advised browser competition on platform rather than UX features that created non-standard APIs live products rely on. That’s why browsers render non-standard code and will have to keep doing so. These are not only cruft, but also security attack vectors. Browser makers are busy keeping the web from breaking. And we can’t stop developers from being sloppy.

The dire state of the web, however, is affecting the business model of web based companies. And the solution, it seems, isn’t to ask the wise old sages of the web for advice. It is piling on more technology solutions. Most end users have some blocker running that gets rid of unwanted trackers and ads. Chrome is considering a never slow mode. Webkit has a similar idea considering limiting the amoung of JavaScript a site can load. And, of course, there is AMP as the nuclear option to replace the slow web with a set of components.

Maybe the important thing is contributing to what people use?

I am not giving up on the web. It is too good a thing to waste. But it is time to face some realities that we’ve become disconnected from what the state of affairs is when it comes to the creation of web content. I love that we have fire and brimstone talks and publications about how horrible we are to the next users of the web with the things we create. But I want to see more sensible contribution and communication to the outside. I am currently working a lot with enterprise developers, people who have a 9-5 job and don’t have time to stay up-to-date. What they do, however, is build products millions of people rely on. It is pretty rewarding to introduce these people to simple tools and workflow optimisations. As Chris Coyier put it, we have a lot of tools in our editors and browsers to create a make it hard to screw up driven development flow. Most of the tools we blame for making the web horrible are open source. So let’s talk to the maintainers of these products and contribute a few small things that can make things better.

It is not anymore about knowing everything about the web and define best practices nobody follows. It is about understanding that the web is a rendering target and getting there as quickly as possible with the least effort is what sells it. I see the web as plumbing these days. We don’t care how the pipes in our houses work, as long as there is water when you open the tap. Only when things are utterly broken, we start wondering what happened. Then you call a plumber to fix it. Web developers are not the creators and drivers of the IT world. Maybe being a good plumber is a thing to consider. And this means we don’t only deal with clear water, but have to start wading through other things to make sure people will get things safe to consume.

When it comes to our online communications, I deliberately step away from in-fighting and Twitter threads. There is much less gain there than going to the source and comment where people write re-used components, libraries and products. We have the channels to make things better at the source. And that’s important.

AI and ethics keynote at Azure Saturday in Munich (video, slides and resources)

Wednesday, May 22nd, 2019

Last weekend I went to Munich to give the opening keynote for the Azure Saturday hosted in the Microsoft office. I was asked to give an overall intro about AI, what we should be worried about and how to embrace this new technology without locking people out or endangering them.

The video recording is on YouTube:

The slides are available on :

View Creating Human interfaces with AI on Notist.

I’ve collected all the resources I talked about in this Gist :

A checklist for more inclusive, accessible, measurable and understandable talks

Tuesday, April 23rd, 2019

Chris Heilmann presenting

I’ve spent the better part of the last seven years presenting at all kind of conferences, meetups and client meetings and I’ve learned a lot along the way. I learned about different needs of different audiences and how to prepare your talk to make it as easy as possible for organisers to work with you. More importantly, though, I learned how to ensure that my presentations can be understood, don’t offend and work in even the worst organised environments.

In order to share this knowledge, and to remind myself of the necessities I put together a checklist to fill out before my talks. Not all of these bits are applicable to the talk you may give, but it is a good reminder of what you can do to help others understand what you do. And to make sure you can show your company what you did.

I hope this helps!

Getting started with Javascript – The right tools and resources (Video Interview)

Thursday, April 18th, 2019

A few weeks ago I was in Paris, France to visit Prismic and they interviewed me about the JavaScript vs. CSS debate. In 10 minutes we covered a lot :).


Here is a verbatim transcript of what we talked about:

Hi, Chris. We are here at Prismic, very happy to have you there. Could you maybe first introduce yourself?

Hello, I’m Chris. I’m a principal software developer at Microsoft, and I’m dealing with all matters web there, ‘cause I’ve been doing it for 20 years, and I love the web.

Okay, you also love JavaScript, I know that, and I’m sure you interact a lot with JavaScript developers, so I’m curious to know, like, where would you recommend someone who wants to learn about JavaScripts, to go and learn more about it?

The problem is, nowadays, there’s far too much JavaScript it’s overwhelming and everybody has a different opinion of it, so you actually have a lot of resources that are outdated, some of them that seem to be simple, so there’s a few things that source of truth that I love to use. One of them is the Mozilla Web Docs, MDN Developer Network, used to work on that one when I worked at Mozilla. That one is an up-to-date information that is actually everything about web technologies, is it CSS, JavaScript? And every time you wanna lookup some JavaScript that is a great way to look up. You can even do that in browsers when you do MDN and space and then the JavaScript that you wanna look, it automatically gets the results from MDN back so you don’t have to go through the website and do it there. Another very interesting thing is is a website that allows you to say something, technology that you heard about, and say which browsers and which environments support them.

So if it’s safe for you, in your case for your product, to actually use these already and also links through the documentation of these things links through the problems that they may have and links through the W3C standard that is actually their source of truth for everything but it’s not as easy to understand. So these are the main resources that I think are a great way for people to get started. And of course look around for videos on YouTube and conference videos because all of them are available for free. Every conference spends a lot of money producing these things and giving them out, so it’s kinda weird ‘cause people watching this right now so this kinda matter. But look at these resources and make sure you look at the date as well ‘cause some of them get outdated rather quickly, but something like MDN the great thing is it’s not a Mozilla product, it’s basically an independent product that people from Microsoft, Google, Apple, Samsung, whoever is doing something on the web are contributing to that one. We realize this is the one resource. We want to keep up-to-date, so this is a great place to start.

Okay, cool. So once they have looked this knowledge, where should they start, which tool should they use?

Once you have all this knowledge you would in the 70s and you don’t have to work anymore because it’s a lot of knowledge to take in. But knowing where to go is always a good opportunity. I find the most important thing right now and the most biggest change for me as well, is that how tooling has become so much better than it used to be in the past. In the past we had an alert to basically say when something went wrong in our JavaScript and that was not fun. Nowadays every browser comes with developer tools. There’s Chrome developer tools, there’s F12 developer tools, Safari’s, Firefox’s, they all differ a bit to a degree but they all give you lot of insight of what you’re doing and what you’re doing wrong. So instead of getting the old error messages, undefined is not defined which is not as helpful. You nowadays have a console in every browser that tells you what went wrong. And sometimes it’s even crosslinked to the MDN documentation that you can click on and know why something went wrong. So knowing these developer tools in the browsers, in and out or at least basically, is a very very good start for you because you know what you’re doing and you don’t need to go anywhere else. You can actually start writing JavaScript directly in those. Another great thing to get into is using interactive playgrounds on the web like: JS Bin for example, JSFiddle, CodePen, just a few others, StackBlitz and these kind of things. CodePen is a beautiful beautiful example because it has documentation, it has articles and it has code examples. So what these things allow you to do is write a code example when you run into a problem and send it to other people and they can then see what you’ve been doing and help you fix the problem in context rather than you having to explain to them what you did wrong. You can do live coding together with each other in these kind of environments. So for trainings and for schooling courses that I do, these things are beautiful to see. So getting to know these kind of environments and CodePen is full of very creative code examples so that’s a beautiful thing. If you’re just a visual learner, this is something to get very excited about. When it comes to setting up your environment I think Visual Studio Code is the editor that, of course I’m kinda biased because I work with the thing and on the thing, but it’s also a product that allows me to write code and learn what I’m doing wrong while I’m doing it. So there’s linters built into the systems, so linting means, while I’m typing something it tells me By the way this is wrong and here’s why. So much like the squiggly lines in Word when I’m writing something telling me I mistyped this, it’s the same happening in JavaScript. And the other thing it does for you is a lot of code insight so you don’t need know every keystroke but you actually tells you, you wrote these three letters, you probably want to write that long word now. and auto-completes it for you and the only one that can come after that is that one and so on and so forth. So it made me a much more effective developer and it’s lightweight, it’s open source, you can install it on Linux, on Mac, on Windows and you don’t have the problem that you had before like the editor had some similar functionality were like 12 gigabyte downloads and that’s not fun to do as well. So that’s one of the things I would be considering because it’s a beautiful experience of learning to become a better developer while you’re programming. Not reading up on it and having to know everything before you’re doing it. The tooling we have nowadays with developer tools and the browsers and editors like Atom or Visual Studio Code is that they do this auto completion things for you so it teaches you new things while you’re typing and you’re actually experiencing code as an adventure.

Okay, and one last question is, what would you start with like as your first project?

Whatever tickles your fancy, whatever makes you happy. I think products that come out of passion, things things that are something that you always wanted to build for yourself are the best things that are out there. You don’t want to start writing Facebook, that’s probably not a thing you’re gonna do in the weekend. But something you’re already excited about and you always wanted to play with is a great thing to get started with. One of the main things that I think are education space is not built on that kind of environment yet, it’s like, here’s a very very weird thing to do, Let’s find an algorithm to do that kind of thing. Solve your own problems and if that’s a to-do list for your things, if it’s organizing your kitchen, if it’s something you always wanted to do, if it’s finding out why the planes are not right at this moment. Friends of mine live on an island where there’s lots of ships coming in and they actually wrote themselves an app to learn code, to know when a cruise ship is coming in because then it doesn’t make no sense for them to go to town because it’s gonna be full of tourists. I guess Paris has similar things so that might be an app to start with kind of thing. Programming is there for us to do tasks that we are bored of as users. Computers are there for us to do the things that we humans would be bored doing. So find something like that that makes you happy and that way go out there. If you wanna learn new programming as well, you wanna learn JavaScript, there’s lots of good courses out there to get started with. But don’t get overwhelmed by the seemingly complexity of it. You can have tools nowadays that get you every step on the way and it’s in an interactive fashion and not, oh, you’re stuck here because you don’t know. The information is free and the tools are free and that’s why this is a wonderful world right now to learn web development.

Okay, cool. Well thank you very much for being there.