Build your own dev tools. Now.
At the Chaos Collective, we build a lot of our own tools. And not just for fun. We’ve found that the little differences in how a tool works turn into big differences after using them for a while.
About two years ago we decided to build our own coding environment. Back then we were doing a lot of php, javascript, css, html, and managing a handful of binary assets (like images, fonts, and video). But the set of online code editors just didn’t cut it for us. We wanted to know where the bugs were, what was marked as “TODO” or “FIXME”, and what was most recently edited. So we created Magic Forest.
Magic Forest was our first major attempt at a fully online integrated development environment (IDE) with our mix of important features. Syntax highlighting, JSLint javascript error checking (back before that was super common), flagged keywords, and a most-recently-used flat file structure. We even added in some features to make it super fast and robust (like drag-from-desktop file uploads, GIT version control with auto saves, and OpenID integration).
Building our own development tools was hard work (and we definitely had our share of hard-to-find bugs), but the effect was much greater than just re-inventing the wheel. The tool changed both the way we worked and also what we created.
And in the spirit of bootstrapping (a la Doug Engelbart), we couldn’t resist using the editor itself to edit the editor. It was awesome - you could feel the acceleration; fixing a bug that made fixing the next bug that much easier and simpler.
Integrating with existing practices was also key. We were already leaving copious amounts of comments indicating what needed to be fixed and updated. By simply parsing the file for specific comment keywords, we were able to make micro-charts for each file showing the number of TODO and FIXME items per file. These became the goto items the morning after a late-night coding slog - It’s the little things that make all the difference.
In fact, the simple structure of having an always-up-to-date list of items to work on next meant there was never a moment of “what should we work on next?” And switching between all of the common files was lightning fast; the browser is quite accommodating when it comes to having multiple windows open, so showing multiple files (or even multiple views of the same file) was practically free without any extra development. This made developing sites like Boxes&Text incredibly fast to build (days, not months).
We’ve come a long way since Magic Forest, and we still stand by building our own tools. The subtle differences between de-facto toolsets (even the really really good ones) and tools with features you’ve consciously decided to include is fundamental to building awesome forward-thinking things.
Don’t wait. Yes, technology is going to keep changing on all of us, but only because the early adopters are using it to generate the next wave of even-better things. Get on board and blaze the trail with us.
