Thursday November 4, 2021; 1:24 PM EDT
- (5 min read)#
- I'll probably change the title of this post. But it's true.#
- I think it's because Dave Winer built all the pieces for himself. And he's been at this for a very long time, so he knows where all the inflection points are. When you solve the same problem over and over, from different directions, you get a feel for where you're going to run into trouble, or want flexibility in the future. #
- When you start out, you put flexibility everywhere, everything is configurable and there's an infinite number of ways to do it. I once had a team of developers, fresh out of college, working on a content management system that we wanted to be as scalable and flexible as possible. This is the project I learned to watch what your developers are doing, just keep up with it, because they were very excited with their design, which modeled every kind of data in just three tables. (Sigh. We've all done this, admit it. There's no shame. And it's a design that can work, but not in SQL on a server that today we wouldn't use to power a watch.)#
- After awhile you get a feel for the data structures that are going to work, and the things that you know you're not going to need to build. If you don't need the flexibility right now, don't add it, it's just one more stupid chunk of code you're going to have to maintain and drag around with you forever until you excise it because this time you're going to do it right. So the flexibility points you choose are absolutely critical in making something like an app. #
- And they're even more critical when you're building something like a scriptable app, a framework, an API, a server, a set of interlocking services, protocols, storage systems, content management, designed and working in the real world right now, which is what Dave's built with Drummer.#
- Think about that! How do you even fucking do something like that? I know, you start right from the beginning as a genius, and have everything clear in your head like a vision, and you build it. It could take years because there's a lot of parts, but that's how it works, right? Well, holy shit no.#
- Here's what you do not do: You do not build something more than once. #
- Wait, didn't I just say that part of making something good is that you've built it several times over and now you can do it right? Well, kind of. But the real point is: Programmers are lazy. The absolute best ones abhor doing something more than once. That's what machines are for!#
- So what Dave's been doing, sure, he's been iterating with More and Frontier and UserTalk and Clay Basket and suchlike. But he's been absolutely fanatical about Not. Doing. Formats. Over. And. Over. If he figures out a way to serialize something, a way to improve interaction between processes on a machine or services across the internet, he does it once, he does it publicly, and then he uses it.#
- Drummer is, when you use it, an entire ecosystem of interlocking services, servers, protocols and formats, all of them documented publicly, running locally and all over the place, and each of them useful in completely non-Drummer contexts. So Dave could build an outliner, and then serialize the outlines into a file format, and make a tool that talks to Twitter, and build a web server, and and then years later build a blog renderer that takes those outlines and turns them into blogs. Each part swappable, each part useable for other things.#
- The other part about being lazy, is that you look for things to automate. And the best way to automate something complicated is making lists of instructions, which is programming, which means you want to write code to make your app do things. So you make your app scriptable. #
- We already know that deciding where to insert the flexibility takes care and experience, but deciding how the code should read is absolutely critical. I've designed and documented developer frameworks for commercial sale, back when you could make money doing that. Building something for developers to use is extremely hard, because you can't break shit. And the decisions you make about the API you're constructing have a direct impact on how their code will read.#
- You will spend 90 percent of your time reading code, even if you spend all day writing code. Being able to look at it and see what it's doing is critical. The fewer stupid syntactical roadblocks you put in front of your developers, the clearer you can make their code, the better. The snippets of code that Dave posts on his blog, where he says "hey look do you see why this is cool", this is what he is talking about. The code is simpler, it is easier to read, and is way, way, way more obvious. That means it's a joy to work with. #
- Take a look in GitHub at the source for some of the pieces of Drummer to see what JavaScript actually looks like when you have to deal with callbacks etc. It's a mess! This is why I want Dave to go ahead and pick a name for Drummer's scripting language, because it really is different. JavaScript generally comes with an entire baggage of stuff that is just a giant pain to deal with when all you really want is to do something with the results of a freaking web call.#
- (Drumkit, of course, is the natural choice.)#
- Update: See here for additional context.#
- Drummer is scriptable, and it's scriptable in the right spots, at the right levels of abstraction. In previous posts I've talked about designing a tagging system (built entirely right inside Drummer, think about that!)—and you'll note that I made an awful lot of assumptions. I know there's going to be a very clean, simple way to walk the nodes of an outline, because duh, there is no way Dave hasn't solved that problem a billion times over. I know there's going to be some standard verbs for string manipulation, node manipulation, navigation, and especially getting and setting attributes. And because Dave built Drummer for himself, and is drawing on a lifetime of building scripting languages and APIs, the verbs are the ones you're going to need first. #
- So even the fancy version of my proposed tagging system, the one that's walking nodes and gathering things into collections and then updating in a single pass, even that version would be pretty readable, and probably not more than a few dozen lines of code. And I really haven't written much Drumkit code yet, but the snippets I've done are enough to let me see that. #
- And how much of that code will be spent on maintaining menus, connecting buttons, building dialog boxes and then displaying them? Well, none. Absofuckinglutely none, because that shit sucks. To add a command to a menu? Edit an outline. Add a button to the icon bar and attach a bunch of code to it? Edit an outline, and put your code right there.#
- So what we've got here in Drummer, is basically a lifetime of experience, distilled into code, documentation, protocols, formats—here for us to play with. #
- Drummer is fucking awesome.#