Transcription
[Music]
Audience: [Applause]
Christian Hellman: Hello. There’s the moment to put the coffee next to the computer without killing the computer. Yeah, fair enough.
Yeah, I’m here to wake you up this morning and get you excited about this. It was fun when he said we’re going to go to Munich because I used to work here for three years, and I lived in Augsburg because it’s affordable, not like here in the city center, like “ah!”
I haven’t been here for years, and it was quite fun to get picked up at the airport by the driver, in this weather, in lederhosen, and without any socks. We’re like, “Okay. We’re back in Munich. This is what the guy is.” Also, in the 45-minute ride he said, like, 4 words to us and was like [grunt], and we’re like, “Yeah, back home in Germany. Excellent!”
I thought I’d start the conference with a bit of digital heresy because there are not many things you can do in the morning that wakes you up better than that. I want to talk to you about sacrificing the golden calf of coding. What do I mean by that? First of all, I think we’ve made code, developing, or programming kind of almost a religion. We have our own rules, and everybody has to follow them.
We see ourselves as somebody different from the world of the people that use the things that we do and pay money for it. They’re stupid. We get everything for free, right? I want to make sure that we understand that technology has kind of overtaken us as humans, and we are not immune to that revolution or that change as well.
The other day I did something that nobody ever does. I went to Twitter and made a grandiose statement without backing it up at all. Nobody does that. Everybody has only research-based things on Twitter and says things that are understandable.
I said that in five years, most of what we call coding these days will be done by machines and they’ll be much better at it. People were all like, “Yeah, well, whatever, Chris. You live in the future or whatever. You’re diluted, and you’re old. Just stop because we have to code and, like, being a command line is the best thing ever.”
When I started at my company right now, we put the WSL subsystem into Windows 10, so we had these announcements with holograms and everything, some really cool stuff. What people got most excited about was, like, you can now write 1970s code on a new laptop.
Audience: [Laughter]
Christian: I’m like, really? We invented 40, 60 years of engineering and software, so we’re back to writing Unix commands? Somewhere in between, we lost it, and we got lost into the fun of coding things.
Machine learning and AI is a thing that is happening right now all around us, and it’s the hot new thing. If you have a company or you want to get funding, you just go to any café in the Silicon Valley and you mumble machine learning, and people give you investment money--
Audience: [Laughter]
Christian: --because nobody knows what it is, and nobody really understands it the way it should be understood. There are leaps and bounds happening. Just today, actually, this morning I tweeted that one that Alibaba and Microsoft’s AI programs beat humans the first time on a Stanford University reading comprehension test. This is a test to see how well people can read. Artificial intelligence programs are better. This is not only reading the words, but also making deductions what the words mean, understanding metaphors, understanding intricacies between words.
We are in a world where AI and machine learning is the thing that people strive for. That’s the new hype that we’re following right now. It can go really far. I loved it in New Scientist where they said, “Letting robots kill without human supervision could save lives.”
Audience: [Laughter]
Christian: I’m really wondering when you stopped finishing that headline and hit enter, and they’re like, “What?! What did I just do?” [Laughter]
We even think that ethical decisions are sometimes better done by computers because humans are failing at that. There were quite a few Star Trek episodes in the original series about computers killing people without having to feel remorse or these kinds of things. It’s kind of weird that we’re already thinking about these things.
Everybody is worried about automation. I work a lot outside of our little world right now, and I talk to people in insurance companies. I talk to people in banks. They’re all really worried that automation and computers will replace them, and they will. They have in a lot of cases already.
I live in Berlin now, and we have next to us one of those Amazon delivery centers with all the cars just lined up. When you think about all these small companies that used to deliver things, or you had to pick up things there, they have been replaced by Amazon Prime already. A lot of automation is happening around us, and people are worried about their jobs. What will people do?
I’m kind of optimist about this. I’m like, if we start optimizing the things that we do that keep us from innovating, that eat up our time and are boring to do, we have a chance as humans to do some more creative things and more important things.
I always love it when people are like, “We’ve got to save the earth.” No, we don’t. The earth is fine as soon as humans are dead. We are the only ones who actually mess up our world the way we actually use it. We’re the best parasite I’ve ever seen. Other parasites help the host. We don’t. We just take, take, take, take, take.
The answer to it, when you go to the press, is always like everybody must learn how to code. “Oh, my God. You’re a custodian now. But, if you want to have a job in two years’ time, you have to go to a code camp, you have to become a coder, and you have to become a developer.”
I find this kind of like a blanket, simple solution much like saying, “You’ve got to learn English to get a job.” Not necessarily in Germany. Not necessarily in Romania. It’s one of those simple things that everybody is like, “These guys code. They have a job. I don’t code. I need to learn how to code.”
We’re not actually exempt of that either. I loved that the other day when the GitHub bot got a job offer.
Audience: [Laughter]
Christian: [Laughter] It’s happening. There are job offer bots going through GitHub, finding keywords, and sending you job offers. Maybe in the future, just bots hire each other, fire each other, and these kinds of things.
Audience: [Laughter]
Christian: It’s going to be interesting to see. Let’s rewind for a bit about the whole coding thing. There are a few great talks about this. When you do your research about, in the ‘60s and ‘70s, when coding was a thing, people were so much more happy about the future of coding. They were seeing computers doing the jobs for us rather than us having to know the nitty-gritty of the command line for everything that we do.
Now, for me, coding, the first time I saw the term “coding,” was a part of the demo scene. It was not in the commercial enterprise. It was not in the job environment. It was people that, in their free time, did random stuff with only outdated, old computers.
This is what I looked like back then, and this is what we did. We had a Commodore 64 in front of us and were sitting there, four people, like, “Why does it still flicker? Maybe change that number around. Maybe do that. Do something sensible with these.”
Coding in the demo scene, to me, meant one thing. It was programming in a creative fashion, pushing the boundaries of limited environments. We had 64K of RAM. We had a one-megahertz machine. That’s all we had. There was no chance to upgrade it. There was no way to wait for the next iteration of the hardware. It was just fixed in time and place, so we had to be very creative in our coding to make things work, to make things look pretty, to make things look impressive.
We didn’t care if it was maintainable. We didn’t care if it made sense. We just wanted to show off how cool we are as developers. Rings a bell, you know, Stack Overflow, Hacker News, the kind of thing like, “Oh, this thing is not ready for production, but you all should use it.” We’re like, “Eh, no.”
To me, back then coding meant performance, cleverness, and inventiveness was the most important thing, whereas maintainability and readability, pff. Readability was actually a thing you made sure that it wasn’t because then other people didn’t know how you did it, and you were the cooler one. It’s like some people have that as job security as well, like, “I’ve written this. Nobody can maintain it. I’m here for the next 40 years.”
Audience: [Laughter]
Christian: Until the next security hole comes around and you have to fix it. When I started having to make money because my parents threw me out and said, “You’re old enough to make money. Why are you still here?” I thought about it. Okay, let’s do this computer thing, and not do it as a hobby, but actually, make some money with it.
To me, the time of coder was over, and I became a programmer, a developer, or an engineer depending on what the company called me. One business card I have says HTML Monkey, and that was okay as well because the money was good, so I didn’t care.
Audience: [Laughter]
Christian: But, when I did transition from “coder” to “programmer,” I thought I’d play nice because I like to work with people who have their stuff together or who have their things together. My focus became maintainability and readability of my code. Whereas, cleverness and performance were not that much of an issue because, when I started on the Web, there was no performance. There was nothing a browser could do that would need performance. It was just like, “Oh, you render forms, you press buttons, and you send them off. Excellent. That was always fast.”
We didn’t have any maintenance, we didn’t have video, these kinds of things, and the inventiveness was all out of the window because most of the people wanted to have the same website that everybody else had done. The amount of websites that I built back then because competitors had the website was just hilarious.
I worked on McDonald’s England for four years. McDonald's doesn’t need a website back then. They didn’t sell anything over it. They made it hard for people to communicate with them because everybody abused them when they communicated with them. They only had a website because Burger King had one.
The always sent us the poster ads and then [said], “Turn this into a website.”
You’re like, “Well, where is the text? Where is the content?”
“Well, that’s it. Be creative.”
“Okay, fair enough.”
It wasn’t easy for us because the environments were terrible. We had Internet Explorer 4.0, 5.0, 6.0. We had Netscape. These things were all not standardized. We didn’t have anything. We didn’t have any documentation to go look at. We actually had to do trial and error to make things work and to do random things like table layouts. We had to use indentation with blockquote and these horrible things we did to HTML because there was no CSS. There was just nothing extra to do.
The problem with that one that everybody who came from that world, or even later, the IE6 world, we carry all this weight of, “Oh, we had to go through that pain, so you should too.” The last 15 years of giving presentations and hearing presentations of development have all these things that I call the worries of the battle-weary people of the Web. The people that went through the browser wars and that had to suffer these horrible environments and those clients that didn’t know what they wanted and still demanded a lot of things. Then they were always still, like, “Oh, my cousin’s son has Dreamweaver. He can do it cheaper than you.” You’re like, “Well, let him. Then I’ll see you in a year’s time to fix it for twice the money.”
People just didn’t trust our job right, so we came up with these things that we keep repeating. I found myself repeating them as well. I kind of got bored of them. One of them is browser X is the new IE6. You see that every few months where right now it’s Chrome. Before that it was Safari. People build for one browser only, and we know for sure that the one thing that that means is that these are also people who are terrible and probably kick puppies because there is no reason nowadays to do something for one browser except business reasons and except people don’t even have a choice to do it quickly. It’s always quite fun how we get up in a jiffy about, “Oh, my God! This only works on Chrome! Google hates the Internet!” [Loud exhale]
You know what? If 90% of your users use Chrome only, your business plan that week is to get this out of the door. Then you fix it later. I’m not saying it’s right. I’m just saying it happens.
The other thing that people keep saying is, “What if library or framework goes away, and that’s all that people learned?” That was always the jQuery thing. “What if people only know jQuery?” We have a whole generation of developers that only know jQuery and, still, they have a job. Still, they build things.
Of course, it means that kittens will die and unloved code will clog up the Internet. This is what libraries and frameworks do.
Yes, service so-and-so is amazing, but what will you do when it’s gone? What if GitHub goes away? The only solution is frantically to copy your code to floppy disks for safekeeping. This is what we do.
Package so-and-so solves this problem for you, but you don’t own it, and you don’t know what it does. NPM, like, “Oh, my God! NPM installed. All of a sudden I’ve got 5,000 packages on my hard drive and I have no idea what they’re doing.” They’re probably liking Trump tweets in the background on your behalf.
Generic code tries to solve too many things you don’t need solving. In my days, all we needed was two lines of CSS, and we changed it every four days. I always like it when people go for frameworks, and they’re like, “Well, it solves all my problems.” You can do this by hand. Okay, next week you have to do it by hand this way. In two weeks, you’ll have to do it by hand this way, so make sure you get this kind of stuff in your world of development, which you don’t because one of the biggest lies, after I read the terms and conditions, is, “Do it now. We’re going to fix it later.” No, we won’t. It’s a lie. Don’t trust people who say that. They never will give you time to fix it later.
Feature of the Web is cool, but what about people on older browsers? In Germany, that’s my biggest thing. Whenever you do something, you’re like, “Yeah, sure. This is in the newest browser that everybody gets for free on their phone, but it doesn’t work in IE9.” Okay.
“My clients haven’t upgraded in years. If malware developers can support them, so should you.” This is the kind of message there that I’m giving to people. Some things on the Web should not be there anymore. Some things should not be used. They’re just a security problem. You don’t want to be in control or you don’t want to have the job to fix other people’s security issues. By supporting them, you support people doing that.
Everybody is invited to build for the Web. You don’t need to use a certain editor or training. That’s the beauty of the Web. That was the great thing about the Web. Notepad and FTP were good enough for me and made me the person I am today. I find it fascinating that we’re so excited about how shit our environment was. We’re all like, “Yeah, cool. We had to do things by hand. We only had zeros and ones, and sometimes we had to use the letter O because the zero didn’t work.”
Audience: [Laughter]
Christian: Well done, but we should move ahead. We should not actually use the bad, terrible tools from the past just because we can.
We’re great at inventing and advocating best practices. I love that. If one of the main principles of good code is, “Don’t repeat yourself,” why do we keep talking about it?
Audience: [Laughter]
Christian: We do. It’s like, “Oh, yeah. These are the 1970s best programming practices that we should follow today as well.” But, when you look around, this is the live code that I saw the other day. It’s “tr class=‘athing’ id=‘15” something like that. It’s a table layout. Anybody have a guess what that is?
Audience: (Indiscernible)
Christian: Yeah? Hacker News.
Audience: [Laughter]
Christian: This is Hacker News, and I love class=‘athing’ because it’s just basically a slap in the face of anybody who ever liked CSS. [Laughter] It’s not even an unnecessary class that is computer generated. It just says, “athing.” How do you style this? How do you style a thing? [Laughter] It’s bizarre that these things are out there.
But, the fun thing is these things work. Computers and browsers have to become lenient because we expect people to make mistakes. One of the main principles of the Web is that the end user should not suffer from programmer mistakes. We made computers, we make browsers very, very lenient with what people do. Lazy developers use it as a carte blanche to write anything there. Well, table layouts worked in 1997, why should I change my skillset?
Why is that? Why do we have all these best practices and these most beautiful things, these explanations, tutorials, and video things, and still there is so much crap on the Web that basically you just look at as somebody who is about best practices and be like, “Why? Why would you ever? No. You can’t have two IDs in one HTML document. That’s what an ID is. You don’t have two passports. This doesn’t work that way.”
Well, the reason is that people are people, people have problems, people have deliveries, people have jobs to do, people get lazy, people get tired, and people make mistakes because they’re bored. We cannot just tell people that the best practice is the thing to follow because a lot of times what we earned from best practices after the first browser wars is not that much of a necessity these days. All browsers are much better than they used to be. All browsers give you insights in what you do.
There’s a quick story about a button. When I started my first company in Augsburg, on my first day I came in. They’re like, “Okay, you’re an HTML developer, and here is the client that we have, a big company that does handcrafted clothing kind of things like wellies for children for 300 pound” and these kinds of things, really expensive things. That was 1997. They send us Access databases, and that was the data that we got every week. Then we had HTML developers that went through the Access database and copied and pasted content into HTML documents, saved them, put them on FTP, and put them on the server. This was our job as HTML developers.
I looked at them. I’m like, “Why are we doing this?”
They’re like, “Well, that’s how you do websites, right?”
I’m like, “This is Access. You can script Access. You know that?”
He’s like, “What do you mean?”
“There is VBScript and there is Visual Basic.”
If you don’t know Visual Basic, it’s a great programming language if you hate syntax and you like to write security holds. This was a great language for that.
Audience: [Laughter]
Christian: I’m like, “I can make you a button to generate these pages from that database easily.”
They’re like, “Huh?”
I’m like, “Give me an hour.”
I wrote for an hour. I wrote the script that basically had a button. Then we generated the website, and we had it finished. We still billed the client for two weeks for development work because that’s how the contract worked, and they didn’t ask. But, I found out really early that way that automating things as developers is our superpower because, if we hand copy and paste things into these HTML documents, we will make mistakes. We will be bored and will not be doing it properly.
If you can write a template, and you can generate the things that way, these mistakes will not happen. You can even write unit tests. You can write tests in between to make sure the computer, while they’re doing it, doesn’t do it wrong. This is how PHP came around. This is how Smarty came around. This is how all the templating languages came around where it’s like, “Oh, we should write HTML by hand and gluten-free, vegan, and these kinds of things to make our artisanal HTML.” No, we’ve got to render things out.
Professional development, for me, means that only a few of us ever hear the, “Wow! How did you do that?!” like we had in the demo scene. Most of the time what you hear is, “Have you finished this?”
Audience: [Laughter]
Christian: Because, we are not part of the timekeeping. We’re not part of saying, like, “How long does it take to do that?” There are assumptions being made for us as developers to get this out of the door. When we, as keen, young, cool, new developers get asked to do something, we always underestimate. We always say, like, “I could do that in three hours.” Then 12 hours later of googling things, you’re like, “Okay, no, I didn’t do it in three hours.” Always pad 400% when people ask you anything. Lie outright to their face because you will have problems that come up.
I learned very early on that instead of code, what made me a career and what made me happy, because I was a developer, was reuse. I started reusing my own things. I wrote my own snippets. I wrote my own extensions to development environments. I tweaked my editor on my browser to my needs. I wrote extensions to the browser itself. I made myself happy by making my own environment rather than writing the code that I was paid for. That way I can then press three buttons and generate the code that people asked me to do because we always think that people want the most amazing and cool things. In essence, they just want what’s on this month’s plan, and the next month, and the next month, and the next month.
Of course, we have to change that. We cannot work that way. But, we are guilty as programmers to never have cared about it, to never thought about, why is a product manager not giving me enough time? Why is that feature so hard when I could do it in two lines of code? Because 16 people worked on it against each other because they were badly done.
I now moved into a role where I was a lead developer, an architect, and now I’m a product manager and a program manager. I learned, all of a sudden, all these horrible things that I had my program manager go through because, as a developer, I didn’t understand the things that they had to do, like sit in random meetings and listen to three-letter acronyms you don’t understand and find the developer that needs to do that and support the developer in the work they do.
Now I work for Microsoft, and I work at huge things, and I learned that a lot of the things that I thought were best practice, not that interested in, not Microsoft itself, but our clients. These are huge companies. These are companies with thousands of software products inside their own thing. My department is called PAX, and I just joined because of the logo because I thought it was something with stars and stuff.
Audience: [Laughter]
Christian: In essence, it means partner application experience. I’m helping people write applications on the Web and on other environments to make their stuff work. What I learned there is that everything counts in large amounts. It’s not really about optimizing to the Nth degree. It’s about, how fast can we roll this out? Yeah, we know it’s crap. But, if we don’t roll it out, we don’t get the budget for this month. We have to do something this month, then we get the budget for next month to do something extra, to do something with it.
That’s where I learned that writing code needs to be modular to be built upon. We cannot just build these perfect solutions that we then have to throw away again. This is depressing for us as somebody that put a lot of effort into making that perfect. We need to build more modular than we actually do.
We always think about building the perfect, gorgeous, beautiful solutions. We’re building this Chippendale furniture where every screw is the right thing and every coloring of the corners is what we need to do. The same thing with us. I remember when we proudly had these valid XHTML batches on our websites. Nobody cared. No end user cared at all. But we were like, “I did it right. I’m happy now. I get more.” You get nothing. Basically, you get more predictability that your thing worked, and you made sure that you were proud of creating something clean. But, the cleanliness is not what people expected. They just expected a website to do something with.
Nowadays, computing is ubiquitous. We have these mobile phones in our pockets. We even have random microphones in our rooms that record, that listen to us and do things for us. That always cracks me up. If, ten years ago, I would have come to you and said, “Can I put a microphone in your house that records everything?”
Audience: [Laughter]
Christian: “No.”
“What if it tells you the weather?”
“Oh, cool. Yeah. Sure. Let’s do that.”
[Laughter] You know, like we have these machines all over us controlling our lives, doing our things. I’m now moving to Germany, so I’m trying to get all my paperwork done. There’s still a saving grace in Germany that we love paperwork and bureaucracy, but everywhere else you’re very much reliant on software. We’re reliant on computers to work.
I think, when it comes to that, then the whole Ikea model makes much more sense. This is the Ikea a Billy. It’s not amazing. You probably will not go to somebody’s house and say, “I built that.”
Audience: [Laughter]
Christian: Because we all did. You know Ikea. It’s like Legos, but for grownups and cheaper.
Audience: [Laughter]
Christian: But, what I like about Ikea is, when I look at how these things are planned, how these instructions are written for anybody in any language or any intelligence levels, and how the screws are at the right place, and the holes are at the right place. The statics of the thing works out, so building something badly together in Ikea takes a job.
Okay, I managed to do it. I managed to build something wrong, the wrong way around, but that’s because I was not putting patience in. I was reading ahead, and I was trying to think what should be done.
How clever these Ikea things are to be built together is just a beautiful idea. How much they thought about making it work, how can we make it as simple as possible to package together and transport it and then build it up? That’s what we should be thinking as well. How does my code modularly work so other people can use it? Not like, how do I build the most beautiful solution and I’m the one doing it?
With increased complexity and demand, any software product would sooner or later use prebuilt components. I used to do games on Commodore 64 and these kinds of things, and Amiga. I’m like, this is cool; this is fun. Then I learned that game development is only SDKs from the console developers, and you basically put things together. It’s more a clicky thing than anything else.
In the indie game scene, yes, you write your games from the start to end. But, when it comes to commercial production, it’s just using other people’s components and code. It makes it faster. It allows them to roll out many more things and make users happy because they always want to have the same thing.
People are happy to get the same thing over and over again just with a new feature. This is depressing, but that’s the reality of the world. Just look at Hollywood over the last 20 years. It’s the same movies over and over again.
Great components are easy to use. They’re easy to keep updated. They have limited pollution of the final product. And, they have appropriate tooling. This is where we get away from this, like, “Oh, I use my text editor and write my HTML in CSS,” because some frameworks make sense to have an IDE to use. Some frameworks only should run on a cloud box rather than you setting up your local machine over and over again with different projects.
When I was a lead developer, I was looking after 12 different projects. My computer was completely shot because I had an Apache running. I had a Tomcat running. I had an IIS for the other tool. I had this environment, that environment. I spent more time fixing my computer and making my local environment work than building things for the end user. That’s why I like that nowadays we have images. We have things like Docker where we can make environments and deploy them in one click.
That’s Ikea as well. They’re easy to update. They limit the pollution of the final product. There’s nothing left at the end of it. That’s, of course, a problem. If you blindly use frameworks and environments, you will have a huge website that uses everything but doesn’t use it when it’s actually being used.
Again, this is where something like webpack and other tooling comes in that can take out these things that we don’t want to have because we don’t want to do that by hand.
All these things, these worries of the old people, they’re problems, but they’re not problems that we should be solving by hand. These are problems that we have tools for. I’m so excited nowadays to see what tools we have when I teach new people coming into our market. I wished I had the stuff that you have now.
Of course, it’s complex when we always say, “Okay, let’s start with HTML and CSS and make a website.” They’re like, “All you do is Grunt, NPM, NodeJS. You set up this.” I don’t even know what branches. You have Gulp, Power, Yeoman, webpack. You all these things can be overwhelming.
But, you know what? They are not there to overwhelm you. The job of all these tools is one thing and one thing only. They need to ensure that large teams can work safely together. If we build things by hand, we assume that everybody else is as clever as we are, and it’s up to us to explain to them how something was done.
If we use a framework that is properly documented, properly installable, properly has demos, has help channels, then this job is done by the framework for us. I’m not saying we should rely on frameworks for everything, but this is a huge opportunity to be able to go away from a project and then basically say, “I don’t have a problem with the next person coming on that has documentation, has a community that supports them, rather than myself.” I’m 100% sure that I won’t find anybody in this room who says, “Every job I ever finished, I left the thing and I was happy with it because anybody can maintain the thing that I left behind.”
We never get the chance to document things on the way out. We stay far too long at companies without having fun because we think it’s up to us to make this thing work. No, it’s not. If you’re unhappy working on something, don’t work on it anymore. Find another way for people to do it because all you’re going to do is write terrible code and be unhappy doing it.
We create code that might not be optimized that way, but it’s easier to convert and maintain. Code written by algorithms, code written by scripts, by build scripts follows rules. That way we can actually write a conversion script to turn it from one to the other. Handwritten code, optimized, quality code is not optimizable with a tool or not as easily.
If you ever try to scrape HTML from the Web and use it or write your own scraper rather than using BeautifulSoup or something like that, it’s daunting. It’s so hard to find HTML code that’s clean because people just randomly put things together because the deadline was then. We see this kind of abstraction happening even in languages itself. Take for example this task, which is a very common interview question a few years ago. Find the largest member of an array, so you have “let arr = [20, 10, 5, 10];”
When I started as a JavaScript developer back in the days when browsers were really horrible, I would have probably written it like that, like largest array is a function. I have a temporary value, which has got to be the highest value at the end. Then I loop through the array in reverse because of for loop that iterates and reads the length of the array was really slow in Internet Explorer 6.0 and Internet Explorer 5.0, so I do this clever trick of using all minus, minus, and loop through it. I do an if statement to compare the temp with the array value at the moment. Then, at the end, I return to temp because the biggest one will always be the one that’s out there.
This is readable, but not really because I already do that all minus, minus trick that you might not know about. I wrote and optimized at the same time. Okay, later on, JavaScript got a bit more features. All of a sudden, I had Math.max, and so I didn’t have to do that stupid if statement anymore. It’s still quite a lot of code for that simple thing.
Nowadays, with IE 6.0, this is the code that I expect people to write, and it feels weird to me. I don’t want to do it, but it makes total sense. I’ve got my array, my fat arrow function, and I have a Math.max function that gets called on each of the iterated elements. I have a spread on the array to go through it.
There’s a lot of magic happening there that I, as an old-school developer, I’m like, “Jesus! What the hell is that?!” But, if you learn JavaScript right now, this is documented, and it works fine.
Now, you can do a micro-optimization, run it through a benchmark, and say, “Actually, the reverse why loop is much, much faster than the spread.” But, by using the spread, I can make the performance problem the problem of the JavaScript engine makers. You don’t have to optimize your code. They have to optimize their engine.
The people working on JavaScript engines love that kind of stuff. When we put new features in, we want people to use them, so we see where the problems are, and we can optimize them. If people don’t use them because they’re not ready yet, we will never optimize them because we don’t know that they’re not performing well.
Something to consider about all of this is that humans rely heavily on technology these days. The time we get to deliver products has been much, much shorter than it was in the past. We’re supposed to deliver a most viable product in every product that I know right now. We’re not even thinking about, okay, we’re going to have the first iteration, the alpha. Then we’re going to have the beta. Then we’re going to have -- no, nothing gets past beta in the startup world.
In real production, we’re always asked to make it work. Then we roll it out. Then we make it better. We have to think about that. People rely on computers to get fixes to get better functionality to have better functionality. This gives us plenty of opportunity to endanger our end users. It’s not about code quality and writing beautiful code. It’s making sure that your code does not become a security problem, does not become a performance problem that cannot be fixed.
When you saw the latest problems with the Intel and AMD on chipset vulnerabilities, with CSS I could make a computer vulnerable nowadays. This was impossible when CSS came out. All we did was put underlines on links away. When we rolled over them, we showed them. We’re like, “Ooh, look at that.”
Nowadays we do animations. We do timing. We do all kinds of things that directly talks to the graphics hardware in CSS, and we can make mistakes without knowing it. There’s nothing more easy for a developer, for a new developer, to say, “Why do people do it that complex? I can do it in two lines of code.” You’re like, “Yeah, you don’t know the repercussions of it.”
Abstractions, to me, are not inherently a lazy way out or dangerous, like I always like to say, “Oh, my God. Use jQuery.” You can use vanilla JavaScript. You don’t need to use jQuery for that because you’re lazy.
But, in essence, there are consensus to enable lots of people to build bigger and better products. It’s easier nowadays to say, for example, “Okay, we’re using Vue.js for that. We’re using React for that.” Of course, you make it more limited to a smaller group of developers that way, but you have a documentation. You know why something was written the way it was because the framework demanded you to.
In essence, to play well with others, we need to establish rules. We can document our best practices until we’re green in the face. If people don’t get the documentation or the error handling while they’re building things, they’re not going to follow them.
We’re not code warriors fighting the man or the good fight. When I came out of the demo scene, that’s what we always were like, “We write code, and this computer company says their computers can never do that. Look what I made it do.”
We’re not code warriors about this. Nobody cares about this fight any longer. We have to deliver things for people to use. That’s why I think we’re becoming engineers, building solutions in teams for people to use. Focusing much more on the teamwork and how does my code affect the people around me, what demands does my code have to the people maintaining it, is much more interesting to me.
There’s a great quote that states that “It may not be warriors who get the glory, but it’s the engineers who build societies.” Building societies is something that we should be considering. Of course, it isn’t Steve Jobs. It was actually B’elanna Torres from Star Trek, but people listen to it much more when it was Steve Jobs.
Audience: [Laughter]
Christian: I love that quote. I’m like, building societies, how cool is that? We’re right now in a massive fight where people look at IT people as horrible people. We’re the ones with a lot of money that go into the houses that other people can’t afford, and we’re not playing well with each other. We’re all arrogant. I think the society thing is something we should be concentrating much more on.
I also loved The Northern Lights by Philip Pullman. There is this beautiful quote that made me rethink my best practices and the preaching that I do about them. It’s the duty of the old to be anxious on behalf of the young, and the duty of the youngest to scorn the anxiety of the old.
I invite every new developer coming in right now to call out people like me who say, “You’re overcomplicating by using this webpack thing.” Show me why you’re using it and what the benefit of it is, and I’m happy to oblige because I realize we’ve been overtaken by the demand of delivery that we have to do. We cannot just build bespoke software for everything. We have to think of the Ikea way of building components that other people can put together and build things for end users.
It’s much more important what you create rather than how you do it. I’m much more excited about what your product does rather than what framework you used because that will change. The fun thing; by relying on a framework with a coding best practice, a coding style, and a tooling, you can convert it to other frameworks after that. With handwritten code, you can probably not do the same thing. That’s why we talk about PWAs. You can write an iOS app. You could write an Android app. You can write a Web app. Or, you can write a Web app and let technology do the other ones for you. Then you don’t need to repeat the code on all of these platforms.
Coding is much more fun when you aren’t carrying years of, “Well, that won’t work this way, “with you. In many cases, it very much works as technology moved on.
Whenever I look at a product, I’m like, “Ah, no, I can’t do that because that would happen. I can’t do that. That would happen.” It stifles me. It makes me not creative and interested anymore. I love when new developers just try things out and say, “Here.”
That one line with the array, I would have probably said a year ago, “Yeah, but, uh, you’ve got to make sure that the browser supports this fat arrow and these kinds of things.” Cool. He doesn’t have; he or she doesn’t have to think about that problem anymore. They can build the next cool thing. They can think about the next big problem.
We have great tools these days. They teach you to code while you write the code. I love, for example, Visual Studio code. I’m working on that project, so I obviously have to love it. I love that it’s written in typescript. I can write the editor that I use for a certain language in the language that I’m writing it with. I can mess around with that thing in any way that I want, and it’s open source.
Microsoft doesn’t even have a right to say no. I can put dancing dinosaurs in the background of mine and it will be mine. It’s fine. It’s an open source project. Of course, I can resubmit it and then they can say, “No, we don’t need dancing dinosaurs,” but you can make this your editor. You can make this your environment. The same with Atom. The same with many other editors out there.
But, what I like most about it is that it comes with linting built in. That’s a bit like when you’re writing in Word and, all of a sudden, you get the squiggly red lines under it, which means you made mistakes there. This is happening in code now as well. I think that’s much more exciting than debugging. That you can put in a JavaScript, for example, an at TS check, and then it puts the typescript rules in JavaScript. Now all of a sudden, we’ve got the squiggly lines telling you, you forgot to actually make that a constant. You forgot to initiate that one with a let. All of a sudden, once you fix that, the other ones go away as well. While I’m typing things, it tells me the mistakes that I do, which is, for me, much more exciting than learning all the rules why something is wrong. You can still click on the arrow next to it to get the explanation why it’s wrong, but it’s much better than writing wrong code and then being disappointed because it doesn’t work.
We have collaborative editing and education tools such as CodePen, JSBin, Glitch.com, and also in the editors itself. Now, much like in Google Docs, you can write code together, and you can see who is writing where. I teach people coding that way nowadays. I ask them, like, “Okay, put it on JSBin.” I come in with you, and I code with you. I show you where the problems are rather than being on Skype and having to explain. “Go to line 15. See that character there and there?” It’s much easier to do it collaboratively and together. If you need inspiration, CodePen is absolutely incredible. It’s beautiful what people do there.
Good tools allow you to find bottlenecks and obvious flaws. Browser developer tools have audits built in. They’ve got performance tools built in. They’ve got just checkers in there. Again, while you’re executing it on your end product, you will find the issues that you have. I think it’s ridiculous to think that nowadays, with our complexity of devices and environments that we have to support, we could actually make the life code our development code. We are past that.
All this tooling makes our code better, so we should write it, use the tooling, and create the most optimized version for the end product by algorithmic and scripted environments rather than doing it by hand for all of them.
If you haven’t looked at Sonarwhal, you can do that later upstairs and now downstairs, I think, as well. That’s a linting tool that shows you all the performance, security and validation problems that your website has before you build it. You can put that into continuous integration. You can put that in your build script to go through these and say, “Okay, here is a unit test on best practices,” rather than knowing all the best practices up front.
Thinking with reusable components is not only a thing for coders. We’ve been doing that in the development space, but also in the design space. If you think about it, it flows over into design space a lot. We’ve got style guides. We’ve got pattern libraries. People are using Sketch and turn it into code with just a few steps in between because our designs are already coded to a degree. They’re not mocked up rather than written. Back in the days, it was just like you’ve got a PSD with 5,000 layers with no names. Nowadays, you can do a lot of generation of clickthroughs from our tools as well.
The thing is when we have predictable, reusable, and well-working parts to mix and match, we can go even further. Why would I need to download Bootstrap and start putting a Bootstrap website together when everybody wants to have the same website anyway? They want to have a hero image, they want to have a carousel under it, and they want to have a footer that says, “Made with Love Somewhere.”
Audience: [Laughter]
Christian: Computers are good at repeating things, finding patterns, and improving them. Humans suck at that.
Audience: [Laughter]
Christian: When I look at something like Bootstrap, I’m like, “I’m already bored. I don’t want to do this.” I know it’s easier, but I don’t feel any passion of putting a thing together that somebody else has written and then releasing it. I’d rather think about what I can do to optimize. Again, with the button thing that I did in VB back then, that thinking is in my head now. When something is repeated over and over again, a human should not do this because we’re bad at that. When we get bored, we make mistakes.
Computers are good at looking at what people are doing. I love AutoDraw by Google where I can do things like that, then press a button, and it turns it into glasses. For somebody like me who has no talent of painting at all, this is great. I love especially the backstory of that.
“Ooh, Google has AI,” but they fed it with a game that they did called Quick Draw. In the past, they asked people to say, okay, here is a game. Draw an elephant. Then the computer took all the elephants that people drew and then found the elephant icon and mashes them together. By letting people do things over and over again, and a computer listening in on it, we can now make it easier for people to do. You can do incredible things like that.
That’s Airbnb. I don’t know if you’ve seen this. What they are doing is, you paint something on a piece of paper like a prototype of the page, and it analyzes it. It creates the page and creates the code from it. They can do that because they have a very strict design system. They also do that because they want to build new websites rather quickly.
There’s a white paper on the background of that, if you want to know about the machine learning in detail about it, the neural network that’s under that, and how to turn a graphical image into HTML code that looks like code written by a person, except without the mistakes that the person would have done. That is amazing, and I love that we’re in that space already.
They use training data, open source, machine learning, algorithms, and a design system in the browser to be able to do this because they concentrate on those things because they knew you’re not going to have a developer for more than a year. That person will go, so make sure that you actually automate around them. Take their skillset and make it a skillset of the group rather than having rock stars in your room.
The question is now, where is the fun in all that? I think humans are better than machines, so working well with people is a thousand times more important than working well with code. Don’t get so lost in the app problems that you don’t spend any time-solving people problems. When it comes to everybody must learn to code, I find that completely the wrong solution. To me, everybody should learn to solve problems. When we automate things away that are boring to us, when we do things by automating the necessary, we gain time to find the fun again in our development. We find time to be creating gorgeous, new components, new packages in NPM that have no security problems, new Web components that are accessible.
We have time to run unencumbered pet projects. It’s your own project. Go wild. Play with things. Write a CodePen that doesn’t make sense, but you want to try something out. Play with those things outside of deliveries.
We can help the tools that we use. You can put a pull request into all the editors that you use, all the tooling that you use, and you can help those. Even with documentation, even with fixing typos, you don’t even need to be a coder to help somebody like webpack.
You can play with upcoming technology. I’m now looking at HoloLens stuff. I’m looking at machine learning stuff much more than I look at JavaScript, although that’s my expertise, because I want more. I want new and different things.
You want to drop out of the rat race and clear your heads because we are in a world right now where we’re not working healthily. We’re working far too fast and thinking we’re doing far too many things right while we’re doing them wrong, where computers could do the things for us and we could spend time having a coffee and talking to our colleagues, instead, and planning the next step before we’re actually doing it.
We have time to help each other out when we’re stuck with some new technology, to teach new people about things. We have time to help others get excited about what we do. This is not about sending them to a coding course, but in telling them, “Our product enables people to do this.” Code is at the base of it, but here are the five components that we use that you could use as well.
If you’re feeling overwhelmed by the whole coding thing, I think there is a change happening right now where a lot of the stuff that we call coding these days can be done better and faster by computers. I find, as developers, we haven’t done our job if that’s already not the case. If it’s still up to the human to do repetitive, boring commands, then we haven’t used the computer as a tool, but we made it a religious object, and I don’t think that should be the case.
With that, I thank you very much.
Audience: [Applause]
