David Heinemeier Hansson (DHH) shares the story of how JavaScript sprinkles in Basecamp evolved into a full-fledged framework called Stimulus. We talked about ins and outs of Basecamp as it is today, Ruby, JavaScript, David’s somewhat new found love for JavaScript, how they open source because they can, and David’s new YouTube series called “On Writing Software Well”.
David Heinemeier Hansson: Sure. The channel is called “On writing software well”, and it’s just on my YouTube. It’s basically just me opening up an editor and taking a topic that could be testing, or callbacks or whatever, and showing how we use that in Basecamp, and showing how we use Rails and Ruby to solve the problems.
What I wanted it to feel like was if I sat down with another programmer and we just looked through some code together - I always love doing that, because I find that many programmers when they’re talking in the abstract about code and patterns and so forth, they have these fierce arguments: “No, this is the wrong way of doing it! This is the right way of doing it!” And then if you sit down with them and you look at the actual code, you end up agreeing way more often than not, because the pressures and the concerns of a specific piece of code guides most reasonable people in a similar direction, at least when they have somewhat of a shared background and experience. There may be functional programmers who are like “Oh, anything object-oriented or side effect-laden is wrong” and whatever, you’re not gonna find common ground with them perhaps, but for anyone who exists in the same paradigm and somewhat have shared beliefs, if you look at concrete code, we end up liking the same things a lot of the times, a lot more often than if we just argued about it in the abstract. And this is one of those lessons that I’ve learned time and time again. Ruby or Rails back in (I think) 2009 merged with another Ruby Framework called Merb. And Merb was born for a lot of different reasons, and some of the reasons were that the people behind Merb cared about different things than what I cared about; not that I actively didn’t care about them, they just weren’t top of mind. There were some extensibility concerns that they had and some performance concerns that they had, and we thought we had these fundamental, underlying philosophical differences about how to write a framework in Ruby.
[01:14:08.05] So I sat down with Yehuda Katz in particular, who was one of the guys involved with Merb at the time, and we had these fierce debates when we were just chatting in Campfire, and then we sat down, looked at the same piece of code and went “Oh yeah, we believe the same thing.” And we’re like, “Wait, what?!” We were just arguing our heads off in opposite directions, and then we looked at a piece of code together and we came to the same conclusions. I’ve done that so many times now that I believe that it’s really the primary way you should be arguing code patterns and principles - by looking at actual real production code, and doing A/B’s. “Let’s write it your way, then let’s write it my way, then let’s see if there’s one or the other ways that’s the best, or more likely that there’s a combination of the two ways that turned out the best that we both like.” I find that that happens just all the time.
So I wanted the YouTube channel to have that feel as though we were sitting down at the keyboard together and looking at code together and coming to similar conclusions. That doesn’t mean – I mean, everyone is not gonna sit down and watch these videos and go like “Oh yeah, I would have written it exactly like David would have written it”, but at least if you hear the why, why we wrote it that way, how we weighed the tradeoffs and came to certain conclusions, you’ll understand why we did it the way that we did, and I think that that understanding is often sorely missing when people are talking programming and talking shop.
That’s why the arguments get so heated. We start having these violent disagreements that in many ways are completely unnecessary, completely unjustified by actual code… And it can’t be solved or it can’t be addressed just by looking at example code. It can’t be addressed by the stylized, idealized version of what programming looks like because until you have all the real constraints and pressures of production code, you’re not taking all the complexity into consideration, and often times that’s exactly what tips the scale as to whether to go one way or the other way - to look at the real code.
For example, I did an episode on globals. Rails 5.2, which is just about to be released, has a new encapsulation of globals for dealing with things like current used and current account within the lifecycle of a single request. And if you just sat down and had an abstract conversation about globals with a programmer, most programmers would say “Well I learned/heard/know that globals are considered harmful. Why are you using globals? Globals are terrible? Don’t use globals. Are you a bad programmer? Are you terrible? What’s going on here?” [laughter] And then you sit down and like “Yeah, all those things have strengths of truth in the aspect that globals are dangerous and you do need to be careful, but hey, let’s look at this code.
Let’s look at how much simpler and easier it actually becomes to understand once we use a global. It’s not a thing you should use all the time and in all circumstances, and you can certainly get carried away with it, but in this particular instance, using the feature on this particular aspect of the code, it gets better. This A is better than that B.”
I think that those are the concrete tradeoffs, as I said, that are really just fascinating, and I think it opens people’s minds much more than just a blog post that says “Global is considered harmful.”