Welcome to the first in a new series of interviews called “How I Work”. These interviews revolve around how thinkers and creators in the Web world design, code, and create. The goal is not to get into the specific nuances of their craft (as that information already exists online), but rather step back and learn a bit about their habits, philosophies, and workflow for producing great work.

Meet Doug Crockford

First up is Douglas Crockford who believes JavaScript might just be the most elegant language ever. Learn why he thinks you should study the history of computer science, the value of reading your code in front of other people, and that jQuery really is a good thing.

Douglas Crockford is known as The JavaScript Guy. He’s famous not only for his O’Reilly book JavaScript: The Good Parts1 but even more so as the visionary behind the JSON2 data format as well as the JSLint3 tool. He was featured in the book Coders at Work for his contributions and philosophies on what JavaScript got right, and what it didn’t.

As a native of Southern California, Doug has the build of a surfer; lean and tall with white hair and a beard. A veteran of Silicon Valley, he’s worked at Atari Labs, founded and worked at numerous software start-ups, was head of technology at Lucas Films and now has the enviable job of being a JavaScript evangelist at Yahoo!.

Self-taught (as many of the greats are), he says his goal is simply to get more people coding in JavaScript, or any language for that matter. While his day job may be as a JavaScript evangelist, speaking with Doug you get the sense he really is an evangelist for programming in general.

Below is a conversation that took place in Bozeman, Montana prior to a talk at Montana State University. Doug freely shared his thoughts on great programmers, user empathy, and how JSON restored his faith in humanity.

Why do you feel programmers should study the history of Computer Science?

Well, first semester of physics is a history class. You study Galileo and Newton and all their contributions to the field and that gives us the overall view of physics. It’s a really nice place to start.

I wish CS would do that. It doesn’t seem to have enough value in its history and it’s a really amazing history that’s completely neglected. It’s rarely that the best idea won. So, we’ve taken different paths over the years and maybe haven’t realized why.

Ironically, despite the rate of change in technology, we see in the story of software that it takes a generation to retire or die off before we have a critical mass of bright young minds to embrace new ideas.

I think if people were more aware of their history, they could see these patterns more easily.

What were the traits of the weak programmers you’ve seen over your career?

That’s an easy one—lack of curiosity. They were so satisfied with the work that they were doing was good enough (without an understanding of what ‘good’ was) that they didn’t push themselves.

I’m much more impressed with people that are always learning. The brilliant programmers I’ve been around are always learning.

You see so many people get into one language and spend their entire career in that language, and as a result aren’t that great as programmers.

Do you feel that the pain a programmer goes through in learning a language contributes to this unhealthy attachment to using only one language?

My advice to programmers to avoid this trap is to learn lots of different languages. We’re in sort of a language renaissance right now and there are a ton of brilliant languages to learn from.

To learn new languages takes nights and weekends outside of work, and that’s a commitment. The great programmers are the people that are constantly picking a project and diving into it, learning a language that way.

In Coders at Work6, you stress the importance of doing code readings with teams. Why do you feel it’s important to present your code in front of other people?

Well, over the years I noticed that there are some terrific programmers out there that are completely content to sit in their cave all day long writing brilliant code. But they don’t interact much with their team, which means it’s a lost opportunity for mentoring other members.

As you know, a lot of coders aren’t the most socially adept animals either.

So, my idea with code reading sessions is to provide a forum where people can come together and read for each other to get them out of their caves. The masters read for the beginners, and vice versa, as a team-building exercise.

The trick for success is to set up rules ahead of time so that nobody is going to get spanked and everyone is respectful in their feedback. It has to be a good learning experience for everyone. You have to be careful with a dysfunctional team, because it can quickly tear apart the group. But I always call the game before it gets that far.

The rules are that it’s about improving the quality of the code that we’re all responsible for, improving the quality of our team, and improving our individual capabilities.

Some people see this as a terrible time sink. Yet, I’ve found by doing this exercise, bugs are caught way ahead of time and you can prevent a team member from going off the tracks. But again, that’s not the goal, it’s about team building.

Over time the masters help pull up the beginners and the overall output from the team gets better.

Are programmers getting better at user empathy?

The best experience I had with empathy was working in marketing support. There were times I would go out into the field and hold hands with the customers and see the consequences firsthand of some of the crap we were delivering to them.

I was shocked when I moved into systems programming and how the programmers actually held the customer in contempt.

I think every programmer should work in customer support for the product they’re delivering.

It’s another case of over-specialization. “I just write the code,” is the response you get and the programmers don’t see it as a chance to improve peoples’ lives.

How much of a language do you need to know?

Virtually every programming language is too big. Language standards have difficulty removing unnecessary features but as users we can choose not to use it.

I would say you can do 100% with knowing 50% of the language.

The language that taught me that lesson the most was JavaScript, because it has more bad parts than good parts. It gave me a very strong motivation for figuring out what are the good parts and what are the bad parts, and what the criteria is for deciding what’s in or out.

What approaches would you say a master has versus a beginner?

When I was a journeyman, I was a maximilist. I tried to use the whole language. While I don’t know if I would call myself a master now, I’m certainly a minimalist. I’ve tried to get good at using as little of the language as possible.

I place a lot of value in simplicity and minimalism.

What are your thoughts on jQuery? Some JS enthusiasts feel like it’s letting people off the hook from truly learning JS.

There is some really clever stuff in jQuery and I think John Resig did some very good work there.

I do have a problem with anybody doing anything without understanding what they’re doing. I’m not going to fault jQuery for attracting those sorts of people.

But I do think there are some other AJAX libraries that maybe doing a better job that aren’t quite as accessible. However, I think there is a place for all of these things.

When you were developing JSON was it tough to pull back and not put too much into it?

My design criteria were three things: minimal, contextual, and a subset of JavaScript.

The last constraint was to keep us from going off the rails and inventing new stuff. We had to only use stuff that was in JavaScript, which meant that our unicode handling wasn’t quite right because JS isn’t quite right, which was disappointing. We don’t have proper support for dates because JS didn’t have it. But we can work around both of these.

But it also meant that when somebody proposed, “Hey we should do this crazy thing” we could be like “Nope”. So, we had a really easy criteria for stopping extra features from being added.

One interesting story about leaving things out: as we got closer to releasing JSON I decided to take out the ability to do comments. When translating JSON into other languages, often times the commenting piece was the most complicated part. By taking the commenting out we reduced the complexity of the parsers by half—everything else was just too simple.

One of the best features of JSON is that it’s stable. If your program works now, it will work forever, and that is an attractive thing.

I still get notes from people saying they’ve got great ideas for the next version. But there isn’t going to be a next version. I always say you’re free to invent a new standard and promote it as much as you like.

How did JSON get adopted?

You know, the adoption of JSON sort of restored my faith in humanity because it was a good idea that won out, only because it was a good idea.

It was a case where there were no slick marketing campaigns. In 2001, I started working on it as a way to tie the browsers to the server. At the time, everyone thought XML had to be used or they’d say “that’s a great idea but JSON isn’t a standard”. So, I bought json.org, made a logo, threw up a Web page and it sat out on the Web for three years.

In the meantime, AJAX happened and when it became the way for writing applications JSON was there. There was counter promotion from the XML community, of course.

But when I arrived at Yahoo! some kids at the company started thinking it was okay to start shipping JSON API’s through Web services. And developers found the apps got faster and were easier to write.

It sort of took off from there—no slick campaigns. So a good idea based on simplicity won out for once.

Watch Doug Crockford At Google Speaking On “JavaScript: The Good Parts”

In this presentation from Google Tech Talks, Doug goes over the ideas behind his landmark book, JavaScript: The Good Parts, and dives into the areas of what JavaScript got right and what it didn’t. Learn about the history and common roadblocks programmers run into when developing with this language.

Learn About The JSON Saga

In this video, Doug tells the interesting tale of how JSON was discovered, and sheds some light on how it became a major standard for describing data in an interesting turn of events.

Vasileios Topouz

Asher Webb

Thanks so much for this article. I enjoy seeing JS’s rise in popularity, and of course enjoy the way it powers HTML5 and the speed needed on the mobile web.
And Doug Crockford is such a great inspiration!

David Mair Spiess

adumpaul

StationStops

This is one of the best perspectives I have ever read about programming, and most closely match my own. coincidentally, I was also a self-taught programmer who worked for Yahoo! (I think I was the first engineer without a CS or EE, which was both intimidating and satisfying).

I think CS and EE programs are a bigger problem than ever. We still need more computer scientists and electronic engineers, but we also need a ton of great programmers as well, and in most of them would be better prepared for the professional market with a lighter technical course load and more artistic, management, business and communications skills to complement.

Claude

Many thanks for the opportunity to discover Doug Crockford’s work !
I’m just in the middle of “The Good Parts” right now, and watched a few of his amazing lectures online. The historical perspective and the deep insight Doug gives about this language helped me to use JavaScript’s abilities in a more structured context.
I would recommend his book to any client-side developer. Thanks !

therealdeal

There is a large piece missing from this interview, especially on how JSON was named and started.

In 2001 a company named Communities.com went bankrupt, 5 people joined into a new effort to rebuild a real-time, stateful web framework using only technologies prevalent in common browsers (frames, dhtml, and javascript). Previously, the tech was built using a proprietary message format because it was believe by some, including Crock that JavaScript was a trash language. In the research conducted after the bankruptcy we had seen some people or companies doing rudimentary passing of elements to browsers without rendering complete pages, thus understanding that it was feasible.

Crock was in charge of the client libraries, part of which became known as JSON, however it would not have been possible without those others and an investor.

There was 5 people in that room when that name was created, 1.8M sank into that company by a VC, It did not just sit on the Web. The tech was licensed to Amazon, EDS, Sun Mircosystem (Oracle). We knew that eventually a larger company would need to back this up and get one of our guys onto the standards body for ECMAScript.

Anyway, that is how it was. I was too young to say much at the time, but I thought that it was fundamentally unfair that he took the domain as a private asset and claim that the idea as if it were only his.

Subscribe to our email newsletter for useful tips and valuable resources, sent out every second Tuesday.

It's finally here. Smashing Book #5, our new book on real-life responsive design. With front-end techniques and patterns from actual projects, it's a playbook to master all the tricky facets and hurdles of responsive design. Get the book.Free shipping.

Fixing RWD issues can be quite easy — once you understand exactly why they come up. The Mobile Web Handbook will help you understand technical issues on mobile and how to deal with them effectively.

Hungry for more content? Over 60 eBooks are waiting to be discovered in our lovely Smashing Library. And guess what? You can watch Smashing Conference talks there, too.