Tell me about yourself and how you got into development.
My father was a teacher in the New York City public school system in the 80s, when they had a pretty ahead-of-its-time computer literacy program. He’d teach kids LOGO and BASIC, and he’d always be bringing home computers to fool around with. The first one was a Commodore PET, when I was probably four years old. It had a green-screen and a tape-based storage system – I mean cassette tapes, not backup tape drives – and would take forever to load anything, but when he showed me how he could make it play Tic Tac Toe, I was pretty sure he was a magician. Over the years he brought home all sorts of machines – a Commodore Vic 20, a Commodore 64 (that one’s still in his basement), all kinds of Apple desktops, and after mastering BASIC I got into C programming on our first IBM PC clone, making little video games. I started doing some web development in college when I was the online editor for the campus newspaper, and I’ve pretty much been doing web and mobile development ever since.
Tell me about Sails.js. Where did the idea come from? Why did you guys create it?
Mike McNeil created the first version of Sails in 2012. He was convinced that Node.js was a huge technology that would open up development to a much wider audience. All that was lacking was a robust framework to make building web applications in Node easy, the way Rails had done for Ruby. I started working with him about a year later at Balderdash, the Sails.js development shop he’d started in Austin. After working on a bunch of client projects, we began to see a lot of patterns – especially in our back-end development – that could be automated. So we started building a tool to do that, and we ended up spinning that project (called Treeline) into a separate company that we took through Y-Combinator. Since then we’ve evolved into The Sails Company, which is involved in lots of different aspects of the project like maintaining the open-source framework, creating new tools, building apps for customers and providing enterprise support for companies using Sails in production.
Do you have an opinion on, or favorite, when it comes to things like bower, browserfy, web pack, etc.
Hmm…a good compiler? This is coming, I’m sure, but it’s not quite here yet. Which means that it’s still non-trivial secure the source code for something like an Electron app.
Tell me a little more about treeline.io and your experience creating it
Treeline.io is a tool that allows you to design application back-ends by connecting pieces (called “machines”) together in an online, drag-and-drop interface. The tool then compiles your designs into a fully-working Sails.js app that you can deploy anywhere – it writes the code for you. It includes a library of basic machines, and you can create new ones right in Treeline with a built in code editor or, even better, by combining existing machines in new ways. But the real beauty of it is that the worldwide Node.js community can contribute their own machines and make them available for others to use, so that eventually the ecosystem could grow to the point that you rarely have to actually write any code at all. Very soon after our initial launch, folks had already made dozens of “machinepacks” for services like Twitter, Mailgun and Twilio, as well as utilities for working with things like passwords. Our goal in building Treeline was to open up back-end development to a whole new set of people, starting with front-end developers who up to this point were reliant on others to build that part of the app.
The experience of taking Treeline though the Y-Combinator program was pretty special, and by far the best part was that it gave us the opportunity to sequester ourselves away from the world, put our heads down and do nothing but work on our pet project for three months straight. Besides the fact that you can make an amazing amount of progress in that environment, living together for that time really brought us closer as a team. I’d recommend it to anyone. Three months is obviously a long time and requires either funding or a nice nest egg, but even going somewhere for a few days or a week can have a pretty profound effect on both your product and your morale.
In the last year or so we’ve taken a step back from Treeline in order to focus more on building the next iteration of the Sails.js framework (and, to be candid, to generate some revenue), but we still very much believe that this is what the future of development will look like.
Anything fun or exciting that you’re working on?
I’m building a six-foot metal dinosaur for my front lawn… or did you mean development-wise? ;)
What do you like most/least about development?
A lot of people mistakenly think of software development as something primarily scientific or mathematical, but when you’ve been doing it long enough you recognize how much art there is to it. Crafting the pieces of a program and fitting them together is like designing and building a complex physical machine – like an engine – and when it all coalesces after a lot of hard work and struggle, I’ll often throw my arms in the air and shout, “it works!” (both my wife and my coworkers can attest to this). My favorite part of development is building tools to help other people get to those moments faster.
The worst part of development for me, in the technical sense, is the frustration that comes from often having to deal with a complex and ever-shifting sea of technologies – browser compatibility issues, library updates that break your code, new phones that no longer support that amazing mullet app you built for the original iPhone. That’s what makes something like Docker so exciting for me. In a more general sense, the hardest thing for me about development as a career is that it can be somewhat isolating, especially if (like me) most of your work is not consumer facing. It’s not the easiest thing to talk about at parties. But it helps to live in a town like Austin where there’s a really great tech scene, with lots of meetups (like the Node.js meetup that my company hosts) and events like Austin Startup Week.
What technology do you currently find exciting?
I’d say that most of my experimenting with new stuff is on the front-end – there’s always interesting new frameworks and concepts to try, even if some of them flame out pretty quick. We’ve been using Vue a lot at work, and I’ve gotten into React/Redux lately, which is really interesting especially when you combine it with Electron to make native apps! But my biggest nerd-crush is on Docker. I presented a native, one-click install version of a desktop app at DockerCon 2017 that eliminated the need to use the command line to set up and run Treeline apps, and it really whet my appetite for what the technology is capable of.
What are you really looking forward to in the future?
A couple of years ago I gave a talk at NYC Camp, at the UN, titled “Welcome to the Machines” in which I preached my devotion to the idea of the Big Red Button – the thing you press that just does it all for you. We are on an unswerving path towards more automation, and it can be a bit scary at times, but I believe that in the case of software development it means removing more and more barriers to entry. I mentioned earlier that I believe programming is an art. At its best, automation allows us to focus on just the art, and leave the more mundane parts (and programming has a lot of mundanity) to computers. Personally, I like writing code, because it’s what I’m used to, but mark my words – the days of writing code as we know it are numbered!
What advice would give to other developers, or general wisdom you would impart to anyone?
That being said, this is a great time to be a developer, with more ways than ever to get started and a huge demand for talent. So to anyone who’s interested, I would say don’t be intimidated – start with the goal of learning to build something small, fun and useful to yourself, get involved in some online (or better yet, offline) communities, and before you know it you’ll be up all night making cool stuff.