The One Who Created His Own Path

As a lead developer on some of the largest web products created by Yahoo and Mozilla, Chris Heilmann learned that knowledge is not enough without good teamwork and a seamless handover. The author of the Developer Evangelism handbook and several books on JavaScript, Heilmann is currently Program Manager at Microsoft. For Behind the Code, he discusses how it all started with programming, how he more or less invented the role of developer evangelist, his experience of working for Yahoo, Mozilla, and Microsoft, and the scourge of JavaScript fatigue.

Combining computer and journalism experience

I always liked computers as a hobby, and would write programs at home on my old Commodore 64 and Amiga. I wrote a few games as well, and I tried to sell them, but that didn’t really work out and I realized I needed a proper job. So when I finished high school, I asked the local radio station if they needed anyone who was happy to talk, and they found me a job. So for the first 3 months I worked for free and was a pizza-delivery guy at the same time to make money.

And then, after two years at the radio station, I realized the Internet was becoming mainstream. So, in 1996, we started using it at the station to get news from news agencies, and that sort of thing. This meant I ended up combining my computer knowledge with my journalism knowledge, which was kind of like web development back then, because you had to create code and publish it. So to me, when the Internet started getting going, it was not only about consumption but also putting yourself out there, collating news and putting it on other sites and that sort of thing.

Teaching to learn

When it comes to learning, that’s where education comes in, that’s where teaching comes in. Because once you write your own first blog or, even better, when I wrote my first book, I had to learn what I was doing—what I was already doing without thinking about it. But then I had to understand it, because people were asking me all kinds of questions about my work, and so I didn’t have an excuse any longer, I actually had to learn. So the best way to learn something is to teach it.

And the web makes it so easy. In the past you couldn’t just go to a school and say, “I want to be a teacher,” as they would have said, “Well, where’s your diploma, where’s this and that?” But anybody can go online and put a course up on YouTube. Or anybody can approach companies such as Skillshare or Pluralsight, or whatever, about doing courses. It’s a big market out there. And I think when somebody feels like they’re struggling to learn something, they should try to explain it to somebody else.

Joining Yahoo because of its open approach

Throughout my career, it’s always been one person making the difference. At Yahoo it was one person who said we’ve got to be more open, we’ve got to hire more people, we’ve got to allow our people to talk more about what they’re doing. Because, previously, Yahoo was just like, “Keep the website running, don’t talk about it.” But then they started open-sourcing a lot of things, such as our user interface library, they allowed people to have developer blogs, they wanted to reach developers through the brand Yahoo rather than just the end users. So that’s where I came in and that’s where that team started.

And the best thing I liked about Yahoo was, through my blogging and through going to events and meetups and that kind of thing, I met a lot of people who I wanted to hire, who I wanted to work with. The team at Yahoo UK was ridiculous. Between its 21 members I think we had written 45 books. They were all experts working on the biggest website in Europe at that time and also starting new projects—Yahoo Answers came out back then, which was something we started from scratch after looking at the source code. So that talent pool was ridiculously good.

Developer evangelism as an alternate career path at Yahoo

It was kind of weird because, being lead engineer, there was nowhere to go. The career path was you’ve got to become a manager now—not that you’re not allowed to code, but you don’t need to do it any longer, you should have a team and look after them. So that’s what a normal career path in IT is. And at that time that I didn’t want to give up programming or talking about programming, so I more or less invented the job of developer evangelist and wrote a handbook about it in 2 afternoons and got it published. And that was basically to convince my managers to give me that role and to initiate that program within Yahoo. So that’s how that whole thing came about. The transition for me was pretty natural because I didn’t want to be the person who writes the same code they’ve been writing for 10 years. Rather than doing everything myself, I wanted to empower people to be allowed to write the code they want to write and not the code that somebody else has decided on.

So, what a lot of people don’t understand is, back then, having an evangelism team, or a devrel team as you call them now, or dev advocacy team, was very important so that you could show the company how much comes out of having that possibility and how much you empower your engineers to do something different. Hiring people is incredibly hard. Having a product out there that people are using, like a library or something like that, makes it a lot easier, because people already know what they are going to be working with when they come into the company. So having to spend three months training new hires is basically done away with because they know what they’re doing when they come in. So it’s a great way to get new people in that are already experts in your product. But doing that needs people who are very good at explaining and at getting people excited about it, because otherwise people will use one of the many other products that are out there. You want people to use your product when you open-source it as well. And that’s why creating a dedicated evangelism team was a very, very important step.

The difficulties encountered as a developer evangelist

I think the biggest problem was making sure you didn’t antagonize the rest of the engineering team and leave people feeling like, “You talk about the stuff that we do but you don’t do it yourself—what’s that about?” So it was very important to make sure that you kept explaining to people—“I do that for you, and whatever you need sorted out, please tell me about it.” So I spent more time in meetings to make sure engineers had more time on their hands to experiment and try things out, which meant that not everything became a product anymore. Introducing opportunities such as hack days or hack weeks, during which engineers are able to do whatever they want rather than whatever their manager tells them, was part of this as well. So the barriers were upper management understanding why they should allow that, why they should spend money on that. But the big answer there was, “It will make it much easier to hire.” And for the engineers in the company whose attitude was, “Why aren’t you coding?” or, “Our bug list is so long, why aren’t you actually fixing bugs?”, I could respond, “Well, actually, I’m sitting in meetings with management averting decisions that would mean a lot of work for you.” So that’s the kind of thing you had to be prepared for back then.

Developing the Mozilla community

I was at Yahoo UK for 4 years, but then the UK office closed down and they asked me to move to America again, but I didn’t want to. So I stayed in Europe and started working at Mozilla, where I stayed for 4 years, working mostly on the documentation part of the web and also on Firefox OS, the operating system, to a degree. The problem that we had at Mozilla is that we were trying to take on the Googles of this world, and the Amazons and the Microsofts, and they had so many more people. Mozilla was a small company back then. So we wanted to make sure that we had a presence at all events and meetups and at universities. But we didn’t have enough people to send out. I was on the road practically every week, and it was too much. So we realized we needed to do something. The great thing that Mozilla has is its huge community of volunteers—hundreds of thousands of people, and worldwide as well. So instead of me flying to India to give a presentation and not being able to answer anything, we first started looking for people who worked for Mozilla in India and said, “How about we teach you how to become a presenter and we give you the materials, we give you the training?” Or if we couldn’t find anybody to do it, then we would approach people in the community and say, “Hey you’re a representative of Mozilla, how about we teach you to actually be able to say the right things and not just come up with random things that you hope are right?”

Daring to experiment at Mozilla

Mozilla has been open from the very beginning. It’s a not-for-profit company. It’s actually not supposed to make money—it’s not supposed to make a loss either, but it’s basically not there for profit—so the idea was you were much freer to do what you wanted. So we could experiment much more and create things that are great for the open web but have no financial benefit. There were lots of things that we experimented with and shut down again. The open web became much better because of what Mozilla does, and did back then as well.

Firefox OS is definitely that thing. That we brought an operating system for mobile phones based on HTML 5 created a lot of new standards, such as video-streaming standards, and geolocation was this weird thing that became a very important thing. Anything to do with hardware acceleration of something like CSS came kind of out of that research, because we had to make things work on the most basic of mobile phones, on the cheapest of devices, and still rendered quickly and gave people a good experience. So writing something like a keyboard for mobile phones in HTML 5 spawned a lot of good new standards. Things like interaction of servers, like knowing when something comes onto the screen rather than hoping to know whether something has come onto the screen. A lot of the W3C and WICG standards that are now part of HTML 5 came out of that research. So while it was not a commercial success, it was a very daring thing to do and people learnt a lot from it.

Microsoft’s challenge to reach a broader audience

I just reached the limit. I was like, “OK, I’m talking to the same communities over and over again. People are pleased for me to be the Mozilla person talking about open-source things, but where do I go now? Where is the biggest problem of the web right now?” And that was still the Microsoft thing, that we had lots of old browsers, Internet Explorer, dependencies. And Microsoft tried hard to reach the open community and get people involved in their open-source products, but nobody wanted it because they didn’t have anybody to relate to. And when Rey Bango—my former manager who I worked with at Ajaxian, where I also blogged—hired me at Microsoft, as well as Aaron Gustafson, the third person who was part of all that web standards work we did… When the two of us got hired, people were like, “Oh my God, Microsoft is really taking this seriously, they want to do open-source things,” because they knew I’m not someone who would stay somewhere if I don’t like what I’m doing.

It’s been 4 years now and I haven’t ever felt, “OK, I’m not doing anything worthwhile here.” It’s like, so far, everything I’ve done is similar to what I did at Mozilla, but with a totally different audience. I can reach those developers who don’t go to events, I can reach those developers who don’t blog or don’t care about blogs, they just do their 9-to-5 jobs, and I can make them learn about cool new things through channels that only reach them. And that’s something I wanted to do, and it was very satisfying to take that open knowledge and introduce it to people who are not that interested in open yet.

Prejudice toward Microsoft

The larger problem I found was the prejudice that Microsoft has faced over the years, with fanboys of other companies saying the same things over and over—tired old prejudices about things the company hasn’t done for 20 years. And my response is, “OK, you say you’re open, you say you’re interested, why don’t you look at the facts about what’s happening now, instead of just shutting it down?” Other companies, such as Google, have the same problem—basically people have a misconception of the company as a whole and then won’t look at any of their products.

Finding best practices rather than defining them

A lot of we learnt, and what I learnt very early on about this, is that best practices are not defined but are found. So we looked at how we actually build products, what was working, what made us more efficient, what actually made our end users happy as well, what made the product more accessible. And then we would document it and say, “OK, here is something we found and think should be a best practice, and here is why.” We wouldn’t just say, “We should be doing this because somebody on a blog said that’s what you should be doing.” We always made sure that when we put something in place that it had an effect. And there was a big clash between engineering teams, especially in Europe and in America. In America, a lot of engineers back then were like, “Let’s make the thing that is the best-performing thing, and make it that way and force people to use it.” And our case was always like, “You cannot force anybody to do anything.” We felt it should make sense more than anything else. There were ridiculous things back then—people demanded we should alphabetize the attributes in the HTML element so that it would pack better when gzipped on the server. And I was like, “I’m not going to reeducate 400 of our engineers to alphabetize these things. Instead, how about I write a script that goes through the HTML and alphabetizes it and then gzips it?”

So instead of forcing people to switch to a certain coding standard, I started writing tools for that sort of thing, writing scripts for that and processes on the server side, or the publication side. It was about making things as effective as possible by allowing developers to do what they do best, but then making sure that their work was readable by other people as well—a much better investment than forcing people to work in a way they don’t feel comfortable with. And that’s a big thing. Every new engineer that comes to a company comes with a lot of great ideas. A lot of them come with weird ideas as well, but that’s also fine. I’m not hiring a number, I’m hiring a person, and that person has to be effective in the team.

And what I also started doing very early on in my team was to make people do presentations to other parts of the company, to the rest of the team. I introduced lightning talks back then, which we held 15 minutes before lunch breaks. The format was to talk for 5 minutes about a problem encountered in the current job, the product currently being worked on, and then 5 minutes on the solution that was found, either in a programming or process sense. And then there would be a 5-minute discussion about whether we should turn it into a best practice, if we should document it, or if it was a one-off and not worth applying to all the other products in the company. So this was a very powerful way of getting the team involved in best-practice documentation, and the best-practice process as well, rather than just saying, “We’ve got a new process, you’ve got to follow it,” because people are not going to do that.

JavaScript fatigue

JavaScript fatigue is a weird one, because it is not necessarily about the language itself but rather the infrastructure around it. So people are very annoyed that having a simple website means 5 megabytes of JavaScript being downloaded because of people using 15 different libraries. I think it’s an interesting one, because JavaScript fatigue—and I think the term is 4 years old now—is changing slightly again, it’s becoming a space where the framework developers and framework communities are starting to listen more to standards people and best-practice people. They’re avoiding making their products look like this horrible behemoth of monolithic code that needs to be downloaded just to get something.

I think we are in an interesting space where the language itself has been standardized so much that it actually does a lot of things that libraries were only able to do previously. And browsers, and also engines such as Chromium that run inside Node and Electron, can do things that we needed frameworks for previously. I’m actually kind of annoyed about the rhetoric surrounding JavaScript fatigue. There are a lot of standards people who are super-angry about it and paint everybody who uses a framework as a horrible person in the web community, because basically, like, “If you use a library, then somebody in India is not going to be able to use your website because it will be too slow to download.” It’s a great argument and, yes, totally understandable, but then help those libraries become better. Help those libraries do server-side rendering rather than client-side rendering, and then it will even be good for those markets because the caching happens on the server side. So there was this situation where people were at loggerheads, where the JavaScript-fatigue thing was happening, because people were feeling overwhelmed. But with the proper tooling and documentation, we can get past JavaScript fatigue.

One big thing we’re working on right now is webhint, a hinting tool, a testing tool for the web. So you can put a URL in there and it tells you what’s wrong with it, how your server is set up the wrong way. And it also ties into how your whole stack is set up. So if you use webpack, if you use React, it analyzes what you’re doing there as well. And if you create far too much code for what you want to do, it flags it up to you and says, “By the way, this is 5 meg of JavaScript that could be 500k.” So I think one of the big things that I am investing in right now is to make sure that the tooling prevents us from making mistakes rather than just telling us we made mistakes. So I hope that, in the near future, a lot of bad products that, because of laziness, have gone out on the web and caused JavaScript fatigue, and confusion, and that implication of, “You’ve got to understand everything or you’re not a professional developer” will be things of the past. It should be, “Hey, if you start with Visual Studio Code and you put these extensions in, you already know what you’re doing, you’re already there.” You use that as a tool for what it is supposed to be, a tool and not something you have to learn. So hopefully we are getting better, and I can already see we’re heading in the right direction.

Machine learning and automation of computing and the Internet

I’m very excited about the whole machine learning part of IT, and I’ve been working on that a lot within and outside the company. I’m advising the German government on topics such as ethics, AI, and automation in the workplace. There are super-exciting things, like autocompletion of your code that actually uses millions of lines of code from GitHub and learning from that to lead you to what you probably want to code next. I believe—and I’ve given talks about this as well—that the skill of programming, the skill of coding, is disappearing as well. It’s not something that we need to know that much anymore. A lot of products we’re building for our end users are very simple. People’s needs are not as complex as we think they are, so we could generate these things rather than write them by hand every time. I’m excited to see how automation in the Internet space and in the computing space will affect us in the near future as well.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by WTTJ