Can you introduce yourself?
I'm Nick Paulson, I work on CloudApp, I'm 17 and from upstate New York.
How did you get into Mac Development?
I started two or three years ago and I was working mainly with AppleScript just to see what I could do and eventually got into things were I was writing probably 500 lines of Apple scripts to work with IRC. I used Xchat back then. I did all this stuff and then it eventually got to a point where I was getting sick of running shell scripts from AppleScript so I started learning Objective-C and it kind of was born from there.
How did you learn Objective-C?
I learned mainly from Aaron Hillegass book and it's Cocoa Programming for Mac OS X (3rd Edition). That book is kind of the de facto book for Cocoa Programming and it was really nice because they taught the concepts like back then I didn't know the difference between classes and objects. It didn't assume any kind of knowledge of C, which I didn't really have. It was really good for getting started.
So what are the differences between a class and an object?
If you don't have any knowledge of any programming, it probably won't make any sense but classes are kind of the instructions for what a program should do. Objects are kind of instances of classes, a class is like information about a certain thing, and an object is an instance of whatever that is. You can have a person class and that class describes the name, the height and stuff like that. The objects the actual specific person, so whether it be you or me it has specific properties and you set those based on that.
So class is like a blueprint framework almost.
And then the objects are the details within that.
Yeah, it's like the classes are the blueprint and then the objects is like a house. It's like the specific thing so that's kind of the in general terms but ...
How was it learning those terms?
It was hard to totally understand it. I went from that book and the first part didn't start to make sense but the great thing about it is that it has really good examples and I personally learn by examples. Being able to actually create something and learn how to take keyboard input or how to turn a string backwards and stuff like that.
When did you feel sufficient to be able to build something?
Honestly, it's hard to answer that question because learning to program is kind of a never-ending thing. I could pick up a book now and learn way, way more than I already know. For CloudApp, it took probably a year before I started developing the very first versions, but that kind of evolved from another app. The first version of CloudApp was really a learning experience and that's why we've thrown out all of CloudApp code twice.
What do you recommend to those that want to follow your footpath?
First I would definitely take a look at Aaron's book because it's really good and then once you get a handle on everything in there, I would read called Cocoa Design Patterns. It's a really good book on what problems developers for Mac and iPhone have had and how they're commonly fixed. It's a really good book so you get more advanced.
What are the things that people need to be aware of when they are building apps?
The two main things that we have issues with, in general, is time estimates. It's really hard to give time estimates if you have not done something before because you really have no clue what it entails. It just takes a lot longer than you would expect, especially if you are going into something different, like if you want to animate something and you never used something like Core Animation before, it will take so much more time than you would expect, just because of the learning curve and trying to pick new things up. Time estimates have been really hard. We used to give ideas like, "Oh, we'll have that done next week." We try not to do that anymore because when you say next week, they expect next week. We try not to do time estimates anymore, so that was one thing that you have to cautious about.
So what do you say instead then?
It's something we're working on. Anytime we are saying, "We're working on something." We're working on it. It's just things take longer than people expect, especially people who don't do development. When they say, "Oh just throw this button in here and move that around and make that and resize this correctly and move this." It seems simple on paper but once you actually get into it, there's a lot more than you think it would be.
So with BaseApp, what was it like building on top of another platform?
37signals makes a web service, called Basecamp, which is a product management suite and it has time tracking and message boards. Tim Van Damme was one of our friends and he used it. I think he approached us with the idea of making a menu bar notifier for it. We worked together with Tim and created BaseApp.
What was it like building on top of another platform?
The thing with CloudApp is that we had total control over the web service. Anytime we need API updates or we wanted to add something to the API, it was something we could pretty easily do but 37signals API is really not made for a menu bar notifier. We had to work around that quite a bit, for example, we were using the RSS feeds from the Basecamp project for BaseApp. We had to work with that and be able to filter the right things, make sure all the projects were correct.
For those that want to improve their coding skills, what is the best way?
The biggest thing is to just keep making apps, even if they're tiny little apps, the more you experiment, the more you try, the better you will get.
What things have you learned from a marketing standpoint?
With CloudApp, we put out this teaser page saying, "This is the best new app for Mac. Sign up if you want it."
That's a broad statement.
Yeah, I know. We just kind of put it out there to see what people would say and you would sign up by following us or tweeting about it. We got like 800 followers in eight hours and people knew nothing about the app. Literally nothing.
Who tweeted it, first of all?
It was under the CloudApp account, you could tweet through the website. You just sign up by following us on Twitter. That's how we sent out our beta invites to redirect message them.
Is that the only marketing you guys have done?
So most of it just has been viral, word of mouth?
Yeah. But it's convenient that we have the CL that LY links. So when people click them, they will go, "Oh what's CloudApp?" And then check us out. That's really it, there hasn't been like any paid advertising that I know of.
Is that something you guys would consider?
Yeah, it's something that you got to think about. You've got to balance how much it's going to cost you versus what you are going to get out of it. Right now, we are still working on making the product really awesome. We want to get that done completely first before we go to crazy with marketing and lose time on doing that.
What do you think is an awesome product?
That's hard to define, because my awesome app is your awful app. It's really hard to say, it's just the thing that works the best for a problem that a user has. We kind of fixed the problem of getting files shared really quickly and easily. I always had the problem were I would take a screenshot and we used to use grabUp but that never worked. We thought, "Okay let's make something better." So we did. Hopefully it will become awesome.
How is it working with a team?
Yeah, I think I'm lucky to be working with people that are so reliable. If I'd say, "Hey Max, I need this done tomorrow." He has it for me and that's a really great thing. The hardest part about working on this team is the time zones because Max is either in Germany or Spain so he is six hours ahead. Larry, who is our web developer, is on my time zone so Max will go to bed around six or whenever he goes to bed and so we still have six more hours per se to work on things. The hardest part is working with different time zones.
You said you are really fortunate to be working with a reliable team, how did you get to be in that position?
Yeah, I met Max through a mutual friend and way back in the day, he designed a Twitter client that will never see the light of day. Then I met him and we became friends and we were talking about this app and we had this idea so we started working on it. From then we found Larry, who is our web developer. Jonathan was Max's friend and so we all kind of started working together and out came the product.
What have you learned?
I think the biggest thing is to work with the best people available. If you are going to work on a product, get the best team. I think that’s what helped us when were doing this, to get a really, really great team. Another thing is loving the product you're working on. I mean every single person working with us has been awesome and they absolutely love what they are doing and that really makes the product so much better when you believe in it what you are doing. As I mentioned before, in the previous 10 minutes, don't give deadlines because it's hard when you say, "Oh we'll have this done" but you never know what's going to happen. So it might not be done and that just poses a problem.
Just make good products. You see so many products out there that, I'm not going to name any names, that are just kind of one off apps. Will Shipley did an article on miners versus farmers on how miners are looking to make the quick buck. They are here to make a quick app or a quick Mac app that sells really quickly and then it's gone. I think that the biggest thing that I'd say is be a farmer where you nurture your product. You keep making sure it's working well and staying afloat and that it's doing well and you keep working on it and working on it. It takes time but in the end that's the thing that will pay off the most. I definitely think that farming versus mining metaphor is a really good advice, really good piece of advice to use. To make really good products even if they take long. There is always the opportunity to make the quick buck but you really got to look how a product is going to work in the long run.