Last year, Gus Mueller of Flying Meat Software wrote a powerful blog entry describing the 1068 days that elapsed between his setting out to be a full-time indie software developer, and achieving that goal.

Paul Kafasis recently redirected my attention to that post, and commented that it would be interesting to hear more stories of the much-varied road to indie-dom. He has posted his (and the other two founders of Rogue Amoeba) very fun story: The Full-Time Gap.

I’m impressed and inspired to read any such stories, especially when they describe the troubles that successful entrepreneurs have struggled through. When we look at the examples of successful companies in any industry, it can be hard to imagine that they once floundered, made stupid decisions, had an ugly web site, couldn’t make any money, etc. There’s hope for us all!

At first I thought it inappropriate for me to participate in this conversation, because by my own standards I’m far from having reached any kind of ISV (independent software vendor) success. But then I consider the fact that I haven’t had a “real job” for four years, yet I have roughly the same amount of money in the bank and a new college degree under my belt. Not too shabby, after all. I hope my story will be inspirational in its own way, different from Gus or Paul, but another example of how “this can work.” I’ll adopt Gus’s and Paul’s habit of occasionally highlighting some salient (I hope!) point of wisdom. These lessons, collected from all such posts, may help you maintain optimism and courage when pursuing your own dream.

Sink, Swim, or Float

When discussing the indie dream much fuss is made about “making the leap.” This idiom can be applied to many risk-taking situations, but in this context it usually refers to that fateful day when an individual decides to stop receiving a steady paycheck, in favor of some pursuit which probably offers less certain financial rewards.

Your familiarity with the phrase is inextricably linked with another well-worn utterance: “don’t quit your day job.” This phrase probably started as a cautious piece of well-meaning advice, but has evolved into a nasty weapon, used by terminally unhappy people to assassinate the dreams of those who aspire to something different.

Lesson: Don’t let other people dictate your dreams!

On July 8, 2002, I announced to my colleagues that I would be “quitting my day job”:

Now, at most companies this move would have invited howls of “don’t quit your day job, sucker!” But remember, Apple Thinks Different. I cherish the replies I received over the next few days. All of them extremely positive and encouraging. No dream assassins! And it wasn’t even because they were happy to see me go. (I don’t think!) Some excerpts, edited for anonymity:

Lesson: Find encouragement early and hold on to it. Never stop repeating it to yourself. You are entitled to pursue this dream.

But before we fly away on a rainbow cloud of optimism, let’s put things into perspective. People say “don’t quit your day job” because honestly, most of us need a day job. Here we get to the “floating” alternative to sink or swim. I was leaving a well-paid job to go to school – a negative paying job. It would have been foolish for me to do this without money in the bank. Because of my frugal lifestyle (no Porsche!) and a belief in my company’s stock that was finally beginning to bear fruit, I was decked out in safety gear when I made the leap. I would not be making money, so I needed a life jacket. I needed to float.

My experience demonstrates the awe-inspiring power of fear. Even with enough money to comfortably survive a couple years back in school, and a buffer period for getting a job again afterwards, I was still scared out of my mind to leave the comfort and security of my career. I think it’s illustrative of a defect in thinking that keeps many of us from taking the risks we should. Instead of looking at the real risk, which was that I might use up all my savings and have to start saving from scratch, I let my mind enumerate all the possible risks. Nobody would hire somebody with a weird gap in their resume. I’d run out of money and have to move in with my parents. I’d never again have an opportunity like Apple. I’d be irrevocably labeled a failure at life.

Come on! Life’s unfair, but it’s not that unfair. Wherever you are right now, whatever your position of comfort and satisfaction, chances are excellent that you’ll be able to return to that position after failing to pursue your dream. And remember, that’s the worst case scenario.

Lesson: Take risks. Don’t take foolish risks. Easier said than done (or not done), but important.

Catching an Income

I spent my first year back in school slowly draining my savings. Don’t worry, when I say slowly I mean really slowly. I didn’t even try to live too cheaply, but I had kept some habits that made me a pretty slow consumer of funds. Eat burritos, watch broadcast TV, buy thrift-store clothes, etc. By not buying a Porsche, or any other expensive car, I had easily come to own my Ford Escort outright. No monthly payments. No debt. Cheap (for San Francisco) rent. This was doable! I haven’t added up the math carefully, but I think it’s reasonable to estimate that for the first year I used up maybe $15,000 in savings, and that includes my university costs. By not driving to work every day, my gas bill went to nil. I avoided the rich lunches out that accompanied work, and abandoned all of those gadget-buying habits that mainly serve to soothe the confusion that comes with having a lot of income and nothing to spend it on.

Lesson: Make your risk count. Don’t spend your savings at the same rate you spend your income. Adjust your lifestyle so that your savings far outweigh your costs.

I would be lying if I said I wasn’t afraid, even with the slow leak in my bank account. It never feels good to lose money. So I started to look out for a job. I thought for sure it would be something student-like, since I figured my schedule wouldn’t accommodate anything in the tech field. I went to the student employment office and tried to picture myself working in the library or as a departmental assistant. $9/hour was looking pretty good.

Then I noticed a craigslist ad for a company in search of Mac developer. It was the beginning of summer, so I could afford to work full-time for at least a few months. What do you know, this position was a short-term porting job from OS 9 to Carbon on OS X. The requirements sounded like they were lifted directly from my resume, so I contacted them and almost immediately got to work on my first contract.

Lesson: The adage about making your own luck is true. If you don’t keep your ears open for opportunity, you can’t blame anybody but yourself for your failures. Luck is lurking everywhere: in the obvious places and where you’d least expect it.

Over the summer I earned enough money to replace the lost funds from the past year, and go a long way towards subsidizing the year to come. I had been ostensibly running “Red Sweater Software” as a shareware company for a few years, but hadn’t really made enough income to justify a bank account. I asked the company to make the checks payable to the company name, and opened a new business account. This would be the first year that I could easily and honestly report significant income for my business. I bought a new G5 and deducted it from that year’s taxes.

It’s cheesy, but just having a bunch of cash in the bank under a business name made me suddenly feel like a business. It immediately broke down a mental block I had previously suffered, viewing businesses as something other people, brave people, took part in. The manager at Bank of America wished me good luck and handed me a company checkbook. I could be a business, after all!

Lesson: There’s nothing magical about businesses. They’re just people who choose to earn their money directly. If you can convince somebody to pay you, you can be a business, too.

Aim Higher

As I proceeded to spend another two years earning my degree in music, I just sort of picked up other contracts here and there. As it turns out, lots of companies are very flexible when it comes to hiring Mac programmers. After all, they don’t have a lot of talent to choose from. You’re coming in to their company to fill a gaping void. The fact that you’ll do it in your spare hours over the course of a couple months often doesn’t matter to them. Once I realized that it was OK for me to be a consultant and a student at the same time, I cautiously accepted new contracts. It was difficult at a few points to perform professionally in both work and school, but by declining several otherwise appealing contracts, I was able to keep the workload small enough that I could comfortably do both.

Lo and behold, I had quit my job to pursue one dream (education in music), and had inadvertently stumbled into satisfying a latent dream: owning my own business. Red Sweater Software was a profitable enterprise, even while in school! I joked with my friends at Apple that I was making only about half what I earned at Apple, but that I was working about a quarter of the hours. Not a bad tradeoff.

Lesson: Some dreams will be realized by accident or surprise.

After I graduated and received my degree in May of 2005, I realized I was at a crossroads. Just as younger students are suddenly faced with the question “what do I want to do with my life,” I had to decide where to focus my energies. I had enjoyed the single-mindedness of school. There was always something important to focus on. Nobody could call me a failure because I was working towards something. Now I had to decide whether success and happiness lie in going back to a full-time job, maintaining the new status quo (consulting), or in pursuing something completely different.

It so happens that around this time I moved from San Francisco to Boston. This pretty much wiped the option of going back to Apple off of my list. I could interview in Boston but I didn’t have a fiery desire to work anywhere but Apple. I decided that the status quo would suffice, especially since I had gained some long-term clients who were happy to retain my services even after I moved. Having this “portable job” proved very comforting in making the huge transition to a new city on the other side of the country.

In Boston, I discovered there is just as much demand for Mac consulting as in San Francisco. That is to say: not much. But if you keep your eyes peeled, you find it. And the lack of competition means that often you’ll be the first person to contact a prospective client. Make a good impression and odds are you’ve got another gig. So I have spent the past year or so continuing with consulting work and enjoying the relatively laid back lifestyle it affords. I sleep in. I start and stop the work clock at my own whim. I write great software for great companies.

Lesson: Consulting makes an excellent back-up plan. You’ve always got a job if you need it, and your destiny is very much in your own hands.

But I’ve got another dream. I want to be a great company. In May of this year I decided that my ambitions of selling software directly to customers were not being adequately served. They had been put indefinitely on the back burner in favor of serving more and more paying clients. But there’s no reason that Red Sweater Software can’t be one of the great companies that is served by my talent.

But in spite of the relatively small number of Mac gigs in the world, my schedule was full! I was already turning away work because I didn’t have the time. How was I going to make time for Red Sweater Software? The decision I had to make is especially difficult for anybody venturing “out on their own.” The survival instinct is so great that a paying job becomes very difficult to turn down. In order to make time for my dream, I had to trade in paying jobs for time that could be spent on developing, testing and marketing my own software.

Lesson: It costs money to start a business, including the money you could be getting paid elsewhere. Balance the pursuit of money with the pursuit of your dream. They’re related, but not the same.

FlexTime was the first product to come out of this risky (but not foolishly so!) plan. After months of work the product went on sale last month, for $18.95. In spite of being satisfying to me, and receiving the praise of some very respectable bloggers and users, FlexTime is so far a “failure.” Why? Because sales are in the low hundreds of dollars. Without further development, I cannot expect to recoup my investment, let alone expand the company. Fred Anderson or another financially savvy person would deem it a failure. But it’s my failure! Mine, mine, mine! It’s mine to tweak and enhance. Without the determination to at least fail, I’d never have a chance to succeed. And the stories of more successful companies like Flying Meat and Rogue Amoeba assure me that it’s OK to fail. As long as I learn from my failures.

Lesson: Don’t be afraid to fail! Failure is your only means of testing for fact. And without facts, you have nothing to base your business on.

See, I sort of anticipated from the beginning that FlexTime would not be a huge success. I mean, I really hoped I was wrong, and braced myself to be pleasantly surprised. But I was not alarmed to learn that millions of users would not be beating a path to organize the “linear, timed activities” of their lives.

But FlexTime was a success in a way that I very much intended. It’s a proof of concept. Not of technological functionality, but of ambitious determination. FlexTime is proof that I can embrace a software development strategy that starts with a product vision and ends in a sellable product. My previous products were not good proofs of this because they sort of evolved resistantly out of personal projects. They didn’t start out with customers in mind. Though I’ve done my best to retrofit them as customer-ready products, they were designed almost exclusively to meet my needs. It’s a coincidence that others find them suitable for theirs.

FlexTime was developed from day one with the customer’s interests in mind, and as a complete product that serves a specific purpose, I’m proud of the result. Now that I’ve proven the concept, my success is all but assured. The machinery is in place, now I just keep turning the crank until something irresistible comes out. Until you know your machinery works, it’s almost a waste of time to set your sights as high as a successful product. Get your first product out of the way as soon as possible, and learn from your mistakes.

Lesson: Pick a small project, design it from the ground-up with customers in mind, and work tirelessly to complete the vision. Then you’ll know your machinery works.

My first success might be a revision to FlexTime (or FastScripts, or Clarion), or it might be something completely new. It might take a year or it might take five years (please, no!), but let me repeat: my success is guaranteed. And yours is too, if you choose this dream and pursue it diligently.

Bring On the Stories

Have you taken the road less traveled? Halfway down it, or just thinking about setting out? Let’s hear your stories. Your successes and your failures. Because the failures are successes, too.

Thanks to Gus for starting this topic and to Paul for reviving it. I’m looking forward to reading more stories along these lines over the coming weeks.

Update: Stories I have noticed being written since this was posted, either inspired by or of a very similar style as Paul’s, Gus’s, and mine:

• Michael Dupuis – Advenio
• Geoff Schmit – Sugar Maple Software

I’m registered for C4, Jon Rentzsch’s ambitious Mac developer conference in Chicago. Even though the event runs only one evening and the following day, it’s clearly a lot of organizing for one guy (even with help) to pull off. Kudos to Rentzsch!

Registration is limited to 75 developers, so I was quick to pull the trigger and sign up. Apparently there are only about 20 spots remaining, so I guess I was smart to do so. The quick enrollment is great news because I assume it all-but-ensures Rentzsch a break-even scenario (and hopefully he’ll even earn a little profit for his troubles).

While most of the session descriptions don’t exactly jump out and scream excitement to me, the people who are delivering them are top-notch and it will be fun to hear what they have to say. I’ll have to finally get around to reading the Subversion Book so I can grill Brian Fitzpatrick on anything I still don’t understand.

Mostly though, C4 is for me a chance to make up for the socializing opportunities I missed by skipping WWDC this year. I already know that several people I’ve been anxious to meet will be present (including Rentzsch himself), perhaps you’ll also be among them? Comment here if you are planning on being there, so I can keep my eyes open for you!

Update: Thanks to Jeffrey in the comments for pointing out just how insane lodging is the weekend of C4. It’s looking pretty much impossible to find anything for less than $300/night anywhere within a few miles of the event. I’m probably going to end up staying somewhere out near the airport and just suffer the train ride in and back. The airport train runs all night long so I think this is a pretty reasonable compromise (for a savings of around $400).

Just got back from Boston PodCamp, which was my first foray into the world of “UNconventions,” where attendees miraculously do not have to pay for anything. I’m impressed by the overall level of organization for a free event, though I was a little disappointed by the panels and seminars I attended. They were generally very short, and so short as to be pretty light on content. Still, can’t complain for the price.

The most inspirational session to me was a session presented by Larry Lawfer and Mark Blevis on interviewing tips and techniques. I’ve been mulling over the idea of giving the interview podcast format a try, because I think there are some not only interesting but very talented people in the Mac development community who would have a lot to say if given a chance.

Of course, I am a great fan of Blake Burris’s Cocoa Radio, which does a great job of introducing us to some of the platform’s leading developers. But I think there are so many voices to capture, that we need more podcasts tackling the same or similar material, from slightly differing angles. In particular I think I could, if I didn’t turn out to totally suck at interviewing, do a good job of extracting very technical information from Mac developers. While Cocoa Radio spends a lot of time talking about inspiration and history, sometimes I really want to know “how did you decide on the data model structure?” or “what are you doing to handle concurrency problems with your threads?”

Perhaps that would lead to the world’s most boring, unlistenable podcast. But then again, you’re reading this blog, aren’t you? Now … to decide on my first victim, ahem, guest. Quick, before the motivation wears off.

I’ll let you in on a little secret. Well, it shouldn’t be a secret by now, but you’ll know I’m talking about you when I say that not everybody has gotten the memo yet. Don’t be embarrassed – today is the day you come into the light (not the “just died and moving on to a happier place” light, but close to it).

Cocoa is better than Carbon. And Carbon is better than Cocoa.

If you admit to me with a straight face that you know only one and refuse to venture into the other, I will immediately form the opinion that you are a bad programmer. A programmer I’d hate to be stuck in a MacGyver episode with. You couldn’t program your way out of a box. Or an NSRect. Or a RgnHandle. You sad, pathetic sack of unadaptable protoplasm. I loathe you. Actually, I love you. You make it easier for me to shine. If you don’t embrace and use every appropriate tool at your disposal on Mac OS X, well, you deserve to write crappy software! (And yes, in case anybody is wondering, I do think this means sometimes POSIX is better than Carbon, and Python is better than Cocoa, or Ruby is Cocoa — it all depends on what you’re trying to do).

The saddest thing in all of Macdom is the sight of Cocoa and Carbon purists crying in their mailing list beers because a given task is “impossible” in the API of their preference. Often a fearless API-hopper like Jim Correia or John Stiles will pop up and cheerfully announce a one-line solution to their woes. In the opposite API than the original poster had hoped, of course.

“Thanks for the response, but I’d like to keep this as pure as possible.”

Excuse me, I thought you wanted a solution. You idiot! What they really mean to say is “I learned this framework 10 years ago and I’ll be damned if I have to learn anything new now.” Yes, believe it or not, even Cocoa has idiots from 10 years ago who refuse to admit that there is value in Carbon. But by sheer force of numbers, the Carbon idiots are the sadder of the bunch.

Wake up people! It’s 2006. It doesn’t matter what you program in, it’s how you get the job done. Arguing about whether to use Carbon or Cocoa is like arguing about whether to use a net or a hook to catch a fish. You use whatever the circumstances call for. If you don’t, you die. (This, from the vegetarian, city-dwelling Mac programmer).

Why am I rambling on in this unusually caustic mood? Just a good excuse to get this off my chest and toss some code out that I’ve been meaning to share. It’s nothing special, but it will be good to seed google with it, and it is very well suited to the genre of code that can only be accomplished by a Carbon/Cocoa double-play.

Download NSImage+RSCarbonIcon (Free MIT License).

[[NSWorkspace sharedWorkspace] iconForFileType:NSFileTypeForHFSTypeCode([whateverTypeCode])]

This simple category on NSImage lets you easily produce an NSImage based on a Carbon “Icon Manager” type code. You’ll find a long list of these type codes in Icons.h, beneath the kSystemIconsCreator enumeration. Generic folder? No problem. Computer icon (inaccurate, but hey)? No problem. All of these NSImage at your disposal, which would otherwise “be impossible.”

It’s also useful in that it demonstrates how to properly make use of Carbon IconFamily data in a mixed-endian world. Thanks to a little documented caveat, these structures must always be treated as big-endian. So even if you figured out how to use the Carbon Icon Manager by yourself, maybe you’ll find it useful that this code sample ensures endian-safety across both PowerPC and Intel platforms.