Whitney Young is a developer at FadingRed

August 25th, 2010 6 notes

It’s been a year and a half now since FadingRed became a registered LLC. A year and a half — that’s not very long — you must be a startup, right? No.

The term startup is usually used to describe young companies in technology. In general, startups have relatively small teams and a reputation for being fun, hip companies where people love to work. This is exactly the kind of environment that we’re working to create, so why is this not a startup?

There’s a couple of commonalities that you’ll find with startups. First, they are seeking or have already found someone to invest in their company. Many startups even receive funding before anything has been built; they have an idea that an investor believes in. When more money is needed, an additional percentage of the company can be sold. Because investors are involved, return-on-investment becomes a key part of the business. Investors are hoping for high returns because the company is growing rapidly.

Growth is intriguing because the real goal is for revenue growth. Sometimes it’s easy to get caught watching the number of employees grow and anticipate that revenue will follow. Regardless, once hiring begins, startups add many new team members quickly. I’m not talking hundreds of people, but it’s likely that they may grow from five people to fifty in less than a year. Such fast paced hiring often leads to startups bringing in an executive with experience to help manage.

The first employees who work for a startup are compensated with stock (in addition to their base salary). These employees clock crazy hours because they love what they’re doing. What’s more exciting than working on or having just completed a 1.0 product? Working a little extra at the end of the day or on the weekend is no big deal because it’s so much fun. There’s a culture of energy and excitement!

Everything could change — for better or for worse — in a split second. So much is happening so quickly that it’s hard to control and mold your company into what you really want it to be.

While much of the what’s written above are generalizations, it fits with what comes to mind when a company is described as a startup. There’s too much, though, that just doesn’t fit with what we want our company to be.

For as long as I’ve been developing software for the Mac, developers who either work for themselves or small companies have been referring to themselves as indie developers. This, of course, is short for independent developers. Independent is a great way to describe our company — we think independently about how our company should operate.

We don’t have investors. We don’t work late or on the weekends. We don’t focus our energy on growing rapidly just for the sake of growing. We think outside the box.

When we started, our company didn’t have anything in the bank; we didn’t even have a bank account. A small operational overhead has allowed us to get off the ground without outside funding. For us, this was an ideal starting point. Starting from zero allows you to really understand how much revenue you need to support your business. Our revenues have been good, and we’ve built up to the point of being able expand our team. Expanding makes sense for us now because we have more work than our team can handle. We are growing because we need to grow not because we can.

We don’t work on the weekend because we don’t want to. That’s personal time. No one wants to feel like their entire life was spent working. We plan things out so that nothing critical happens at the end of the week, so there’s nothing to worry about during the weekend. Everyone should relax and enjoy life outside of work, and the weekend is your time.

What we’re building is a place where we love what we do, where everyone who works for our company loves what they do. Decisions are made based on what is best for business and our happiness. We don’t report numbers to investors to determine our success. Our success is based on the quality of what we create.

Hg Init

A Mercurial tutorial by Joel Spolsky

January 29th, 2010

Steven Frank:

We learned about computers from the inside out. Many of us became interested in computers because they were hackable, open, and without restrictions. We worry that these [new] devices are stifling the next generation of programmers. But can anyone point to evidence that that’s really happening? I don’t know about you, but I see more people carrying handheld computers than at any point in history. If even a small percentage of them are interested in “what makes this thing tick?” then we’ve got quite a few new programmers in the pipeline.

I agree with this for sure. I think a concern is that there is a large barrier to entry — currently, you still need to own a computer in order to tinker. Without the ability to tinker, though, there is still a generation of inquiring minds with easy access to the internet and information about how things work.

Fast forward to a time when you can tinker with these devices. Now young thinkers have easy access to a ton of information and can start applying it immediately.

January 28th, 2010

Alex Payne:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

This bothers me as well. I think there are a lot of programmers out there that got started tinkering in the same way. I remember tinkering with ResEdit as a kid too, and without a real computer at that age, I don’t think I’d be programming now.

Using malloc to Debug Memory Misuse in Cocoa

Bill Bumgarner gives great advice and examples for tracking down leaks in Cocoa apps.