Chapter 27. The Foamy Rules for Rabid Tools
The brother-in-law lives in the ‘burbs and needed five trees removed. Not big trees—10 to 15 feet tall, six-inch trunks. Not a problem.
I live on the edge of a redwood forest in Northern California. There are sturdy oaks, playful maples, lovely madrones, weed-like bay laurels, and of course, giant redwoods. But the pleasure of living in a forest has a tax. Trees fall and trees die, and in a forest of any significant size, this is always happening.
You need a chainsaw. In my case, I need three. There’s Junior, who is great at handling the small jobs. He’s light and ladder friendly.
Then there’s Marty. He’s the everyday mid-sized saw that is enough to handle almost any job. Marty would be perfect for a job in the ‘burbs.
Last, there’s the Rocket. Any tree is the Rocket’s nemesis.
Even if you’ve never handled a chainsaw, you’ve probably used a handsaw. It’s a physical, grinding affair. It’s fun for about three minutes, and then you start wondering...am I making progress? The brother-in-law had taken it on himself to use a handsaw on one of the trees. In his three minutes he’d sawed off...a branch.
When Marty and I showed up, we dropped all five trees, cut up the trunks and branches, and stacked them into disposable piles in an hour.
The lesson: the correct tool is exponentially more productive.
That’s a long introduction to say an obvious thing, but I’m going to make it even longer. Take a moment and step inside the mind of the brother-in-law. I’ve got several trees I want to get rid of...and what do I have in the garage? Two hammers, a paint can full of nails, some leftover wood and...a saw. Perfect. A saw.
Context shapes perspective, so thanks to the contents of his garage, he knows of no universe where there are chainsaws. He’s heard of them and suspects they’re much faster than the laborious, sweaty grind of this sawing, but there’s no chainsaw here, so he’s semi-happily hacking away. To me, standing there with my arsenal of chainsaws, it’s absurd. It’s a criminal waste of his time.
The lesson again: the correct tool is going to make you exponentially more productive.
The Foamy Rules
As an engineer, there is a short list of tools that you must be rabid about. Rabid. Foaming at the mouth crazy.
This is an obvious list of tools, and there’s nothing here that you haven’t heard before. The news is that you need to care. You need to be able to explain in great detail why using green-colored text on a black background is THE ONLY WAY TO CODE. You need to be a zealot about your tools, and zealotry starts with fit.
I was a database guy, then I was a shrink-wrap guy, and then I became a web applications guy. Each of those professions came with their own set of bright and shiny tools, but the tools were not important. Even a specific feature inside of that tool is not that interesting. I believe you can be just as productive sitting inside of a rich development environment such as Xcode as you can inside of TextMate and a slew of terminal windows. The point is not which tool; the point is that the way that tool—your tool—looks, feels, and functions fits how you see, move, and work.
These are my foamy rules, and they may differ wildly from your list. That’s cool. My development experience is different than yours. I started working with computers before the mouse, which means I trust my keyboard more. Integrated debuggers had just landed when I began developing, which means, yeah, I like debugging at the command line. Again, the point is to get foamy, because what makes you foamy makes you your best.
My foamy rules:
My Tools Appear Deceptively Simple
TextMate. Terminal. Transmit, LaunchBar, DropBox. The mean time to get one of those tools set up is just a few minutes. I can build out my development environment on a new machine in a half hour. This has a couple of handy implications. My tools are readily available and lightweight. I can download and install everything except for an operating system in a short amount of time. Similarly, setup and configuration of these tools is close to zero.
You might think this setup means I’m expecting my computer to randomly explode. No. These tools are not simple; they are well-tuned. A TextMate user knows it’s an onion application. You can keep pulling back the layers and finding new functionality, which is going to make your development experience faster. The same goes for Terminal and LaunchBar. The base functionality just works, and if you have a particular development itch you want to scratch, the tool can scratch it.
My Tools Do Not Care Where My Work Is
How many times have you experienced this? You write a quick script on your local machine to do something clever. You fine tune it and then plop it on your server and rediscover the rule—there’s nothing quite like production.
Any tool that does not allow me to develop live in production is slowing me down. When someone showed me how to set up Transmit to do editing on remote files, I saw hours of heretofore unknown production debugging issues vanish.
Yes, editing locally is fast, especially when you live on the edge of a redwood forest where DSL latency blows, but a tool that doesn’t allow me to develop over the wire isn’t a tool; it’s a debilitating hindrance.
Rands, edit? In production? Are you insane?
No. The tangential background rule is: “If you don’t know what you’re doing in production, you don’t belong there.”
There’s a corollary, which is: “I don’t care where my work is.” This is recent foaminess brought on by Dropbox. For nonproduction work like, say, writing a book, I don’t want to think about where the most recent version of the work is sitting. Yes, I’m talking about version control. But shh, don’t call it version control—just call it Dropbox. Provided I have a network connection, this tool magically refreshes a shared directory sitting on each of my machines. I can’t think of the last time I worried about which version of a document I was on, and that means I’m spending more time working than worrying.
My Tools Are Designed to Remove Repetitive Motion
One of my first algorithmic holy shits was during my second computer science class as we were learning sorting algorithms. The professor elegantly walked us through the construction of different algorithms, explaining the pros and the cons, and then he landed Quicksort. Holy shit.
It wasn’t just the elegance. It wasn’t the recursive simplicity; it was the discovery that with imagination there were approaches that were wildly more efficient—and simpler. Whether you’re formally trained as a computer science nerd or not, you’ve learned the value of efficiency—to make each action that you take mean something. You know that when you’re efficient, you have more time to do what you love.
This is why I have a simple requirement that any tool I rely on has complete keyboard support. I will fall back on using the mouse for one-off activities, but for any action I take that I know I’m going to do again, my question is, “How do I make this action cost less?”
Think of it like this. What if I told you that each time you wanted to save a file, you had to stand up, climb up on your chair, and jump up and down, yelling, “I would like to save my stuff now!” The first time you had to do it, it’d be kinda fun, but after that it’d drive you batshit crazy. It’s a similar feeling each time I reach for my mouse. I feel I’m engaging in an unnecessary task, which is always going to waste my time because with a mouse sometimes you miss, and missing is a tremendous waste of time.
Finding any file or application is, ideally, four keystrokes. Cmd-Space (LaunchBar), Letter #1, Letter #2, Return. Sometimes I get lucky; sometimes it’s three, and you know that puts a smile on my face every single time it happens.
My Tools Do Only What I’ve Told Them to Do
Back when Dreamweaver first landed, I wanted to love it. I was so tired of the repetitive motion of developing HTML pages, and the idea of a tool that was going to visually handle that laborious process was appealing. Problem was, Dreamweaver changed my code...without asking.
It what?
Dreamweaver was attempting to be helpful, but the moment it reformatted my code, I threw a fit. YOU TOUCHED MY CODE. Dreamweaver never recovered from that horrendous first impression.
My impression and my opinion of robust integrated development environments is that they can do a lot of good in terms of helping you visualize what the hell is going on. Borland developed some of the best environments for building code back in the day, but I still find myself with extremely primitive development environments where I’m tweaking code in TextMate and debugging inside of a couple of Terminal windows.
Yeah, I know all about the glory of integrated debugging, and I see all you Eclipse guys having a ball, but what I found in many years of development is that embracing the fancy tools means spending time tinkering with your tools to get them to behave how you want.
The corollary to this rule is: “My tools don’t have a lot of moving parts.” Dreamweaver-grade code offenses are few and far between with solid development tools, but the fancy still comes with a cost. You may be fully willing and foamy to embrace that cost, but I’m not.
Am I more efficient than you? Maybe. Do I know where I stand relative to my tools? Yes. Do I have to relearn my development process when the people behind an elegant tool shoot for more elegance? Nope.
My Tools Are My Tools
Choosing a thing makes it yours. The choice is the result of that unique mix of logic, superstition, stubbornness, and experience that fits you.
You read that right. Green text. Black background. I’ll tell you why right now. I’m an old-school DOS guy. My first word processor was Wordstar, and that’s the word processing program I came to associate with the fugue-like state of maximum productivity: the Zone. This is why I continue to favor colored text on a black background in my current favorite editor, Textmate. The coloring reminds me of a primal, safe place where the tool is serving its purpose—to get the hell out of the way so I can go be exponentially more productive.
This is why, as engineers, we stick with something that works for us. This is why the ancient likes of vi and Emacs continue to flourish. Once we find a tool that works for us, once we’ve chosen that tool, it becomes ours and remains ours. It allows us to get foamy.
An Evolving Foaminess
My brother-in-law doesn’t need a chainsaw. When I took out his five trees, I eliminated half of the population of trees on his property. While a chainsaw is a delicious combination of sound, power, and sawdust, my brother-in-law didn’t choose a home where the trees are on the offensive, so he doesn’t need defensive weaponry.
He does need to know about a universe where chainsaws exist because every moment of his time is valuable. What differentiates us from the monkeys is not our ability to pick the right tool for the right job, but to pick the best tool.
And you never stop looking. This is why the last foamy rule is the most important: my tools are always fighting for their lives.
My current tool set is influenced by all of my experience. Yeah, the elegant simplicity of vi is attractive to me—it reminds me of the uncomplicated early days of development—but vi can’t compete with the holy shit moment I experienced when I first ran into TextMate. This tool is always five steps ahead of me. I love that.
But TextMate, like all of my tools, must evolve.
Try this right now. Stand up and walk into the office of the best developer in the building. I promise two things: he will be happy to, at length, foamily show you his development setup, and you are guaranteed to learn at least one thing about moving faster. Perhaps it’s a tool you’ve never heard of, or maybe it’s the way he deftly manages a tool you’ve taken for granted.
I don’t know what you’re going to learn, but I do know you’ll see one thing that will instantly and obviously make your universe a smaller, more productive place.