01:59 - Greg Wilson Introduction

02:37 - What’s Missing?

05:48 - Disconnect Between Computer Scientists and Software Developers

09:09 - How necessary are books?

15:18 - Being Part of a Process vs Starting a Process

17:01 - Software Tools; Spreadsheets

28:45 - Language, Vocabulary, and Theory and The Software Craftsmanship Movement

33:41 - Reinventing the Wheel

36:24 - Crowdsourcing

Picks

Software Tools by Brian W. Kernighan and P. J. Plauger (Greg)
Scratch (Greg)
Techies (Greg)
HTML element standards (Jessica)
Feerless (Coraline)
Félienne Hermans (Avdi)
moonconf (Jessica)

Special Guest: Greg Wilson.

 

Hello and welcome everyone to Ruby Rogues episode 255. Today on the panel we have Jessica Kerr.

Good morning.

Avdi Grimm.

Hello from Tennessee.

David Brady.

[Chuckles] And I'm Coraline Ada Ehmke. We have a special guest today, Greg Wilson. Greg, do you want to introduce yourself?

Sure, hello. My name is Greg Wilson and I'm calling in from Toronto, Canada where it snowed again.

It snowed here in Chicago yesterday too, and I'm kind of done with it.

It's like 70 degrees here.

I feel conflicted saying I want global warming to pick up, but I want global warming to pick up.

Been gorgeous here in St. Louis.

Yeah, there's a lot of savvy land speculation and opportunities out there right now.

I'm still stuck on the gorgeous in St. Louis bit.

We're not that far south of Chicago, but it's beautiful here.

Weather-wise, sure. I can buy that.

[Chuckles] Hey now. So Greg, what are we going to talk about today?

I'd like to talk about what's missing. It's easy to point at things that are out there and critique them or talk about the strengths and so forth, but it's a lot harder to spot things that don't even exist but maybe ought to. And I started thinking about this in the late 1990s when I was the book review editor for Dr. Dobb's journal and I would get in the average week five or six new books on Java programming or three new books on design patterns. They were all basically rehashing the same stuff. And it's like listening to one of those radio stations that plays pop tunes that are pretty much interchangeable. Same beat, same chord progression, same rhythm, same angsty lyrics. And after a while you start to think, where's all the other stuff? And around about 1997 I actually wrote an article for Dr. Dobb's called 'Not on the Shelves' where I said, alright if washing the car makes it rain, maybe if I write some book reviews of books that don't exist, somebody will come along and write the damn book for me.

And for example, pretty much every undergrad program in Computer Science that I've ever seen has a course somewhere in it on compilers, right? How do you write a compiler? And last time I checked on Amazon, there were well over a thousand books in print today on how to write a compiler. There is not a single useful book out there on how to write a debugger. Why not? There are three books. There's even one book called 'How Debuggers Work' except it's a lousy book. It talks at a very high level hand-wavy sort of, “Oh right, you have to think about how you're going to capture information.” Well, that's great. What should I think about how to capture information and what information should I capture and what should I do with it once I've captured it? They don't talk about that. So, why is it that most programmers spend at least as much time debugging as they do coding, at least that's been my experience, and yet that topic just doesn't exist in the literature?

And I've got a theory about that. And my theory is that sitting behind compilers you've got a rich mathematical theory about formal machines and formal languages and translations between them and you can do all this graph theory for compiler optimization and you can do all this algebra on the whiteboard. And you can publish math and proofs and so forth. Debugging, there's not a grand unified theory of debugging. There's just the nitty-gritty details of building a tool that's useful. And that's something that tradesmen do. Gentlemen don't get their hands dirty. If you go back a hundred years… [Chuckles]

I'm quite serious about this. If you go back a hundred years, many of the people that we think of as great experimental scientists never actually touched the lab equipment themselves because they were gentlemen. They had tradesmen who would come in and make the glassware, who would actually pour the chemicals, because you don't want to get spots on your tuxedo. I'm exaggerating a little bit, but people like Michael Faraday were actually an exception that they actually made their own gear and did the experiments with their own hands. Because science used to be something that dilettante gentlemen got involved in. And it took a long time for it to become the craft that it is today.

So Greg, you're bringing up an interesting point and that is that there seems to be a disconnect between computer scientists who are living in academia and software developers who are actually writing and debugging software.

I used to think of it in those terms and I'm trying to get away from that, because I know a great many people in industry who are as… what's the polite way of putting it? As disconnected from the realities of software production.

[Laughs] As they could be. And I know a great many people in academia who are up to their elbows in [cow] every single day, right?

That was a great metaphor.

It describes a lot of the software I work with. So, I think it's part of a mindset. There are architects for example who do not know anything about how to hang drywall. They know a great deal of the [gestaltery] of making a space…

Oh, [inaudible].

Absolutely. And it seems to fall as far as I can tell sort of along class lines. There are people who just don't get their hands dirty and there are people who do. And you can do interesting work in computer languages using multicolored pens on a whiteboard. You can do type theory and you can do the graph theory behind compiler optimization. You can do all of this stuff without ever actually writing a hundred thousand lines of code. We don't have that kind of theory behind debuggers so it's not an intellectually respectable thing, because all you're doing is building useful software.

It's the same struggle I think that HCI has faced over the years, that much of what a good user experience designer does is a craft, not a science. And yes, we can come back and we can do A/B testing and we can talk about human perceptual psychology. But when you take a look at the social status of the various specialties within our field, people who work on operating systems are like the physicists of computing and people who work on the user interfaces, well they're somewhere down there with the biologists, right? And then we've got the marketing types and other further down who nevertheless get paid more. But we won't go there because it's really depressing. So, I see that same sort of hierarchy. And so, you start to see these gaps in the things that we write about.

There's writing at all levels of that, right? But it's not the same?

Find me… I know of one good book on debugging, only one. And it's 'Why Programs Fail' by Andreas Zeller who did his PhD. Among other things he built the graphical frontend to GDB. He built a thing called DDD which draws your data structures for you, which is really useful when you're trying to do C and C++ debugging. But that wasn't the core of his PhD thesis.

Mm.

And this is a book about up and coming debugging tools, things like bisection debugging which Git has popularized. The idea that if you've got a test suite I can just go and run and search back and forth and bisect your history to find out when the bug was introduced. That was possible 20 years ago. We still don't teach it in school. And I'm willing to bet that most developers still have never run into it. So, there was one of the things that motivated me to write this article for Dr. Dobb's nearly 20 years ago, was if I've got five books sitting on my shelf this week about compilers, where is the text book on how to write a debugger? Because it's at least as hard because it's dealing with all the same issues.

It kind of begs the question Greg, how necessary are books to learning how to do things? There are so many other avenues of sharing information available today.

Yeah.

Is a book really the measure of “We have thought about this problem”?

I think it’s a measure of intellectual respectability.

That strikes me as a little classist, actually.

It is. And I think it reveals some of the classism, some of the unspoken hierarchy within our profession. Let me give you another example on this.

Go ahead, Jessica.

By intellectual respectability we specifically mean within the classist system that exists.

Mmhmm.

And how it's defined. And this is a negative that we're missing out because we value certain pieces more highly. There's more status conferred to working on compilers and programming languages than something like debugging that happens to be immensely more useful given the delta between where we are and where we could be, because it's less studied, because it's less prestigious.

And this is the same thing that Andreas Stefik and I were talking about the last time I had the opportunity to appear on your show. What Andreas and his colleagues had been doing is usability testing of programming languages which as soon as you see it is an absolutely obvious thing for us to do. Does syntax matter? The answer is yes. It has a significant measurable impact on the learnability of the language for novices. We can make programming easier for newcomers to learn by changing the syntax of our languages or by picking it more carefully. But he has a hell of a time getting people in the programming language community to pay any attention to his work because it smacks of [well fuzzy] HCI or tree-hugging and eating granola and wearing sandals. And I think that reflects some really unfortunate biases as Jessica said. They're blinding us to opportunities.

Here's another one. And this is one that I'm going through right now. I'm willing to bet that most people listening to this podcast have at some point or another read something about how to start a tech company. If I go through the airport bookstore there are three shelves of books on startups. I

can't count how many seminars and webinars and you name it on startups. Where are the books and the training courses and the blogs and so forth on wind downs?

On…

You see, I helped start Software Carpentry. And at the moment, last fall I stepped aside as Executive Director and we've got a new Executive Director. So, I am stepping away from some of the responsibilities I used to have. The second startup I was involved with in the '90s was eventually acquired. New management was brought in. We were made part of something larger which meant a lot of the responsibilities we'd had were now somebody else's, right? So, for every company that starts up, there's going to be one that winds down. Either it crashes or it gets bought or maybe it continues on but you walked away.

Think about Guido van Rossum. He created Python. He got that wheel going. Then he moved onto other things. How did he hand that onto other people? How did he hand on those responsibilities?

What were the pitfalls? There's got to be at least as much craft in handing the project onto the next person, handing the company onto the next person, as there is in getting it going in the first place. It's just as important if you want the thing to survive. And yet when you go onto Amazon or go to your public library or start browsing on the web, the only stuff I've been able to find is a smattering here and there about how to hand on a family business to the next generation.

I say that the things that we pursue, the information we pursue, tends to be aspirational. I'm going to get a book on learning patterns because I want to know patterns. I'm not going to get a book on how to dissolve a business because that's not what I aspire to.

But do you aspire, if you've started a successful project, an open source project for example, to hand it onto somebody else so that you can go onto the next thing?

That's the kind of thinking that people don't do. People don't do contingency planning and people don't do succession planning, in open source especially. And we end up with projects that are abandoned and someone else comes along and ends up rewriting the whole thing because that's easier than getting up to speed on someone else's project.

And how much of that is circular? How much of this is we don't think about it because nobody's talking about it? And nobody's talking about it because the person before them didn't talk about it? It comes down to things like… and I see an analogy here with some of the other changes that are now finally thankfully taking place in computing. 10 years ago there wasn't discussion about codes of conduct in open source projects. It just wasn't a thing. Now it's everywhere. We've recognized that here's something we should talk about.

Thank you, Coraline.

I would say not everyone feels that way. But we're winning slowly, yeah.

Yeah.

At least the discussion is everywhere.

Yes.

We've made it… we've put it on the table.

Mm.

And regardless of whether people are pro or con, it's no longer something that's neglected. Similarly, I think open source software is now mature enough that there are as you said a lot of projects that are now languishing because we know how to start projects but we haven't really sat down and written down the rules for “How to I hand this off?” How do I do succession planning? If you go into politics, there's an office with however many hundred people attached to the white house and its only job is to manage presidential succession. You go down to Silicon Valley or to Wall Street or any other business center, there are firms whose entire specialization is to manage succession of large companies. We don't yet really have that for our technical projects. If there was a book on how to hand your project onto the next person, or to wind it down if you've decided that its time has passed, I'd buy that. I think a lot of people are now at a point where they'd buy that.

Jessica, go ahead please.

Yes, I think so too. If we want to have a lasting impact with our work, if we want it to outlast us, we need to know how to transition it.

Mmhmm.

Greg, do you feel as if in the computing industry we are uncomfortable with being part of a process? We prefer to be part of starting a process?

There's such a mythology has built up around the cult of the startup. Two guys in a garage and 10 years later they're worth a billion dollars. I kind of wonder whether we're going to start seeing more discussion of succession, of wind down, of the exit as more and more of the boomers start to say, “Okay, I'm done and I'm out.” We've got an enormous wave of people hitting retirement now. And I wonder if that will prompt a new wave of literature. It's a hopeful thought. But again, I'm partly interested in this for its own sake but I'm also partly interested in what it says about our industry, our profession, our view of what we're doing that we are so obsessed with startup.

A friend of mine who's in the military pointed out, there are thousands of books on leadership. There aren't nearly as many on followership. How do you be a good participant in somebody else's venture? How do you behave in a meeting when you're not setting the agenda? It's a skill that is taught in some places. And when you've been in a meeting with people who've actually been taught how to be a participant when somebody else is chairing, we could save so much time and so much wasted energy by teaching followership. But which of those two has higher social status?

Being a leader or being a follower?

And that goes back to Coraline's point about aspirations, about there are books about things people want to do. And why do people want to do this? Well, because we assign higher status to it?

Yeah, absolutely. Here's another one. And this switches over to software tools. Hands down the most popular most widely used tool for numerical calculation in history is the spreadsheet. And people doing big data might sneer at spreadsheets but you walk around and it's what, I don't know, 80%, 90%, 95% of people who are crunching numbers are using. Because if you've got a few thousand values and want to able to see things and interact with them immediately it's actually a really nice tool. It may not scale to larger more complex analyses but most people aren't doing that. So, here's my question. Why can't I diff and merge spreadsheets in existing version control systems? Think about it. A spreadsheet these days, whether it's LibreOffice or Microsoft Excel is stored as a bit of gzipped XML. It's a tree. And we know how to diff trees. And we know how to render those things as grids of cells.

So, the best guess I've been able to get from somebody on the LibreOffice team was that it would be something like three programmers for eight months to build something that would take two versions of a spreadsheet and display the differences in a useful way using the existing rendering engine. So, even if they're wrong by a factor of two it's less than three programmer years. It's less than four programmer years. It's a small project compared to a lot of things that are out there. And it would immediately remove one of the biggest impediments that I see when I'm working with scientists to using version control. Version control won't handle the formats that they use for files. Most scientists outside physics, math, and CS use something like Word for writing their documents. They don't use LATEX. They don't use Markdown. Well, guess what? Version control systems just tell you the binary files differ. They punt.

Most people are using Excel spreadsheets to store their data. The administrators at the university who are handling the grants for the scientists are keeping Excel spreadsheets and mailing them around to each other and manually finding things that might have differed. We could have fixed that 15 years ago in the days of CVS. And you think about it now. How hard would it be for you to design a plugin architecture for subversion or Git or Mercurial that looks at the MIME type of the file and says, “Okay, I'm going to launch that tool to display the diffs”? And we know it's possible because two years ago GitHub started showing you diffs for images because they care about the graphic designers who are building the websites and want to be able to see what's changed in the logo or the photo or anything else. This would make version control a lot more attractive than it is today for literally millions of people.

Because right now, when the grants officer comes and says “What are you using for document management?” and we say, “GitHub. It's great. It works at scale. It lets you all work independently,” and she says, “Okay, let me try putting my spreadsheet in there” and GitHub gives you the middle finger just like every other version control system, she has a choice. She can use the tools that we built to collaborate with us but it means throwing away all of the skills that she has built up to work with this format and all of the tools that she's got for working with her files. We're giving her a cliff to climb. Why is that? Why haven't we built diff and merge for spreadsheets? I think the answer is that programmers sneer at spreadsheets because spreadsheets are for noobs. They're for nontechnical people. Even if those non-technical people outnumber programmers 10-to-1.

I just brought up that feature in the engineering channel on the GitHub Slack. I'm really curious to see…

Mmhmm.

What the responses are. And I may even share them publicly right now. [Chuckles] depending on what people say.

I've asked this question in talks for at least a couple or three years now. And some people say, “Oh no, it would just be too hard to do, because” and there's all these complications and all of these things that Excel can do with macros and embedded VB. And the answer is, “Yeah, it's an 80/20 rule.” It wouldn't be hard I think to build diff and merge that would work for the kinds of spreadsheets that most people actually construct.

You'd have to render the values. You'd have to perform the calculations. I see that being a really difficult thing to do from outside of the spreadsheet application for example.

But we do have a spreadsheet application that is open source. It's called LibreOffice. And it can read the files, render the files, do the calculations. So, if you're using that starting point, you've got something that does 90% of the work. We know how to diff trees. Those algorithms have been around for yonks. I'm not saying it's a trivial engineering problem. I'm saying it's a much smaller thing than many of the things that we build and use routinely these days. Let's say it's 10 programmers for a year. That seems like we can do something.

Is that something that can be accomplished inside academia?

I don't know. It hasn't been. But it also hasn't been accomplished inside industry. Imagine that you were SourceForge back in the day and you were trying to grow your…

It is LibreOffice. It's free software that we're trying to achieve, right?

Maybe. Honestly if I was GitHub and I was looking to grow my user base or if I was Bitbucket and I was looking for a way to attract more users, this makes my system accessible to many, many times more new users than anything else I can think of. Again, I come back to the question of why haven't we already built it? It seems given how much we all love version control like something that ought to exist, and yet we keep saying version control only works with text. Why? Well, because we only use text. Why do we only use text? Well, because it's the only thing that works with version control. And around and around we go.

I've had that discussion in a bar in Austin, Texas after a couple of beers. And I could not get the person I was arguing with to acknowledge there's a bit of circularity here.

It's a blind spot that we have that is the way things are.

Mmhmm.

As developers we're supposed to be really good at spotting those and solving them with more engineering.

It's the story we tell ourselves.

It's almost like we're so busy thinking outside the box that we don't see this gaping hole right in front of us in the box.

Yeah.

I think that one of the things that we can attribute problems like this to, and let's take the spreadsheet example because I think that's a good example, we have different ways that people get involved in tech. And we tend to elevate people who have some from a CS background who have a very strong technical background and we tend to devalue people from non-traditional backgrounds.

Now, I do a lot of work mentoring and teaching people who are for example coming through bootcamps or who are self-taught, people who have had previous careers. We need a diversity of backgrounds and a diversity of experiences to make us aware of the problems that other kinds of people who are not developers are facing in their daily lives. And as long as we are elevating people who have been removed from some of the mechanical work, some of the day-to-day work, some of the drudge work, some of the marketing, some of the design, as long as we devalue people like that we're going to devalue the ideas that they have for software that we can write to make the world a better place.

Absolutely. And people coming out of CS degrees or out of bootcamps, they frequently wind up working in the financial sector for example. They go off and they're building financial applications. They are not themselves financiers. But there's money to be made there and there's a well-trodden path. So, they all into, let's build yet another website for keeping track of your stock portfolio for yet another company on Wall Street or yet another order fulfillment system.

Isn't this where startups are supposed to solve the problem by filling those holes with new companies?

Startups solve problems that face startup founders.

Exactly.

Yeah, yeah. And I think… again, I don't know why the blind spot persists. Most of us have at some point had to work with for example graphic artists. And I would really like Git on the command line to launch some sort of image diff application when the graphic artist has changed some of the assets that are being used in the computer game that I'm working on. Why should that be any different from launching a two-pane [min diff] style viewer to show me the differences between the code that Jessica's got on the pull request and the code that I've got on my machine? They're just different MIME types. They're just different renderables. And yet…

And yet they're cows. [Chuckles] They're deep cows. [Chuckles] They're not as elegant and generalizable as we like to see programming languages that are so easy to talk about and write books about.

Or at least we don't think they are.

Yeah.

And I think it's persistence. The people before us didn't do it so we didn't do it, as much as we like to say we're disrupting things.

And to talk about spreadsheets a bit more, this blind spot, it's not just that programmers… in my view it's not just that programmers view as something they don't need and so they don't see it as something to address their skills to. But programmers actually handicap themselves by not using tools like these and by disdaining tools like these.

Like spreadsheets.

Exactly, particularly like spreadsheets. Let me start with a non-spreadsheet example and then go to a spreadsheet example. No you know, I'll just go straight to the spreadsheet example.

Spreadsheets, numerous times I have seen a programmer want to do some number crunching, want to evaluate some options or something like that and immediately write a script. And then oh, and then they want to compare the options graphically. So then, they have to figure out how to plug their script into gnuplot or something. And then they want to change some of the variables that go into it so they edit the variables and then rerun it. And…

Then we think, “I should use the right tool for the job,” so we switch to Python. [Chuckles]

Right, right. Whereas if they had punched all that stuff into a spreadsheet they wouldn't be rerunning it because it would be rerunning itself constantly. And they wouldn't be thinking which graph plotting library do I want to use here and how quickly can I learn it? Because they'd just be dropping a graph control in. there's an astounding disdain really for graphical tools in general among a lot of the programmers that I've seen.

And one reason that we don't use spreadsheets is because they don't work with version control.

So, we think we can't collaborate with them.

And around and around we go.

Yeah.

I wonder if there aren't some market forces being applied to these types of problems. I had wondered for a long time why the most powerful editors that a developer can use, it comes down to either vim or Emacs. And the reality is I don't want to write a text editor. I don't want to rewrite Emacs. But neither does anybody else. We can make a sexy text editor. We can make something that's like TextMate or Sublime Text 2 or RubyMine and they can solve about 40% of what Emacs solves for me. But that last 60% is really, really hard and not attractive to solve. There's not a strong… I can't put a strong dollar value in front of a startup founder and say, “We should rewrite text editors.”

Your PhD advisors won't let you write your thesis on it.

Right.

Either.

Sure. That's part of it as well.

I had a comment about the programming languages stuff in the very beginning. I've noticed that we focus a lot on programming languages but the language is the least of it. We program in language systems. So, the debugger is a huge deal. The version control is a huge deal. The graphing library. All of these pieces are not glorified the way that the language itself is. And you brought up the point Greg that this is because we have a language, I don't mean a programming language. A language about the language. What is the word? Well in this case, we have mathematical models and things like that. We have a way to talk about programming languages. Once the first book on design patterns emerged, oh we have a whole new vocabulary to talk about these things. Let's all write more books. But we don't have a theory behind debuggers. I want to a theory and vocabulary around dependency management.

I'm wondering if this, Jessica and what you're talking about and Greg, going back to something earlier you said about the difference between the gentlemen scientist and the person working the lab, is this a failure of the Software Craftsmanship movement?

Mm. That's very distinct from Software Carpentry.

Yeah.

I don't know. I don't know enough about the Software Craftsmanship movement. There are enough other people playing in computing that we could equally well say it's a failure of Silicon Valley. Again, I don't want to beat up on either Atlassian or GitHub but if something would make their platform accessible and attractive to millions of new users and they haven't built it when the effort required to build it is so much smaller than the effort required for things that they are kicking out with every release, there's got to be something I'm missing. There's got be some other reason why this isn't happening. And I don't know what it is.

But our theory, or one theory is that developers are valued more highly than researchers or business people or all the people in the world who use spreadsheets.

Well, developers get told to do a whole lot of things that they don't personally value. I'm speaking from experience here.

And I imagine you've all been handed jobs that were just, “Why am I implementing the tax law for Kansas in this Java application?” The answer is because somebody wants it and they're willing to pay me.

The answer is because no Ruby programmer would bother.

[Chuckles] Oh.

[Laughs] Oh, nice.

Ouch. So, there's that. Here's another one. And this has come out of the work I've been doing with Software Carpentry over the last few years. Just to poll by voice, how many of you have ever edited a Wikipedia article?

I'm it.

Yes.

Nope.

Okay. So, more than…

No.

Okay. How many of you have ever contributed to an open source software project?

Yeah.

Yes.

Yes.

Okay. How many of you have ever sent a pull request for somebody else's lesson?

Somebody else's lesson?

Yep.

For the audience, Software Carpentry is a program for teaching software practices to scientists.

Mmhmm.

Because scientists need programs and a little bit of, “Here's how to do Python. Here's how to do SQL. Here's how to do version control,” goes a long way.

Yeah. So, right now as we're recording this it's a Tuesday in April. I am willing to bet that across the United States there are hundreds if not thousands of high school teachers prepping lessons on how to multiply polynomials. And they're all building their own and they're all using their own which makes as little sense as having every single programmer build and deploy her own PayPal fulfillment module for Rails. We solved this…

But that's so much easier than adopting someone else's project.

You're being sarcastic. I can tell because your lips are moving.

[Laughs] Hey.

Right? But I'm serious. I understand that teachers want to personalize lessons and they want to make it more relevant for their particular audience. But every website that I've ever built was a little bit different from the one I built before. But I reused things that were out there and I contributed back to them. Now, there's an open educational resource movement, OER. But every OER project I've seen is basically a repository. I create it. I upload it. You can download and use. But there isn't that feedback loop where you can then almost trivially send me improvements or fixes. There's no equivalent of the pull request. And it isn't even part of the mental model. And I don't understand, why not?

Teachers are a very tight-knit group. They know each other. They're at the school together. They marry each other. They work together for years. So, there's a strong sense of reciprocity. It's a strong expectation that if I help you it'll pay forward and eventually somebody will help me. They're all working on the same problems. There's only so much geography you can teach in high school.

We've got a limited amount of geography to teach.

I wonder if, because you talk about these teachers that are all reinventing the same exact wheel, and I wonder if the reinventing it almost from scratch, they're teaching polynomials but they're going back to fundamental algebras, right? They're going back to geometry.

Sure.

They're starting from Euclid. They're ignoring everything between Euclid all the way to the modern day except for Pythagoras who came after Euclid. But anyway…

Take your college education for example.

Yeah.

I'm willing to bet that most of the classes you were in, the person teaching the class had written a slide deck that was being put up in front of you. And if she hadn't, she'd inherited one from whoever taught the course previously and she made some tweaks to it. But they weren't crowdsourcing those slide decks in the way that the Wikipedia article on Green Lantern has had however many…

Thousands of contributors.

Mmhmm.

Or the docs for the Python standard library had had however many thousands of contributors.

Right.

Or clearly we're able to craft prose en masse.

Right.

Because we do it with documentation for software. We do it for Wikipedia. But for some reason that is so rare for lessons that outside Software Carpentry in the US Navy. I cannot find a single working example of people doing it at scale. Last year alone, we had more than two…

I have an example of that, actually. Girl Develop It in RailsBridge both have open source curricula for Ruby and Rails and they do accept pull requests. And it is on GitHub.

Right. Those are programmers who are taking the practices they learned in programming and saying, “This is the hammer I've got so I'm going to treat teaching like a nail.” And that's great. That's how it happened with Software Carpentry. We have people who are doing, they're using GitHub and Markdown for their scientific project. So, it was very natural for us to put our lessons there and then use the whole pull request, pre-commit review, file an issue cycle for developing the lesson. But why isn't that ubiquitous already? Why isn't it, if not ubiquitous, why isn't it at least common? The tools for doing that have existed since the late 1990s. Ward Cunningham invented the Wiki in what, 1994, somewhere around there.

Mmhmm.

Okay. So, the technology we need is there. Wikipedia has familiarized people with the process. I read somewhere that high school teachers in the United States are 40 times more likely than the average citizen to contribute to Wikipedia, which makes sense. They're using this stuff in their classrooms. They probably know a little bit about the domain. They can't stand typos. Perfectly natural that they would have the technical skills and yet they don't translate it over their teaching.

They don't translate over to the thing that they do day to day.

Do you think there's a collective phobia? Because you're talking about… when you… I get this image in my mind of what if we crowd-sourced how to teach math and we came up with a single right way to teach math. And all of a sudden this sounds like standardized testing, no child left behind, and black kids dropping out of school because the crowd-sourced thing was ultimately written by privileged upper middle class kids.

There isn't a single PayPal module for Django. Last time I checked, there were three or four that were viable, each of which has different decisions embedded in and it plugs in with different things. So, I would expect that if you're doing a lesson on, I don't know, the American civil war that there'd probably be a dozen out there that would be large enough to have critical mass. And what you're going to teach about the American civil war in Maine is probably different from what you're going to say and how you're going to say it in Kansas or south side of Chicago or New Mexico.

Or Georgia, yeah.

Or Georgia. Right. Certainly we teach the American rebellion differently than you do. You call it a revolution and as far as Americans are concerned George Washington is a hero. We have reservations about that up here in Canada. But you know…

Practice safe government. Use a monarchy. I understand, even within a project the size of Rails, and let's face it. There are probably fewer Rails developers in the United States than there are high school teachers. You do see multiple viable alternatives for solving various problems. And that's a healthy thing. But you don't see one per developer.

Right.

And if you saw one per developer you would say that was broken, because of course whatever a newbie junior programmer wants to do is write everything themselves from the ground up. And we say, “No, no, no. That's not how you do this.”

And that's actually kind of the point that I was saying, where I was headed to when I said that math teachers are starting at Euclid. They're ignoring everything that's happened in the field of geometry since then. And well, when they're creating their lessons is what I mean. And that's what I'm wondering is… because you're asking why are they not crowdsourcing this? Why are they not? And I'm wondering how far apart… so, on one extreme we have one right way to do it and on the other extreme there's nothing to share, what are the market forces that are operating on these teachers? We know that they're altruistic. We know that they're community-minded. Do they know that there are resources? Is there a market force against sticking your neck out and spearheading a project? Let's teach the Battle of the Bulge. Here's a unit on that. Use it if you want.

So, I've got a long list, a growing list of countervailing forces. There are no professional incentives. Okay. That will knock some people out. But it won't knock out everybody. Or the curriculum has been completely standardized and you have to use this text and teach this lesson. Okay, that knocks out some people but that doesn't apply in every jurisdiction.

Yeah.

So, what we seem to have is either a collection of partially effective filters that between them knock out almost everyone which seems unlikely, or there’s something I'm missing. There's some really big thing. And as is often the case with social issues, I look at technology and I want it to be a technical problem because then we can solve it. But it's clearly not a technical problem. Wikipedia is proof that the obstacle is not technology.

Oh, wow.

Right?

If we look at this purely… I love that you talk about these overlapping filters as countervailing forces. Is this a similar model to the social forces that build up to create intersectionality?

How would you find out?

Okay. And we had you on the call last time and we talked about creating experiments. That's actually my question to you, is how can we find out how much these countervailing forces… how do we design experiments and run them?

I don't know that this would be solved by a controlled experiment. But it's the sort of thing that… the sort of person who works for a think tank in Washington, the sort of policy wonk who goes off and figures out, why don't banks provide services to low-income families in rural areas? It turns out there's half a dozen reasons and they all tie together. Somebody like that has exactly the skill set to go off and look at this and say, “Oh, okay. Here are the five reasons. And here's how they interact. And it's a complex problem to solve but here's where you start pulling on the piece of string.” Again, based on my experience with Software Carpentry as soon as you have people working collaboratively on lessons the way we all work collaboratively on software, the lessons improve much more rapidly. Because instead of one person teaching them once or twice a year, you have dozens of people teaching them dozens of times a year. So, you've got a much tighter and more rapid feedback loop.

But then the question… there's a question there of do we get better at teaching the majority or will it actually broaden the people that we can teach?

I think that one of the things the internet does is give people who are thin on the ground a chance to connect with each other. If you are the only person within driving range who has a particular view of English literature, you want to build a course that reflects your view, you've got to do the whole thing from scratch. If you can collaborate through something like a GitHub or a Wikipedia or any other online platform you can find people who share your perspective on English literature and you can collaborate with them to build something that reflects your collective view. And if at some point you decide that Jessica and I just have very different perspectives on French-Canadian literature in the 19th century that's okay. We fork the lesson.

Yeah, that's a really important distinction to make, that when you're crowdsourcing you need to leave room for different crowds. Because if you're defaulting to what the majority of people believe… there are wars that rage on Wikipedia over controversial topics and things that should not be controversial but are as people with different ideologies go back and forth and back and forth. And Wikipedia is incredibly political. It is not a neutral source of information. So, I think as long as you're talking about education, teachers should be tailoring lessons to the students that they have. They should be speaking from their own experiences for the sake of authenticity. So, if you're proposing a grand unified theory of this is how you teach subject X, I would be really scared of something like that. But as long as we're allowing for different viewpoints and different communities to have a voice, then I would more readily agree with what you're saying.

And I'm proposing this precisely to escape that one grand unified theory. As Jessica has just said in the chat that of course people on the podcast won't be able to see, there is one Wikipedia is a problem. And in some ways, I view forges like SourceForge and GitHub as a response to that shortcoming of Wikipedia. They make it easy for us to fork and go our separate ways. There is one Wikipedia. So, we're going to have to fight for control of the content in the article about Green Lantern, because really I regard him as a minor figure in the DC universe. And…

Oh, you shut your filthy mouth.

You see?

Hang on. I got to [inaudible] something.

Okay, so…

We're taking this to reddit where it belongs.

That's right.

[Chuckles] Right. Okay. So, GitHub and other platforms that make it easy for us to fork allow us for better and for worse to go our separate ways. And again, I wouldn't imagine that a lesson on the causes of the American civil war is ever going to satisfy everybody. And that's why they fought over so fiercely. It's because they do matter. And if you've got this view of there is one textbook for the whole state of Texas, it matters which textbook. Once you get to some sort of a federated model where people can reflect their views and the views of their community and their experiences and their history and their needs and find like-minded individuals who can support them in doing that and they can in turn support, it becomes feasible. It becomes affordable to offer a proliferation of lessons that address different needs just as there's a proliferation of PayPal fulfillment modules for Django that fulfill different architectural needs or different design styles and so forth. My question is why hasn't it already happened?

I was just realizing as you were talking about this that picture a teacher who is exhausted. She has her hands tied by bureaucracy. She's joined the teachers union just out of desperation and some way to try and defend herself. And at some point she just wants to go home at four o'clock and be done with the day. This is a person who when you say, “Hey, why don't you build a whole bunch of stuff and give it away?” it's kind of like software companies in the mid-90s when we started talking about giving away software. And they were like, “Well, open source is all well and good. But I don't want to give it away. I don't want to give our proprietary stuff away.” And it wasn't really until, at least out here in Utah which granted is like 10 years behind the rest of the world, like around Y2K… that's actually not true. Salt Lake's actually a hot bed. But anyway, like around Y2K, 2002, that time period, there was almost like a sea change where companies started actively contributing to open source. And the thing that caused it was there was now a very large corpus of open source stuff that the people who were, like you talked about, the people who are not getting paid to generate this stuff are passionate and they do go generate it. I wonder if some of these things will start to shift once that tired teacher can look at this and not see, “Oh, gosh. Stuff I have to do more,” but rather, “Oh my gosh. I can just have this be done for me. I just have to go pick which set. I like the way this person is teaching this. I don't like the way they're teaching that. I'm going to use this module and tie it in here and I'm done.”

That's a 'not yet' argument. It's “Yeah, we're going to get there but it hasn't happened yet.” And I'm…

Yeah. Yeah, the corpus doesn't exist yet.

And I'm always suspicious of those because I think they're an easy way out. Because I have friends who are still die-hard communists who believe that yeah, of course it's going to happen.

Just not yet. And I have friends who believe a lot of other odd things.

Mm, that's fair.

And they're all absolutely confident. And there's no way for me to respond or falsify a 'not yet'.

And that's fair because in 1996 there was no predictive element to open source software that it would ever go anywhere.

In 1991 I actually wrote a fairly lengthy email message to my boss explaining why open source software was just never going to work.

I wish I'd saved a copy.

I do want to say that we are seeing… there is one area that I'm pretty happy about where we are seeing open source being used by non-developers to good ends. And that is something that I saw for the first time last year where a company took its employee handbook and put it on GitHub and opened it up for change requests.

Yeah.

So, I think that's a great idea of sharing common knowledge, not… giving people a starting point, opening things up for a discussion of “Is this a good policy to have? Is this something that's problematic? Is this something that's going to server all of our employees well? Is this something that reflects our company values?” So, I think we're at the beginning of seeing open source tools being used for things besides software. But it is a little frustrating that it's not everywhere yet.

Yeah. Completely agree. I hope so. And General Motors turned into a finance company that happened to build cars. If 10 years from now hubs like Atlassian and GitHub have turned into places where you teach that happen to have a version control system [inaudible], I think that's actually a pretty nice future.

This has been a great conversation, Greg. But I know you're limited on time. So, I think we have to get to picks. And we'll let you get to picks first.

Okay. First pick. If people haven't read the original 'Software Tools' book from 1976 by Kernighan and Plauger they should. It's 40 years old and still ahead of its time. I believe very strongly that the books that Brian Kernighan and others wrote are the real reason for Unix's success. It's not that the operating system itself is so much better. It's that they explained their view of computing so clearly and so compellingly that after you'd read something like 'Software Tools' with a Unix programming environment, you simply couldn't see programming through other [eyes]. And I still don't know how they managed to do that. I've done a lot of writing and I have never achieved what Kernighan and his co-authors achieved over and over again back then.

The second one, I had been playing around a lot again with Scratch. And for those of you who haven't seen it, it's a programming tool meant to introduce children to programming. And it's blocks-based. You drag out the blogs and connect them together. You snap them together like Lego. My daughter has just turned nine. She started Scratch when she was six and she's coming back to it now that she's able to actually build more complicated things with it. I think the rest of us could learn a ton by going back and re-experiencing that and asking why the vims and Emacs and Bashes of this world and god help us, Git, are so much harder to use. If nothing else, working in Scratch again has given me a fresh set of eyes to see just how complex programming doesn't have to be.

And there's a lot of work now on reviving the idea of frame-based editors, of really properly structured editors to take away a lot of the mistakes that aren't necessary. There's no point letting you type in a program character by character. All you can do is make typos. The structure of a loop, the structure of a function, they're all there. So, why are we not composing those the way we compose elements when we're using a drawing package? This is an idea that comes back every 10 years or so. And playing around with Scratch has reminded me again just how much better tools could be. So, whether you have kids or not, go off and play with it and ask yourself what would it look like if something like Scratch was built into the browser so that those of you who want to script things a little, who want to automate repetitive tasks, could do it without typing JavaScript. You could just connect blocks together. There was something like an ‘if this then that’ built into Firefox as a way of automating it. I think the world would look very different than it does today.

And my third pick is one that just came up. And I don't know how many people have seen TechiesProject.com. And I will paste the link into the chat to make sure that it goes up. Techies, TE-C-H-I-E-S project, all one word, dot com. That's my third pick and should probably be the first. It's a collection of stories from people who are in the tech sector who are from groups that are underrepresented and not heard from as often as they should be. I spent most of yesterday reading through those stories and learned a lot. And I'm not ashamed to say I cried a couple of times. So, if readers are looking for something to remind them how much better the world could be and how we're going to get there, I suggest they check it out.

Awesome. Thanks so much, Greg. Jessica, you have some picks for us.

Okay. My pick is HTML 5 elements. So the other day I learned that there's elements now called main and output and aside and there's even validation built into HTML element properties. The browsers and the HTML standards, they're making it so HTML can be expressive. And having learned HTML in the days of we do all our arrangements on the page in tables with TRs and THs, I'm like astounded that I can write HTML that I don't hate. So, Mozilla has some good reference material up for this. I'm going to pick the new HTML element standards.

Awesome. David.

This is going to surprise everybody but I don't have picks today.

What?

I know, right?

It's like you don't have any opinions.

Right.

It's like you don't even care anymore.

It's true. It's true. I'm just phoning this in. No, I have a document that has my list of picks and the document has run dry and the only item in there that's not picked, I just checked our picks page and I've already picked it. So, those of you that have a 20-minute commute left in your commute, I'm sorry.

[Laughs] Well, thank you anyway. I have a pick. This is kind of cool. It is called Feerless, F-E-E-RL-E-S-S. This was developed by my new colleague at GitHub, Daniel Leon. It basically is crowdsourced preemptive notifications for Netflix watchers who have PTSD or other content sensitivities. So, if you are one of these people not knowing when a potentially triggering moment is coming in a Netflix episode or show can lead to anxiety, Feerless removes the unknown by providing you with the power to take control of your Netflix experience with simple non-invasive notifications.

//feerless.us. And that is my pick for the day.

Oh, Avdi. I forgot Avdi. Oh, no. Avdi, what's your pick?

My pick today is a person. It is Félienne Hermans. I'm not sure if I'm pronouncing her first name right. But she is a software engineering researcher. And she has a lot of interesting research going on. One of the things that made me think about her during this episode though is she's done a whole lot of speaking on various topics around merging software engineering and working with spreadsheets. She's talked about bringing software engineering best practices to spreadsheets and unit testing and done a lot of interesting stuff around that. So, you can find her work at her web page which is www.felienne.com

Oh, I have another pick. It's Moonconf. This is a last-minute conference. If you happen to be in Boulder in late May and you want to go to a conference about functional programming and community, Moonconf is May 26 through 28th I think. And it's going to have some sessions and some un-sessions and be about how we can be compassionate and empathic and great functional programmers.

So, a very fun show. Thanks to all the panelists and thanks to Greg Wilson for joining us. And we will see you all next week. Thanks.