02:37 - Dave Thomas Introduction

04:17 - How Dave Got Started in Programming

06:34 - Tools and Constraints

19:29 - Limerence

28:54 - Ruby = Happiness: Does it Hurt?

31:00 - Tools and Falling in Love with Tools

35:08 - When Do You Learn? When Do You Train? (Not Falling Behind)

38:01 - Choosing Similar Tools and Technologies vs Choosing Different Tools and Technologies

43:36 - Relationships and Identities

46:08 - Looking Forward vs Looking Back (Knowing Your History)

01:01:48 - Is the rampant use of social media hindering the learning of big ideas?

01:08:15 - How You Learn a Language / Decide You Like a Language

Picks 

Slack (Dave)
Why Does E=mc2? (And Why Should We Care?) by Brian Cox and Jeff Forshaw (Dave)
Philly Emerging Tech Conference  (Dave)

 

Special Guest: Dave Thomas.

 
DAVID:

I skipped out on oral surgery to be on the call today. So Dave, if anybody has ever told you that everyone would rather have a root canal than talk to you… [Laughter]

You can now tell them it is not true.

Awesome!

Hello and welcome to the Ruby Rogues podcast. Today, featuring Coraline Ada Ehmke.

Hello.

David Brady.

Caution, this podcast stops and backs up frequently.

Jessica Kerr.

Good morning.

I am Avdi Grimm. And joining us today is a special guest, Dave Thomas.

Hi.

Alright. Dave, who the heck are you?

[Laughs] So, I’m Dave Thomas. And I play with Ruby a lot. I play with Elixir a lot. I play with programming [inaudible] a lot. And I also spend a fair amount of time thinking about how we program as a community. Because fundamentally, we spend so much time doing it. And we put so much of ourselves into it but we need to find ways to make it fun and keep it fun. And that’s it. I don’t offer anything profound. [Laughter]

Okay, so Dave, I have to ask this. I was reading Uncle Bob’s Clean Code yesterday and in the intro chapter he introduces you as the ‘godfather of the Eclipse strategy’. And I’d like to see how you tie godfather and ‘programming should be fun’. I’m assuming that’s fun for the people who aren’t sleeping with the fishes, right?

Eclipse strategy?

Yeah, I’m thinking he’s talking about the OTI Dave Thomas at that point given that I think Eclipse is the work of the devil.

Good, good, good, good.

I take no credit for that.

I am actually in the Bugzilla quotes database @eclipse because I tweeted that I wish I owned two laptops so that I can watch Eclipse die in a fire twice.

Aha!

Okay, but you have a good point there, David. There are multiple Dave Thomases. And we are talking to PragDave of the pragmatic [inaudible].

Otherwise known as RubyDave, although now perhaps ElixirDave?

Oh, just FunCodingDave. How about that?

No, you must identify yourself strictly with one language. [Laughter]

Oh, that is very true. That is very true. BasicDave, then.

Oh god.

Was that your first love?

That was my first love. It was indeed my first love. I learned to program… do you want the story?

Yes.

Yeah, a love story.

Yes!

Okay. So, I was a slip of a lad. I was 15 I think and I was in school. And the way English schools work, you do tests called O-levels and A-levels. And you take your O-levels at normally about 15. You take your A-levels about, oh, 17 or so. Anyway, once you finish those tests, you’re kind of like, just like sliding into summer but you still have to attend school. So, the school was looking around for ways of stopping us destroying the place and offered a number of us the change to go across the road to a local technical college and participate in their very first computer science O-level. They were basically running this class for the very first time. And this was 1970-something early, like one, zero, something. And they wanted to basically try it out on some people that didn’t matter.

So, they though they’d use us.

So, we went across the road and they taught us BASIC programming. And we actually had an ASR-33 which is the old teletype and the paper tape reader. And we had a 110 baud modem, which halfway through the course was upgraded to 300 baud. And we went online to the local county council that ran an ICL 1900 mainframe. And we would submit our BASIC code to it. And it would type back at us and tell us basically that we’re idiots. So, I fell in love. I learned a whole bunch of programming chops doing that.

We were given on the computer I think space to store five files. Everything else would be kept in paper tape. And five isn’t very many when you’re [inaudible]. I think one of my first BASIC programs was a self-modifying code that would actually act as a file system. So, I could actually inject extra programs into my BASIC program and it would work.

Awesome.

Yeah. So, that’s how I got started. And yeah, BASIC was my first love.

I think a lot of art comes from constraints. And it sounds like from the very beginning you had constraints that you had to work through in order to accomplish your goals.

Yeah, I don’t think I’d call it art, particularly. Graffiti possibly.

But yeah. I don’t if… yeah, the constraints actually… I think all along yeah, constraints have made it really interesting. There are always constraints because we are always at the leading edge of something. We’re always pushing ourselves because as an industry that’s what we do. And that’s how you could be competitive. So, whatever we’re doing, whether it’s trying to work at how to maximize the use of five files on a mainframe or how to get some reactive bit of JavaScript to work nicely, I think we’re always pushing the envelope. So, you’re right. I think we have to learn to enjoy the constraints.

What are the primary constraints you see coming into play in today’s programming. You mentioned JavaScript. And constraint is a nice way of putting that. But what sort of factors do you think are limiting us and pushing us to be creative today?

Mm, I don’t know about factors pushing us to be creative. I think factors that are making it hard, expectations that we put on ourselves, and that kind of comes around to the topic of the day at some point. But I think that as a community we are really, really bad at socially straightjacketing ourselves. And so, we have these incredible expectations that every developer as well as being imaginative and original and everything else also has to follow the traditions du jour. And that may involve which testing framework you’re using or which build tool you’re using or whatever else. And as a developer, that means that you’re constantly having to stop the interesting stuff and go back and try and catch up with what all the cool kids are doing. And so, I think we’ll probably a three-fold increase in productivity if we could somehow break that cycle.

It’s the cycle of having to learn the new latest thing over and over?

Well, I think there’s like this fashion… I don’t know if it’s fashion of fear. But for example, I was working on a, I told the story at Philly ETE. I was working on a project for myself. It was a JavaScript tool that would let me do constraint-based diagrams.

And I started off, I actually started off with CoffeeScript because I like CoffeeScript. And it was going along quite nicely. And then maybe, oh I don’t know, two or three weeks in I got bitten twice in one day by the CoffeeScript habit of splitting parameter lists into multiples hashes if, blah, blah, blah. So, I thought, “Screw this. I’m going to go switch to JavaScript 6, because I’ve always wanted to play with it,” blah, blah. So, I spent maybe two days then converting all my code across to ES 6 or ES 2015 as we’re now supposed to call it. And that was fine. And it worked out great.

At the same time I was using Grunt just because I happened to have a Grunt file lying around and just copied it across. And then the cool kids said, “Well, actually Gulp is a way better alternative.” So, I switched across to using Gulp. And now I run into some problems with getting the tests and getting all the right JavaScript in the right place. So, I did a bit of googling and switched across to Browserify. And then I had to work out whether I was going to use Bower or npm. And it just keeps going and going and going. So, I would guess I actually finished the project as much as you finish any project about a week ago. I would guess of the total time I spent, I probably spent at least half of that time on retooling exercises, just like going back and fixes.

And I’ll be honest. It’s better for it because when you revisit code that many times, you get the opportunity to refactor it. But at the same time, that’s a hell of a lot of time to spend effectively with zero progress. And I don’t think I’m unique. I talk to people and there are a lot of people doing that.

I identify with that exact process. I went through that process recently with some of these JavaScript tools. Do you think it’s in part an enthusiast’s problem? I think back to some of the programmers that I first started programming with before I deliberately switched my career so that I would be around enthusiasts all the time. So, my pre-enthusiast days, that’s not a thing that I really saw as much because there were just the accepted tools that everybody had always been using and why would you even think about looking for a different tool? You just write everything in C or write everything in BASIC.

Yeah, I don’t know if it’s enthusiast… maybe it is. I think there’s probably… just off the top of my head, but there are probably three levels. And if you imagine it as woodworking and not programming, then you start off and you get a cheap chisel and a cheap hammer and whatever else you need, a saw or something, and some wood. And you sit there and you basically knock out crap-looking stuff. And you’re quite proud of the fact you didn’t actually cut your fingers off while you were doing it. And your family goes, “Oh, that is absolutely wonderful,” while they’re trying to think, “Where the hell are we going to put this?” And that’s great.

And then after a while, you develop into something slightly more experienced. And then you look at the tools you are holding and you think, “These tools are not worthy of me. I need better tools.” And so, you stop going to Home Depot for your tools and you start going to these specialist woodworking stores. And you buy the incredibly expensive chisel because you know it’ll keep its edge sharper and it’ll give you a nicer cut and everything else. So, you buy the latest Japanese whatever it is, saw, because obviously that must by way better. And once you saw [inaudible] using that, so it must be good. And you go through that process I think of acquiring tools because you’re convinced it will make you better. And I think a lot of people stick in that mode. And they become trophy tool owners. Golfers do the same thing with their equipment. And then you get to a certain point.

And I think once you get to mastery, which clearly I haven’t got to in JavaScript, the tools then fade into the background, because ultimately, it’s you that writes the code, not the tools. So, in the same way that if you look at a really experienced craftsman, their tools may be absolutely crap in terms of the newer shinier stuff and still they produce really, really high-quality work. And I think that’s, I think we’re going through that transition at the moment. And I think we’re still stuck in the bright, shiny things phase.

When you say “we” are you talking about developers in general or a particular set of developers?

I think “we” the industry in general. I think certain people have it worse than others. But I think as an industry we’d like to think that our tools are the problem.

Mmhmm.

And that’s our excuse.

Do you think the focus on tools is a form of cargo culting?

Maybe. I think it’s maybe it’s more explicit than cargo culting with certain tools. People become advocates for their tools. And I think to some extent that’s because they feel that if other people don’t agree with them then they’re wrong. And therefore you need to make everybody a convert to Gulp or Browserify or whatever it is you’re using today. And so, it’s not just cargo culting in that you see someone else doing it and you think, “Oh, I’m going to copy.” I think it’s actually a more active form where people who blog and everything else are going around telling people, “If you’re still using Grunt then you’re an idiot, because obviously you should be using Gulp,” or whatever it might be. So, that I think is a lot of the problem. I think we are surrounded in this sea of implicit advertising for all these tools. And we feel that we have to try them.

Is that something you’ve felt that you’ve done?

Sure, absolutely. I have done that bigtime with Ruby when I speak to more enterprise people. It’ll be like, “Of course you’re using Java. But all the cool kids are using Ruby,” or whatever it might be. I’m not so much that way now. Although I guess my attitude now is I like to present things to people rather than say, “You should be using this.” So, I like to say, “You might want to think about some of the benefits of doing this rather than that.” But yeah, I agree. I think that I am definitely going through that. I think everybody is, to some extent.

What is some of the negatives around that? It sounds like almost elitism over chosen technologies. What sort of chilling effect does that have on innovation?

Well, I think it has two. First of all, it introduces a lot of inefficiencies into the system, because if everybody is constantly churning through the latest set of tools then they’re not getting work done. And some of these tools are phenomenally… they have a very high overhead, right? And so, someone comes along and says, “Oh, you need to use,” whatever it might be, Angular or React or whatever else. And you got to go away and you got to learn that. And that’s non-trivial. And then you got to start applying it. And you apply it. And just as you get good at applying it, someone comes along and says, “Oh, you’re still using that? Oh no, you need to switch to this,” you know? And so, I think there’s that inefficiency.

I think the other thing is that the quest for bright, shiny means that you quite often forget what you’re actually doing and what the actual benefit of what you’re doing is. And I see that. A good example of that for me is the use of gems in the Ruby community (he says, vaguely bringing us back to Ruby). If you do any kind of decent-sized Ruby development, it brings in some gems, you’ll be absolutely blown away by the number of secondary dependencies that you have.

A Rails application, I don’t know what the current count is, but it’s probably 100, 150 gems, [inaudible] brought in. And the second you start bringing other things in, it increases crazy. And a lot of that, if you actually dig into why they use these gems, it’ll be for one or two minor little functions. And because they wanted to, I don’t know, format something as whatever, then they’re going to bring in this gem. And that gem brings in six other gems. And the whole thing just gets out of hand. Now they’ll argue, well clearly that’s reuse that’s going to save everybody time. But it doesn’t, because down the road what it means is you now have 12 extra gems sitting around that you’re dependent on. And you switch from Ruby 1.9 to Ruby 2. And three of them break. The entire idea of, stuff is out there, therefore I should use it, I think is a dangerous one. Because I think it gets in the way of what we’re actually trying to do.

I wish that every Gemfile had a field for an explanation of why that gem was necessary, because I know, especially in a legacy codebase you might have 100 gems in the Gemfile and you have no idea and no way of tracing down what’s what and what’s used where.

Absolutely, yeah. In fact, I actually [inaudible]. I actually deleted our Gemfile for our online app and tried to see what would happen. So, I deleted it and then ran the tests. And it was kind of instructive. But I didn’t have the courage to actually put that back into production, because I had no idea what was lingering in there that I deleted out. I found a few things that were out of date. But no… and the whole thing, the whole process that we run through, tools like Maven, tools like Jasmine. Why do we test JavaScript with Jasmine? It is ridiculously verbose. It doesn’t give us any particular benefit in that verbosity. But we do it because people say that’s what you should do.

Obviously, that’s the way you do it, right? It’s behavior-driven, or whatever that means.

Do you really think…

RSpec in JavaScript, yes.

Yeah.

But Dave, when you were talking about how you went through a bunch of toolsets on your latest project, each of those tool switches was triggered by a problem.

Yeah. And you know the interesting thing? When I switched tools I still had typically that problem.

But it’s like, you sit there and… underneath it all you know it’s your fault, right? If the code doesn’t run the chances are pretty good it’s your fault. [Inaudible] is rarely broken. But every now and then you think, “Oh, you know what? This file is being left out because the dependency analysis in this is crap. I’m going to switch over to that instead.” And you do that. And surprise, surprise, it still is broken but it gives you a slightly different error message. And then you go, “Oh, I understand now.” And you go back and you fix your source code. And then it works. So yeah, I was like, making excuses I think. [Chuckles]

I was thinking, “Okay. Yeah, maybe I should try Browserify. Oh, I got a good reason to do that because my GOB file is too complex,” or whatever. And so, I switched across. And I do that time and time again. And after a while it almost got to be a game. I was watching myself do this and just grinning widely in the background.

[Chuckles] This is a fun thing that I’ve noticed where you have this stack of yaks and you’ve got to get them all shaved. And of course the rule of a yak stack is that it’s infinitely deep. And you push out a yak onto the stack thinking, “Shaving this yak will eliminate all these other yaks.” And once you shaved it, you pop that yak back up the stack and you’re now confronted by the same yak stack you had all the way, had originally.

Except it’s now all covered in hair.

Yes, yes. Yak fur feels like productivity to me, honestly.

Dave, you said something interesting. You said, as an industry we like to think that our tools are the problem. That reminds me of something. It reminds me of a lot of people, including me, in relationships. And there is a word that you wanted to talk about today that relates to that. So, can you tell us about what is limerence and how does it relate to our tools?

Well, I’m probably the worst person to talk about limerence simply because… okay, the story of limerence was that I was actually reading a short story a while back and bumped into the word.

And the curse of modern e-readers, you can highlight a word and see what it means. And up popped a definition that didn’t seem to make much sense. And so I thought, okay, I’ve got to go and waste an hour looking at this. And it turned out to be a very interesting hour.

I’m probably going to get this wrong. So please people, be gentle on me. But limerence first came out in I think the 70s in a book called ‘Love and Limerence’. And it was an attempt to try and find some kind of slightly scientific-ish way of talking about the process of falling in love. And the word limerence was coined to reflect the first stages of the process of falling in love, when it’s really kind of one-sided. So, you haven’t formed a relationship yet. It’s just you projecting yourself into a relationship. And so, you become, infatuated is the wrong word, but deeply interested in another person. And that process is labeled limerence. If you want to get all mathematical about it, you could probably think of limerence as the first derivative of love. So, it’s kind of the ramping up as you start to enter a relationship.

And the reason I was thinking about that is I’ve been thinking about the way we look at our tools and our techniques as an industry. And I think we tend to have that kind of relationship with many of our tools. We have that one-sided love for our tools. And we’d like to try to think that these tools maybe love us back. I always used to talk about loving languages. I used to very happily tell people, “I love Ruby.” And in a way it was to do with a relationship. I felt I had a relationship with Ruby. And I used to say things like, “Yeah, Ruby keeps me interested because it has ambiguities,” which when you think about it is really very close to what you would say about a relationship with a person. This person keeps me interested because they’ll throw me curveballs every now and then, or whatever it might be.

I think it’s good and I think it’s bad. I think you need it but I think you also have to be aware of the fact that it’s happening to you.

Why shouldn’t we love our tools?

Oh, we should, absolutely. If you think about it, it comes back to this idea of you spend all day, every day using them. It would be a hell of a waste of a life if you didn’t enjoy the process. In the same way, it would be a waste of a life to live with someone that you didn’t love or whatever else. So, I think that it’s very important to have that feeling. I also though think it’s important to recognize the seduction that takes place, because sometimes the tool becomes more important than what you’re trying to do. And I think that’s when it gets to be dangerous. It’s like an infatuation gone wrong.

It’s time to leave the abusive relationship, yeah.

Yeah, I don’t know. Maybe you’ve become codependent with your tools. I don’t know. But I think you can certainly become something of a stalker. [Laughter]

I like to stay up at night watching C++ sleep.

That’s not creepy, is it?

No.

You could rest easily now, Dave. BASIC is dead. [Laughter]

I don’t know. I don’t know. I still go out and put flowers on its grave. [Laughter]

That’s so beautiful. The word limerence is not strange to me. It’s one I’ve been using for a long time because clearly English does not have nearly enough words for love. We use the word love for a thousand different things. And once you get into the separation of concerns you can speak more clearly about relationships including apparently with your tools. To me, limerence is the phase of falling in love that is irrational where you have an irrational level of affection and interest for someone. And it works with tools, too.

When you fall in love and are limerent with your tool you dig deeper into it than you have a real need for at the moment. And you find out more about it. And after that, once hopefully, hopefully you find the edges, you find where your tool doesn’t solve your problems perfectly, and then you can step back and you’ve developed that relationship, really that knowledge of how the tool works.

You can use that and use it wisely going forward, thanks to that period of irrational interest.

Yeah, I like that. I think there’s one more facet of it. And that is while you’re in that phase, you can become incredibly defensive. And if the object of your attraction, if someone criticizes it, you’re likely to be irrational in your response and overly come down on any criticism and overly defend what you’re using.

Yeah.

I think there’s another side to that, too. And that’s, you talked about people who are at the leading edge calling other people stupid for using the old tool. I think there’s a kind of arrogance that comes along with mastering a tool and not seeing other people using it at all or using it the same way that you do and judging them for that.

Yeah, I agree.

Some of the books that talk about limerence mention that while you’re feeling limerent, while you’re in that phase, you may be very happy and you may be having a great time with your new love interest. But you shouldn’t make any major life decisions. Not the time to change jobs or move or anything else that might bring you closer to the object of your affection. That maybe isn’t the best idea long-term.

As in they’re likely to be ephemeral?

You’re not able to see clearly. You’re so excited about this one, the object of your limerence, that all your other priorities which really are important to you can sometimes fall to the wayside. You might forget for instance why you’re doing the project at all, [chuckles] because you’re so wrapped up in the latest tool. And you don’t want to make any, I’m just drawing the parallel, it’s not a good time to make a major commitment like, “Oh, we’re going all AWS on this.”

I like this, because my mind is still blown by the math thing that you threw out. Because the reverse of that is that the integral of limerence over time is love. And yeah, while you’re in limerence, you don’t know if the relationship is going to be reciprocated yet. You don’t know if this tool is going to give back to you. And so yeah, quitting your job to go be a programmer of, I’m not going to pick a language, but pick some language that is really new that you look down upon because it’s too new and all the cool kids are doing it and we’re snobbish, because we’re just as bad as they are. Because they’re saying, “You’re dumb for not using this new tool,” and we’re saying, “You’re dumb because you’re not getting [inaudible] done.” And my point is that if you don’t know that the relationship is going to be reciprocated, you don’t want to make a life-changing decision based on that relationship, right? Don’t move across country to be with this person who doesn’t even know you exist yet.

There’s also some interesting research in psychology around this stuff. And that goes beyond just states of being in love, but just people have studied states of positive emotion versus states of negative emotion, and made some kind of depressing findings. Because it turns out that basically people that are feeling really good make dumb decisions. And that’s a broad generalization. But the finding is that, people that are in cynical moods are more likely to evaluate all the angles. They’re more likely to nitpick and see potential problems with decisions. So, it’s actually, people that study negative emotional states have found that there are benefits to being depressed or benefits to being in a crappy state of mind. Because they can see in studies that people that are in those states of mind actually make better decisions about things, because they’re not just floating gaily over the surface of the issue.

Yeah.

I would guess, I don’t know if it’s true or not, but most great artists are probably depressives and possibly for that reason. They are self-critical and that drives them to produce better things.

And this is kind of interesting, especially for Ruby I would think, because we all talk about all the time how Ruby is this, it’s this language that’s all about joy. It’s all about happiness. And we’re all about finding programming happiness. Do you think that actually hurts us sometimes?

That’s a really good question. I don’t know.

The expectation of being happy all the time can hurt.

I’m trying to think back through my own history to work out. I think the reality is that probably there have been times where I have chosen to use Ruby over something else somewhat selfishly. Maybe a different language would have been a better bet. And I just used Ruby because I would tell myself I didn’t have the ramp up time of beginning experience with the other language. But the reality was, possibly I just didn’t want to be with another language. I really enjoyed being with Ruby.

The thought of being unfaithful was making me nervous.

And it just didn’t sound like fun. So, I don’t know. Maybe that actually is part of the issue that we’re skirting around, is this idea that if you fall into that trap, then there’s a way bigger activation energy required to make you look at alternatives. And so, your decision making goes down partly because as you said, you’re probably less [inaudible] because you’re happy. But also you probably make worse decisions simply because you yourself don’t want to risk being unhappy, moving to C++ or whatever.

Yeah. People who are happy will take risks that cynical people won’t. And so, that’s where your innovation center comes from. But if you’re on an airplane and it’s 30 degrees out, you really want a pilot who’s trying to decide whether or not he needs to de-ice the wings one more time. You really want a pessimist in the cockpit. Because now is not the time to try and innovate with ice on the wings.

It’s true. Although recent experiences show you don’t want someone who’s too depressed in the cockpit.

Ugh.

True. This is true.

But anyway, coming back to this idea of tools and falling in love with tools, just to step back, is that a stupid analogy? Is that just pushing it too far? Or is there something we can draw from this, any kind of conclusion we can draw from this? And let me step back and say the reason I wanted to do this episode about this is that I have no idea. And I couldn’t think of a better way of trying to refine my thinking than by talking to a group of clever people and then having an even bigger group of clever people listen to how ignorant I sounded. So, I thought that way I’m bound to actually come up with something.

And how do you feel about that risk now? [Laughter]

Oh, I’m looking at the clock.

I think it’s a great analogy personally. I think it’s excellent. Because like you said, you were stepping back and smirking at yourself watching yourself switch from tool to tool. At the same time we can totally do that if we have words for our excitement that we feel about the tools. Then we can start to distinguish between what is excitement at solving the problem and what is excitement at this particular toy. Because there’s a balance. In the end, if you’re a professional woodworker you should upgrade your tools.

To a point.

I actually live down the street from a man who made harpsichords for a living. And he insisted on the use of 17th century tools. And his tool decision actually had an impact on the quality of the instruments that he made and was part of what he was known for, was his 17th century techniques. So, I don’t know how that comes into play. But I don’t know that as a craftsperson you need the latest and greatest tools. I think you can, whatever you’re used to and whatever’s frictionfree has benefits for you.

And I think particularly, if you think about say, the woodworking analogy. A great woodworker, which I am not, their tool becomes an extension of their thinking. So, they’re not consciously holding that tool. And they’re not consciously thinking about angles or anything else. They just know that if they do something, then the result would be something else. So, it takes time to build that. You may or may not believe the 10,000 hour business. But it does take a long time to develop that kind of tacit knowledge of how a tool behaves when you use it.

And if you’re constantly switching tools you never give yourself the time to get that mastery. And so, I think that you need to decide on, maybe it’s not an individual tool as much as a philosophy of tool when it comes to software. But you need to decide on tools that work for you and then say, “Okay. I’m going to let the next three generations go by me as I develop mastery of these tools.” Personally, I think that will give you way more satisfaction and probably way better outcomes than constantly switching to the brightest shiniest thing.

I think we have that fear of falling behind, that fear of irrelevancy that probably is part of the reason that we’re constantly trying out new tools and technologies, because we’re afraid that our existing tools are going to make us irrelevant.

That is true.

I think there’s a certain amount of sense to that fear. I don’t think it’s completely ungrounded because we are, as an industry, we still basically have no idea what we’re doing. And so, it’s a bit irrational to say, “Oh, this tool is definitely it.” But at the same time I completely agree that you will go nowhere if you just keep hopping from tool to tool. You have to some time, at some point decide “Yes, I’m going to let a few generations go by me while I get really comfortable with this thing.”

Different tools work well in different contexts and that context includes us. It includes what we know and are skilled with. When you do switch context, that’s a good time to think about maybe switching tools. If you were writing a hardware code in C and then you switched to business software, good time to switch tools.

Yeah, that’s a really good point. But I think there’s another side to that, too. And that is it comes back to another of my hobby horses. And that’s this idea of, okay, so when do you learn? When do you train? I think too many developers have this idea that, okay, I train on the job. So, I train in whatever my employer is telling me to use next. And that’s how I get my experience. And if you do that, then you’re definitely going to fall into the trap of staying a generation behind or possibly just going in a totally spurious direction because someone’s manager has a brother who happens to run whatever, you know? I think as a developer you have to take responsibility for your own development and your own training and your own keeping up to date.

So, I think that you should probably have this slightly schizophrenic thing going on where you have the tools that you use to create value. And those are probably going to be the stable tools, the ones that you don’t want to mess with too much because that’s where your value comes from currently. And then you need to think about okay, the future. And that’s when you’re going to be training yourself in these new technologies. And the mindset you’re in when you’re doing that is very different. In that mindset you’re deliberately making mistakes. In fact, if you’re not making mistakes you’re not picking up what’s valuable about these tools. And so, you’ll be at home. And you’ll pick up, I don’t know, you tell me, React.js or something. And you’ll spend a week of evenings just messing around and doing your to-do list or something just to see what it’s like and see what the philosophy is and trying to at least remember that there is this here.

I think it was Avdi who was talking about the danger of falling behind. I think it’s absolutely true, right? But we are responsible for not falling behind. And to do that we have to partition our time. We have to partition it into value generation and generating ourselves. And I think too few developers actually think about it in those terms.

So, let me bring this home a little bit. Dave, about 15 years ago you wrote in ‘The Pragmatic Programmer’ that we should learn a new language every year. Do you still think that’s a good rule of thumb?

Yeah, although it may not be language anymore. It may be a technique or it may be framework or something similar. But yes, I think we have to take on a challenge at least once a year of something new and get up to some kind of speed with it. And I think we do that because first of all it keeps us current. I think also quite often I learn new things. I write Ruby very differently now that I know Elixir. My Ruby code looks way more functional-ish. My functions have shrunk down in length. So, it’s really like there’s a cross-fertilization that goes on there. That when you do learn new things and you push yourself to learn new things then you’ll find it does actually leak back into what you do on a day-to-day basis as well.

So, here’s something I just thought about in relation to that. You talked about going through the progression from Grunt to Gulp to Browserify. And there are a lot of these new technologies and new tools that are very similar. And when we talk about learning a new language or a new technique or something, do we have to use a certain amount of care in choosing something that’s actually different?

If we want to maximize what we get out of it, absolutely. I’ve always said that. I think you need, if you’re looking at a language and you already know C… or sorry, bad example. If you already know C++ then switching to Java is not a radical change if you’re trying to train yourself in something new. Whereas switching to Clojure or Haskell or something else is. And I think you need to think about that.

Now, the interesting thing to me about say Grunt versus Gulp is not the actual specification of the build that you want, because they’re both incredibly ugly and really difficult to use. The interesting thing about Gulp once you get used to it is the internal way it actually works, which is basically a set of filters that apply to a stream of activities that are passing through them. Whereas the first activity is probably just picking up file contents and then we’re transforming them using compilers or minifying them or whatever we’re doing. And Gulp actually shows us one way of organizing the workflow in that streaming environment.

And what I’m shocked is that no one has come up, or maybe they have and I haven’t heard of it, with a Gulp-like thing for business processes, because it seems like a natural fit. It’s like an asynchronous message queue but really easy to use. So for me, the big learning experience with Gulp which was frustrating when I first started, was getting that into my head. That’s how it worked and that’s how to think about the progression of my data through it. So, I think in that particular [inaudible] yeah, there’s no real big difference between Gulp and Grunt in terms of capabilities. But in terms of how they do them, I think Gulp was interesting.

Hm.

Gulp thinks about it in a very functional way.

Yeah. But it also has this non-functional idea of the multi… it’s like trying to work out what the stream actually is in Gulp is the interesting part. And how it handles the fact that you have multiple things going on at the same time in that stream and how it handles the synchronization of those things. That’s what I found was really nice.

Great point. So, that’s a great example of how learning a build tool can have the same kind of effects on your brain that learning a new language might.

Yeah, absolutely.

But only if you really dig in. Git is like this, too. Git has all kinds of brilliant ideas inside that are super useful outside it. But if you just stick with the surface, “What do I type? How do I make this work? Give me the spell,” you’ll never get there. You have to get the philosophy of it.

There was a really great author. I forget his name. But he wrote a book where he said, “Don’t trust evil wizards.” Do you know who that was, Dave? [Laughter]

I know, it was Andy Hunt.

That’s it. That’s it.

And another guy, and another guy.

Yeah, another guy.

I still recommend ‘Pragmatic Programmer’ to people today. I think it is still as valid today as it was 15 years ago. And that book is probably in my top five books that hit me like scripture almost, like revelatory experiences. And yeah, the horrible thing about Git is that to really get good use about it, you really have to dig in and understand what a directed acyclic graph is. The awesome thing about Git is that if you dig in and find out what a directed acyclic graph is, you can do mind-blowing things in your code, like move a chunk of code from one file to another and still see the revision history in that other file of the code when it was in the file that it came from.

Or if you’re me as I just did this morning, you can totally destroy about three days’ worth of work by trying to be too clever with it. But yeah.

Yeah.

It comes back. Okay, let’s try and circle a little bit here. I think it comes back, when you put it in those terms, doesn't it also sound about the same as forming a relationship? In that you can be superficial, “Well, she looks cute,” or you could be, “Hey, I want to learn more about you.” Yeah?

Which one’s going to lead to a more fulfilling and long-term relationship?

That’s so true. You could be the pick-up artist. How do I just get this to work?

Yeah. Or, “Hey, I really like your directed [acyclic graph].”

If I had a dime for every time I heard that.

Yeah.

So, one of the things I like about the conversation we’re having is that it acknowledges a personal and emotional component to the technology to reflect some of our humanity. We as professional developers, we seem to idolize objectivity. But we’re acknowledging through this conversation that we are necessarily subjective creatures.

And I think we often try to hide that by couching what is fundamentally subjective in this patina of objectivity. And I think that’s one of the dangers that I was talking about at the beginning where you have people that push a particular solution as being ‘the solution’.

Yeah.

Well clearly, you do it this way. As if there was some objective benefit to it as opposed to, “This one makes me feel better.”

I think there’s another parallel with relationships where you see that person who gets into a new relationship and their relationship becomes their identity.

Yeah.

It’s all they talk about. They get the person’s face tattooed on their arm or something. It might be an extreme example, but you know. You look at their social media profiles and it’s all about who they’re attached to, right? And you see that. I see that a ton with technologies. Look at people’s Twitter profiles or something and it lists basically what technology they’re in a relationship with.

Yeah. And you ask them what they do and they say, “I’m a Ruby programmer.”

But the ‘to be’ verb in there. “I am a Ruby programmer,” as opposed to, “I write Ruby”.

Right, yeah. You see it. And it’s inheritance versus composition.

Our relationship status with technology should read, “It’s complicated.” [Laughter]

Yes.

Yeah. So, maybe what we should do is we should all stop and form some kind of technology counseling service.

[Laughs] Have you been injured by a technology?

[Laughs] Yeah, yeah.

Please see a doctor if your vim usage lasts for more than four hours. [Laughter]

Please tell me how you feel when you get this compiler error.

[Laughs] Is your language hurting you?

[Inaudible] fun.

And then that goes back to what Dave said earlier that as an industry we like to think our tools are the problem. So, if you’re going from tool to tool and frustrated and unsatisfied in all of them, maybe it’s you.

Yeah.

Ish, except at the same time I kind of appreciate the view that at this point, all the tools suck. I don’t know, maybe that’s me. [Chuckles] But…

They’re all tradeoffs. They all solve some problems well and cause others, right?

I think we have this tendency to think of new tools as being this linear progression of better and better solutions, when I think a lot of times we’re just rehashing forgotten solutions.

Yeah, absolutely, absolutely.

But the context has changed. So, some of those solutions that didn’t work in the 70s do work now.

I actually…

Like the person you had a relationship once and it totally didn’t work out but then you both matured in the past 20 years and then you meet again?

It could happen.

It could happen.

Except if you’re both married and have kids and…

Right. [Chuckles]

Yeah. [Laughter]

I might be taking this too far. [Laughter]

It’s [inaudible], yeah. [Laughter]

No Avdi, you… [Laughter]

You were talking about looking forward and looking forward. And it does. It makes me think about sometimes we forget to look back. To go from woodworking to metallurgy, Damascus steel was made in Damascus 2,000 years ago. And we didn’t know how to make it. The secret to making this was lost. And we have now in the past 10 years rediscovered one way to make it and it requires modern tools. So, it’s probably not how they made it 2,000 years ago. It requires a long, lengthy process and all this… And the history of it is a lot of fun. You can look it up on Wikipedia sometime. But computer science is moving so fast that we are having these same kinds of experiences within half a generation gap where… well, I guess it would be a full generation at this point.

But I can remember back in 2009 going back and watching the SICP lectures from MIT and being very angry that there were concepts being taught at MIT in 1984 that not only did I not know them, but nobody I knew, knew them, which means that I was not hearing them from any modern programmers. And these were enduring concepts. It wasn’t the CAP theorem but it was like the CAP theorem. It’s like one of those immutable laws of things like streams and that sort of thing. And now it’s all come back because there was this big resurgence of SICP in 2009. And now when you talk to people about streaming things and using queueing and that sort of thing it’s come back into our lexicon. And it’s like a rediscovery of a 2,000 year old metal working technique. But the reason we’re rediscovering it is because we forgot it.

And so, I love looking forward and moving forward. But don’t get so limerent with the new that you throw out all of the old, because the principles and practices from the old are still going to hold true.

Absolutely. And in fact, I was thinking a couple of days ago it was actually 40 years ago that I sat in the lecture theater and Tony Hoare talked about Communicating Sequential Processes. And whoopee, we’ve just discovered them again.

Yeah.

So yeah, I think that’s absolutely true. But here’s my question. So you’ve got, what have we got now? We’ve got 60 years of history as an industry. Maybe a little bit more if you roll in some of the more math-y stuff.

Yeah.

How should somebody learn the salient points of our history? How would somebody discover on their own Communicating Sequential Processes? Or the ‘Algorithms + Data Structures’ book, or all of the old stuff that still has so much to teach us. How do you go about discovering that?

Oh, I hope you have an [inaudible].

You pick it on Ruby Rogues.

And then people randomly sometimes read it.

There you go.

I think you’re making a great point that we are in a cycle of forgetting our history every four or five or six years.

I think we are. But I think part of that is because our history is not made available to us. I mean, I know that’s like blaming someone else. But the reality is that the presentation of history is an incredibly powerful way of influencing people and teaching people. And I think as an industry we do a really bad job of that. We don’t honor our history and the people who made our history. We don’t study it. We’re like a group of people who are writing books that have never actually read a book.

They just enjoy the process of writing so much.

Yeah.

I think that’s… we need to find ways of making that history accessible and relevant, because it is. It’s fundamentally… the first OO language arguably is Simula 67. And Simula 67 still has features in it that no current OO language that I know of has. It’s amazing to me. There is still so much back there that we haven’t mined.

Do you think that’s in part due to an imbalance between people who are CS majors necessarily and those who are self-taught?

Could well be, could well be. Having said that, I don’t have a thing against self-taught. In fact, I would say that the majority of the better programmers I know do not have CS degrees. And to some extent, many of those actually have a better grasp on our history. And I think maybe that’s because they chose to come into it a bit later. And it is more likely to have been because of some interest as opposed to their parents saying, “Go get a job.” And as a result they are more likely to go grubbing around and learning stuff. I don’t know. But yeah, that could be. I don’t think having a CS degree is in any way a guarantee that you actually understand our history.

Yeah.

I have a CS degree but I was actually taking it at the point the history was being made. So, I have a great understanding of the history.

Do they teach this kind of thing in ordinary computer science courses that are not MIT? I only minored in comp sci. and I definitely didn’t get this. And in fact the culture was, “History? That’s for liberal arts majors. Do you want fries with that?”

Yeah. There’s been a nerfing of the curriculums at a lot of schools. Brigham Young University used to have one of the top-rated CS programs in the country. They were in the top 10. And now they’re not, they’re just embarrassed to even talk about comp sci.

And when I was there in ’91, well ’92 and ’93, the comp sci. program was very much grounded in mathematics and the history. And it was actual computer science. When I circled back to 15, 16 years later talking to programmers in 2006 who were recent graduates from BYU and I was asking them, “So, what did you do your senior project on?” “Oh, we don’t do senior projects anymore.” “Oh, okay. Well, what did you do about…?” “Oh, we don’t do that anymore.” “Well, how hard was it for you to apply to get into the major?” “Oh, there’s no requirement to get into the major anymore.” And I’m like, “What?” And I finally sat down and said, “What did you learn in your computer science degree?”

And it turns out that, and I hate to dig on my alma mater, but their computer science program is now a trade tech school for programming. It’s no longer computer science. It’s computer craft or computer tradesman-ship. And I’m going to get hate mail. Sorry guys, I love you. But yeah, the CS program in a lot of schools has changed from, “How will this teach you the science of computing?” to, “How will this get you a job as a programmer?”

It’s interesting because one of our editors and authors is Brian Hogan and he actually, his real job is teaching. He teaches at a university. And he bemoans this partly because it’s actually the students that drive that. The students say, “Hey, you know what? I don’t want to come out of this with a math degree or something else. I want to come out of this with a job.”

Exactly.

Yeah.

And so, I need you to show me how to code Java or whatever it is. On top of which, most of the people teaching in those courses, they really don’t have that much experience in doing it for real. And so, they’re very happy to go along with that. And so, you’re absolutely right. It leads to a gradual tragedy of the commons in terms of what you learn.

Yeah.

The good news is that once we mature a bit and we learn that the liberal arts is actually a way to learn to process information and is a fabulous thing, then we have the option of going back. And for instance, if I’d learned about CSP in college, I would not have appreciated it. But now with some experience I can much better grasp how this might be used, how it contrasts with other techniques that I’m familiar with, and I can appreciate the history in ways that I couldn’t then. And the books are out there, right? I’ve got a couple of them on my shelf.

What are they?

So, I’m looking at SICP, the ‘Structure and Interpretation of Computer Programs’ and that’s one of the classics, right?

Right.

Oh, ‘Smalltalk Best Practice Patterns’, that’s a good one.

Yeah.

Absolutely.

I’ve got ‘Types of Programming Languages’ by Pierce. Now, have I read all of these? I promise I have read chapter one in everything on my shelf.

And that’s where all of the big ideas are. And I figure if I believe them and I don’t need extra proof, then I don’t have to read the rest of it.

Absolutely.

Or Dave, do you have a curriculum list, as an author and publisher? Is there something that you’d recommend to people, ‘here’s a resource to go soak up the history of your profession’?

I cannot think of one or a small number of books that I’d recommend for that.

We can ask our listeners to tweet that [inaudible].

Yeah.

Yeah, absolutely. I would love to hear what people think. Because you’ve got things like Knuth volumes one through four, right?

Yeah.

Everybody owns and nobody’s read?

Well yeah, I mean, I think that is a really cool book. I actually was probably one of the few people that actually read every word in the first three. And I really, really enjoyed it. But if I was to look back on it now, it’s not something I would recommend to someone who just graduated simply because it’s very, very focused on one thing. So, you have to read whatever it is, a thousand pages, two thousand pages, and you’d come away knowing about analyzing algorithms and thinking about the beauty in what you do and everything else. But at its time, it was revolutionary and it made us all think. Now, it’s like it needs some kind of condensing down to a chapter in the story of how we got where we are.

Yeah. Knuth is, I like to think of Knuth as the Shakespeare of our time because everybody wants to have read Knuth but nobody wants to read Knuth.

No, it’s true. There’s this volume of information that could be condensed. And that’s what speaking is about, for me largely. Conference talks is to…

Yeah, that’s a good point.

Condensing those ideas, bringing it alive, and then sharing it in a way that keeps people’s attention.

And here’s the other thing about knowing your history. If you actually understand, and this is not just in computing, this is in the world, if you know your history and if you know the various drivers then you are less likely to be fooled by snake oil salesmen. So, people will quote stuff as, “This is important. That’s important.” And if you actually know where they’re coming from, what the history of this was, then you would be able to say, “Actually no, that’s not true.”

So, one of the things I thought was really interesting to me was the whole big thing about goto. So, Dijkstra writes the letter in the ACM ‘Go To Considered Harmful’. And not only did he create the ‘considered harmful’ meme but he also drives an entire generation of language designers to create all these convoluted languages without goto. Why? Because Dijkstra didn’t know how to prove mathematically a program if it included a goto because he couldn’t work out what the pre and post conditions are prior to goto. No one can, because you don’t know where it came from, right? And so, ‘Go To Considered Harmful’ is just basically, “Goto is considered a pain in the butt in my research because I can’t make proof about it.”

And now as a result, people certainly for a long time strenuously avoided goto when it was actually clearly the best thing to use in a particular point. And the number of totally convoluted programs I have read simply because people were trying to avoid goto’s or whatever else. Structured programming was fantastic. Without structured programming we wouldn’t be where we are today. But the reason for structured programming is totally lost. We don’t do structured programming for the reason that they did it initially. And that was provability.

And so, I think if you understand that history and if you know what motivated it, then you’re in a lot stronger position possibly to resist the allures of the things that you might become infatuated with today.

Goto is a fun one because we watched it morph from ‘Go To Considered Harmful’ to languages like Visual Basic adopting, eliminating the pure goto but keeping on error goto, and then the end of the function or whatever. And then it became exception. Goto’s got replaced with exception handling. And it’s fun to watch that yeah, there are entire swaths of computer science that we consider part of our bedrock that are really just the result of some guy’s blogpost.

Yeah, exactly right.

Dave, it sounds like your next book should be ‘The History and Philosophy of Programming’.

Yeah. I don’t know. How would you even approach that?

It’s tough, right? Because I’m thinking about something like CSP, Communicating Sequential Processes, which I think is a great example of a fascinating paper then I assume a great book, because I only read the paper, with really big implications. And nobody knows about it except for the people that I guess implement Erlang. And I’m having a hard time imagining a useful way to address that in a single chapter in a book, you know? I can imagine writing about it. I can’t imagine it having an actual impact on how somebody thinks about their problems if they just read a chapter in a book on ‘Here’s what CSP is’.

Well, I think what you possibly would have to do is to have two types of story in a book like this. There’s the story of the things that came about. So, something like CSP and agents, both of which are 1970s ideas really are coming to fruition 40 years later. And so, part of the book would be those kinds of stories. But then part of the book would also be the rest of the stuff, the stuff that we don’t currently copy. And the idea there would be to show that there’s a whole bunch of stuff back there. And maybe to fire some neurons and somebody somewhere to go, “Hey, you know what? That actually would solve my problem.” And basically, by laying out what’s possible and what’s come before then people can pick and choose what would be useful for them. If they don’t even know it exists, then they can’t.

A really great example there is bloom filters. Very few people actually know of bloom filters. And to my knowledge, there are no off-the-shelf library implementations. Fantastically useful algorithm, unbelievably useful algorithm. I use it maybe once a year and it solves some massive problem. And yet it’s just not known. So, that’s the kind of thing where if you could highlight those kinds of things then maybe, I don’t know, people would have a better understanding for what they came from.

Mm.

That would be a great blog. Somebody please start that blog. You can call it, ‘The next big idea that is not new’.

The last big idea.

Make it a Twitter account.

It’s like neofuturism, right?

Mmhmm. Computer archeology. Computer anthropology.

Anthropology, I like that.

Nice.

The history thief.

There’s a lot of treasure in those tombs. [Chuckles]

I’m going to state a bias and ask you to confirm it. I feel like the rampant use of social media and Hacker News and proggit and stuff like that is not helping with learning these big ideas that we’ve lost. I feel like it’s really reinforcing the constant cycle of new that isn’t really new. How do you feel about that?

I couldn’t agree more. And a lot of that is because the people that are the most strident typically are also the people that spend so much time thinking about themselves they don’t really have that much time to think about other things. And so, the people that are famous and the people that are the volume producers of all the stuff on reddit and everything else are typically not that informed.

I’ll disagree. Four years ago before I was on Twitter, before I was going to very many conferences and before I read any of that stuff, I was a very different programmer. And I learned very little. I went through 10 years of getting really good at Java but I could have been a lot better if I’d been keeping up with what the rest of the community was doing. And Twitter has been amazing for me. Twitter in particular is awesome because I can curate my own feed and only listen to the people that are talking about this kind of historic thing and these big ideas and are not getting too irrationally excited about the next big thing. So for me, Twitter is a lot better than, well, I just don’t go to reddit or Hacker News. Sorry, I don’t read that kind of stress.

Right.

The self-curation I think is key there, Jessica. It’s not participating in a culture in which amplified voices then to be the voice of the majority.

Good point.

You’re curating it. You’re finding people who are interesting and maybe who have viewpoints that are different than yours.

And I seeded that by going to conferences, meeting some people, and following them, and then following their retweets.

And that’s actually, that’s really good. I don’t disagree with that at all, because what you’re doing there is as you say, you’re selecting. You’re selecting it. But even with Twitter and even if you only pick, to some extent if you follow people that you trust, Twitter can also be that incredible distraction. It’s like, what was the name, Doug, that dog in the movie. It was constantly going “Squirrel!” and chasing off after something.

And somebody I respect posts something about, “Oh, I’m really enjoying this,” and bang, there goes two days of my life. And in fact, one of the things will actually be my pick. And it’s your fault, Jessica, because I was chatting with you about Slack. And your enthusiasm convinced me that I should give it a go. So, I just spent the entire weekend and yesterday coding up various extensions so I can integrate it into our systems.

Awesome. [Chuckles]

So yeah, that was a classic squirrel moment, because I really don’t have that time. So, I think you ought to be careful to balance every source of information. And fundamentally I think you need to control your… it needs to be a disciplined thing. Learning is discipline. And you need to have it. I don’t.

[Chuckles] That’s a fantastic point. And it’s something that I’ve been thinking about a lot lately, just because I’m getting to a point in my life where I’m realizing just how little time I have left relatively speaking, in the grand scheme of things, to learn compared to all the stuff that there is to learn. And realizing that I actually need to write up a list of the programming languages that I really genuinely want to invest some time into. And then I need to deliberately avoid the others, because I just can’t. I can’t. There’s too much. Is that, do you do that? Do you do that deliberately?

For me it’s the other way around in that I typically, for a programming language, what I’ll do is I’ll dip my toe into a programming language, particularly if someone I know likes it. And then pretty quickly I’ll decide whether or not this is for me. And it’s nothing to do with the technical side of it or the theoretical underpinnings of it. It’s just, does it work for me? And if not, then I’m not going to do it.

But again, I think that, so for example right now, so Scala versus Clojure has been weighing on me a little bit, because I’ve avoided JVM based languages now for years and years. And I keep feeling I need to learn one of the two of those. And both of them when I first tried them put me off. And now a lot of people I’m respecting are telling me that Clojure is good. So, at some point I’m going to go back and spend a week running a few, all my standard programs and recoding them in Clojure, and maybe come around and say, “Okay, yeah. This is cool.” So yeah, I don’t know. I don’t have a list the way you do, because like I said that would require discipline and I don’t have any.

But I do consciously think about what I learn. But to some extent what I learn is based on what makes me feel good, which is probably not a good idea. The other thing I’d say is that one of the things as developers that I think we need to be thinking about, and that comes back to your ancient aged self and how… [Chuckles]

You only have a few minutes left and you’re spending it on this call… [Laughter]

Is that we need to think about all of the things that we learn, not just the technologies that we learn. And we need to make conscious efforts to learn whatever we can. We need to read. We need to experience. We need to do stuff partly because it’s really easy to get totally absorbed in what we’re doing. It’s so much fun and it drags you in. there’s all that infatuation thing that we’re talking about, the limerence, the idea of it drags you in. It makes you want to participate and addicts you in a way. And we tend to forget about the rest, showering and stuff like that. So, we don’t go out there. We don’t experience and we don’t learn.

And I think as developers we actually owe it to ourselves and to the rest of the world to make a conscious effort to learn other stuff as well as just the technology. And in the same way that learning random technology will actually improve what you do day by day in your current technologies, I think learning other stuff also has that kind of impact. And it makes you a more rounded person, a better person to work with, and more interesting over a beer.

That is a great point. It’s a series of great points. We are getting to time and overtime. There’s one thing that you just mentioned that I really, I can’t stop myself from circling back on, I really want to ask you about. You mentioned coding some of your standard programs. You mentioned how you learn a language or decide you like a language. And I’m really curious about that process.

Yeah, so I have two or three that I like to try to write. Depending on the language, what it’s good that, I’ll do different things. But for example, Sudoku solver is actually a pretty good program to write because it involves a fair amount of messing around with data and trying to structure things in a tidy way. And also, it’s a challenge in a little bit of a way, because some of the solutions that would work in an OO context don’t work at all in a functional context, because obviously state management is different. So, I enjoy that one.

If I want to get really into a language and I’ve got some time, a really good program to write is a markdown parser, because markdown is such a badly specified markup. And it has so many weird little edge cases that it’s actually very representative of real-world coding. And so, I’ve done that three times now, written a markdown parser, just to learn the language and the way around it. And every time I feel I’ve done it better. And every time I’ve learned a whole bunch about the language I’m using.

Sweet. Should we do picks now? Let’s go with the important picks. Dave, what do you want to pick?

Oh, I don’t know about important, because all my picks are relatively straightforward and nothing exciting in them. And the reason I pick them is not because of the surface features but because of the stuff that’s behind them. So, let me try and justify this.

My first pick is Slack. And I’m a newly found, or a new convert to Slack, thanks to Jessica’s recommendations last week. And I’ve been working on it since, oh I guess the weekend, so maybe three, four days. And I have been blown away at how easy it is to integrate Slack into the rest of our business. The thought that has gone into the various APIs, the webhooks and the API calls directly, and everything else, is just beautiful. They’ve resisted the temptation to put the kitchen sink in there. And as a result, they’ve come up with something which is simple and clean and just works. So, they’ve made a convert out of me simply because of that discipline. So, hat’s off to them.

My second pick is a book. And it’s a book that’s about four, five years old. It’s called ‘Why does E=mc2?’ by Brian Cox and Jeff Forshaw. And I picked it firstly because I like this kind of book. It’s a mass market science book. And I like reading about this kind of stuff. And I picked it because it’s a phenomenally good book in terms of the way it produces explanations of things. They have a talent for choosing really apt and interesting analogies. And then also for saying, “Okay, at this point I’m going to stop using this analogy because it’s broken down. It’s no longer valid.” They also have a really good way of taking concepts that are kind of weird and converting them into the every day.

And what I found is at the end of this book, my understanding… no, my intuition about fourdimensional space-time is now a lot more solid than it was. I can actually manipulate things in my head that I used to have to sit down and think through as explicit thoughts. A lot more has become tacit as a result of reading this book. The phenomenal job they’ve done is that in the middle chapter of the book they actually show the derivation of E=mc2 using really nothing much more than three postulates, three suppositions, and Pythagoras. And based on that, out it popped. Phenomenally good job.

And my third pick is a conference. And it’s a conference that Jessica and I went to last week along with five, six hundred other people. And that’s the Philadelphia Emerging Technology for the Enterprise conference. I do a lot of conferences. And I typically either don’t attend the talks or I do attend the talk, I’m sitting at the back next to a power strip just working on either my talk or some other project. This conference I actually enjoyed and participated in every talk I went to. In fact, it was actually hard to pick between tracks sometimes. The talks were of such good quality. The reason for this I think is that it has a slightly controversial format. They don’t call for papers. Instead they invite speakers. They decide what topics are interesting. And then they go and they look for the best speakers to talk about those topics. And as a result, it really is world-class. So, if you have the opportunity and you’re in the area, I would strongly recommend the Philly ETE conference. And those are my picks.

Awesome. Thank you. Well, thank you Dave and thank you everyone for this episode. It’s been super interesting. And I bet we’ll have you back again.

I would love to be back. It’s always a pleasure.