164 RR Staying Sharp with Dave Thomas

The Rogues talk to Dave Thomas about keeping up and staying sharp in programming.

Special Guest: Dave Thomas.

 
DAVE:

Yeah. I’m jolly good, y’all.

Hey everybody and welcome to episode 164 of the Ruby Rogues Podcast. This week on our panel, we have David Brady.

Now with 100% more Daves.

James Edward Gray.

Not a Dave.

Avdi Grimm.

Hello from Pennsylvania.

Saron Yitbarek.

Hi from New York.

I’m Charles Max Wood from DevChat.TV. And we have a special guest, Dave Thomas.

Hey everybody.

So Dave, for the handful of people who aren’t aware of who you are, do you want to introduce yourself?

Sure, I think program…

Um…

Oh, sorry. [Laughter]

Alright. Yeah, I’m Dave Thomas or pragdave on the net. I wrote ‘The Pragmatic Programmer’, was one of the authors of the Agile Manifesto, and in terms of Ruby Rogues, wrote the original Pickaxe book back in 2001.

But your name’s on the current Pickaxe book.

Oh, yeah. It is indeed. A labor of love is to keep maintaining that as Ruby grows.

And that has to be challenging as heck as things like complex and stuff make it into the core. I can’t imagine how hard it is to redo that back section every time.

Actually, you know what? The back section, the reference, that’s the easy part.

Really?

Oh yeah. And it’s infinitely easier. The first time I did that, I had to do it by reverse engineering the C code, because there was no documentation at all. And that’s actually one of the reasons I wrote RDoc, because I thought if I give them a tool that they can use to document the core as they go along, then it’ll make my life easier, because I’ll be able to see what they think these things do. So, that was totally self-interest. So, because of RDoc it’s now a lot easier for me to do that.

What’s really hard is the first section, the first half of the book. When things change, you can make lots of little small changes to reflect the various small changes that happen. But over time, this is tension that develops because we discover better ways of writing Ruby. And so, every now and then I got get in there and basically just slash and burn and change a whole bunch about the way things get done.

But that’s not too bad. The real challenge for me recently has been keeping up with Elixir, because that revs about once every two weeks. And typically, it is not compatible, because it’s still pre-1.0, so very happy to break things. So, that has been a challenge.

That’s right. So, you’ve been doing a lot of Elixir. Why don’t you tell us how you got into that?

Well, I got into it because I’ve been looking to find a functional language that I could practically.

Good luck.

Yeah, yeah, yeah. [Chuckles]

And I never quite, Clojure came closest I guess, and that was relatively recent. I’ve been looking for a long time. And I wanted a language that I could use, I could explain to people, I could show people why I thought functional was cool, and never really found one I liked. And I was talking, oh, a couple of years ago to Corey Haines. He said, “Well, you should have a look at Elixir.” And I’ve had a look at it once already and I don’t know what, I was in a bad mood or something, I didn’t like it. So, that night I was in a hotel with him. We were doing a course together. And I went up to my room and I downloaded the latest Elixir and I was still playing with it three in the morning, which is bad because I was supposed to be teaching the next morning.

And I felt the same way I felt the first time I downloaded Ruby in that here was something that was useful. It thought the way I thought. And it had that same kind of slightly sloppy feel that Ruby has. It doesn’t tell you exactly how to do things, but you get to play around a bit. And I really enjoyed that. So, I started writing more and more Elixir code and just experimenting with stuff. And I was having a blast, because it’s the first time I’d really done any volume of functional code. It was the first time I’d had any volume of concurrent code done in a way I thought I’d be proud of. And I was just, like I said, I was having a blast. So I thought, “Okay. Maybe this is the next language I want to get into.” And the way I learn a language typically is I try writing something about it. And so, I started writing about Elixir and ended up with a book.

What was that you said, slightly sloppy feel. I like the sound of that. Can you explain what that is?

Well, Ruby and Elixir have ambiguities in them. They have multiple ways of doing things. They don’t feel as prescriptive as many other languages. So, as a programmer, it makes me feel like I have choices and I can express taste, because I can choose to do things this way or that way. And I can think of a reason why I want to do it that way, or just it looks better or whatever it might be. And because of that, I think they draw you in. They make you more involved in the programming that you’re doing. And so, to me that’s a big deal.

Do you like being on the forefront of the language curve? Because I feel like you pretty much brought Ruby to the western world. And so, you were definitely on the front of that curve. And now you’ve been doing a lot as Elixir is coming of age. Do you like the languages that are still finding their place in the world?

Well, yes and no. The reason I found Ruby is that back in the 90s, I was subscribed to Compline [Misc], the Usenet group. And I would download every new language anybody ever mentioned just because I enjoy programming languages. I enjoy trying to find ways to express myself. And for me, a programming language is one of the tools I use to do that. So, I like looking around at different languages. I don’t typically like something because it’s shiny and new though. So, a lot of the new stuff I see coming along, I avoid like the plague, because mostly that’s faddish. And it doesn’t actually add much to the art. It’s all just bright, shiny things on top of the same old, same old. So, I’m not particularly drawn to the vanguard of languages as much as I’m looking for something which actually moves things forward. And Ruby, I thought, Elixir, I think is doing that. And I’m sure there are other languages as well.

So, can I ask? I have a friend that has a podcast called Mostly Erlang. He’s doing an episode today about why the cool kids don’t use Erlang. And I’m wondering, is there a major difference between Erlang and Elixir that makes you like one more than the other?

Yes. And interestingly, this is not particularly contentious in that Joe Armstrong pretty much agrees. The evolution of Erlang is basically it came from Prolog by way of Haskell. And it as a syntax which is very much a kind of compile and run syntax. It’s fine. It’s a bit quirky, but that’s just syntax. You get used to it. But what Erlang doesn’t have is a dynamic side to it. It’s very much a fixed language. If you look at Elixir, it instead has a full macro system, which means meta-programing.

That means in terms of the Erlang environment, is that it makes it a whole bunch easier to use the facilities of Erlang like OTP. So, if for example you’re writing Erlang code and you want to write an OTP server, the canonical way to do it is to copy and paste about 100 lines of boilerplate into a buffer somewhere and then start filling it in. With Elixir, because you can meta-program all that boilerplate code, you just say, “I want to be a server,” and that’s it, using what is it, gen_server or using server.

That is an interesting approach. There’s a book that was really enlightening to me years ago. I think I’ve even picked it on the show. It’s called ‘Principles of Object-Oriented Design in C and C++’. And the first half of the book, they build up things like encapsulation, privacy, inheritance, everything. And you’re just using Struct. And when you call a method, it’s like Python where you have to pass the ‘this’ object as the first argument. And then he finally reaches a point where you need templates. And C++ can do templates. Actually, that’s also inheritance you can’t do in C either without using macros. And at the point when you get to inheritance and templates, he basically says, “At this point, we do actually have to go to C++. Sorry.” And he moves onto the next level of dynamic.

And I watched a programmer build a suite of tools in C that used this inheritance. And literally what he did is if the compiler would say, define my favorite class name to be this model, now include this .c file. Not a .h file, but include this .c file. And it had macro insertions for all the structure names and elements. And then he had an endif and then he had the next thing of define and it was the same constant and he gave it a new class name. And then he did an include on the same .c file. And it was god awful. It was just absolutely byzantine. And I cocked my head and I’m like, “Wait a minute. You’re implementing inheritance using C macros.” And he’s like, “Yup.” I’m like, “Why don’t we just do this in C++ because this is a C++ compiler,” and he went, “Oh.” [Laughter]

It’s not as fun that way.

Well, he’d been programming since 1970. It was like, “I’ve been programming since before C++ was a thing.”

I’d say that I’ve played a fair bit with Erlang back a couple of years ago now. Not as much with Elixir, though I’ve seen Dave show it off a couple of times. And I would say that the syntax I think did bother me more than some languages. One of the things that really bug me in Erlang is the three different line endings. So, you got comma, period, semicolon at the end of each line, which basically means anytime you have you reorder lines, you’re basically guaranteed to be wrong in multiple places. [Chuckles]

And so, it’s really annoying to fix.

You’re absolutely right. That does suck.

Another couple of problems I had with it were interacting with Unicode. And I believe that’s gotten better, but I did before that. And then using a simple regex, I had something and I just need a simple regex to do this, and that was a nightmare. But I love the pattern-matching and the processes of course are what make Erlang amazing. So, I think Elixir is a neat twist because you get those niceties of the underlying stuff, the pattern-matching, the processes, and stuff like that, with a much prettier interface painted on top.

It’s not just the prettiness of the syntax. It’s for me, I always was sad that things like method definition and most of the control statements in Ruby were hardcoded. And in Elixir, they’re all macros which means that if you want to, the kind of meta-programming that you do to do things like say decorate a method or add advice to it or something, is really, really straightforward to do. It also means that because pretty much everything can be invoked via macros, that you get incredibly good control over the scope of the changes that you make. So, I can change the behavior of a particular thing for one particular parameter in a method call. It’s the accuracy that you get from that is fantastic. Although it is in a way just like lipstick on top of the pig that is the Erlang virtual machine, it does a lot more than that. It does a whole bunch of stuff at compile time very, very smart. So, that really does make it a joy.

I want to go a little bit meta on this conversation. And the thing that really fascinates me about you and about your approach to a lot of this is just your, it seems like you just go out and explore things. You see something that looks interesting and so you dig into it. How do you pick the things that you’re going to jump in on? How do you know which projects look interesting and when do you decide to give up on them?

Ooh. The first part, easy in that many things just… it’s taste, isn’t it? How do you know what movie to go see? It’s the same kind of thing. You look at what people you respect are interested in. I used to have this rule that if something came up three times in a month then I’d go look at it.

And that’s still a pretty good bet.

That is a great rule.

So, I’ll go play with things. The trick is knowing when to abandon them. And that’s exactly the problem, because if you get in there and get, say frustrated or you decide that something’s not very good, it could just be your own stupidity. You’re not getting it and you need a bit more experience. There are some things that I get into and I don’t like simply because of taste. Honestly, every probably two years, I say to myself, “Okay. This month I am going to like Python.” And I’ll sit down and I’ll spend that month writing Python code. And I have never ever managed to make it stick. So, there are some things which are just purely taste that you abandon.

But the rest of the time, it’s really, I guess the decision is, “Is it paying back?” So, I’m sitting here. I’m investing time in this thing. Am I getting something out of it? What I’m getting out of it is insight. What I’m looking for is ways of developing my craft and getting better at what I do. So, if it’s not paying back in terms of giving me new insights, then I’ll move on to something else. And I’ve reached the point in my career where insights don’t come from sexy new syntax. It comes from new ways of thinking about things.

So, one of the things that are keeping me really interested right now in the functional programming side of things is realizing that functional programming and pattern-matching is actually equivalent to writing programs as parsers. And so, it’s really interesting to me to explore how to think about general purpose programming problems in terms of parsing and transformation. To me, that’s really quite exciting.

Okay, that was mind blown right there for me.

Yeah, I’m still thinking it over, too.

Yeah.

Yeah.

Alright. So, okay let’s take a simple case. Imagine you had to do a [run length] encoding a list. Okay? So, you have a list of numbers. And 1, 2, 3, 4, 5, okay, so there’s no compression you can do there. But if it was 1, 1, 1, 3, 5, then you’ve got three 1’s there. So, you can replace that with 1 three times followed by 4, 5, or whatever it was. So, if you think about writing code to do that in say Ruby or anything else, you know damn well that you’re going to write that code and there are going to be edge cases that you’re going to have to deal with. And it’ll take you three or four goes to get it right, have a little flag here for what happens if you’re accumulating the run and you hit the end of the list and it’s got to stop.

If you’re doing it in a pattern-matched functional language, then it actually is you basically write the thing as if you were writing a parser for it. So, you say okay. So, if I’m looking at a list where the first two elements are the same, then I’m going to replace them with some kind of indicator that I got to repeat, where I have the element and a count of two. If I have a list where the first element is one of those repeat things and the next element in the list is the same value as in the repeat, then I’ll take that second element out and up the count in the repeat. Otherwise, I’ll just copy the front element to the result. Okay. So, it’s a parse. And by doing that, the code just works. There’s a little bit of housekeeping to do with the empty list and stuff. But fundamentally, the code just works.

And I actually wrote that code this morning for a talk I’m giving in Texas. And literally, it just worked first time. And I expected it to, because it was just laid out as a simple parse transform. And you think, okay, that’s an abstract example. I’m working on a Markdown to HTML translator using exactly the same techniques. Think about Markdown. So, if you have a paragraph that’s immediately followed by underscores, then it’s actually a heading. Yeah? Well, that’s just parsing a stream of blocks. And you look for that pattern and you replace it with something else. So again, it’s just a stream transformation. And that’s really exciting. And then you take that next…

JAMES: So…

Sorry.

So, I was just going to say, obviously we can write code like that in Ruby. In the worst case, we could use a parser generator and handle it that way or whatever. But you’re saying that you think the big thing about pattern matching is that it puts that as a first-class way to divide the program. And thus…

Right.

It makes you think about it that way.

You could do class-based OO in C [chuckles] as we’ve discovered.

Right.

But it’s not natural. And this makes it natural. And actually, you’re encouraged to do it that way. And then you take it a step further, because one of the other things that you get in languages like Haskell, Elixir, and OCaml is lazy streams where the results are presented to you as you need them. So, these are effectively infinite streams if you want them to be. And you can do exactly the same rules on those. And that gets really interesting because if you have the ability to have lazy streams and if you have the ability to perform operations like reduce and zip on them, then what you’ve basically got is reactive programming, but in a functional environment. And I think that is possibly how we’re going to be writing servers in the future.

Yeah.

Reactive programming being where you respond to events?

Basically. Yeah, but what you do in reactive programming is you convert your events into streams. And then what you’re doing is you’re using your regular stream operations to combine and process events. It takes some of the time issues out of event processing.

Yeah, we did an entire episode on functional reactive programming on JavaScript Jabber so I’ll get a link for that and put it in the show notes. I wanted to talk to you about something else. I know that it’s not a clean transition, but you signed the Agile Manifesto what, forever ago. And it’s interesting how that ecosystem has changed. And you wrote a blog post about Agile not being Agile anymore, is what I got out of it. I’m curious, not so much what your thoughts are on that because I think the blog post pretty well summed it up. But what do we do about that?

Well, I think we have to work out why we’re all so keen on Agile I the first place. And the reason is that it helped us write our code better, whatever that means. We were writing more accurately. We’re maybe writing a bit faster. We’re having fun as a team. It was basically, we all felt it was a better way to write code. And that still holds true. But what’s happened is we were having too much fun. And so, people came along.

Hey, whenever people are having fun, there must be a way of monetizing this. And a whole bunch of people jumped into the fray and started finding ways of monetizing, little M. So, some people were charging money. I know the scrum people have made a fair chunk of change out of doing the scrum master training. And there’s people like, well, there’s the new safe agile framework, god help us, and things like that. But also, people were making non-cash money in terms of writing books, conference talks, all those kinds of stuff. And all of it was really ignoring the underlying principles and ignoring the underlying reason we were doing things. So, what we can do is to get back to that basics and just say to ourselves, “Okay. Let’s not worry about are we doing this right? Are we following this particular creed?” or whatever. Instead, let’s just go back to the principles and find something that works for us and do it.

The reality is that no two teams should be doing “agile” the same way, because the best practices, best anything, is always contextual. There’s no such thing as universal best. So, whenever you’re looking for something which is like best practices, it always has to be local to what you’re doing. And so, teams need to be exploring the way that works for them. And they need to be using the Agile principles to do that. So, you try a little change. You monitor to see whether or not it is better or worse, and if it is you adopt it, if it’s not you don’t. And you just keep repeating that. And if you keep repeating that, you’ll get better and better every time. So, I think that’s what you do about it.

That’s what I was trying to say in the blog post, too, is let’s just abandon the word agile because it’s now being abused so horrendously that I don’t think we’ll get it back again. And let’s just do things with agility. And I think if we do that, we can just carry on doing what we have been doing and probably be a lot happier for it.

So, how do you find the balance between adapting, this is the first time I’ve heard somebody come out and say agile, because everyone says, “Oh, turn everything up to 11,” right? Well, that’s extreme programming. But when we talk Agile, we think about take these 11 principles of extreme programming, dial them up to 11 and that’s Agile. And this is the first time I’ve heard somebody say, find the tradeoffs that work best for you.

How do you tell the difference between that and when somebody basically says, “Well, for our team, the tradeoff we’re going to make is we’re not going to unit test or we’re not going to pair program at all”? How do you tell when somebody’s basically saying, “Okay, you’re not making a tradeoff, you are actually abandoning, you’re at the other end”? Instead of dialing it to 11, you’re dialing it to 0 and you’re doing it without consideration of the tradeoffs. How do you crucify those people, is what I want to know.

Maybe that’s the wrong question to ask. [Chuckles]

You don’t. Who are you to judge?

Right.

Not you specifically, but who is one to judge?

Yeah, yeah.

First of all, there are no 11 practices of Agile or whatever it might be. XP is an implementation, which actually preceded the Agile Manifesto. So, if it follows agility, then it’s more by luck than judgment. It does. I’m not going to argue with that. But XP is one particular instantiation of agility. I think agility is simply you are being agile if you follow a process that says, “Where am I now? Where do I want to be? Take a small step towards it. Analyze what happened. Go back and do it again.” That’s agility. And there really is nothing else to it but that. You apply that fractally. So, you apply it to variable naming, you apply it to coming up with a release schedule, whatever it might be. And you do that over and over and over again and you’ll be successful.

Now, one of the times that you do that is this meta-time where you sort of step back and look at what you’re doing and apply that same iteration to the way that you do things. Now, if for example you were to say, “You know what? Let’s not pair.” Well, the “agile” way of doing that on my list would be, “Okay. So, let’s decide a period.” And typically you don’t want to do something until you have a test to say whether I’ve done it or not. So, in this case you’d say, “So, what is a reasonable period in which to analyze this?” Maybe it would be, oh I don’t know, three months.

Okay. So, you say we won’t pair for three months. And then we’ll look at these metrics and work out whether it was better or worse. And then at the end of that time, we’ll say, “Okay. In our particular team, on our particular project, at this particular date, pairing actually doesn’t work better than not pairing.” Or we’ll say, “Guess what? Pairing does work better and we’ll go back and adopt that.” And you’ll know, instead of having some consultant come in and tell you to do this. So, that’s what I’d say.

But the consultant’s always bringing such fun games.

Oh, absolutely. They do, because that’s a proxy for thinking, isn’t it?

There’s one piece of…

I love that. I love it. [Laughs]

It’s a proxy.

I want that t-shirt. Go ahead, Avdi. [Laughter]

There’s one piece of that I want to dig into a little bit deeper, because it seems like the deciding whether it worked portion can be one of the hardest pieces. It can be very subjective and you can have effects of, well, you can try something very briefly and say, “Well, that wasn’t any fun at all.” And I don’t know. There are a lot of ways it seems like that can go wrong. Do you have any thoughts about that?

Yeah, well how do you know that agile works?

Because you told us so, Dave.

No.

Because we’re smart people.

No, I never did. See, that is the thing. And that’s the thing that makes me very sad, is that at no point did anybody in that room, well maybe that’s not true. Most people in that room did not go out and say, “Hey world, do it this way.”

Right. I would say we know it works because we are now able to deliver more software faster and with less problems of, “Well, we spent three years building this and it had nothing to do with what they actually want.”

I think that’s definitely true. I think that for teams that are following that kind of path, they are capable of iterating a lot faster. And I definitely think that’s good. How do we know that’s the best they can do?

I was about to ask that. What metrics do you need to be looking at in order to measure that?

I don’t think we have them. I don’t think we really honestly yet are in a position to have metrics. I think we’re I the position of 17th century bridge builders. Actually, even 19th century bridge builders, where we’ll keep stressing the system until something falls down and then we’ll back away from it. We don’t really have the analysis tools, I don’t think, to be able to optimize. So, we’re going to have to do it, I think, based on a kind of intuition, a kind of, “Is this working for us in these environments?” And I think what you do is you try and codify that intuition by saying for a particular team, this is what we value.

So for example, we may value delivering, or we may value low bug rates, or we may value something more client-oriented like client conversion rates, or whatever it might be. These are our values. Now, what we’ll do is we will work out a way to measure how well we’re doing against those values. And then we’ll try iterating the process to see what effect it has on those measurements.

And I think that’s the best you can do.

So, it sounds like the measurements themselves are going to be contextual. So, having these universal metrics really doesn’t seem to make sense.

Absolutely not, absolutely not, because can you think of any single truth that is not contextual?

Yeah, I think it’s a great point. You used the example of pairing earlier and I’ve been experimenting a lot with that this year and just with six months of really trying it in different scenarios and stuff. What I feel like I can say pretty confidently is it helps a lot in some areas and then there’s other areas where I think it actually hinders, which doesn’t surprise me at all.

So, can I throw a gauntlet down to you guys?

Sure.

Sure.

Alright. For three months, write no tests.

No. [Laughter]

I’m out.

And David Brady raids [29:04].

So, I think that’s really funny. I’m sure you’re aware of the DHH keynote and that was highly controversial, right, his ideas about testing being “fad diet”, or TDD I guess more specifically is what he said.

For what it’s worth, we talk about context and we talk about experts and consultants coming in and basically crapping on a team and walking out again. He and I do the same thing. We have experiences and we have ways of doing things that work for us. And for him, TDD doesn’t work. And that’s great. Now, one of the things that he does and 37signals does is, “Hey, this worked for us so you should do it.” And I think you got to ignore that because again, it’s contextual. They happen to be in a certain place at a certain time. It worked for them. Good for them. It won’t necessarily work for everybody else.

For me personally, I did that experiment. I have been writing tests since the 70s. And I have always written them. Well, that’s not quite true, but since the mid-80s, I viewed them as being a design technique more than anything else. And so, my tests would inform the way I designed my code. It helped my code be decoupled. It helped me modularize it better, et cetera, et cetera, et cetera. So, I’d been writing a lot of tests. And I noticed that I was getting into very much a routine, that it was almost like there was no thinking involved. And I was coding, I was writing tests. I typically didn’t do test-driven or test-first, because I saw that as stupid. But I would be testing as I went along and blah, blah.

And I realized that actually, I was thinking about the testing as I was writing the code and then write the test. But the test didn’t actually contribute anything because I’d already done the thinking about the test. So, I almost never ran into the situation where I then wrote the test and went, “Oh, wait a minute. I got to refactor this code.” Just basically, I got to the point where it had become automatic. It had become tacit he said, to key a second conversation at some point.

And so, as an experiment, I stopped writing tests. And I actually measured informally things like bug rates. And they made no difference whatsoever. But that was to me. And that’s because I have a certain set of experiences and I write code a certain way. I cannot say to you, because of this, “Hey, guess what? I’ve just come down from the mountain. Here’s a tablet that says stop writing tests.” It’s always going to be an individual or a team decision. And it’s something to experiment with. However, the interesting thing to me was the sharp reaction I get whenever I say to people, “Stop writing tests.” [Chuckles]

That’s all like, “Over my dead body,” blah, blah, blah.

And it’s like talking to the NRA. You’ll pry these tests out of my IDE over my cold, dead keyboard. But you know what? That is every bit as dogmatic as the people that are telling you to do it this way, or that way. Unless you are prepared to experiment with our process, then you are stuck in a hole and you’re not going to get better. Now, I’m not saying that you’re better off not writing tests. But I am saying that if you want to challenge yourself and if you’ve reached a level where you are on autopilot when you’re writing tests, or when you’re writing code from those tests, whichever way around you do it, if you are at that point in your career, then I think you owe it to yourself to see what happens when you stop.

That’s very interesting, because I came from a long history of not testing. And so, I had a compiler and I worked in statically compiled languages. And I was very heavily dependent on the debugger. And the test people came in and said, “Stop using your debugger.” And I said, “Screw you guys.” And then I started using Ruby where the debugger never works and so I finally stopped using the debugger.

And now, I’m very much test embracing. And yeah, that was my first reaction, was no way am I going to stop writing tests. And as you were talking about this, I did, I started considering what are the other things that I get from my tests? Well, the ability to communicate to my teammates that stuff works. Well, that’s actually the subject under test isn’t it? It’s not saying I can’t communicate to my coworkers that my code works if I don’t write tests. It’s asking the question how do I

communicate to my coworkers that my test works if I don’t write tests? And that’s an interesting question.

That’s a really good point. That really is a good point. I’d also say that I think there are things that you have to test, like for example things to do with money or whatever else. And those are just classical unit regression-style tests. I just think that the practice of TDD is one which has become religious. And I think that you’re absolutely right. Once you start thinking about doing it a different way, and this is like that going from OO to functional, it expands your thinking as a programmer. So, maybe changing our practices does the same thing. And this idea of, “Okay, if I don’t use tests to communicate, how else do I communicate?” maybe it’s a question of naming better or having more expressive APIs or whatever it might be. I think that changing what you do A gives you the ability to improve, but it also makes you think about what you do, do.

Did you just say doo doo?

I just said do, do. [Chuckles]

That was my joke to Chuck. [Laughter]

Sorry.

I have one job on this podcast. [Chuckles]

You said that I think there are things you should test. Can we also finally admit that there are things you can’t test? Because I’m pretty sure I believe that, that there are things we…

Well, given enough mocks, right? [Chuckles]

So, to give an example, in our current system we have an SOA architecture. And requests come in and they get filtered out to several different sub-bots. They handle various purposes. But the pool of bots grows all the time. And we only have to interact with one or two of them at any given time for complicated reasons. But let’s just say that pool is currently, we’ll say 40, somewhere in there. We would love it to be 500. Well, at the point when it is 500, which each one of those being a web app, I probably don’t have enough resources on my development machine to being up the entire system at once to throw some integrations [inaudible]. So, then what? [Chuckles]

Eventually your staging server is a copy of the entire internet.

Right. [Chuckles] Yeah, there has to be some line, no matter where that line is, there has to be some line where it literally becomes impractical. And we handle that by different ways. We’re saying, “Okay, we can’t guarantee that all these things are doing this thing. So, we try more to guarantee interactions between them.” So, this thing should respond to this interface and this thing should understand that. And then if we keep up those contracts on both sides, then when we plug the two of them together, that gives us hopefully enough. And then the rest you have to monitor with business metrics. Is that particular service still getting regular calls or whatever? If not, something may be wrong there and we should look into it.

Is this application like running a pacemaker or anything else, [inaudible] software?

No. Nope, it’s not that critical. [Chuckles]

Alright. So, here’s another way of thinking about, when you’re talking about testing in this context, you’re really talking about, “Is my software working?” not, “Have I designed it right?”

That’s right. You’re right.

So, your tests are integration, regression-style tests.

Right.

So, there is an alternative. Let’s come back to the Agile way of thinking about things. Deploying is one of those activities in that list of steps. I have 17 bots. I need to make it 20 bots. So therefore, my action will be to deploy whatever else, right? I think a whole bunch of development would be so much easier if the cost of failure was less. That’s the entire basis of how Erlang OTP gets its reliability. It says, “Fail early and we’ll handle it.” So, the same thing applies there. If you rolled out a system that N bots and then you want to add N+1, you add N+1. And if you suddenly see it fall down you go, “Oops,” and you take that +1 out and you go back to a working state.

Agility doesn’t necessarily mean you have to get it right. It means you have to be able to get it right eventually, or quickly. And so, I think agility in deployment, and one of the things that Rails gave us until the asset pipeline came along, was ability to deploy and then un-deploy very quickly. And the number of times I’ve deployed our store and some untestable non-functional requirement went bang and I just rolled back, it’s phenomenal. And that takes a whole weight off my mind. I don’t have to test all those really weird hard, impractical to test edge conditions. I just roll back.

Have we talked about Wicked Problems on the podcast in the past?

I think so, but it’s been a while. You can bring it up.

So, a Wicked Problem is a problem that defies resolution, let alone testing. And I think it applies really well to testing. Dave mentioned… Avdi says we just talked about them. Was it on the show that I missed in Scaling Rails?

Oh, yeah, yeah.

Okay. Then I’m not going to rehash them. The point that I wanted to make is that I see wicked problems as a pattern for things that are very hard to test, because they have no stopping rule, right? There’s no way… Well anyway, go listen to the other podcast where we talked about that.

But yes, there are things that are not testable because there are things that are not solvable.

Right.

And go read the wicked problem page on Wikipedia if you don’t know about them because they’re awesome. And knowing the points of a wicked problem are a really good way to keep yourself out of getting into a land war in Asia, in software.

Dave, you talked about lowering the cost of failure, right? But what if I am programming a pacemaker?

Oh, I think that, yeah…

Cost of failure is kind of high.

Sure, absolutely. There was a story. When I first started working, my boss used to work for a software company in England and he tells a story of, they had a contract with the Royal Air Force to develop hover autopilot software for rescue helicopters. So, the idea was that you were on a side of a mountain and you were lowering the cable down. And the pilot wanted to be able to push a button to say hover and the thing would just maintain altitude. And he swears that the acceptance test for this was the project team got into a helicopter, the pilot took it up to a certain height, and then pushed the hover button.

Wow.

Yeah.

Aaaah!

That’s a great motivator though, right?

That extra little minute gets you [inaudible]. [Laughter]

Now, this works from a physics standpoint. This works. We just have to assume that helicopter pilots are uniform spheres oscillating in perfect harmonic motion. [Laughter]

But yeah, I think I would never, ever… Well, first of all I would actually never, ever work on software like pacemakers or something like that, because I don’t know how to write software that well.

Yeah, me too. I’ve seen my code. [Laughter]

I have. I have worked on that kind of software and it is not, you don’t write software well. You write software awfully, because your test criteria are so paranoid, you’re not dealing with Murphy’s computer where anything that can go wrong will go wrong. You’re dealing with Satan’s computer, where everything that can go wrong will go wrong at the same time, at the worst possible moment.

Wow.

But how do you know you’ve covered all the cases?

You have really lots and lots of good insurance for malpractice suits.

That may not be the answer to the question you asked,

But that’s the answer to the reality that that question implies.

Yeah, because the same guy who told me the helicopter story told me story, and again this is probably just apocryphal, of software that he’d written again for the Air Force I think it was. And they got called in because it would restart itself once every, I think it was seven seconds or something. And it was just some real-time software. And they noticed it was crashing every seven seconds. And it didn’t do it anywhere apart from when it was installed. It worked absolutely fine on the bench. It worked fine during acceptance tests. It turns out that they were installing it in the same building that had a radar on the roof. And the radar dish was rotating around once every seven seconds. [Chuckles]

Wow.

Wow.

You can’t test for that kind of thing.

Works on my machine.

Yeah, exactly, exactly.

But it’s also worth noting that with stuff like that, you always have a separate testing organization. It’s not like a lot of the stuff that we work on where the programmers are mostly or solely responsible for testing their own stuff. You have somebody else who probably has very little idea of how the software even works who’s responsible for building test sets and elaborate test scenarios, and basically annoying the ever-loving heck out of the programmers every time they try to release some software.

That’s a great point of harking back to the tradeoffs and how agile should adapt. Because from XP, one of the principles is you have on-site customer. And the idea is the testers are embedded with the programmers like wartime journalists in a battalion. And there’s this high transparency and low barrier to communication. But yeah, when you’re writing something that could kill somebody, it’s actually a good tradeoff to have the QA team be actively hostile to the programmers, and to actually take a perverse glee from, and I’ve worked on teams like that. And Avdi…

You’ve come from a government background so I’m sure you know what it’s like to have a QA team who, their entire joy in life is ruining a programmer’s day.

I was one of those QA people.

I know. [Laughter]

But at the same time, if it’s not mission critical stuff, a lot of times the edge cases can be allowed to slip because if they happen once in a great while, it’s actually cheaper and more effective to just have a human handle it.

That’s the credit card scenario. We actually know lots of techniques to make credit cards more secure. And the credit card companies never do them because those techniques, if you add up how much they cost versus how much credit card fraud costs them each year, it doesn’t make sense.

Yup.

They just swallow the fraud.

The PCI Compliance spec actually stipulates that your servers must be in a building and it specifies which direction the hinges face on the doors. They can’t be exposed to physical attack. And every accessible entrance has to be manned by an armed guard. The PCI government spec actually says a human has to be there to handle, because the edge cases will happen.

Dave, you’ve been challenging us on this show to try things that break our usual models. And you’ve been challenging people and me indirectly to do that kind of thing for a long time. 14 years ago or so, you challenged quite a lot of people to learn a new programming language every year, to do crazy things like valuing plaintext over really awesome fancy formats, and all kinds of stuff like that. Now you’ve challenged us to not write tests for three months. Are there any other things that you can suggest to break our brains and get out of the box?

Well, basically everything you believe in. And that’s an impossible target, because no one’s ever going to even actually enumerate their assumptions.

I guess part of my question is do you see any sacred cows that are so embedded that we’re not really thinking about them right now? Like I guess this Ruby podcast, so particularly in the Ruby and agile communities.

I don’t know if they’re… They used to be sacred. A lot of them are no longer quite as sacred. I think I am really distraught that the crowning achievement of the Ruby community is a web framework. I think that the browser is dead. It just doesn’t know it yet. And I think that we are helping perpetuate it. I think the idea of server-side code that renders pages is absolutely ludicrous, particularly as we move towards the so-called internet of things. The world is going to change dramatically. And so, I think one sacred cow I would love to see killed is this idea of the web-centric nature of development at the moment. So yeah, that’s one thing.

Can I talk about that one, just to try and get…

Please, please.

This year, I gave myself a couple of challenges. One of them was to try a bunch of things I’d never tried before and do them in different ways. And one of the things I’ve been doing is using Ruby for a list of manner of things that I’m pretty sure if I showed them to you, you would list which language you would use for that. And Ruby would not make your list. [Chuckles] So, I’ve just been trying random things. This morning before I jumped on the podcast, I was playing with a game in Ruby. So, literally drawing sprites on the screen and animating things and stuff like that, which you, yeah, most people don’t use Ruby for very much, I don’t think. It’s taught me a lot.

And I think that’s excellent. I really do. The idea of doing things that are uncomfortable or doing things which are against your intuition is how you learn. And so, I guess that is a perfect way of doing that. Knowing upfront that Ruby is not suited to writing real-time pacemaker software or whatever, but trying it anyway will teach you where it’s good, where it’s bad. It’ll teach you what the constraints are of that environment that you’re working in. So, I think that’s an excellent, excellent way of doing things. As long as it’s done in the spirit of, I know this is a silly thing to do, but I want to learn.

Yeah.

A lot of people do that because I know Ruby and therefore that’s what I will write all my programs in. But that’s not the way you’re doing it, and that’s perfect.

So, a follow-on to that question, you mentioned earlier about just trying something crazy. And like you said, you jumped into Python ad you’ve tried it two or three times and it just hasn’t stuck. I’ll leave it for my pick, but this sounds a lot like trying to identify pseudoscience before 50 years have gone by and we’ve really established that something is a pseudoscience. And it actually turns out that it’s very hard to prove something is pseudoscience before a longitudinal study has occurred, even though the idea is crazy. How do you jump into something? If you were going to jump into Python or if you were going to jump into Go or Dart or another programming language, or no testing, what do you do to help jump in with both feet? I guess is what I’m asking.

Well, you have to make a commitment. So, you have to find a project that you’re actually going to do, I think. Whether that’s a live project or whether that’s a play project, it depends on your circumstances. I try to carve out for myself maybe about a day a week where I can just play. And it’s typically not consecutive hours. But over the week, I’ll spend eight, ten hours just playing with things. So, if for example I was looking at say Go, then I’d say, okay so I want to get an example here where I can have lots of little actors playing around with each other and doing something. So, I’ll come up with some toy program that would let me experiment with that and see what I thought. Something that was open-ended so that when I got to what I thought might be the finish I can keep developing in a different direction or whatever else.

I have a little suite of things I can do in different languages. So, I have, I guess you can call them kata. Some of them are trivial. In any language, the printing hello is just to make sure you actually get the environment set up. But then you’ll always move on to something else. So, you might want to do, I don’t know. It depends on the style of the language, but some list processing. I do typically my little anagram server. And I do that because it allows me to play with agents and concurrency and synchronization, this kind of stuff. And if I’m really getting into a language, I’ve only done this a couple of times, maybe three times, I’ll try and write a Markdown parser for it, because that is, whatever you do, Markdown is an incredibly ugly thing to parse.

Yeah.

And so, it really, explores the outer edges of how to stretch your code in that language.

Cool. Can I give you a suggestion for a kata to add to your list?

Please.

Coming from the video game world, the hello world in video game programming is to put a 3D spinning cube on the screen and animate it as it spins. And that’s really hard in Ruby, because graphics in Ruby is really hard. But it’s trivial if you can get a canvas and get access to OpenGL.

Right. That’s interesting.

I wanted to ask you a question about your Agile is dead blog post, how you talk about we’ve lost the word agile but we have the word agility. And you say that it’s our job to make sure that we keep it meaningful and that we protect it. How do we as developers do that?

We use it correctly, I think. Ultimately, the word is less important than what we do. in a way, it’s a bit like a design pattern in that it’s really just a codification of a certain structure, a certain way of doing things. So, if we don’t call it anything at all, but we actually still follow the basic practices, if we still value the values, then we’re doing it. We don’t have to call it agile or agility or some trademark name or whatever. It’s what we do. And they really cannot take that away from us by devaluing the name. It’s just really a question of living a life.

So, all this we’ve been talking about is about how to stay sharp, I guess you would say, that you’re trying to break your brain, as you say, use different languages, try different ideas, do them in unusual was, stop doing things that don’t seem to work, things like that. This is how we grow and change as programmers you think? This is how we get better over time?

Well, plumbers do it. I don’t see why we shouldn’t. If you’re a plumber, then you have to go for annual, whatever it is, to keep your license. You have to keep up with the new techniques, the new trends. So, when different materials come along or different codes come along, you have to go and learn those. I don’t see why we shouldn’t do the same. But I think there’s a different reason to do it as well. And that is that we are in possibly one of the fastest moving industries there has ever been. And it is very easy as a developer to become a specialist. And so, you learn Ruby, then you learn Rails, and then you learn all the various libraries for Rails, then you have to learn some CoffeeScript or whatever it is you use in the frontend. And you can slap together a blog in 10 minutes and everybody thinks you’re a hero. And you can keep doing that and making money doing that for year after year after year.

But eventually, the world will have moved on. And you’ll be sitting there looking at a big gap between where you are because all you’ve done is Ruby and Rails and whatever else. And everybody else is out there doing whatever the magic is of the day. And suddenly you have to bridge a five-year gap in technology. And in our industry, five years is an entire generation of technology. So, unless you are doing incremental improvement to yourself as you go along, if you’re not investing a bit of time each month to keep up with what’s new and what may or may not be big, then you are going to be way, way behind. And that gap gets to be really, really hard to bridge.

So, I think you have a duty to yourself to experiment and keep current. Now, you’re never going to know what’s going to be big next. No one could have predicted Ruby would take off the way it did. You don’t know that. So, what you have to do is to be broad in your experimentation. You have to choose experimentation that actually pays back. So, if you’re a Ruby programmer doing Rails don’t go and experiment by looking at a different web framework. Go and experiment by looking at Python or Erlang or Elixir. Or experiment by writing totally different kinds of server code, or iOS development, whatever it might be. But do something that is wildly different, because that’s what pays you back in the end.

I think that’s something that I struggle with, being a new programmer, is how in depth should I get into the framework that I’m comfortable with? And at what point do I start exploring? Because I can see a situation where if you’re new to programming and you try a bunch of things, nothing really sticks. No conventions really sink in for you to then go out and challenge them. So, I’m wondering at what point do you get comfortable and then when do you start exploring and breaking your brain as you say?

So, I think that’s a really good question. And I think it depends on where you are in your career. I think when you are just starting out you have to dig deep, because it takes a while. You haven’t really done, I’m not talking about you particularly, but people in general who are just starting out, you’re learning a whole lot of things at the same time. And as a beginner, you’re going to have to learn those by experience. You’re going to sit there and try it and do different things, and put in the hours. So, maybe learning Ruby and Rails to the point where you are comfortable I think is the trick. So, the point where you can sit down and write an app and most of it just flows. And yeah, you got to stop and look up an API every now and then, but pretty much you know where you’re going and what you’re doing.

you carry on doing what you’re doing, but at the same time you fork off a little process I yourself to go and look at doing something else. And what you’ll find is that the second time you’re doing that deep dive, then it’ll be easier, because you’ve learned the techniques of learning, a little bit. And then the third time would be easier still. So, I think that as a beginner, you go deep. And you get to the point where you’re comfortable. And then you got to move back to something else where you’re not comfortable, do it again. And if you keep doing that, after a while it gets a lot quicker to pick these new things up because you’ve shown yourself how to do it.

Makes sense.

I just want to say I think that’s fantastic advice, because I think when you’re a beginner it can be tremendously frustrating if you don’t have some set of tools that you have facility with where you can see a problem and have some idea of, okay, I know the point A to point B that I need to go through to solve that problem. And if you don’t have anything where you’re that comfortable then just all of programming is a frustrating experience. And I’ve worked with, I feel like I’ve worked with some newbies that I think had, what they had picked up from the industry, the impression they picked up from the industry, had just filled their minds with so many different shiny objects that they felt they had to just keep running back and forth from one to another. And it held them back.

It’s not just newbies. Experienced people. If you look at the sheep mentality of people flocking between all the various JavaScript libraries nowadays, or even the new gems in the Ruby world, “Oh, we can’t do that anymore. We’re going to do it this way,” the same thing applies. You got to ask yourself, what am I really going to get out of this? Before you invest the time in it.

I would argue a little bit that even your challenge that you gave to use today, Dave, don’t write tests for three months, I think you can do that because you have so much experience now and so much test practice that when you stop writing tests, I bet your code is still pretty well-structured. You just have these habits that you’ve ingrained and stuff. And I have played with this idea that’s interesting. And I notice that when I do write code now, even if I don’t write the test, I still set my code up and it looks like it was written by tests, because I’m just thinking that way now. So, I think it’s easy for you to do that, whereas at earlier stages of development in programming, they probably do even more for you, because they’re training you to set things up that way.

Oh yeah, absolutely. And that’s why, you asked that question, the context, DHH and his keynote, and I was saying both he and I are in a position where we can say that because it works for us. And the people on this call all have experience and I believe that I wasn’t being too radical I suggesting that you’ve probably all reached that point where that kind of code structuring is pretty much automatic for you. Yeah, if you’re a beginner and you’re just starting out, then obviously, that’s not the way to do it. And that’s why this one-size-fits-all idea of, this is how you should do things, is clearly wrong.

Yeah. It’s not just being agile in building your apps. It’s being agile in your own learning, too.

You got it.

I’ve got to go. So, I’m going to push us into the picks.

Alright.

I know. It’s horrible. I could sit here and talk to Dave all day otherwise. James, do you want to start us off with the picks?

Sure. I have a couple of Pragmatic Programmer inspired picks, and based on this discussion as well. One of the languages I’ve had the most fun playing with lately and learning new things from is Dart. I figured that out because I read the Chris Strom book, ‘Dart for Hipsters’. That is a Pragmatic Programmer book. And it’s fun and it’s light and you can go through it quick. And then playing around with Dart has been fun for me. And it’s taught me lots of new things. I enjoy the syntax more than I do JavaScript, which means I play with it more, which means I’m figuring out more things and stuff. So, that’s been a good brain-breaker for me.

Also, the Pragmatic Programmer developed PragPub a while back, their magazine. And it’s spun off into its own thing now but still co-done with the Pragmatic Programmers, I think. And they have, first of all their recent issue on Swift was really good, if you want to just learn quite a bit about Swift in one fairly cheap magazine. But the real pick I would say, they have a free issue that you can grab on their site that’s teaching kids to code. And it has six articles in it, but they’re putting a new article in it all the time, so one a month, I think. And anyway, the six articles there already in it are fantabulous. If you have kids, this is an absolute must-read. So, it’s really great.

And then just for a fun pick, there is an excellent TED talk by, I don’t want to ruin it. The title of the TED talk is Gorgeous Woman Shakes on Stage and Crowd Goes Wild. So, I’ll just leave it at that.

But it’s not what you think it is and you definitely need to go watch it. So, that’s it. Those are my picks.

Alright. Saron, what are your picks?

Sure. So, my first one is a documentary. I think this weekend I watched it for the fourth time. I’m obsessed with it. It’s called Something Ventured. It’s available on Netflix. I think free on the site, as well. But it’s a story of Silicon Valley and different tech startups from the VC perspective. And it highlights the story and the beginning of Cisco, Atari, Apple, Tandem, and a bunch of other pretty well-known tech companies. And it’s really, really fascinating to hear how the business side of it got started along with the technology, too. So, if you’re interested in that, I highly recommend it.

Another that I just found out about yesterday is a gem called fake_braintree, which Trace Wax from thoughtbot told me about. And I’m really excited to use it. When we use the Braintree gem, we’ve just been stubbing out a bunch of its responses and it’s been a pain. And then he said, there’s a gem that does that for you and we built it. So, if you’re using Braintree and you’re doing testing, I think you should definitely give it a try.

And the last one, which is more just for fun, is called the Bit-Shadow Machine. And it renders different particles entirely in CSS box shadows. One of the animations is of two cats, because it’s the internet and that is a must-have. Another one is of a milk carton running.

Which is very exciting. And there’s a couple that simulate gravity and other physics things. So, it’s just really pretty and really fun to look at. And that’s all I got.

Alright. Avdi, what are your picks?

I have so many picks. But I’m going to try and pare it down and go through these quickly. First up on my list is an article I read recently called ‘The Thermocline of Truth’. And it deals with a particular organizational dysfunction in large organizations that rang pretty true for me, which is basically that there is a point in the levels of the organization that has levels, there is a point toward the top where the amount of information that penetrates through that point suddenly just drops off really fast. And it’s a great explanation of why a lot of projects are on schedule until right at the end where suddenly, they’re six months off schedule.

This is going to seem like a really weird pick, but one of my picks is XML.

Yeah, that’s weird. [Laughter]

I can either do that or not write tests. One of the two. [Laughter]

XML is a terrible format for configuration. It is a terrible format for data interchange. It is a wonderful format, oddly enough, for marking up documents. And I spend a lot of time working on my digital book binding framework called Quarto. And I built it around a core of doing transformations on XHTML 5 documents. And that has helped so much. A lot of reasons I shouldn’t really get into all of them right now because it would take a while, but XML is rich and flexible enough that pretty much any input format I can translate into it in a way that isn’t lossy, which I can’t say about a lot of other formats.

It’s easy to put information next to other information even if they come from disparate sources without them interfering with each other, which is hard to explain but it's true. Things like namespaces and flexible XPaths and stuff like that make it possible to add new information to a document without breaking your old processes because they can basically just ignore the old information. And also, a lot of the tools that have built up around it just make working with it, doing semantic transformations on it, really, really easy. Nokogiri and CSS selectors and XPath selectors and stuff like that just make it so easy to do transformations on it without worrying about breaking text formatting and stuff like that.

XSLT of course is a functional and pattern matching programming language.

Yes, probably the worst syntax for a functional and pattern matching programming language ever, ever devised.

I think it’s almost an answer to the challenge can we make a functional programming language that has a worse syntax than Prolog? But [chuckles]

So, it’s the Befunge of functional programming? [Chuckles]

But yes, it is actually, yeah, XSLT is very powerful. I don’t use it. I mostly just use transformations in Ruby using Nokogiri. But I’ve thought about using XSLT. But yeah, there are a lot of really neat things you can do with it. There are other cool aspects of it like the fact that it has a well-defined canonicalization and you can canonicalize two documents and then see the things that are actually different between them rather than the things that are unimportantly different between them. A lot of cool reasons that XML makes a ton of sense for documents, not really for anything else.

TorGuard, that’s another pick for me. After the Heartbleed fiasco, I decided to take another look at anonymous VPNs for when I’m out and about and logging into public Wi-Fi networks. And I did a little bit of research, not a ton of research, and decided out of the ones that were out there to pick TorGuard. And it’s worked pretty well for me. Basically what it does is you set it up on your computer and turn it on and all of your data use goes into a wormhole and then pops out somewhere else in the country that you’re in, or even somewhere else in the world. And it’s very anonymous and very secure and keeps you from exposing your stuff on the local Starbucks Wi-Fi. There are a lot of options. Some of the reasons I picked TorGuard were that it was relatively inexpensive, very cross-platform, the tools that they offer are for everything, and they’ve got very good ratings from some of the organizations that classify the security and privacy guarantees of these various anonymous VPN services. So yeah, TorGuard.

One more, real quick. The unitwise gem. There are lots of Ruby gems for representing physical quantities. This is one of them. But it’s a pretty nice one. And it’s very comprehensive when it comes to representing all kinds of different quantities and compound units of quantities and stuff like that. Alright, I’m done.

Alright. I’ve got a couple of picks. I don’t know if I’ve picked this before, but I use Chrome for my browser mostly and the Chrome Developer Tools are actually really, really handy. I was using a website and I couldn’t find a button. And so, I actually went and used the Chrome Developer Tools to find it and then used jQuery to click it. And then I got everything that I needed out of it. So, I’m going to pick the Chrome Developer Tools.

I’ve also been using in Chrome a plugin called Tab Wrangler, which if you’ve ever been in that position where you have 10 million tabs open on a single Chrome window, Tab Wrangler will actually close them if you haven’t used them in a while which is very handy. And you can actually get them back just by clicking on the Tab Wrangler icon and then you just click on the site and it’ll bring it back. And so, that’s been really helpful.

And then I also read this book. It’s called ‘Dad is Fat’ by Jim Gaffigan. It was pretty funny. And if you have kids, it’s hilarious. If you don’t have kids, it’s probably still funny, just because you get a glimpse into all the wacky stuff that you don’t realize kids put you through. And anyway, I really enjoyed it. I thought it was funny.

And finally, I’ve been using a task management system called Redbooth. It used to be Teambox. And I’ve been using it to manage my to-do list. I’ve also been using it for the stuff that I delegate to Mandy. And I’ve really been liking it so far. So, I’ll pick that as well. Dave, what are your picks?

So, about two years ago, I made the decision to move away from my desktop system where I had two massive big monitors and a Mac Pro under the desk and everything else. And I moved down to a 13-inch MacBook Air. And I have never regretted it. However, I did have envy for the vi, tmux people because they could manage their desktops way better than I could as an Emacs user, until I discovered MultiTerm. And that’s my first pick. MultiTerm is a really easy way of basically creating shell windows inside Emacs. So now, I start up Emacs, I run it full screen, and that is basically my entire environment. I run my shells, I run my editing, I run my code, all from there. Nice tiled environment, very flexible, easy to use, et cetera, et cetera.

A second pick is one of those bend your brain ones. I remember I talked about writing Markdown as a kata. Well, I came across an implementation of Markdown in OCaml called, not surprisingly, OCaml-Markdown. It’s on GitHub. The user is gildor478. And it’s worth it just to have a look at some of the ideas, in a way that captures the idea of parsing, because it starts off by defining types. And the types are basically what you would write as the BNF of Markdown. So, it’s actually showing you how types correspond to non-terminals in parsing, so that’s interesting.

What Managers Need to Know about How Artists Work’. And it basically describes how people like theatre companies put on a show. And when you think about it, as a project team we have deadlines and we’re in theory supposed to meet them. But every now and then we go over by a couple of weeks and everybody goes, “Oh, that’s software development. Ha-ha,” right? Well, if you’re a theatre company and you’re putting on a play, you have an opening night and you better damn well be ready by opening night. Otherwise, you’re going to be really, really embarrassed. And so, how does something as artistic and as soft as putting on a show manage to deliver a show on opening night and then deliver a show that’s repeatable night after night after night. It’s an interesting book.

Wow.

I haven’t read that, but I want to now. [Chuckles]

So Dave Brady, did I skip you?

You did.

Do you have some picks?

And in the interest of your time, I have three picks but I will do them as quickly as I can. The first one is to point out that yet again we’ve had somebody on the show who refuses to plug his own stuff. So, I can’t believe this isn’t in our picks. But there’s a book called ‘The Pragmatic Programmer: From Journeyman to Master’ by Andrew Hunt and some other guy.

[Chuckles] And some other guy. [Chuckles]

By Dave Thomas. And this book came out in 1999 and it immediately became like scripture for me. This book was revelatory. And so many epiphanies flowed from that book. If you haven’t read it, it is not by any means out of date. Go back and read it. Everything is text, learn a new programming language every year, your information portfolio has a half-life of 18 months, it’s all still very valid.

And I highly recommend to people, pick that up and look at it.

Thank goodness for Andy Hunt.

Oh, yeah.

So, my second pick is because I just mentioned plugging your own crap, I’m going to plug my own crap which is my own blog, because it touches on something we talked about on the show. I wrote a blog post a few months ago called ‘Teach Yourself a New Programming Language in 21 minutes (Or 2-3 years. It Depends)’. And I’ve said on the show before that one of the reasons I got into Ruby was that it was one of the first languages I’d learned in 10 years that required me to actually learn a new language. Because once you learn C and C++, you can go to Java, you can go to C#, you can go to gosh, Lua for crying out loud, and all you have to do is learn how it encapsulates data, how methods are invoked, and where the semicolons and braces go.

And Ruby is not a block-oriented lexically-scoped language. It acts like one, but you can break a lot of rules with it. And so, I highly recommend that. And that blog post, basically it’s a heuristic that I use to determine, is this a language that I need to just figure out, bash something out, and then walk away from? Or is this a language that I’m going to have to really dig down in and learn. And I

present some use cases where one language that I discarded and it saved me years of grief by never learning it. And another language, Lisp, I’ve never learned but I get bitten by it every six months. And I really ought to sit down and learn the language.

Immanuel Velikovsky and the Birth of the Modern Fringe’ by Michael Gordin. And the reason, I’m picking the first two chapters of this book. The rest of the book, sure why not? But the first two chapters are worth the 10 bucks that you can get this on Kindle for. And basically, he talks about, there is a branch of philosophy that concerns itself with the theory of science. Basically, where do we get the scientific method from and how do we take a new idea in science and determine if it is pseudoscience? And we have a lot of rules.

And we talked about on the show about diving into something new, how do you tell early on that jumping into this language is just going to a waste of your time? And the answer is you can’t. Not without doing a true longitudinal study. There’s no way. You can search the web for how to spot pseudoscience. And he goes through and he basically says, “Okay. Let me teach a little bit about the theory of science.” And he takes all of the points for identifying pseudoscience and he shows that without 20 or more years to look back on how the science has played out, it’s impossible to determine if something is pseudoscience in the moment when it’s first coming out. We talked about extreme claims require extreme evidence and that sort of thing, but it is everything from alchemy to quantum physics. When it first came out, it was impossible to distinguish it from a real science or a fake science. And some of the things that we have today, the jury is still out on.

And I want to give a caveat that the point of the book is not to say science is useless, because he does. He basically says the theory of science is we don’t actually have a working theory of science. And he’s not trying to demolish science. He’s trying to say, all of the things that you believe about the scientific method are based on beliefs. And those beliefs are based on tradeoffs. And every one of these has a point where there’s a divide by zero error in that belief. And you have to keep those in mind as you do your experiments and as you move forward. And you have to be ready to be confronted by new evidence and learn and grow. And that’s where I’m going to stop. The rest of the book might be good. It might be awful. But the first two chapters are absolutely worth it. So, those are my picks.

Alright. Well, thanks for coming again, Dave.

Hey, my pleasure. I enjoyed it.

Alright, well I guess that’s all we’ve got. So, we’ll wrap it up. We’ll catch you all next week.