Transcript

CHRIS: Hey, everybody. This is ShopTalk Show. This episode is brought to you in party by Lynda.com, the online learning platform with over 3,000 on demand video courses to help strengthen your business, technology, and creative skills. For a free ten-day free trial, for ShopTalk listeners specifically, go to Lynda.com/ShopTalk.

Also brought to you by the CSS Dev Conference in which both me and Dave will be at, along with all kinds of other awesome people that have been on this show, like Jonathan Snook, Val Head, Sara Soueidan. We have had Sarah on, haven't we? I believe we have because she was one of those guests that I really wanted to get on for a long time. Oh, yeah, I remember. There were other guests in that category though.

Anyway, CSS Dev Conference is going to be really fun. It's out in Long Beach, California, which is, I guess, the L.A. kind of area. I haven't spent a lot of time there, but I'm looking forward to it, especially because it's on a giant, weird boat that's, like, permanently docked there. It looks amazing, and I can't wait to spent time on it. CSS Dev Conf, known for being at cool, weird locations and stuff. Anyway, that's literally CSSDevConf.com. We'll tell you about more of those things, but for now let's kick off this unusual show, Dave.

[Banjo music - Just Build Websites!]

DAVE: Hey there, Shop-o-maniacs. You're listening to another special episode on the ShopTalk Show. Chris, why is it so special?

CHRIS: Well, you know, it's hard for me, because we record things out of order a little bit sometimes, but not so long ago we did a panel, right?

DAVE: Yep.

CHRIS: In the panel, we credited JS Jabber, not that they invented the concept of a panel, but it's the format of their show, as they have some permanent kind of panelists, kind of like me and Dave. Then they invite on not always one, but sometimes many, multiple people to talk about a very specific concept. We've moved away a little bit from Q&A, which is kind of the foundation of ShopTalk Show, and probably always will be.

DAVE: This is like our burning man season where we're just going out, exploring, and finding ourselves.

CHRIS: That's good.

DAVE: Yeah.

CHRIS: Maybe we'll, whatever; drop a little P.O.D. and see what happens. I heard it's very safe. We explored their format a little bit, and we have some other ones planned that we're going to explore. Maybe we'll do a little Terry Gross style interview stuff. We'll see what happens. In this one, we're going to borrow a format from our friends Liz Andrade and Niki Brown, who do a show called--

DAVE: PageBreak Podcast.

CHRIS: I know it's called PageBreak Podcast.

DAVE: It's one of my favorite shows. And, if you're not familiar, Niki and Liz will sit down, and they will discuss either a blog post, and it's, like, a little seven-minute podcast, or they'll read a book together, which is, like, a full hour-long podcast. It's really one of my favorite--

CHRIS: They have their own book club, and they record it. How awesome is that?

DAVE: Yeah. It's like my favorite -- like, when I think about podcasts that have formulas, I always go to this one because I think it's so successful because it's like, "This is what we do, and we just make it happen," and it's great every time. It's thoughtful.

CHRIS: They explain it really well. Go to the website and just read the first paragraph. That's good Web design too when there's just no mystery about what things are. It's just like, "PageBreak is an audio podcast hosted by Liz Andrade and Niki Brown. Join us Tuesday for a discussion on books in a 20- to 50-minute format." It's just like, "We're going to tell you how it is." It's just so great.
Anyway, we're going to copy it. Ha-ha!

DAVE: Yeah. Don't put it out in public because we'll steal it - is sort of the message.

CHRIS: It's an homage, as it were. Dave's like, let's read something together, and we'll talk about it. Dave picked out a very interesting thing for us to read. It wasn't a book because that's a lot of words, you know.

DAVE: It's officially a book, I guess.

CHRIS: It is a book, and I ordered the book because I enjoyed reading the article, I guess, or what's a fancy word for an article? An essay.

DAVE: A collection of essays.

CHRIS: Okay, yeah. It's called The Cathedral and the Bazaar. I'm sure many of you have heard of it. Apparently Dave had heard of it. I had literally never heard of it. It never came up for me in my circles. Maybe it's less, I don't know -- Dave is a little bit more back-ending than I am.

DAVE: Yeah, so it's about open source, and I pulled it from a talk by Jacob Thornton, @fat on Twitter, where he did a talk about why does open source suck and I hate it, or something. I'll try to find the link for the show notes.

CHRIS: Oh, really? So he doesn't necessarily agree with this.

DAVE: Well, he just was kind of doing the history, and he mentioned Cathedral and the Bazaar, and I was like, "I'm sad about open source, so I would like to learn more about it, the history of it." And it just so happens that this is an amazing, like, I don't know, almost prophetic. It just describes open source to a tee. I don't know. Maybe I'm getting too far ahead.

CHRIS: Well, we're dedicating our entire show to this, so I'm sure we'll get to all those concepts. But, it's old. That's something that you should know about it before we start talking about it. Not, whatever, 1800's. It's old for software.

DAVE: 1997.

CHRIS: 1997 was the first draft of it, I think, and then it has been updated a number of times and possibly expanded until the version that me and Dave read is from the year 2000, and I don't believe it has been touched since then. There is a book. I ordered it just because it seems like I enjoyed this, so maybe I'll read the book. I'm not sure how different the book and this essay are. Even just finding the essay to read is slightly challenging. It's hosted on a website, but the website looks like it's from about that time.

DAVE: Yeah.

CHRIS: The content has bit rot a little bit. In fact, I downloaded a PDF because I wanted to take notes in it and stuff. I thought it might be nice, a format that I could jump across to my mobile and stuff, as I was reading it. Like any text that italicized, for some reason doubled up in my PDF.

DAVE: Oh.

CHRIS: It's like, what happened there?

DAVE: Well, yeah, it's probably not even UTF-8. It's probably encoded in Latin, ISO 8859-1.

CHRIS: It could be. Yeah. Yeah, definitely.

DAVE: There's your problem.

CHRIS: It's just to set the stage here a little bit. We were trying to read a piece of content that wasn't exactly a typographic masterpiece, which kind of fits the vibe, in a sense, of this thing.

DAVE: Mm-hmm.

CHRIS: It is written by a man named Eric Steven Raymond, and apparently he's often referred to as ESR because he's made quite a name for himself through this essay and book and his work. He's kind of a Linux dude. I don't know much about him, so I'm not going to give the story of Eric's life or anything here. All I've done is read this essay of his. The whole deal is, so it's an unusual title, isn't it, The Cathedral and the Bazaar? It's kind of an amazing title for something. It seems like a kind of book I would read. Right away, he explains what's a cathedral and what's a bazaar. He just goes right into it. Do you want me to hand that off to you, Dave?

DAVE: Sure.

CHRIS: Or should I explain?

DAVE: The cathedral and the bazaar are two different style of development. There's the cathedral, which is the: Yeah, we planned everything. We architected it really well. And when it ships, it's perfect and immaculate.

CHRIS: Big brick walls. Nobody is allowed in. Nobody can see in. He likens that to--and this shows its age a little bit--the eMax software, which has been around a long time, still is around, but apparently there's a team that works on that editor. It's not open source. It's just like there's this core team of people that work on it, and they put out releases sometimes, and it just is what it is.
I guess if we're likening it to modern times, it might be something like anything that's closed source like Apple software or something, or even GitHub isn't open source. We get what we get from team GitHub.

DAVE: Mm-hmm, yep. I think it brought up, like, Microsoft in the late '90s, 2000s, or early 2000s, or Apple now, which is hard to admit, but they are very wall of garden.

CHRIS: Sure. It's just anything but open source. It's like there's a team of developers that work on this thing. This is the cathedral we're talking about. For everybody that uses that software, you just kind of get what you get, versus the bazaar, Dave, which is?

DAVE: The bazaar is sort of the Linux model, which is just pandemonium. If you think about it like people selling garbage in the street or whatever, trinkets or things, it's just a million people. You don't control a single one. Let's make commerce happen. That's the approach.
He really gloms onto Linus Torvalds and the whole Linux explosion, which was happening.

CHRIS: I could read a passage, potentially. Maybe that would be useful.

DAVE: Oh, yeah. Let's read it.

CHRIS: "Linus Torvalds's style of development: Release early and often," which is, how often have you heard that? That probably came from this essay. "Release early and often, delegate everything you can, be open to the point of promiscuity came as a surprise. No quiet, reverent cathedral building here. Rather, the Linux community seemed to resemble a great, babbling bazaar of different agendas and approaches aptly symbolized by the Linux archive sites who'd take submissions from anyone." Or, in my PDF, "anyone anyone," because it was italicized. At first I thought it was a cool touch to this.

DAVE: Like he's really poetic.

CHRIS: "…who'd take submissions from anyone, out of which a coherent and stable system could seemingly emerge only by a succession of miracles." That's how he starts out, but yeah.

DAVE: I think that accurately describes a lot of open source software, if I'm completely honest.

CHRIS: Sure. He's comparing that, and Linux is the ultimate example because it has thousands of contributors, and everybody has got their own agenda, what they want to work on, and stuff. There are a bunch of rules, as we'll go through in this essay, that are all kind of interesting and largely stand the test of time, and lots of quotes from this are still in the modern vernacular. Like, part of the Linux thing was that -- what's that one? We've said it on this show a number of times, I think, that, "Given enough eyeballs, all bugs are shallow."

DAVE: Yep.

CHRIS: Have you heard that one? That's from this essay.

DAVE: "Linus is Law," that's from here.

CHRIS: It's "Linus's Law," that ESR--

DAVE: Got dubbed.

CHRIS: Dubbed or--what do you call that--coined?

DAVE: Coined, yeah.

CHRIS: Yeah. Okay, so it's just a really nice sounding metaphor for two different styles of development. It then goes on to tell a story, and Eric's story is largely him looking at Linux and a few other projects and a project that he is running. He works on mail fetchers, and they all have different names, but this is a long time ago.
First of all, let's set the year tone a little bit. Again, this was originally written in 1997, and revised through the 2000s. What was happening during that time?

DAVE: Well, I can tell you because I went to college in 1998. They sit you down, and they say, "Okay. Telnet into this IP address," which Telnet is basically pre-websites. It's like you go into this computer, this IP address, and you sign up for an email. Then you type these explicit commands like, whatever, fetch mail. Then you'll get this really weird GUI that you can kind of keyboard through to open your email, all on these green screens. That was sort of the flavor of the day.
I think he's basically writing a piece of software to run on these types of machines, these sort of very small. They connect over a 56K modem, which was actually kind of fast. But, yeah, this is pre-ethernet, pre-broadband. This is connecting to your email on some server, or you could maybe, I guess, be hosting it and pulling it.

CHRIS: And there was a Web, but it was very early. It was kind of coexisting with things like Telnet, at the time, I think. I think part of his mail fetching was that, I think, at some point he despised having to Telnet in for his mail, and he was preferring the non-Telnet version of essentially email.

DAVE: Yeah, I think he wanted kind of a local client to just fetch the mail, and he ended up calling it Fetch Mail.

CHRIS: Eventually it became Fetch Mail, yeah. That's great. It was things that we recognize today, POP3 and even iMap, that I thought iMap was much newer than that, but apparently was working on that feature even back then.

DAVE: I thought Apple invented it with the phone because they were like, "People are going to want to check their phones and computers and sync."

CHRIS: Yeah, it's funny. CSS2, I think, is about this time. I don't really think of people talking about CSS1 all that much, by that was like end of '96. Then I think it was so weird that really CSS2 is the thing that we kind of think of as normal CSS. It was like 1997, 1998, so that was happening just then. It was clearly not super popular, but was just starting to be birthed at that time. There are a couple of other things that happened around that time that are of relevance to ShopTalk Show people, I think. One is that classic article that we refer to all the time is the Dao of Web Design article, right?

DAVE: Yeah.

CHRIS: That was released in 2000, so that was right about at the same time that this article was being written, apparently a lot of philosophers during this time.

DAVE: Early Web philosophers.

CHRIS: Which is John Allsopp, right? There's an article I published not so long ago on CSS-Tricks called Design for Community, by Derek Powazek, that also has this prophetic feeling of writing. I reviewed it in the context, largely what we're doing now on this show, and that was released in 2001 talking about kind of online communities and stuff. You know, this is an article that fits in that kind of trio.

DAVE: I think what's really shocking is to read an article from, whatever, 1997. It's a book, but it's really just nine blog posts or something like that. It's really weird to read this and almost spooky that it applies so much now. The Dao of Web Design is another great example of that. It's like, whoa, this is the same. Nothing has changed. Oh, my God! No progress. I found myself approaching it from kind of three different ways. I approached it from, obviously, I do open source. How do I make websites or how do I manage open source projects? That was the first one.
I've thought about it from a product perspective. We're doing a DayTrip. You're doing CodePen. How do you build a product? I feel like there's tips and stuff.

CHRIS: Yeah. Well, it's impossible for us to have read this without bringing along our personal experiences here. Certainly, we're going to try to attach some of these principles to those projects and just see how that goes.

DAVE: Yeah. The third one was also as a user and of companies I like and stuff like that. How do I kind of perceive things in that way? Yeah.

CHRIS: Yeah. Yeah, and was this prophetic, is the question. I think it was in some ways and not in some others. The easiest way to go through this is probably by the rules because I think that's what drives kind of the momentum of this article. He's telling stories, but then kind of stops to say, "Here's one of the rules."
One of them, because he was working on these mail client fetcher things, was that he came to realize that the reason he was working on it and spending time on it was because he really wanted it. I guess that's obvious, but he had this desire to have a mail fetcher program for himself that did the job and did the things he wanted it to do. In fact, he talks about hacking on a feature that he really wanted and stuff. The very first rule became: Every good work of software starts by scratching a personal developer's itch. Now think of the way he put it there. People still say that verbatim.

DAVE: Yeah.

CHRIS: I don't know if he was the first person to ever say that, but if you grabbed 100 startup people, like founders, literally 100 of them and line them up, and they couldn't hear each other. You said, "Give me your one minute elevator pitch," I bet 75% of them would say, "Well, it's just trying to scratch my own itch, you know."

DAVE: Yeah.

CHRIS: It's become trite. It's become, like, gosh, I hope you are. In fact, maybe it's just a pet peeve of mine, but gosh; you better be. Maybe it came from this. Maybe it didn't. Maybe it just has entered the culture of the world, but people still say this all the time.

DAVE: Yeah. This is number one software philosophy. I know Rails did this to the max. I was intending this to knock me off my feet, but this was something I've been thinking about. Have you used apps where you're using it and you're like, "No one from that company actually uses this application"? A new one for me is maybe Twitter for Windows. It's like clearly the people working on this don't use Windows. Another one is Twitter, the phone client. I'm picking on Twitter, but it's like they're running some A/B tests now, and it's just like, "Have you guys ever used your app?" because your decisions are horrible. Or when you're scrolling Twitter and you hit the little "follow" guy button on the right rail because that was the only place you could scroll. Uh! Anyway.

CHRIS: You're trying to solve a problem that you have. Then, Dave, you've kind of extended it, which I think is apt to it needs to keep scratching your itch.

DAVE: Right. Use your software. If you're not using it--I don't know--it just doesn't make sense. You're not aware of your problems I guess would be what I'm kind of saying from a software thing. I think, in some open source stuff, I'm getting dangerously close to that. I don't use FitVids that much. We'll probably mention FitVids 100 times in this show, but I don't use FitVids that often, and it is sort of just sitting there because I don't use it.

CHRIS: Well, we definitely will get to that because it's going to talk about our own project. It really quickly moves on to the second rule. Eric was working on some POP stuff, and it turned out that I think a different project was a little more robust and stuff. He kind of was like, meh; was faced with kind of a fork in the road. Do I stick with this one, or do I move to this other one and kind of put my development effort behind that? There's already some existing code here that I could use. The rule becomes: Good programmers know what to write. Great ones know what to rewrite and reuse.

DAVE: Boom! Mic drop.

CHRIS: Yeah, that's kind of a big deal. Still something we talk about on ShopTalk regularly and it often comes up just because of the kind of topics that we talk about on ShopTalk, just because of what gets sent in and stuff. I'm just going to drop WordPress here, a large, open source project, but it comes up in the: Should I code my own CMS or use WordPress? Should I use this plugin, or should I do it my custom way? Should I use this tool or not, or this other tool?"

DAVE: Should I use Bootstrap or Foundation?

CHRIS: Yeah.

DAVE: Well, great programmers know what to write or good ones know what to write.

CHRIS: He's not saying great programmers use Bootstrap. He's saying great programmers know when to use Bootstrap and know when writing their own thing would be useful.

DAVE: Which I think that's huge. That's almost revolutionary to the discussions we have on ShopTalk.

CHRIS: Sure. We should just refer to this and be like, "Should I use Bootstrap?" "Well, if you're a great programmer, you'll just know." [Laughter]

DAVE: Yep. ShopTalk--you heard it here--has been replaced by a book from 1997 - entirely.

CHRIS: Mm-hmm.

DAVE: Oh, God. But this one was good too because he's like, "Should I write my own mail client from scratch? I have a little bit of code to do that. Or should I take this one?" And he kind of chooses to take this. He actually had a choice of two. He said a novus coded version.

CHRIS: It was clever, but clearly showed the immaturity of the product.

DAVE: Yeah.

CHRIS: Then there was one that was a little bit more well-coded, but I think he would have kind of had to start from scratch with the new work that he had to put into it.

DAVE: Yeah. It was so rigid, he had to kind of tear it down, learn it, and then figure out what was going on.

CHRIS: What guided that decision was Rule 3: Plan to throw one away. You will anyway. He's saying, "You know what? I'm going to have to give up some work here. Now looking at this from a step back, I can see that I should probably go with the more mature product because I'm going to have to throw away some code anyway, so let's just do it now."

DAVE: This is good. We're on, like, the first chapter, and I'm already just like, "Oh, my God!" because how often do I? I wait to code something because I'm like, "No, I want to have the best idea right now." It's almost like, "No. Just put out a bad one and then whatever. That might go away, but then you'll do it again and it'll be great."
It's almost like practice. It's like, "Oh, I'm not going to go to the driving range to work on my golf swing."

CHRIS: I work with Alex at CodePen. He's very good at this. He knows, and he's good at vocalizing. He's like, "I'm just going to code this because I know it's going to suck and I'll figure it out." Even in this, I'll quote from the article. "Or, to put it another way, you often don't really understand the problem until after the first time you implement the solution. The second time, maybe you know enough to do it right." It's like, just code it once, and then you'll kind of wrap your head around it, and then you can recode it. I'm awful at this. I often think if I'm going to take the time to do it, I'm going to take the time to do it right, but that's not the case. You should take the time to do it knowing that this code is -- it's almost like FPO code (for placement only).

DAVE: Yeah.

CHRIS: …for design….

DAVE: If I was the guy in the 1940s in academia, I'd be just smoking a pipe by a window for, like, 12 hours a day. Then I would just write one word. That would be my style.

CHRIS: It bugs me in music too when somebody is like, "I haven't put out an album in eight years. I just need to be in the right, perfect mood for it. Oh, inspiration has struck, blah, and I just spit out this album, and it's amazing."

DAVE: "One take. One take."

CHRIS: Why does that perpetuate itself? It's like I want to listen to the person who wrote 50,000 songs and then the fifty-thousand-and-third song is well practiced. They learned a lot along that journey of writing a long of songs and that became the thing because that's probably closer to the truth. You can say anything you want in a story, but you don't write an amazing song, or you don't write ten amazing songs, without writing a couple hundred mediocre ones - I feel like.

DAVE: Yeah.

CHRIS: Stop perpetuating the myth.

DAVE: How many Tom Petty tracks are just on the cutting room floor?

CHRIS: Right.

DAVE: He ended up accidentally writing….

CHRIS: But it makes a better interview to go, "Oh, I just rented a cabin in the woods and just watched the stream and a beaver was making love to his beaver wife."

DAVE: "Taught me this riff."

CHRIS: Yeah. [Laughter]

DAVE: Gosh. If I had a dollar for every--

CHRIS: It's certainly a better story than, "I wrote 10,000 garbage songs."

DAVE: --every beaver taught riff. All right. But, you know, there's a thing going on in open source, like nodey land, where it's like code is disposable. I don't know if you've heard that. That's a really--

CHRIS: Poet is poetry, so thus poetry is disposable.

DAVE: Whoa! That's a transit of property. I react to the "code is disposable," and I'm like, "No, it's not! Not my precious babies." But I think a good developer knows, yeah, you kind of have to go because you don't know the dragons ten steps down the road yet. You don't know those dragons, so you just have to get to those dragons as fast as possible, probably fail, and then start back over.

CHRIS: Of course, it's precious all the way up until the end, until you don't care about it at all anymore, which is another interesting juxtaposition. It's kind of like there's a moment at which maybe there's an open source project that you held dear for a little while and then maybe slowly, or maybe all of a sudden, you're just like, "I don't care about this anymore."

DAVE: Yeah.

CHRIS: Dave, you mentioned FitVids a little bit. I don't know if you're at the moment where you absolutely don't care about it at all anymore. I think we've talked about this in private in the past where at one point we were going to have this idea. It's not a totally original idea, but it's one where we'd have a standardized sunset graphic that you could apply to repos to just try to make it as visually clear as possible that this is done.

DAVE: Yeah, this has sort of lived its life. Yeah, I think, for FitVids, I've had Ken Howard chip in and help quite a bit, so that's been really great. If you're listening, Ken, thank you. I think it's probably time where, yeah, you need to hand off your baby to somebody who cares.

CHRIS: The rule is, in the article, number five: When you lose interest in a program, your last duty is to hand it off to a competent successor. Dave, you may be in the process of doing this.

DAVE: I'm super bad at this, but I'm bad at this in life, I think, too.

CHRIS: I think, at the time that he was writing this, it mattered a little bit more. There just wasn't as many. I guess maybe it's not necessarily true because he was kind of saying there was five, six mail fetcher things. But it just kind of seems like today--I don't know--I have some repos out there that are a drop down alternative. It's not that good, and I don't have a lot of evidence that there are a lot of people using it. I don't care if I pass it down to somebody else. Maybe I'm breaking this rule, but it seems like just sun-setting the thing seems to make a little bit more sense, if not just wiping it off the face of the earth. I guess that would bother an archivist.

DAVE: Well, that's an interesting thing. If you're just releasing a plugin or something or, here, this is how you do this, that's maybe one thing. But, what qualifies as a program, I guess, is maybe the question too. That's tough because some people probably depend on that program. Maybe a whole university depends on this Fetch Mail thing he built, and he doesn't know or something. That could be pretty devastating to a large organization, but maybe that's the thing.
Maybe it's just your duty to hand it off to somebody who can make the mature decision. Maybe you, as the owner or something, aren't capable of making a rational decision because you've put so much heart and mind into it.

CHRIS: We'll see. I think that's one where it seems like a good rule, but maybe, at least to me, doesn't apply to absolutely every piece of open source software. Remember, this was long before, it seems to me, the explosion of open source. In fact, I don't even know what version control looked like back then. Was there version control as we know it? Was it?

DAVE: It was like CVS. He gets into it in the next chapter here, chapter two: RCS and CVS, which are just weird versions of SVN.

CHRIS: I think there was stuff, though. You could tell who did what, and merge conflicts and all that stuff existed then, but maybe it wasn't. It's not like GitHub and BitBucket are today, even more specifically GitHub because it's so public. You browse around it and see what's happening in open source. It's really changed how things go. There's just everybody, anybody is blasting stuff around on GitHub.

DAVE: Yeah, it would be more like SourceForge where, if something got lost or broke and then the developer disappeared, it's kind of gone forever because you have no idea where it comes from or who does it. I don't know if you've used SourceForge lately, but it still suffers from some of the problems it had in the '90s, which is just kind of like it's a lot of weird information and ads.

CHRIS: All right, well, there is another chapter and many more rules to go over. This is all very interesting. I think I should mention that the show is brought to you in part by--

DAVE: Lynda.com - we nailed it.

CHRIS: We did it. It wasn't quite a melody. We just kind of sang the same note there.

DAVE: Yeah.

CHRIS: It worked out, though. It's Lynda.com/ShopTalk is where you go to to get your ten-day free trial for the world's largest online training thing. We always say that because it is that.

DAVE: The world's largest online training thing.

CHRIS: Yeah, well, it's a website, so certainly you could go there, but they have apps for all your different devices and stuff, and you log into those apps. Then your world comes with you, meaning you can create and save play lists of things you want to watch or, as they say, customize your learning path. Or you can share with friends if you have other people doing Lynda.com too, and colleagues and team members, take notes in there, and download them if you want so you can watch them on other devices. Each course has transcripts to follow along with, or you can kind of search for stuff, search for code, search for answers. Check out the table of contents of each.
It's like 3,000 courses, and that's just courses, let alone individual videos in those courses because they're all kind of multi-video things. You learn step one, do this stuff, meaning like there's a class called iOS development with Swift, essential training. That's one of their ones that's going to be a big, like this is the most important course in Swift land and Lynda. You watch the first video introducing--

DAVE: Essential training.

CHRIS: E-s-s-e-n-t-i-a-l.

DAVE: Essential training, Swift. Sorry, I interrupted.

CHRIS: No, it was good. You work your way through the course. It's not like, okay, here's a video. It's four hours long. Press play and see if you get anything out of it. It's broken into chunks. You watch a smaller video. There are files that go along with it. There's a transcript that goes along with it. Then you work your way through it, kind of marking your progress as you go. It's just kind of well laid out that way, so check out Lynda.com/ShopTalk. Let's talk a little bit -- oh, yeah.

DAVE: It's basically essential oils for your brain.

CHRIS: Omega-3 for your head.

DAVE: Omega-3 for your brain. Put it in your brain. Chapter two: The importance of having users.

CHRIS: That's its title. I didn't even think of it as chapter two, but I guess having users is important. He kind of just talks about in this chapter that his Linux obviously has tons of users, and your best users -- it was funny though that the users of this kind of software that he was talking about and using, the people that tend to be those users, he even says here, "Properly cultivated, they can become co-developers." It was maybe a different time, different products.

DAVE: Yeah.

CHRIS: A lot of the stuff we work on, I wouldn't expect your average user to just start committing code back to you.

DAVE: I mean that could happen maybe on GitHub or something.

CHRIS: Sure, or even maybe on CodePen here and there, but yeah.

DAVE: He does kind of draw a big line between coder and normies, you know. He's very, like, normies don't get this stuff, so you want the coders. I do like the idea--his number six--which is treating your users as co-developers is your least hassle route to rapid code improvement and effective debugging. We always are like, "Focus on the user." Treating your users, this was interesting to me because you're always like, "User-centered design, user-centered UX," blah, blah. But I don't think of them as co-developers, but in a lot of ways they are.

CHRIS: We could replace co-developers with "with respect," or "with enthusiasm," in a sense. Maybe co-developers too, but if somebody sends you a bug report, it's kind of like treat it with the utmost enthusiasm and respect. They're doing work for you.

DAVE: Right. Not to cross synergy too much, but I was just listening to the CodePen Radio Podcast about social media, and your users will tweet things and tell you about bugs on twitter. In a lot of ways, because you have such a developer audience, your users on CodePen are kind of co-developers. Do you see them that way?

CHRIS: Yeah, the guys talk about this a lot. I kind of have been used to it. At somewhere like CSS-Tricks, people will be like, "Oh, there's a problem with this comment form. You should add this line of CSS to fix it." I've always been like, "Oh, yeah, you're right." That's kind of new to these other guys, and they're always amazed by that.
Somebody will send in a pen with the demonstration of how to fix something somewhere else on the site. They're like, oh, that's crazy.

DAVE: That's kind of fun.

CHRIS: Oh, I think this should be a feature. Here's how it would work. It's very much like that at CodePen. Not every project is like that, of course, but it remains true that treating your users as theoretical co-developers can be a good plan.

DAVE: Yeah. I've gotten a CodePen comment that I had a typo in a code comment on a CodePen before, and I almost quit my job. But again, thorough is good. What, is that the next point in this whole thing? We already said it, but with enough eyeballs, all bugs are shallow, right? That's one thing he ends up saying.

CHRIS: Yeah. It's coming up, I think. I wonder. He also gives credit to Linus Torvalds. He brings it up a lot, and this is kind of a related point that I think is interesting. He says, "In fact, I think Linus's cleverest and most consequential hack was not the construction of the Linux kernel itself but rather his invention of the Linux development model," which is interesting, right? He used clever art, but perhaps his most clever thing was getting thousands of developers to build something cohesively.

DAVE: Yeah. Keep going. Sorry.

CHRIS: He says, "When I expressed this opinion in his presence once, he smiled and quietly repeated something he has often said, 'I'm basically a very lazy person who likes to get credit for things other people actually do.'" Which, that's part of the plan there too is to be coy about it, but really--I don't know--he says he's taking credit, but you know he's not really. He's doing it with a grin kind of thing. Then he says, "Lazy like a fox." That's clever, you know.

DAVE: I want that on my tombstone, "Just lazy like a fox." This is interesting. It's cool that he's citing Linus a lot, kind of like borderline idol worship--I don't know where--probably a six on that scale. Is that right?

CHRIS: Yeah, six and a half.

DAVE: Six and a half, creeping up, but then Linus ends up kind of being a total d-bag. You've read those articles, right?

CHRIS: I didn't know that, actually. Is that the case?

DAVE: He just berates people, and he's like, "You F-bomb, tooting F-bomb, toot faced dude."

CHRIS: Did something happen in his life that made him like that or it turns out he was always like that? I don't know.

DAVE: Well, I think it's either two things. I think it's either you become this hard crusted troll man because he had to do so much open source software and have to deal with so many people chipping in their bad opinions or good opinions, or he's just maybe this, you know, punchy kind of guy, you know, like this charismatic guy who just basically says things for shock and awe, maybe to control the room or the email thread, but more or less it sort of has created some caustic environments. There may be some posts over on Model View Culture about it. I realize Model View Culture has some debates around itself as well, but it's just this kind of idea that he's maybe kind of a very harsh individual and very alienating to people kind of learning and wanting to help, I guess.

CHRIS: That's weird. I wonder if that was always the case. How could it have been so successful so early on if he was that caustic that early? It kind of seems to me like maybe the caustic stuff came later, but who knows. I don't know. I don't know the story.

DAVE: If you just Google Linus Torvalds a-hole--

CHRIS: I know. I just was.

DAVE: --you get a few hits.

CHRIS: Okay. That's how you might get some opinions on it. All right. He did mention at the end of this chapter that there have been other software products with two-level architecture and two tier user community that combined a cathedral mode core and a bazaar mode toolbox. I kind of like that too that this isn't necessarily just straight up two sides: you either go this way or you go this way. I'd like to think that I could use that more effectively. I guess I can get into that a little bit more later, but how does it even effect you, Dave? With new products you work on, you're probably not going full open source with DayTrip, right? But is there some way that you can leverage some bazaar action with it?

DAVE: Yeah.

CHRIS: Maybe you will go for open source. I kind of doubt it.

DAVE: No. At some point you can't. Once you're hosting users' data, I can't hand over keys to my server. I guess I could make it open source, but I probably just wouldn't sort of maybe for security kind of reasons. But I don't know. I think you do this very well where you talk about your business.
One thing, my father-in law, he's a rose farmer. He farms roses for a living. He's like, "So, Dave is going to these conferences." He's talking to my wife about this. He's like, "Dave is going to these conferences, right?" My wife is like, "Yep." He's like, "And he's just giving away trade secrets. Is that what's happening?"

[Laughter]

DAVE: Jessie's just like, "Yep." And so I think it's this interesting thing. It's like we are very sharey, you know. All of our -- we don't--

CHRIS: I was trying to think of this the other day. I was like what is it -- so rose farmers don't share, but I was like, I wonder. Do chefs share? It's like, yeah, it kind of seems like they do. They're all about sharing food and just how they do it, and it's usually no big secret. It's just practice and stuff. Then I was like, do doctors share? Yeah, of course they do. They can't wait to get published in a medical journal and stuff.
I was struggling to think of one that's not sharey. We pat ourselves on the back for being sharey, but is it true that most professions aren't? I guess rose farmers aren't.

DAVE: Well, yeah. How do you grow a rose in extreme heat? There is some sharing, just like you have to do this, blah, blah, blah. But if you think of sales, sales is kind of a big one. People are very kind of secrety about how they make sales happen because it might involve some kind of weird manipulation or something.
But there's also people in software who are like, "We did this. I'm going to tell you about it in exchange for attention, so you'll think I'm cool and use my product." Does that sound right?

CHRIS: Mm-hmm.

DAVE: But, I think what you all are doing with CodePen, you're sharing your process very transparently. I think that's kind of as close as you can get, or maybe that's the two tier. It's the cathedral and the open source because you guys have this cathedral, the CodePen system, but it drives a lot of open source collaboration, and so maybe it's both.

CHRIS: Yeah, perhaps. But part of the bazaar is people that come in, they have their own agenda, and actually work on the core thing with their own agenda, and somehow that still kind of works out.

DAVE: Yeah, it all comes together. Could you imagine doing CodePen in the open?

CHRIS: No, and that's one thing I guess we could take a break to say that what are some things about this essay, so far even, as a whole, that it didn't address. To start that discussion, I would think one of the things is money. Really, I think it barely touches on that. I don't know. Maybe I just missed that part and I'm just an idiot or whatever. But, it seems like it would be distasteful, possibly, for us to -- I don't know if it's distasteful.
I guess I just don't know how I feel about it yet, but it seems like I want CodePen to be a business that makes money for me and the people that are a part of CodePen. It's a business. It's a carpet cleaning business. You expect a carpet cleaning business to make money for them and theirs, right? This is a Web version of that. It's not a hippy colony or whatever. I am trying to not be rude about this or whatever, but I'm trying to be like, "It's just a business."

DAVE: Not a hippy colony.

CHRIS: To be like, "Everybody, help me. Everybody, come over here. Start writing code." At what point does that seem distasteful? All these projects that are talked about in all this thing are free. They're open source, free products. Nobody pays for Linux. Nobody pays for eMax.
What about products that you want to make money off of? That's kind of the point. How does that factor into cathedral and bazaar? Do you have to use cathedral then?

DAVE: Well, it's interesting. Yeah, I don't know. There is this idea. People are like, "You can't make money off of open source." But Automattic is a trillion dollar business, right?

CHRIS: Very true.

DAVE: I think it's just this idea that, well, Node.js, or whatever they are now, ioNode, whatever those guys are [io.js], that's open source, and then people sell the support to float the boat. That's what Ember is doing as well. They have Ember as an open source product, and then they sell the premium support to large orgs.

CHRIS: It would be a different business model. It could be done too. It could be done for any of the projects we work on, but it would be like, "Nah, we'll just make all of CodePen free, but we'll make some kind of enterprise product that you can install behind a firewall or whatever, and we'll charge for that, or there'll be some support contracts we sell or something. Maybe there's some very specific premium features. I don't know, but it would be different than what we do now.

DAVE: Mm-hmm. Yeah.

CHRIS: Anyway, I guess it doesn't necessarily draw a line in the sand, but it does feel like certainly money and business model factor into this, and it's just not covered.

DAVE: Yeah, there's another book by Richard Stallman who is mentioned in this. It's a free book called Free as in Freedom, and it's all about open source as well, but it's a bit older. It's not email clients, which are super hot this last couple years, by the way, but it's printer drivers, so it's a little rougher read. Maybe that's the next book the next time we do this.
It's a little bit more about how to get hackers attracted and what is a hacker. There's actually another RSB article about hackers. I don't know. Every time I read a hacker article, it sort of reinforces that neck bearded--

CHRIS: An awful word.

DAVE: It reinforces this male coder in a basement stereotype that I don't like. Anyway, I don't like reinforcing that stereotype, so I'd say it was a stereotype asset dummy.

CHRIS: Or it means nothing.

DAVE: What?

CHRIS: Yeah, okay. Anyway, let's do a sponsor quick. Oh, gosh, there's so much open source going to be cooking at this thing, the CSS Dev Conf. The URL, if you go to CSSDevConf.com, it'll redirect you to the year. This is 2015 CSS Dev Conf, its fourth year aboard the Queen Mary in Long Beach, California. [Boat horn sound effect]

CHRIS: That's right.

DAVE: Trying that out.

CHRIS: That's right. Try that toot. I wonder if they'll blast the horn. There are three huge smoke stacks on the thing. I wonder if they burned coal to run this ship at one time.

DAVE: Oh, yeah.

CHRIS: They probably--

DAVE: It shipped out in, like, 1919 or something.

CHRIS: I know it's super old.

DAVE: Oh, yeah.

CHRIS: This is before nuclear power.
[Laughter]

CHRIS: October 26th through 28th, so it's coming up here in a few months. It's going to be super beautiful out there, I'm sure. Can't wait. Jina Bolton, me and Dave, Val Head, Jonathan Snook, Sara Soueidan: those are some people.
Go to /speakers or you look at the schedule to see who is going on. They actually do a really nice job with the schedule too. It's using one of those services where you can kind of line up your day. What do you want to see and when? Sarah Drasner, Philip Walton, Gregor Adams -- oh, this is going to be fun.

DAVE: The schedule, I got that the other week. It looks hot.

CHRIS: This does look hot, and it's multi-track, but not multi-track such that you are going to miss things that you want to see because people vote on the things that are very good. Then, at the end, those presenters redo them, which is pretty cool. For sure, if you go to the very end, we'll see the best stuff. Oh, look at that: 4:00 p.m., closing keynote, Dave Rupert.

DAVE: Uh-oh. I think I just figured out my talk, and it's going to involve Alan Alda, so look forward to it. He should be there.

CHRIS: Oh, very nice. Yeah, I'm going to be bouncing around just saying hi. I'm going to do a Q&A kind of thing, which should be pretty good. Cool. CSSDevConf.com is the URL for that. It's going to be a good old time. Please come to it.
As this goes on, one of the most more obvious chapters, perhaps, that pretty much everybody buys into: Release early and often. In fact, that's rule number seven, literally: Release early and often. It's just one of those things. Do work. Get it out there. Let people see it and react to it. That's way more bazaar-like than cathedral-like.
Although, you've got to guess … if Apple is developing Final Cut Studio 8--I just made that up--they must have some internal release thing. It's not like they can just -- I mean they must be releasing to some group of users to find bugs before it ships out the door.

DAVE: Maybe, or maybe they do a master merge month.

CHRIS: I don't know.

DAVE: It's just like, "Okay, everybody. Land your plane. Let's go." But I would hope they do something. But, anyway, this is really good. I think I've seen this in my own life. The second you kind of stop releasing often, it just sort of--

CHRIS: Inertia.

DAVE: Inertia just plummets. You could almost chart a drop off graph about it.

CHRIS: You can get it back, but yeah, certainly, once you've stopped for a minute it becomes more daunting in your own brain.

DAVE: Yeah, not necessarily the project is more daunting. Let's use FitVids as an example. It's maybe 30 lines of code, and people have committed 3 lines of code, but I'm like, "Uh! It just takes -- uh! That's like 10% of the code base! Uh!" I have an unhealthy attitude, but it's because I've lost the momentum. Yeah, I've even seen this on DayTrip with closed source, but in the switch to Windows, and this is the full transparency.
Ruby on Rails is pretty busted in Windows right now. I think it's going to get fixed this week, but it's pretty busted, and so it's really hard to get that up and running. And so I haven't. I've been mostly Windows, but there's been a couple times I had to bounce over to fix something, but I haven't done much on DayTrip this month, and that's a bummer because it's basically slipped a lot of opportunity and momentum. But, I'm enjoying Windows, so I guess there's a tradeoff. But anyway, I've noticed in my own life that "release early, release often" affects your happiness.

CHRIS: I think it's affected to bugs, right? If you release often and a bug happens, it's like, well, it was related to this very small release. It's very easy to see where that bug came from, which is related to the next thing, which is basically the rule is: given enough eyeballs, bugs are shallow.

DAVE: He makes a really good argument for this, I feel like, because he's saying release early and release often, and all bugs are shallow thing, go hand-in-hand because, if you don't release often and you ship a bug, your users will be like, "Uh, this is going to be buggy for weeks, months, years."

CHRIS: Oh, I see. But if you have a regular release schedule, you're like, "Eh, no big deal. It'll be fixed next week," kind of thing, or at least that's the perception.

DAVE: Yeah, you have kind of a mindset going on, an internal mindset. But he also makes the point. He's like if I build something and I test it, I'm probably not that thorough, or I'm focused in on one thing. If I even hand it off to a Q&A team and do a whole Q&A cycle, and maybe they are only looking for the things they look for. You actually don't get a 100-person test Q&A suite until you release it to the public.
He makes a really good kind of rule. It's like, if you ship it to Q&A, it'll get bounced back by Q&A if there's a bug, and maybe you've saved yourself some time. But if you ship it to everyone, it'll still get bounced back to you. It's like the Q&A step is almost superfluous, kind of unnecessary. Now we probably automate a lot more testing than they did back then, but I don't know.

CHRIS: The shallowness comes from, given enough eyeballs, it's like there's enough people looking at the code base that the fix is obvious to someone, as they say. It may seem weird to you, like, "Oh, that's a weird bug. It feels daunting to me." But somebody is like, "Oh, I was just looking at that code. I can go grab it." But it's not necessarily enough, but it's enough with wide coverage. I've definitely seen very large apps, and a bug comes along. Unfortunately, even though there are a lot of people that work on the project as a whole, there's very few people that look on just the billing portion of this app or something, or if somebody left, and they were the only person that knew a lot about that code, and now there's somebody struggling to look at it. It's not just the number of people. It's the coverage.

DAVE: Yeah. You have more dark corners if you kind of silo everything up, right? Yeah, no one is working on billing. Well, guess what. Billing is broken now. You don't find that out until later.

CHRIS: In this chapter, he brings up the Delphi effect too, which I hadn't heard of. But the way he kind of describes it is similar to the wisdom of the crowds, which I think is more common these days to talk about. At least the wisdom of the crowds, maybe you've heard of it.
It's like if you go to the fair and there's a cow. You ask 2,000 people how much the cow weighs, almost nobody knows how much a cow ways. But, for some magical way, the average of those people, when you remove the really ridiculous outliers, is usually really, really close - or how many gumballs are in the gumball thing. You ask enough people, the average is usually really, accurate, which is super weird, right? It's like one of the coolest, weirdest phenomenon I've ever heard of, but it can apply to software development too, and the number of people kind of working on a project can have those same kinds of effects.

DAVE: Yeah. That's maybe people kind of using it, right? Not necessarily developing on it, because he also talks about Brooks' Law and The Mythical Man-Month.

CHRIS: Observers, yeah. Yeah.

DAVE: Yeah. I got into The Mythical Man-Month. He cites a formula about the number of developers and then the communication load. After three developers, basically the communication load goes higher than your progress, so that was interesting.

CHRIS: It has to do with maintaining the software, right?

DAVE: Yeah. Brooks' Law is--

CHRIS: More users find more bugs, is the point, right?

DAVE: Yeah, that was more users find more bugs, but the converse is you can't just throw developers at it. That's kind of Brooks'.

CHRIS: Yeah.

DAVE: Like The Mythical Man-Month.

CHRIS: Oh, I see.

DAVE: It's just basically that. The interfaces between code written by different people, or bugs tend to strongly cluster at the interfaces between code written by different people, and that communications coordinations overhead on a project tend to rise with the number of interfaces between humans. It's, basically, you count the number of nodes between people. Let's say there are two people. There's one node in between people. If there are three people, there are three nodes.
Then, after that, it's a spider web, and there are so many points of communication where problems can happen. It's basically like, the number of points of communication equal the number of problems you're going to have on software, sort of. I'm paraphrasing it badly, so yeah, hey - chapter seven.

CHRIS: Yeah, there's so much to talk about here. We're only half or a third of the way through this, potentially, and we're already coming up on an hour, so maybe we'll power through. We'll just go through a few more of the rules without the context, potentially, just so that you guys get a taste of this more.
I think number nine here, way down, is that smart data structures and dumb code work a lot better than the other way around. That's hard to do without context, but maybe we'll just let that sit there.

DAVE: Have better data than smarter code. Number ten: If you treat your beta testers as if they're your most valuable resource, they will respond by becoming your most valuable resource.

CHRIS: Dun-dun-dun.

DAVE: It's sort of a self-help axiom, so that's good.

CHRIS: We talked about that a little bit already, I think.

DAVE: Yeah, that makes sense.

CHRIS: The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better, meaning that your users ideas might be better than your own. A very strong, very modern concept as well that has stood the test of time. I feel like that's talked about very often is that it's pivoting and words like that are related to this.

DAVE: Yeah. Well, in his situation, it paid off huge because he was able to offload a whole bunch of gnarly, bad code to this guy's idea, so I thought that was pretty darn cool.

CHRIS: I didn't even think about that, but it's true. It's like we get a good idea from a CodePen user. We implement it. They're happy. Theoretically those other people like them and they're happy. But, in the world of open source, you'd be like, "This is a really good idea. Let me work on it, and can you please come help me work on it because it's your idea?" You're probably interested in doing that. It's a way in for some smart people, for you to get some smart people to work with you.

DAVE: Yeah.

CHRIS: Very cool.

DAVE: Well, and recognizing that, "Hey, that is a smart idea. Let's do it," is very strong. Otherwise you're just sort of like: If you just say yes to everything, or even if you just don't accept good ideas, you're not going to get good help, I guess. That's the other thing. He doesn't talk about how to deal with bad ideas, and that's interesting. By anyway, that's maybe another whole podcast.
Number 12: Often the most striking and innovation solutions come from realizing your concept of the problem was wrong.

CHRIS: Yeah, that's similar is that you've had an idea for your thing, but you better be willing to realize that it was wrong. It should be treated with equal weight: your good idea and a revelation that an idea was wrong.

DAVE: Number 13: Perfection in design is achieved not when there is nothing more to add, but rather when there's nothing more to take away.

CHRIS: That's a quote from Antoine de Saint Exupery. I forget who that is, but I recognize that one.

DAVE: Yeah, aviator.

CHRIS: That seems a little high brow. You're definitely wearing a buret when you say that. It's true, but also feels very like you're smoking a cigarette with a holder in it.

DAVE: Yep. Writing a medium article, but it makes sense.

CHRIS: It does. It's a good one.

DAVE: Just take things, like strip away. Make it as good as possible, and that fits the Unix philosophy of, like, only do one thing well.

CHRIS: Hmm. Fourteen is: Any tool should be useful in the expected way, but any truly great tool lends itself to uses you've never expected. I think that's the -- what's the good eats guy?

DAVE: Um, blanking.

CHRIS: Shoot. That's embarrassing. I don't, unfortunately. Alton Brown where he doesn't have single use tools in his kitchen. It's like a thing. Anyway, that's what I thought of, but I don't know if that necessarily is exactly right.

DAVE: I think about, like, my son. He picks up sticks, and they are guitars to him, you know.

CHRIS: [Laughter] Sure.

DAVE: No one intended that to be a guitar, but it's a guitar to him, and it brings many people great joy, so there you go. But in software it's probably like, "I didn't know you could use FlexBox that way. Oh, my gosh." There you go.

CHRIS: Good point. Yeah.

DAVE: Number 15: When writing gateway software of any kind, take pains to disturb the data stream as little as possible and never throw away information unless the recipient forces you to!

CHRIS: Write a good API and have queuing servers that don't dump data. I don't know.

DAVE: Yeah, I don't know. That one was sort of very specific to a situation. But, I guess, I don't know. We could probably abstract that into a larger post, but nope; not going to do it.
Then it sort of just takes off, doesn't it? Number 16: When your language is nowhere near turn in complete--JavaScript--syntactic sugar can be your friend--jQuery.

CHRIS: Oh, that's good. Yeah, syntactic sugar is still a very commonly used phrase that came up in some code I was just editing yesterday. In the context of, if you can think of SVG elements, there's and and all of them, . They're all syntactic sugar for the path element, which you may or may not realize.

DAVE: Oh, yeah. I guess so. It's just different--

CHRIS: It was the path you can draw them to. It's just a little more programmatically friendly.

DAVE: Yeah, interesting.

CHRIS: Hmm.

DAVE: Number 17, I liked: A security system is only secure as its secret. Beware of pseudo secrets.

CHRIS: Which again was very specific to this, but yeah. It's security by obscurity is stupid, kind of thing, right?

DAVE: Y'all at CodePen Radio, again, max synergy here, the secrets episode you guys had is a real good example of this because you're just like, "What secrets do we have? Who has access to those secrets?" Those are security problems.

CHRIS: Some of them are very literal like ABW server keys and stuff. What do you do with those? How do you keep them out of Git and that kind of thing? Although, actually, read the article because it was pretty interesting, this one. It seemed like something that was going to be secure, but for obscure reasons it wasn't. Anyway, there's only one more of these, right?

DAVE: There are two more.

CHRIS: Okay.

DAVE: Number 18: To solve an interesting problem, start by finding a problem that is interesting to you.

CHRIS: Very similar to number one.

DAVE: Mm-hmm. Then, number 19: Provided the development coordinator has a communications medium at least as good as the Internet--okay--and knows how to lead without coercion--okay--many heads are inevitably better than one.

CHRIS: It's trying to say many heads are better than one, with a whole bunch of preconditions to that.

DAVE: Right. You have to have email and not be an a-hole, I guess, is the answer.

CHRIS: Two heads are better than one, as long as you, yeah, have -- gosh, that's hard to wrap my head around.

DAVE: Well, I think of it like the node community is probably a really great example of this. They have a very strong core team. You hear the word "core team" a lot. If a core team is good and it can lead without manipulating and politicing background sort of things, that's awesome and healthy. I think they hit the io.js hot drama sort of thing, like, because one company wanted to kind of maintain control, but that's sort of the coercion. So they were like, peace out. We're going to just be a core team over here, and now it's getting rolled back in together.

CHRIS: I guess rule number -- there is no rule number 20. It should have been rule number 20 is that you can have an odd number of rules. It's okay.

DAVE: [Laughter] You don't have to accommodate OCD people who really, really, really wanted to go to 20, a number divisible by 10.

CHRIS: Yeah. We could have talked a lot longer on this because each one of these rules, there are things that we probably could have connected and stuff to our own projects, but this is a new format to us, and we didn't really realize how long we could go on and on about this stuff, but wow.

DAVE: It's pretty great. Again, thanks, Niki and Liz, for the inspiration. Obviously this is a way cool way to do a show, so everyone go subscribe to PageBreak in your podcatcher of choice.
Chris, what did you think of the booklet in general? Was it a good read? Would you thumbs it up? Would you recommend it? What's your feeling?

CHRIS: I would, or just listen to this show. I think we covered it pretty well. No, just kidding. [Laughter]

DAVE: We quoted it verbatim. That's what's weird is you just listened to an hour show. You could be about 85% of the way through the book if you had not listened to this show instead.

CHRIS: Yeah, yeah, you really probably could have been there.

DAVE: Woops. But I think it's so cool. I think it's amazing that a book about software can withstand the test of time.

CHRIS: And it doesn't bother. All the eMax and Linux stuff, it's not bothersome. Maybe it helps that those products still exist, so it's interesting to think about. It's less fun when the things they're talking about are obscure to you or just are already dead and so they have their own baggage or something that you're bringing with it.

DAVE: Right.

CHRIS: But in this case that's not true, so it tends to not be annoying as you're reading through it. I found that to be very true with Design for Community, too, that Derek Powazek book I brought up at the beginning, is that it's prophetic and interesting and very relevant to today. The stuff that's in there that feels old, it's like it doesn't hurt.

DAVE: Right. This is borderline like it starts hurting, but it's still really good.

CHRIS: Right, because there's a few things that have changed. Anyway, so enjoy that. We'll have links to all this stuff in the show notes, of course, all the things that we mentioned. I hope you enjoy it. Let us know.

About the format for the show, of course we'll probably come back to Q&A style ShopTalk at some point. That's kind of the meat and potatoes, but we're just going to explore a little bit.

I also wanted to tell you that ShopTalk is brought to you in part by our sponsors, but also in part by the ShopTalk job board. It's literally at ShopTalkShow.com/jobs, so it works both ways, a job board. If your company is hiring, please post your jobs there. We've had a lot of great success stories of people finding front-end developers, kind of sometimes a rare beast to hire. You know how valuable you are, potentially, if you listen to this show, and for people looking for jobs, especially if you don't like your job.
That's why I love having that there because we can hopefully kind of inspire you to look and see what's out there, and possibly find a better job if you don't like the one you're at. We get questions like that of people that are unhappy about their job al the time at ShopTalk Show.

Here is a particular one that I really think you'll like. The company is called Upstatement, and we just had an article go out on CSS-Tricks. The title of the article is--let me read it verbatim because I love the title of it. It feels a little like BuzzFeedy or whatever, but I went with it--Timber and Twig Reignigted My Love for WordPress.

I was like, oh, that's a perfect title because it's specific. It's got the keywords in there. It was by a guy named TJ Fogarty.
Twig is PHP templating. It's like mustache for PHP, essentially, and Timber is the thing that makes that all happen in WordPress or your ability to use Twig, and it makes your templates look way nicer. Instead of having to write: <?php echo the_title(); ?> There's that stuff all over. You just go, like: {{title}} It makes your templates look good and, while it's doing that, it's kind of separating the view concerns from the data concerns, so it's kind of MV or more like CV.

Anyway - anyway, anyway, that was a big thing, right, Timber and Twig? The makers of Timber are Upstatement, so this is a job that's there, but it's not all they do. It's not like they just make that. They're a big agency, and they do lots of interesting things. When they see interesting things happen, they let it flourish, like the case of Timber.

In this case, it's an agency that the job is a Senior Interactive Designer, which is great. Senior jobs mean money, which is cool, usually. But it's all this stuff. It's like you're qualified. You're almost qualified -- you know, not automatically if you listen to this show, but it's the stuff that we talk about on this show: HTML, CSS, SCSS, being a designer, having a keen eye for detail, that type of stuff.

Yeah, we'll put the link to this Upstatement job in there. It looks like a particularly good one. I've said before on this show when the website you go to for the job looks really nice, you know it's good. They care about their own website, I think that's a really good sign, and this is a hot looking page.

DAVE: Yeah, they've got quite a few jobs, so check it out. Yeah, they also worked on Boston Globe. You might know that site. Hey. Yeah, so that's great.

Well, all right, you've been listening to another episode of the ShopTalk Show. We thank you for listening. Be sure to subscribe to this in your podcatcher of choice. Rate it, star it, heart it, whatever so that people can find out about the show. We really appreciate that.

Yeah, if you hate your job, get a new job: ShopTalkShow.com/jobs. I can't think of anything else. Follow us on Twitter, @ShopTalkShow. Chris, what's the last word?

CHRIS: The Cathedral and the… ShopTalkShow.com.