Have you noticed a gap in your workflow? Do you think you can fill that gap? Or have you made something that fills the gap only for you, but deserves wider use in the developer community? Samuel Giddins talks through some key steps to determine if you are ready to build developer tools, as well as some points to consider to be certain that you won’t be pulling your hair out in the process.

---

Introduction (0:00)

I’m going to talk today about the art of building developer tools. It’s not what most people would consider an art, but given that it’s something I do every day, I would like to elevate it. And of course, given that I’m talking about an art, I need a snobby subtitle, so “The Art of Building Developer Tools, or When to Take the Plunge”.

I’m Samuel Giddins. I’m a Cocoa engineer here at Realm, and I’m just going to go quickly through a couple of projects. First off, we have a very cool looking dragon. This also happens to be one of the tools that I need to make my living. It’s called LLVM: Low Level Virtual Machine. It’s an open source project, and it’s the backbone of Apple’s compiler toolchains, both for Objective-C and Swift. Swift is a programming language that Apple has given us, and that I spend a lot of time writing in. Two random projects. What do these and a bunch of other projects have in common? Why am I throwing up pretty logos? And less pretty logos? At least to those of us who have experienced the trauma of being Cocoa developers, Xcode. And of course when we install Xcode, Apple even tells us that we’re installing Apple’s developer tools.

Developer Tools (1:42)

They’re the tools that we use as developers to get from Point A to Point B on a daily basis. They’re the things that turn our code into programs we can run. They’re the things that turn our text files of dependencies into things that we can compile and link against. Developer tools are also the things that generate pretty webpages for us, and do a whole myriad of things.

My Projects (2:17)

Now to mention a couple of projects that I work on: Bundler and CocoaPods are both dependency managers because, of course, someone needs to work on two dependency managers to stay happy. Jazzy is a project that we built here at Realm. It’s a documentation generator for Swift. Realm, obviously, is a database, and I build RestKit, which is a project that makes using RESTful web APIs easier.

All of these are different kinds of tools and they do very different things. You know, they’re written in I think a total of four or five different languages. Bundler is all Ruby, CocoaPods is all Ruby, Jazzy is a mix of Swift and Ruby. Realm is Swift, Objective-C, C++, and RestKit is all Objective-C. They’re different tools in that they’re built in different languages. They’re different tools in that they target different people. For instance, if you’re building a database, RestKit probably isn’t very useful to you. If you’re building a database that has no dependencies, you’re not going to need a dependency manager. But if you’re building a database that you want to have users for, you’re going to need a documentation generator.

These tools all sort of fit together into the ecosystem that we use to create pretty much every application that we run.

How Can I Make Them? (4:12)

If you haven’t hit Command-W on your web browser yet, if you’re still listening to me, you might be thinking, “How can I make these things? These all sound like cool, fun things to work on, totally not things that I stay up 12 hours a night building. So, how can I make these things? They seem like fun, they look good on a resumé, and it’s cool to help other developers build stuff.”

Find Something Missing From Your Workflow

This is kind of a long list, but I think the first thing is the most important. It’s finding something that you feel is missing. Don’t build a Python web server if you’re not a web developer and you don’t use Python. Don’t build a database if what you are really interested in is building beautiful animations.

Build It

Number two is, okay, build it. Get home from work one day, and ignore everyone else in the house. Sit down and start banging away on the keyboard until you get something that compiles and it runs, and it kind of does one thing. You can make a gif of it working before it crashes. So that’s step two.

Build It So Others Can Use It

Step three is, great, you’ve got that little prototype working. It can compile, and if you hit the exact right sequence of keyboard strokes, it’ll do kind of what you want. Scrap that. Build it again so other people can use what you build. No one’s going to like using a command line tool that you have to enter 300 different characters each time to invoke a command. Git, I’m looking at you. You want to build something that other people are comfortable using. For instance, we use Xcode because it’s really hard to write a makefile that will do exactly what Xcode will do for us. Xcode makes things easier. We can hit a button, build and run, and it will do what it says, unless it crashes.

Receive Feedback

We’ve built it, and we think other people can use it now. Push it up to GitHub, push it out on Homebrew, or on RubyGems, or on CocoaPods. Now we receive feedback. We say, “Okay, I’ve built this thing. I think it’s ready for other people to try it. What do you think? You’re not me, you don’t know all the underpinnings of how this thing works. You’re approaching this from a slightly different background. Does this work for you?”

Ignore 70%

So, we’ve received this feedback, and now we’re going to ignore most of it, because most of the time when people give feedback on developer tools, they forget to put their developer hat back on. They’re in user mode. And that means that a lot of the time they won’t understand that no, it’s not possible to combine X, Y, and Z at the same time. Those options are mutually exclusive. Or, no, it’s not worth it to add this one extra option that just you are going to use, because it will take 20 hours to build, and then I’m going to have to test it, and then I’m going to have to support it for the next five or six years.

Feedback’s super important, but even more important than receiving feedback is knowing the feedback that you can safely ignore.

Have A Thick Skin

We’ve ignored our 70 percent of feedback. What do do with the other 30 percent? Well it’s important to have a really thick skin, because people can get heated on the Internet, to put it lightly. So, when you receive feedback, remember that most people don’t understand how much time you’ve sunk into building this thing. They may not even realize how helpful it is to them. Whenever I hear someone complaining and filing an issue and getting upset, I like to remind myself, “Okay, this means that this is something, I’ve built something important enough that they’re willing to complain about it and try and make it better instead of just not using it.”

Keep On Improving

Finally, we’re going to keep on improving. There’s a reason we have version numbers. We don’t stop, we don’t release something, say, “This is version one,” and then never go back and improve on it. We have version .001, we have version .1, we have version 1, we have version 2. We fix bugs, we add features, we listen to feedback. We sometimes go against that feedback and strip away things that we know are getting in the way of improving.

Is This Something I Want To Do? (9:39)

That’s a lot of stuff, so is this something I, or in your case, you want to do? Maybe. Building developer tools is not something you want to rush into. There are a lot of really complex things in this space that you might even enjoy working on. But it’s a lot of work. Here at Realm, we essentially build a developer tool, Realm. And we work on it, collectively, hundreds of hours a week. And part of the reason, at least I think, that we can be good at it is that we enjoy working on it. It’s something where we have a passion for building it. And this is true of all of the projects I work on.

I work on them because that’s what I want to do when I get home from work, or that’s what I want to do when I wake up in the morning, or that’s the thing that’s keeping me up at night, thinking about, “How can I solve this problem that I keep on butting my head against?” We also want to think about:

• Is there a real problem to be solved here?
• Do you actually need to build a tool, or can you hack together a three-line shell script that’ll do what you need?
• Do you need to build a tool, or is it okay to just manually do these five steps once every other month?
• Do you need to build a tool, or can you let someone else do it?

Because even if you recognize that there’s a problem somewhere, even if you recognize that it’s a problem you have and you want to see a solution to, and you’re passionate about, think: is it really a problem that you can solve? Do you have the time to solve it? Do you have the relevant expertise? Do you know enough people who will be willing to try it out, even when it’s buggy and in its first alpha? You’re going to want to think about what are you going to get out of building this project versus how much you’re going to risk by putting into it.

You’re going to want to think about “Do I have access to all of the relevant tools needed to build what I’m building?” So if I’m building a tool for, let’s say Swift, which we like building tools for here. Oftentimes, the answer for us to that is no. Apple’s the only one in the position to build this tool properly.

And finally, think about time. It takes a lot of time to build software. It takes a lot of time to build software well. It takes a lot of time to support software, and developers like using other developers’ time. Then I think this is kind of the most important question, which is, “Does my experience butting my head up against this problem leave me ready to solve it?” Which we can break down into:

• Do I have a problem that is general?
• Does it affect a bunch of people, not just me, not just the people in my office?
• Is it a complex problem?
• Is it a problem that really requires a bunch of in-depth knowledge, that requires some sort of domain expertise?
• Is it a problem that’s kind of hard to work around?

If so, great. You found something that you’re going to want to build, and you’re going to have fun building. And when you’re done with it, the developer community is going to have fun using it.

So go and build it. Thank you.