JavaScript and the Pressure to Knowing Everything, with Christian Heilmann

In this episode of the Versioning Show, Tim and David are joined by Christian Heilmann, well-known developer, speaker, author and Developer Evangelist at Microsoft. They discuss the pressure to know everything in tech, dealing with impostor syndrome, encouraging human growth in tech jobs, new perspectives on progressive enhancement, and avoiding the “happy path” in web development.

Show Notes

• Christian on Twitter: @codepo8
• Christian’s website: christianheilmann.com
• Christian’s YouTube channel
• Christian’s slides on SlideShare
• The Imposter’s Handbook
• demoscene
• From Christian’s blog: A great time and place to ask about diversity and inclusion
• Monica Dinculescu at CSS Day
• Say hello on Twitter: @mdavidgreen | @tevko | @versioningshow | @sitepointdotcom

Conversation Highlights

There’s a massive problem with people coming up to people like us in our positions and expecting us to know everything. We cannot even admit that we don’t know things, and that’s a very weird position to be in at times. — [3:40]

---

I think that we need a lot of empathy, that there are a lot of different ways to work in our market. I had a taste of all of them. I think everybody should work for an agency for a while, where you have to use all kinds of technologies continuously. — [6:30]

---

So, I’m like, Who are we building this for? Are we building these to give keynotes at a conference or are we building these to solve problems? I think that’s partly because people still don’t understand what we do and still don’t value ourselves as experts. — [7:30]

---

JavaScript is not turned off. JavaScript is just unreliable. JavaScript could not be loaded. JavaScript could be slow. JavaScript could be interfered with. — [14:00]

---

Demonizing JavaScript as the thing to think about is I think the wrong approach. We need to understand that JavaScript is a given. It’s everywhere. It’s in every browser. It will be available. There are scenarios where it will not be available and will go wrong, but these are edge cases that are not making sense to concentrate on.

We should much more concentrate on the fact that if we say JavaScript is a given, we also have the responsibility to make JavaScript work. Right now, we have far too many JavaScript solutions that are just using frameworks for everything or have a success case and never define an error case. — [15:00]

---

I think it’s not a one-off state, progressive enhancement. By definition, it’s progressive. We have a good opportunity right now to start owning our interfaces. It’s all about who has responsibility for the interface. If we say we’re doing it with JavaScript, then we also have 100% responsibility of what’s coming out to the end user. If we say we’re not relying on JavaScript, we might actually deliver a terrible, terrible solution for everybody that kind of works. — [18:40]

---

I hire people that are better than me. I want people to disagree with me in job interviews and make a good point of it. I want people to be better than me, because then I can do other things, and they can do the technical bits that I don’t think I want to cover anymore, and I want to change anymore. — [21:40]

---

We’re seen as very antisocial people. I think that’s something that we need to break. If we’re seen as the geeks in the corner that code stuff and we give them a lot of money so they shut up, it’s not helping our market at all. We need to be seen as people who are just people, and should be in every meeting and in every decision — not only in the final rolling out of the product. — [25:30]

Transcript

Tim:

Hey, what’s up everybody? This is Tim Evko …

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number 15 of the Versioning Podcast.

David:

This is a place where we get together to discuss the industry of the web, from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

Today we have with us Christian Heilmann, who we’re going to talk with all about a whole bunch of different things, because he does a lot of work all over the industry. We’re really excited. We’re going to have a great episode today for you. So let’s go ahead and get this version started.

Chris, thank you so much for joining us. How are you doing today?

Christian:

I’m good. I’m based in Seattle right now, before I go back to England. There’s a storm warning, so I probably will be stuck in the office for a few days, so we can record for quite some while.

David:

[Laughs] We’ll try not to keep you that long, but I’m glad you’re comfortable at least. Stay safe in the storm.

Tim:

One to two days, tops.

Christian:

Yeah. It’s going to be good. As somebody like me, a developer evangelist for years and years, I don’t feel anywhere I’m home anyways. It doesn’t really matter if I’m in a hotel or at home, so it’s just really good.

[Chuckles]

David:

Speaking of being a developer evangelist for years and years, since this is the Versioning Show, we like to start our show with a philosophical question for our guests. Your philosophical question for today is this: in your career, what version are you, and why?

Christian:

I think in my career I’m version 1.0, maybe 2.0 already. The reason is because I reinvented myself a few times. I was a web developer first … Well, actually 3. I was a radio journalist at first, then I found the web and became a web developer. When I was a web developer, I hit a ceiling really fast of realizing in our structures and companies, you can only get promoted to a certain level before you have to become not being technical anymore but go into management.

I didn’t want to do that back then, because I was too young and immature, so I invented the idea of developer evangelism, which is a transitional role between developer and the rest of the company. It’s a translator role. I wrote a handbook about it, and then I gave myself the job title. Then people realized it would be awkward to not give me that job title in terms of paperwork, so they had to do it. That’s what I was at Mozilla, in my last job as well. I was the principal evangelist there.

Now in the company that I’m working for right now, Microsoft, we have already a structure of evangelism. I’m feeling I’m going into a different world right now where I have a lot of peers that can benefit from my rogue attempt to do the same things that they’ve been doing for years.

I think the biggest thing about philosophy when it comes to our job is that you just be flexible. Don’t think that you will do the one thing that you’re very excited about now for the next 20 years to come. You can change a lot, and you will have fun doing it. It’s not that you’re losing something by changing. It’s actually making it more interesting for you. I’ve never heard of a job like ours where every year is different and we’re having fun doing it.

David:

It’s funny. We’ve talked to a lot of folks, and we’re finding that most of the people we talk to did not train to be the engineers and the roles that they evolved into. Sometimes your education has very little to do with what you end up doing. Certainly in our industry, things change very quickly.

Christian:

It’s true. I talked to Rob Conery the other day who just released a book called The Imposter’s Handbook, which is about people like us who are in high-level positions in IT companies but never went to a formal training, never had a computer science degree.

It gives you all the things that we missed out, but we should know, and people just expect us to know because we’re already on a certain level. There’s a massive problem with people coming up to people like us in our positions and expecting us to know everything. We cannot even admit that we don’t know things, and that’s a very weird position to be in at times. It was a good talk to him about the perils of being too known, and people just expect you to understand everything they say.

Sometimes people come up to me. I found a few JavaScript patterns. They come up to me and say Ooh, you’re the inventor of that pattern. It’s so amazing. It saves me so much energy and I love using it for this and that. I’m just standing there like, Oh, so that’s what it does. Interesting. I had no idea you could use it that way.

Don’t look too up to people in our market. We all cook with water, as you say. We’re all just faking along quite nicely. That’s what you have to do in a world that changes all the time like ours.

Tim[4:17]:

Speaking of inventing yourself and changing your career three different times like you mentioned before, how did you initially get into the world of web development?

Christian:

I started by finding the web when I worked at a radio station and I realized, Oh my God. In my free time, I did things on Commodore 64 and Amiga, demoscene stuff and these kind of things.

A few of those groups started having FTP servers where we put our stuff. And then, later on, we had mailing lists and IRC of course. Then we had websites, and I’m like, Oh cool. My company had internet access, so I basically started looking at these websites on that internet access.

I thought, “Hey, I can program in Assembly and in BASIC. I probably can do websites as well. I started looking at the source code, downloaded the HTML specs back then, which was like the zip file, and went to a hospital because I had to have an operation.

On a laptop, I wrote my first website, sent it around to a few companies in my hometown. A large car corporation found me and said, Ooh! You know HTML. How about we give you a lot of money to build our intranet. And I’m like, OK, that sounds OK. That’s when I started as a web developer.

I started at that company. After I had a big name like that on my CV, a lot of agencies started getting interested in me, and I started working in the agency market for a few years. I went to Yahoo as one of my big corporations. From there to Mozilla, and from there to Microsoft now.

I went through the whole agency field, and through the whole building things for smaller clients. I did a lot of content management systems, like enterprise-level content management systems. I think that also gave me an appreciation of what I do now — to understand what developers have to deal with, because not every web development is the same. People have different issues. It’s unfair to go to somebody who has to use a $60,000 content management system to tell them off for the outcome of their HTML because they cannot even control it.

I think that we need a lot of empathy, that there are a lot of different ways to work in our market. I had a taste of all of them. I think everybody should work for an agency for a while, where you have to use all kinds of technologies continuously. You always have to have like two months to learn it, and then you have to discard it because the next project works on another content management system or backend and these kind of things.

There you learn really quickly that the biggest task in our job is to learn quickly, implement and also discard quickly and find something new to work with — which sounds like a waste, but weirdly enough, that’s how our market works.

David:

It feels like the skill set that you have to develop is that ability to acquire something new and then be able to discard it comfortably and be aware that things are changing and you need to adopt something new … So that you don’t get married to one technology and become the one person who does this one thing, but you don’t know how to do anything else.

Christian:

I’m kind of worried about how self-serving we became in our market. The amount of things we invent to win Hacker News for a week and then … I’m busy in my job a lot so, I see something on Hacker News, and everybody gets super excited about it. I’m like, OK, when I get time next week I’m going to take a look at it. Next week when I find time to look at it, the first blog posts are all that, This is dangerous to use. You shouldn’t use it any longer.

So, I’m like, Who are we building this for? Are we building these to give keynotes at a conference or are we building these to solve problems? I think that’s partly because people still don’t understand what we do and still don’t value ourselves as experts. They just value us as people they don’t understand.

It’s very depressing to get praise for a project that you think was terrible, but it happens a all the time to us because we’re seen as a delivery part of a company. But we’re still not quite as understandable as a database architect is for example, or somebody whose technology has been around for 30 years in a proper educational way.

For web development, it’s still things like, Well, they use new things all the time. It’s OK if we hire somebody new and they just discard completely what the person did before and start from scratch. I’m like, Seriously, this is what we’re doing?

It seems like we’re getting more and more into a world where we’re just showing off to each other. It’s getting us more riled up than building real projects. I think we should go back to the stage where we think about what we deliver to end users out there, and how did we reach that, rather than how easy it was for us to develop it.

Tim[8:36]:

How would you say we get ourselves back to that stage? It sounds like this train is moving at such an incredible speed and everyone in the industry is trying to get out the next thing that is exciting and gets people’s attention.

What would you say that this industry can do to get us back on track as you’ve described?

Christian:

I think it’s partly being less greedy ourselves. Understanding that it’s not about how cool we are, but actually what we build for our end users out there. That sometimes means that you go outside of your comfort zone and say, You know what, I’m not going to write the next cool Node package management system. I’m going to find a contract where I work for a bank, or where I work for a website that I hate and I want to change that one. I want to talk to developers that work on these.

For example, what I learned being at conferences almost every week, going to conferences that are in the Mid West in America, or in Romania, or in countries where you normally don’t go, but not the cool conferences are, that’s where you meet the more interesting developers because they have to deliver day-to-day jobs.

When you have something in your talks that inspires them, you get emails weeks later about, Look, we implemented it and this is how much money we saved. I’m like, this is so much cooler than seeing Wow! You impressed me but I’m better than you. Let’s look at my stuff instead.

So I think it’s up to us to change the pace as well, and sometimes to say no. Sometimes to say, No, this is not ready yet. I’m not going to use it. We don’t want to use it with the old technology, but this is cool to use.

Also what I did at Yahoo and other companies is carve out time to be creative and to do things. We had internal hack days at Yahoo. We had internal presentations, lightening talks. I think it’s important that you separate your day-to-day delivery from your Where do you play with the next version of what you’re going to do?

We cannot do it in the live products — that’s just unfair to our end users. But we don’t demand enough from our companies to give us that extra 20% time for better or worse, to play with something like that, because our final products should not be a test run with our end users out there.

Right now, we’re at a weird weird position where people bend over backwards to hire us. No other market has that issue. When I go to my family, half of them are worried about their jobs. We’ll be like, Well, we’re worried about getting ten job offers a day. This is a very odd world to live in.

I wrote a blog post about this as well. If you want this world to change, then we should take this leverage right now and allow us to be deliverers in our company, but also creative in our development. More importantly, in job interviews, ask questions about what the human growth in these companies is.

Everybody says, Yeah, we got great perks and these kind of things. But ask things like, Hey, what if I become a dad? Can I work 4 days a week? What’s your maternity plan in this company? What do you do to get minorities into the corporation? What do we do about diversity in these?

We give keynotes about these issues, but where it really counts is when people try to hire us, because there we’ve got the upper hand at the moment, so let’s use that leverage to make our work environment less of a competitive environment that it is right now — one that we manage to be creative, but also allow us to get old in it, because right now it burns us out. We’re like the investment bankers of the 80s.

David:

That is absolutely true. Certainly I’ve seen a lot of job listings now from companies and recruiters contacting me and all of these things talking about, You get a chance to play with this new technology. You’ll be able to build things in this thing.

Often something that’s rather untested, or something that’s new and trendy, because they know that’s what’s going to attract the thrill-seeking engineers. I think that’s not really what people should be looking for when they’re looking for these jobs.

Christian[12:08]:

It’s good that the companies do it. There’s nothing worse than being stuck with one outdated environment, unless you’re a 9 to 5 developer and you’re totally fine with doing that and go home and have your life with your family. That’s OK to.

The untested environments and the random listing of cool stuff in job descriptions is always a red flag for me. My favorite is when they’re just wrong and they’re like, you could ask to get a five-year experience on a one-year-old technology. That sadly enough happens as well.

Again, I think we shouldn’t be arrogant about this. We should point these out. When we get job offers like that, we should basically say, I wasn’t interested, because of the wording of your job description.

It doesn’t help if you go on Twitter and make jokes about it. We should really point out that this is not appropriate as an offer to us. That way we can make job offers better as well.

Tim:

Chris, I wanted to get your opinion on the subject of progressive enhancement. What you think about it. What you think developers should be doing when they build software and web applications. What are your thoughts on that?

Christian:

I’ve been writing a lot about this — since 2003, or something like that. Even earlier, like 2002. I’m a very big defender of progressive enhancement as the best way of building something. It’s not even a technology thing, it’s an approach thing.

If you were to jump into a river, it probably is a good idea to understand that the river is deep enough and has no crocodiles in there. Instead, we just jump into rivers and say, Well, the crocodiles are probably not as dangerous and only freaks get crocodiles kinds off things.

Where it boils down to sadly enough right now is that our best practices are what we talked about in 2002, 2003. What progressive enhancement meant back then was saying like, Don’t rely on JavaScript at all. JavaScript is going to be turned off, and you cannot expect it.

I think this is not the truth any longer. JavaScript is not turned off. JavaScript is just unreliable. JavaScript could not be loaded. JavaScript could be slow. JavaScript could be interfered with. Its very nature means that it is not fault tolerant like HTML and CSS is. Both of those, make a mistake, doesn’t matter, the end user still get something. In JavaScript, one mistake and everything is broken. That’s the problem that a lot of people have with that language.

On the other hand, our best practices when it comes to progressive enhancement talk a lot about a world where we own a desktop computer with a fat connection, but we might not have JavaScript enabled, whereas our reality right now is that most of our users and certainly the next users that we’re going to get are going to be on mobile devices with a good browser with JavaScript enabled.

We can do great things with JavaScript nowadays, like with Service Worker and indexedDB and hosting things on the device itself that would allow us to have an offline functionality of the web, which we never had before. This was never an option. This needs to be an option, seeing how flaky connectivity in the mobile world is, especially in the countries where the growth is happening on the web right now.

Demonizing JavaScript as the thing to think about is I think the wrong approach. We need to understand that JavaScript is a given. It’s everywhere. It’s in every browser. It will be available. There are scenarios where it will not be available and will go wrong, but these are edge cases that are not making sense to concentrate on.

We should much more concentrate on the fact that if we say JavaScript is a given, we also have the responsibility to make JavaScript work. Right now, we have far too many JavaScript solutions that are just using frameworks for everything or have a success case and never define an error case.

We have to start thinking much more about the error cases of our solutions than about the success cases, because there’s nothing more frustrating than a bad error case in an interface. If I have a spinning button that doesn’t do anything, then I really really failed my end user. If I have a button that times out after three seconds and says, There’s obviously something going wrong. Please restart the app or please reload this app … That’s what’s happening on old Android devices if they get too heavy as well, the apps for them. This is nothing we should be ashamed of. We should be understanding that the sirens of progressive enhancement was always like, We don’t have any responsibility for the outcome because we test everything on the way until we get there.

The sad fact is that a lot of the things that we implemented in the web technology stack in between 2003 and now are not delivering to what we want to have. I had my mind open by Monica Dinculescu at CSS Day about this when she gave a talk about the input element. She was talking about how terrible it is and how broken it is.

I got very angry about this, because I like the input element. I thought it was cool like, if you have an input type range, if the browser supports it, it becomes a slider. If the browser doesn’t support it, it’s an input element where you just type something in. But then she pointed out just how broken is it across all the browsers that we’re using right now. Nobody complains about this, and nobody asks the browser makers to fix it.

A lot of the browsers you cannot for example style the thumb of the slider. It becomes too small to even use. The premise of saying like, if you don’t rely on JavaScript but you let HTML do its thing, everything will be fine, is already broken. This is already done.

The same way when people say JavaScript is not accessible, it’s bad for people with disabilities, that’s absolute nonsense, because 90% of the stuff we do on the web right now — if we do rich interfaces — need JavaScript to become accessible. Putting an ARIA attribute on a HTML element does nothing to talk to assistive technology. We still need JavaScript to actually tell the assistive technology that this ARIA attribute is there and that it’s trying to trigger something.

We have two factions — of old school people who still try to solve problems of like 12 years ago, relying on the functionality that the web doesn’t break because that’s how it was defined, which is true. But there’s a lot of mistakes that were made in between that we never fixed, like these input elements, and also security issues of the web like an input type.

A link with a target of _blank is a security problem nowadays, because the next tab has full access to the JavaScript of the tab that opened it. We need to use JavaScript to work around that security issue.

These are the kinds of things that people that are about the old school progressive enhancement would never want to know about or say is not an issue, whereas the newer people that basically grew up with JavaScript, and saw the web as something that’s just a given and never saw a browser without JavaScript, don’t understand that relying on it for everything without testing and without having a fallback is not a good thing either.

I think it’s not a one-off state, progressive enhancement. By definition, it’s progressive. We have a good opportunity right now to start owning our interfaces. It’s all about who has responsibility for the interface. If we say we’re doing it with JavaScript, then we also have 100% responsibility of what’s coming out to the end user. If we say we’re not relying on JavaScript, we might actually deliver a terrible, terrible solution for everybody that kind of works.

I think 2016 is not the year where we should deliver something that kind of works. We should deliver something that is beautiful and actually engaging to do, because otherwise people go for native applications instead or discard the web completely. Maybe the web is ready to die in the next five years the way we know it. It would be really, really sad, because to me, it’s like the only democratized medium we have out there that allows anybody to be part of it, regardless of disability, location or knowledge.

David:

There’s no question that the web is going to die as we know it in the next five years. What’s going to come along, and how it’s going to evolve, might still be called the Web, but it won’t be anything that we recognize. It’s the way that things seem to go.

I’m hoping that that democratized nature of open publishing that’s available now remains a part of what comes next. I’m interested in this — the way that you’re getting your message out to people — because you’re going out and you’re evangelizing this.

I’m curious what kind of feedback you’re getting, and how the community is responding to these ideas.

Christian[19:52]:

So far, I’ve only had good feedback. It’s actually right now — you said it before — the noise is ridiculous in this kind of fashion. I’m having a hard time following things, and I’m actually pointing this out in my next blog post as well that we’re just chatting about it, but we’re not really solving the problem. We’re not really starting to say like, OK, we admit the things from 15 years ago are not the right things any longer. We just have to find new ways of doing it.

It’s far too easy for people to give the same keynote they’ve given for five, seven years or ten years at one time, slightly updated with new technology. I don’t think we’re moving ahead as a market if we do it that way.

People are open to it because I come with a pedigree because I’ve been doing it for so long. Sometimes they may be afraid to disagree with me, which will be sad because you are happy to just agree with me in anything I do. I make mistakes like everybody else.

I think the problem is right now, we have hardliners. I think this should be over by now. These hard-lining fights, we’ve heard them for so many years. Most of the time they’re based on very blanket statements that don’t really make any sense any longer. I don’t think there’s a way of doing it.

The bigger problem is when me and other people who are open in the limelight, a lot of people assume that whatever you say comes with a massive background and a massive agenda. When you say like, Oh. You just said this because you actually want to discredit another person who said this, I’m like, I don’t even know that person who said that. Don’t put that in my mouth.

A lot of it is like people think that everything you say is very very deep and very very important, and you’re like, Well, I just want to inspire. I just want to show what worked for me and what didn’t work for me. I want you to think about that.

When I was hiring engineers, and I still do that when I hire people, I hire people that are better than me. I want people to disagree with me in job interviews and make a good point of it. I want people to be better than me, because then I can do other things, and they can do the technical bits that I don’t think I want to cover anymore, and I want to change anymore. People get excited about it.

Every new generation of developers should go through a lot of trial and error. This is how we made the web work right now. I don’t want to go through trial and error anymore. There’s other people that should go through trial and error. They have more knowledge of the current stacks, and that’s totally great for me.

Feedback is tricky, because at conferences, you get very polarized feedback. You get black or white. I wish that more people would listen to speakers at conferences, and when they’ve found something that worked, give them feedback two weeks later when they implemented it.

These are the stories that we really want to hear. Every time I go on stage, I’m still scared. I’m utterly scared. That’s good, because I don’t want to be complacent with what I do. I want to make sure that it was worthwhile. My main goal is to get somebody in the audience, to teach them something that they can go back to their boss and impress their boss with and get a better life after that. This is my job as a speaker. My job is not there for you to tell you that you’re doing everything wrong, and in my perfect world you should be better.

I think I should be there just to tell you, Hey, here is how it worked for me. Here are the great opportunities you might be too busy to learn about. We always talk about the bleeding-edge stuff because we have time to look it up, whereas other people have to do day-to-day delivery, so they can’t talk about the bleeding-edge stuff.

That doesn’t mean that you’re falling behind. It just means that you did the right job of going to a conference and learn about new things. That’s fine.

Tim:

So, if there was some sort of advice or warning or anything that you could leave for either the next generation of developers coming up or developers in general, you have an idea of what that would be?

Christian[23:32]:

I think the biggest problem we have always is that we underestimate the value of what we role out. The end user’s experience is the most important thing. What’s coming down the wire, how fast it is, how big it is, how demanding it is to the end user’s machine, is what we should be judged against. Sadly enough, we normally get judged against how fast we delivered something.

To break that cycle of being a fast deliverer, and being a quality deliverer, will help you later on in your career. Everybody is very excited going to junior developers and saying, Hey, I heard you can do this really quickly. Can you do it in two days instead of the seven days that we had in the project plan?

People fall for that. It’s rewarding, it feels quite good, but it will mean that in one or two years you’re going to feel burned out. You’re not going to have a career for a longer time in this market. So make sure that you invest in yourself — especially in your health, and your mental health, as much as you invest in the final product and what you use.

Don’t get too excited about making it easier for you as a developer. Make sure that the final product is better than it was the day before. Also don’t get too excited about comparing yourself to other people. Compare yourself to yourself, because you can always pretend that you have knowledge and sound clever on Twitter, but if you don’t understand it, then it doesn’t help anybody.

I’ve used JavaScript professionally, get paid for it for years. I learned JavaScript when I wrote my first book about it, because then I couldn’t pretend any longer. I had to explain it. Teaching and documenting and describing is probably the best way of learning things. Instead, were just like, Oh, learn it and use it.

Describing what you do to other people means you’ve written something that is very very simple and very good to use. So make sure that you check that skill as well.

We’re seen as very antisocial people. I think that’s something that we need to break. If we’re seen as the geeks in the corner that code stuff and we give them a lot of money so they shut up, it’s not helping our market at all. We need to be seen as people who are just people, and should be in every meeting and in every decision — not only in the final rolling out of the product.

David:

Very sound advice. No wonder everybody looks at you and thinks that you know everything.

[Laughter]

How can our listeners find out more about you, and get a chance to see some of the things that you’ve presented, and read some of the stuff that you’re writing?

Christian:

I put everything on my blog, christianheilmann.com. I got my videos on YouTube as well. All my slides are on SlideShare. They’re are also creative commons, so you can reuse them if you want to. I also allow people to download my things and reuse them. That’s basically my main trick. Whatever I gave out, I gave out as creative commons or as open source — so if I get run over by a bus tomorrow, my knowledge lives on. I think that’s a very important thing to do.

On Twitter I’m @codepo8 with an 8 at the end. That’s a very simple way to contact me. I will not be able to answer all the time. I’m incredibly busy, so please, if I don’t answer within a few days, I’m not angry at you, I just didn’t find the time because I’m somewhere in a hotel room or an airport or something like that.

I’m happy to discuss things and to go and help you present as well. A lot of my time right now is coaching people on public speaking, and coaching people on blogging, because I find that there’s an unhealthy competition of going up on stage and showing five hours of live coding that the audience then cannot repeat and didn’t understand but still are impressed with.

I think we need to be better as communicators. I think with my background in radio journalism, and going into this world, I had a good head start that way, because I learned that whatever I say on radio, nobody listens to. It’s like people do it on the side. They drive or they’re ironing or they argue with their dog or something.

I think we should partly think about the same way when we publish on the web. People are not hanging on every world that we do. Only the trolls do to try to actually quote it out of context. Other people are busy as well. Making your words count is a very important thing.

David:

Excellent advice. Of course, our listeners are hanging on every word here — not to troll us, because they know that we’re really good stuff.

[Laughter]

Thank you so much for making the time to come and share your knowledge with everybody out here on the Versioning Show.

Christian:

Not to worry. Be nice to each other out there. We are all humans. We all make mistakes. Make sure that you’re not discarding people just because you think they make mistakes.

Twitter is a terrible, terrible way to communicate feelings and ideas with each other. It’s a good way to get news out, and get people to try something out, but don’t be terrible to each other. Life’s too short for that.

David[28:00]:

Good words to end on. Thank you so much!

Christian:

You’re welcome.

[Musical interlude]

Tim:

One thing that always inspires me about Christian is how much energy he has. He seems to appear at every sort of event, and every sort of podcast or writing an article here or releasing a new thing there. It’s inspiring. It inspires me because there’s so much to do and so much to work on within this field.

I really enjoyed getting to sort of understand where he’s coming from, and some of the things that he’s trying to solve right now.

David:

I know what you mean. As I was researching him in preparation for this show, I was trying to get an overview of what he’s been talking about, and it is so broad. He goes CSS this and JavaScript that, philosophy of this, employment … He goes in so many different directions.

It’s hard to get a sense of, is there a single focus, or is this just generally the good of the developer community?

Tim:

Yeah. The range of technical topics are so impressive. There’s a blog post of his that I still don’t understand. It’s condensing radio attributes toggled on or off into binary via specific bitwise operators.

I read it once and I was like, Yup, this is the thing. All right, good. Going to just keep that in case I ever need to do this one day in my job. Other than that, this is totally over the head for me.

David:

I remember having a long conversation with some of my coworkers trying to figure out what is a practical application of bitwise operators in JavaScript. Ultimately I think we came out with calendering as something that could be a convenient use for it.

The thing is, most of the JavaScript engines are not optimized for it because nobody uses bitwise operators. It’s mostly a back-end kind of a thing, although nowadays with back-end JavaScript, I’m imagining that’s going to be more of an issue.

Tim:

Yeah. Right now, most of what I do is back-end JavaScript. There are probably applications for it, but I would probably run the other way if one of them showed up.

David:

We’ve got a whole audience full of listeners out there. Come tell us how you’re using bitwise operators in JavaScript. Impress us!

Tim:

Yeah, and please provide a thorough and detailed explanation so I can maybe learn it.

David:

Take Chris’s advice, and teach what you know. You’ve got this information in your heads, and clearly the two of us don’t have it. We’re not the only ones. There are people out there who will be pleased and impressed if you can share something useful.

What I like about that also, it’s something useful about fundamental JavaScript. Not something useful about the latest framework that may or may not be released in the next alpha version in six months. Something useful that applies across the board. It could be a really impressive thing to share with people.

Tim:

One thing I really liked when Chris was talking in regards to progressive enhancement was when he mentioned that JavaScript is this thing that we pretty much can depend on; that the whole goal of progressive enhancement is just to provide an experience that’s just not broken.

What did you think about progressive enhancement in general, and what he had to say about it?

David:

It’s nice to hear it being given a more comfortable spin than what I’ve always heard. I’ve had the tendency to be a little put off by the people who promote progressive enhancement, because they will tend to promote standards that are kind of out of date, like this whole, If it doesn’t have JavaScript, it should still work and expect that JavaScript will be turned off.

I remember when that was true. That is no longer true. I think that today’s version of that is, Expect the network not to be available, or expect connectivity to be poor. Develop your application in such a way that it can accommodate a very slow network, and that it can still provide, if not full functionality, at least something that the user can understand and experience while offline.

It’s 2016 right now, and I think that that’s the big challenge people are starting to try to grapple with around progressive enhancement.

Tim[32:04]:

My goals towards progressive enhancement … I work in ecommerce. The fundamental goal for any commerce application is that a user can purchase a product, right? My goal was always most applications that deal in ecommerce — when you click the Buy button, an Ajax request is sent with a product ID as a parameter and you get a response back. What I found was, when I initially started at my current company, there’s a very high JavaScript error rate, which meant that it was very likely that a user could not purchase a product in certain scenarios, because that core fundamental experience was powered by an Ajax request.

The whole fact that it was powered by JavaScript pretty much had nothing to do with progressive enhancement in a sense. I’m not saying that it wasn’t progressive because we used JavaScript to do it. It wasn’t a progressive solution because we didn’t have a fallback. We didn’t have a fix in place in case something broke. Anything could break, right?

It could be malformed HTML so you don’t have an href attribute in your link, and then you can’t go to a product page. That’s an entirely JavaScriptless solution, or JavaScriptless issue. The problem that we were noticing was, we had a lot of JavaScript error rates due to maybe a lack of testing or developer error or third-party JavaScripts, or maybe a user downloaded a browser extension that polluted the global space and broke something, which can totally happen.

I think the thing that I tried to get into my head was not to blame any specific technology for this. It was just to code defensively. When I talk about progressive enhancement, that’s the sort of thing that I try to remember. It’s not about, like, Oh, you don’t use this technology. It’s about code defensively. Code in such a way that when you’re working on the most unstable environment of all web development, it’s probably a good idea to have a fallback in some cases.

So for us, where you click the button and it sends off an Ajax request, maybe turn that into a form, and if the Ajax request doesn’t work, a form submits. That has nothing to do with the idea of relying on JavaScript, but everything to do with making your application a little more defensive — in an increasingly volatile environment.

David:

That increasingly volatile environment really is an issue, because right now, you depend on so many layers of technologies when you’re publishing something with the JavaScript. You’ve got the framework, you got the transpiler. You’ve got all of these things that are happening behind the scenes, and whether these things are dynamically generated or not.

These days, you have to know so much about your stack from top to bottom in order to be able to code defensively. That’s a very difficult proposition. I can’t tell you how often I’ve been in a situation … I can think of a couple of situations off the top of my head with some very major publishers with huge high-end products.

For example, I was trying to click on a download for a preview for some software for a large company that makes photo manipulation software that shall not be named. The user interface for their site relied on the fact that the buttons were set to disabled. They used the disabled parameter inside of the HTML. I was able to go in and I was able to turn off the disabled parameter and download the preview because they had not checked.

That’s probably because they were operating in an environment where something was being generated dynamically for them, and that error checking was happening through a framework that they were using and they just didn’t know to check if somebody went in there and made that change, somebody would be able to get around that.

Tim[35:42]:

Just to nail the point home a little bit more, because I hear a lot form critics — I’m sure you do as well David — that it doesn’t make sense to talk about not writing any JavaScript. I write JavaScript maybe 98% of the time during my day job.

It’s really not an issue of avoiding a specific technology. It has everything to do with checking things, testing really hard. When you make a web app and you pull it up on your phone, open six other tabs and three other apps. Make your CPU busy. See what happens. Try to break it.

When you do successfully break it — and most of the time for me that’s as soon as I try to test it: first time running the code, it’s broken! As soon as that happens, I ask myself, How can I make this better? How can I make sure that even if I try really hard to cause an error here, how can I make this thing still work?

I think that’s the core of what the idea of progressive enhancement is trying to get at.

David:

I think you’re absolutely right, because it is about looking at the resiliency of what you’re doing and trying it in different environments. It’s part of what Chris was talking about with these companies that are trying to get coders to turn it around as fast as possible.

Yeah, you can turn it around as fast as possible, if you only follow the happy path. You only do the thing that you know works. You never test with the wide variety of variables and inputs and on different devices and in different contexts.

The problem is, you get a situation where you end up with something that’s very brittle, and the end user will suffer for that.

Tim:

Yeah, and here’s the thing. The term progressive enhancement would not exist if — and I’m just as guilty here so don’t … Pot calling the kettle black — the term would not exist if for everything that we built, we tested in low network speeds, we tested in different devices and different browsers and we tried to break it for every single time we released something.

If we did that, we wouldn’t have this term. This discussion would never occur. We are often plagued by deadlines or trying to impress others, or just getting a few more followers on Twitter … [clears throat] … @VersioningShow! [Laughter] That’s why that happens.

If we just tested more and relied less on the idea that, Oh, this came from GitHub and it has a lot of stars so it’s clearly not going to break, then this wouldn’t be a problem.

David:

This kind of harkens back to some of the stuff Chris was talking about, about the whole developer community. He even suggested there may be technologies being developed out there so that people will have an excuse to go to conferences and talk about them and look smart.

I don’t think he actually said that, but it was kind of an implied subtext.

Tim:

It was implied.

David:

Who among us has not been to a talk where something looked really cool and then you went home and it was like, How did that person do that magic? I’m never going to bother with that because it’s too complex or too esoteric or the technologies are not something that you can apply immediately in what you’re doing today.

One of the things that he said that really caught my attention was this issue of being seen as the guru who has to know everything about everything. I’ve found at least once or twice in a situation where I’ve been in, like a job interview, and somebody’s asked me about, What is the Big O notation for this? It’s like, I have no idea what that is. That’s not what I studied. There’s never been a reason for me to apply that in my work, and yet people sometimes expect me to know these things, because there’s so much going on, but you have to know everything.

Tim:

I really like where Chris touched on the idea of hiring people smarter than you. I have to honest, hearing that it almost sounds like, Oh no. Why would I do that? When you really think about it, of course you want to hire people smarter than you. That’s how you get better. That’s how you learn. That’s what motivates you to try new things and enjoy your job more.

David:

Yeah. I don’t want to work with people who are dumber than me.

Tim:

Maybe it’d be hard to find people who are dumber than me [chuckles], but you know what, at least in this job I’ve had some of the best experiences working with people who are the most different from me.

David:

It is all about the people, honestly. It’s nice to get reminded that the community — the network, the people — really is what it all comes down to when your doing this web development. We spend all of our time staring at out computer screens, but honestly, it really is about the people that you work with, and about the interactions and the communication.

Tim:

We build the software for the people. I think that’s also another important thing to remember. If accessibility and really caring about who is going to be looking at this thing that we built, I think we would be more inclined to test more. We would be more inclined to make sure stuff doesn’t break under the slightest bit of stress.

David:

That is an excellent note to end on. I think this has been a wonderful show. I’m really pleased with Chris. I’m hoping to hear back from the audience about what they thought of this.

---

Thank you so much for listening, everybody. We always enjoy talking technology with all of you.

Tim:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes to let us know how we’re doing.

David:

We’ll see you next time, and we hope you enjoyed this version.