Steven Frank Co-Founder of Panic
Who are you and what do you do?
I'm the other founder of Panic, Inc., an independent Mac and iOS software development team.
We make a variety of apps. Transmit; an FTP client, Coda; a web development environment, Unison; a Usenet browser, Prompt; an iOS SSH client, and more. You can read all about them at http://panic.com/.
On Twitter, I'm @stevenf!
How did you get started in developing for Apple devices?
When PCs and Macs started to become a thing, I desperately wanted a Mac. They were very expensive. My parents couldn't afford one and I was too young to work. Some PC compatibles came through the house and I tinkered with them enough to learn a bit, but they weren't very exciting.Later, I discovered the Amiga and became totally obsessed with its unrivaled (at the time) graphics and sound capabilities. Being significantly cheaper than a Mac, I eventually got an Amiga 500. I dove into learning the C language and some 68000 assembly language in the hopes of producing something as cool as what was coming out of the European demo scene
By this time I had enough programming experience under my belt to write a prototype of what would effectively be my first real honest-to-goodness shipping app: a terminal emulator, for calling dial-up bulletin board systems (BBSes) on an Amiga. There was a tiny Amiga developer shop in town, and I applied for a job with my prototype term program. I got hired and, among other things, was allowed to develop the program into a full-featured shrink-wrapped piece of software, which came to be called "Termite".
Through local BBSes, I met a Swedish exchange student living nearby who, it turned out, had a stack of disks with Amiga demos, and other utility software including Soundtracker, which was the program used almost universally to write music for Amiga demos.
Later, through another BBS, I met another local Amiga user about my age who was musically gifted, and happened to be looking for Soundtracker. His name was Cabel Sasser. We arranged to meet at a local Amiga user group meeting (SO EMBARRASSING) and swap disks.
We ended up getting along really well and became great friends. Fast forward a few years -- there's a little bit of college in there, Cabel moved to LA for a while and began using Macs instead of Amigas, some other distractions -- and then, I don't remember how it started exactly, but we began kicking around the idea of going into business as Mac developers. Which sounded fun to me, except I still didn't own a Mac.
Fast forward again to early 1996. I ended up buying Cabel's PowerMac 7500 after he upgraded to a newer model, and we both moved into a loft in southeast Portland. I started teaching myself Mac development from books. Cabel designed and I wrote a couple little apps but nothing really went anywhere until he suggested writing an FTP client. His day job was web work and he was somewhat unsatisfied with Fetch, which was basically the only option for FTP at the time. I'd like to say we did a lot of market research and business analysis and were super-smart, but, no, we pretty much just impulsively decided that's what we were going to do and I started writing code. Transmit 1.0 (originally "Transit", until we received a dispute over the name) took me about 18 months to write based on Cabel's design, and shipped in September 1998. And things just kind of snowballed from there.
What does your computer and workspace setup look like while developing?
Pretty minimal. I don't like having a lot of stuff on my desk, so it's pretty much just my monitor, keyboard, mouse, and a few other essentials.
Same with the virtual workspace. A long time ago, I used to spend hours tweaking every little aspect of my desktop, and it just became a burden trying to maintain this very particular setup on every computer I touched. So I threw that out, and now I run as little software as I can possibly get away with and my life is generally easier. I try to keep my actual data in open formats, and on a local file server. I can bring a reformatted Mac up to a pretty productive-for-me state in probably less than an hour, which I guess is kind of a bizarre thing to be proud of.
When I'm actually working on something, I usually have my IDE (which might be either Xcode or Coda, depending) covering about 2/3rds of the screen, and then I devote a little corner for IM, Twitter, and a Terminal window. I've never been able to get used to Spaces, LaunchBar, or Mission Control, so I just switch apps with the Dock or command-tab. I use Spotlight as an app launcher.
I used to try to avoid using 3rd-party software when good-enough equivalent apps were provided with the OS, to further pare things down. But lately I've been experiencing a lot of instability with Apple's first-party software. I've stopped using, for example, Safari, preferring Chrome. Messages has been so unreliable that I've switched to Adium, at least for now. I do still use Mail, iCal, and Contacts, but I've abandoned iCloud syncing in favor of Google's equivalent services, because iCloud has been rather problematic for me.
There aren't very many third-party apps (other than our own) I would say I couldn't live without, but Dropbox is one of them. I also use LaunchBar, but primarily for its clipboard history feature (seriously, try it -- I have it bound to Cmd-Opt-V).
I'm perpetually on a mission to find a "perfect" notes app (just ask my Twitter readers) which I don't think actually exists. I am really big on keeping notes because I hate having to re-find any information that I've already spent time finding. I'm also kind of scatterbrained at times, and the notes help me a lot. Right now I'm using Evernote which has pretty nice syncing and multi-platform support, but does some weird things to your formatting and (still) doesn't know how to export plain text, so I wouldn't say I'm delighted with it. I don't think there will ever be a note app that I don't end up nit-picking in some way.
Running a well-known software business like Panic must pull your time in many directions. How do you deal with distractions when trying to do any actual software development and programming?
Well, I'm very fortunate to have Cabel around to wrangle most of the business stuff. And we now have an excellent support team that can stay focused on helping customers without having to bottleneck through the two of us.
My actual job right now is all over the place. I still write code, but less often than I used to. I do all kinds of other things like writing help files and documentation, helping Cabel maintain our web site and other servers, dealing with the occasional escalated support or billing issue, and work internal tools like our sales database and billing tools. I kind of pick up assorted loose ends.
Oddly, most of the code I end up writing these days is on the back end. Like right now I'm working on a server component for a possible project we're experimenting with. So that's a lot of PHP, MySQL, and so on.
But I do still get to occasionally sling some Objective-C. For example, I did a large part of the work adding the MySQL component into Coda 2.
But yeah, there are plenty of distractions, and I'm sorry to say I don't have any great secret methodology for dealing with them. Sometimes I have to leave myself a note of what I was doing when I get interrupted. Or I'll leave a window open with a particular piece of text highlighted, and that'll be enough to trigger my memory. When unexpected thoughts or other tasks come up, I try to leave a trail of some sort. What's fun is when one interruption gets interrupted by another interruption and so on, and you end up with this sort of "stack" you need to unwind. Trying to fit that in my brain usually ends in tragedy and broken promises so, yeah, a blank text file, or an Evernote, or a piece of paper -- just not in my brain.
Coda 2 has been out for a little while now and has been received very well. How do you and your team handle all of the feedback and feature requests that you receive while planning out a programs next steps and releases?
We got an absolute tidal wave of Coda 2 feedback. Which was great! But it completely buried us for a while, which was not so great.
We have an issue tracker called Hive (which runs on Redmine
After a few weeks, we usually start to notice trends in what bugs are getting hit the most, what the top requests are, and we produce a short list of those that's a subset of the hundreds of issues in Hive, and that becomes our checklist for the next release. You reach a point when your user base reaches a certain size where you just can't keep up with everything coming in, and you have to start prioritizing based on the relative impact of the issues being reported. It never feels good to let a known issue slide, even temporarily, but there are simply not enough hours in a day. There has to be a cut-off for the next version or you'll go insane and never ship.
If you had two minutes to share your favorite debugging tip with a fellow developer, what would it be?
Well, the best bug is the one you never wrote. Recently, I've become big fan of automated unit testing and continuous integration. I think some developers shy away from it, because it seems like "extra work" you have to do on top of writing your actual program. But that's myopic because it doesn't consider the time saved in the long run by being able to make broad, foundation-level improvements to your code without having a doubt in your mind that it still works the way it's supposed to.
And it's not just the "testing" aspect that's great. Writing tests also makes you a client of your own code, which is not a perspective programmers of desktop software traditionally have had. Your app internals start to look to you like a set of mini-APIs, and as such you hold them to a different standard. Suddenly it's like this great spotlight shines on any part of your code that's even a little awkward. Certain things stand out like sore thumbs in a way they didn't before. You start asking a lot of: Why is this method in this class? Should this be two different methods? Is anything even calling this function? And so on. You see design problems much earlier. I find it a wonderfully proactive way to stop bugs before they start.
That said, we have a ways to go before our apps have as much test coverage as I'd like them to. It definitely takes time to add tests throughout a large, existing codebase. Also, testing view classes and asynchronous network code can be extremely difficult. That's OK, though. Just start to add tests where you can, in your models and controllers, and use a system like Jenkins to do building and testing for you. Think about where the most critical parts of your logic are and start adding a few tests here and there. The first time your build server emails you about a bug you had no idea existed, you'll be hooked.