This is the latest in our weekly series Seven Questions for Developers on App.net, where we ask a different developer the same set of questions to learn a bit more about the people behind the apps. If you’d like to participate, contact @ben.
Our next developer is @billkunz, an indie iOS and Mac developer, based in Mountain View, California, who makes Felix. “Most of my work has been for clients, like [REDACTED] and [REDACTED],” he wrote, “But I like to make software on my own when I’m not consulting.” @billkunz started writing software for iOS in 2008. Before striking it out on his own in 2006, he was a senior front-end engineer at Netflix for about nine years. All told, @billkunz has been writing software professionally for about sixteen years, with some dabbling before that. His company’s web site is http://tigerbears.com.
I make Felix, an iPhone client for App.net. I’ve worked on social networking software before, but never a Twitter client. When I saw @dalton‘s first posts about ADN, the ideals behind it struck a chord in me and I signed up immediately. After taking a look at the actual API and seeing the philosophies behind it, it was clear ADN is intended and poised to be something very special. I started work on Felix a day or so after my account was activated in August. (It’s not named after either of my cats.)
Generally speaking, my goal is to create an app that highlights and enables the connections people have with each other. Right now, that’s usually expressed by the conversations we have, but over time it’s not limited to that. It’s also important to me to have the app evolve along with ADN. How people interact with each other here is a bit different than on other networks, and as this culture changes and grows, Felix will do the same.
Both ADN and Felix started off behaving and feeling somewhat Twittery in terms of visible feature sets, despite having more complex underpinnings. (It’s often most efficient to start with a known target, and a few months is actually a blink of an eye despite the “instant killer software” Valley creation myths.) However, both are shedding that early scaffolding quickly. You can see some hints at the shape of things to come in ADN’s sweet new messaging API and Felix 1.3, respectively, for example.
Where that ends up is anyone’s guess. I have a general roadmap for where I want to take it, which is pretty different from how it works today, and I lay out more foundations for that with each release. In practice, though, it’s shaped heavily by our community’s shared culture.
What qualities make a great app?
Great software gets out of people’s way while enabling them to do what they want. Most people don’t use an app to, well, use an app. They’re trying to achieve a goal or have some purpose served. Good apps find that primary purpose, serving it well and with focus.
They eliminate cruft and distractions when possible, but include enough little flourishes to bring a smile. The phrase “childlike delight” is both a cliché and an overstatement, but good software is designed for at least some level of enjoyment because it connects people with what they want.
Getting to that point can take years of iteration, polish, research and insight. Creating something that feels simple and also powerful is actually a remarkably difficult task. It’s a process, and one would be hard-pressed to find an example of it ever being truly “completed.” Recognizing that (even taking advantage of it) is key.
What tools are important to you as a developer?
In terms of software, I live in Xcode, Instruments, Photoshop, Sketch, Opacity, Tower, Rested and Things. xScope from Iconfactory is immensely useful as well. Billings when I’m on a gig. Coda 2 and Core Data Editor for other stuff. Kaleidoscope. Shameless plug: I wrote and used Objectify, a Mac app that generates Objective-C code to model the data in a chunk of JSON. I shaved off a bunch of early development time for Felix using it, which was a nice change of pace from being its developer.
Hardware-wise, I love my Retina MacBook Pro. I can’t imagine going back to another display, especially for this kind of work. My Cinema Display’s idle. I have a large suite of iOS test devices that have been key tools over the years; I lost count after a dozen. I keep a decent 10x loupe handy as well.
I’m fortunate to have an awesome team of beta testers (¡hola, amigos!) that keep me sane and in check, all while catching a bunch of my mistakes, bad assumptions and oversights. Plus, they’re all cool and smart people, so it’s fun. (Sorry, I can’t add any more people right now.)
Solo software development is a true emotional roller coaster, so I couldn’t do this without the love and support of my wife (and our cats!) who helps me celebrate the highs and temper the lows.
“Because it was there.” The App.net ethos is extremely appealing to me, and I wanted to participate and make a contribution. I had a sense of where it could go and believed the team would expand the platform rapidly, which was exciting. Fortunately, that belief was well-placed, as the API and infrastructure have evolved remarkably quickly in a very cool direction.
My style of development (when working solo, that is) is heavy on iteration and evolution with a fairly fluid roadmap. I guess it comes from all that time working with aggressive schedules in the web world, for better or for worse. Working with a rapidly-changing API felt like a perfect fit and, well, it just sounded like fun and a great challenge.
What got you started writing code?
LOGO on a PET, BASIC on an Apple II and fiddling around on an original IBM PC. I tried learning Pascal and C around 1990, but it didn’t stick despite my love of math and logic puzzles. (Maybe I shouldn’t have kept getting myself “grounded” from the family computer in high school, but it worked out.) My grandfather used to say there have been builders in my family for 800 years (he was a farmer and mechanical engineer, and my father’s an OG hardware / EE guy, still in the business) so the die was pretty much already cast.
I just like making stuff people enjoy.
Any advice for aspiring developers (all the young coders out there)?
Time spent on language and style holy wars is better spent on honing your craft. Change what you work on from time to time. Sweat the details. Learn how and when to say no. Premature optimization is the devil. Beware of habits you build up when interacting with your app – we train ourselves quickly, and that hides bugs. Experiment. Welcome constructive criticism but don’t sweat the critics too much – there’s a difference. That ultra-clever bit of code you just wrote will be a lot harder to debug in six months at 3am.
Ask questions, but after listening and doing some research. Learn when to take a break and let your subconscious take a crack at a problem. Don’t blink. Find opportunities to experience the long-term software development life cycle – there are powerful lessons and instincts to develop in the maintenance, obsolescence and replacement phases that are missed by just hopping from one new thing to another.
Watch your posture and maintain a work-life balance. #doasisaynotasido
When you’re not coding you’re…
Chilling out with my wife, playing fetch with one cat and playing “bird” with the other. Going to A’s games with friends and watching the Raiders do, well, not much this year. Avoiding any mention of said Raiders games around my Broncos-loving wife. I’m looking forward to some injuries healing up so I can get back to the track with my motorcycles. Occasional trips to the range to rain hellish vengeance on my mortal enemy: sheets of paper.
I want to try this “sleep” thing people keep talking about, but heard it’s overrated. And probably monetized by Facebook.