Developing for the desktop has been fun and an interesting change of pace from iPhone development. A full post-mortem is on the way.

In the mean time, it’s a great feeling to add a bit of OS X freeware to the world.

The most important point: If you want a great application with a user experience you’ll be proud of, build a native application using Apple-blessed developer tools and resources. Apple’s developer tools are outstanding applications and the iPhone frameworks provide useful, battle-tested, mature code that lets you do a lot without reinventing the wheel every time you need to build even basic functionality. Best of all, Apple gives their tools away for free.

Don’t screw around with stuff like PhoneGap or Adobe’s Flash-to-iPhone binary whatsit just because it might be a little closer to your comfort zone. You’ll risk writing an application with a library that gets left in the dust when Apple releases a new version of the SDK with great new features. You’ll also risk having your application rejected if Apple decides one morning that the tools you used are accessing private methods, running interpreted code or disrespecting some other element of the SDK agreement. Finally, you’re not going to be working with the same design vocabulary expressed by every popular iPhone application.

With UIKit, Apple hands you an enormous pile of outstanding interface classes that are exceptionally clever, attractive and versatile. They’re yours to build with and do as you please. Thousands of hours of interface coding that you don’t have to do, saving you time and allowing you to write an app with an experience that’s consistent with everything your users will expect on the iPhone.

With Core Data, you get a powerful object modeling framework with built-in persistence. What does that get you? If you’re building an application, you’ve got data. Lots and lots of data, sometimes. You’re going to need a way to define and encapsulate that data so that you can keep track of relationships between different chunks, pass information around the application and store it for later use. This can be tedious, laborious, time-consuming work. Core Data does all of the heavy lifting for you.

For me, those are the biggest freebies you get with approaching iPhone development “the right way.” That barely scratches the surface, though, since Apple provides powerful APIs that let you accomplish drawing, manipulating the filesystem, performing network operations, dead-simple threading, and many other useful things.

Hopefully you’re intrigued. You’ll need to be, especially if you’re starting from scratch. There’s a big chunk of learning you’ll have to do. It’s worth it, though. The iPhone is a really fun platform and there’s something potent about developing for a mobile device that’s always in your pocket.

Find the section that describes you below and proceed from there for my advice on great learning resources.

You’ve never coded anything, ever (or, C-based languages scare you)

Let’s start with C. C is a venerable language with a long history, born in 1972. C is important background to have for iPhone development, since so many Apple APIs use either C or Objective-C, a related language we’ll talk about next.

Luckily, Dave Mark has you covered. Learn C on the Mac assumes no pre-existing experience with any programming language. You’ll get a friendly explanation of everything you need to understand C and the basics of programming. This is ground zero, indispensable knowledge for anyone who is approaching this with no experience. The best part is that Dave has written for someone who will be using Apple’s developer tools, so you’ll be getting a perspective that will be useful for your iPhone efforts a little bit later.

You’re comfortable with programming and C, but not Objective-C

Objective-C is built on top of C, so if you’ve got a basic comfort with programming in C, you’ll have an easy time getting up to speed. Objective-C lets you build object oriented code. Whuzzat? It’s Legos for programming. You can build your own bricks and trade them with friends. Put simply, object oriented programming (OOP) lets you build modular software that maximizes code reuse. Reusing code is good! Chances are, if you solve a problem once in your project, you’ll need that solution again later. OOP lets you easily package up these solutions and deploy them anywhere they’re needed in your code.

Confused? You won’t be after you read Learn Objective-C on the Mac. You’ll learn all the details of how Objective-C works. The book is packed with clear explanations of how to use object-oriented programming and practical exercises to get you comfortable with building useful code in Objective-C. You will not enjoy learning iPhone development without a solid foundation in Objective-C. You’ll get one here. Many lightbulbs will turn on for you.

You understand Objective-C but you’re not yet confident enough to build an app with it

If you feel great about Objective-C and you can’t wait to get started, go on to the next book. If you want to build a little more confidence, it might be worth spending some time practicing with Objective-C and how it interacts with Apple’s Cocoa API. What’s Cocoa? It’s a huge collection of pre-made building blocks you’ll use to build applications. (Not to be confused with Cocoa Touch, which is a version of Cocoa custom-tailored for the iPhone, which you’ll meet later.)

Cocoa Programming for Mac OS X is great introduction to Cocoa. You’ll learn about using Objective-C with Cocoa, use Interface Builder to construct some interfaces and walk through plenty of exercises. You even get to play with Core Data. By the first dozen chapters or so, you should be ready to rock. Many of the Cocoa goodies you play with on the desktop will be waiting for you on the iPhone.

You’re comfortable with programming and Objective-C

It’s time to get rolling with the iPhone.

I own several iPhone development books. None is a better, more useful introduction to developing for the platform than Beginning iPhone Development. It’s Dave Mark again, alongside Jeff LaMarche, with everything you need to get started. Beginning iPhone Development is a comprehensive exploration of building software for the iPhone. The authors provide friendly guidance as they break you in gently. You’ll learn how to construct interfaces, master table views, and how to store and load data, even using Core Data. The book is filled with useful, practical exercises that you’ll be able to use for your own projects. Dave and Jeff are great about providing code that is both understandable for learning and yet practical enough to serve as a springboard for solving your own problems in your own apps.

If you’re learning how to develop for the iPhone but you don’t have their book, you’re doing it wrong.

They don’t stop, there, either.

Jeff and Dave’s latest, More iPhone Development, is loaded with meaty chapters on advanced topics. My favorites: several chapters on Core Data (nearly half the book) and an outstanding tutorial on how to use Xcode’s debugging tools.

The breadth and depth of these titles together is unbeatable for a beginner iPhone developer. Between both books, you’ll have answers for most quandaries you’re likely to encounter in your early projects.

On teaching yourself

So how do you use these great learning tools? I’m a passionate, lifetime autodidact. Here’s my advice:

At least one hour, every single day.

The books I’ve described present their content split up into chapters. Read and work through at least one chapter per day. Don’t try to cram it all into a couple of weekends, skimming examples and reading exercises instead of trying them.

Even if you’re starting from the ground up, you can easily get through every single book I’ve described here within three or four months.

You’re setting up your own little school. Make a point of setting a time when your studies begin and end and make a habit of sticking to that schedule. If you have to miss a night of your programming school, give yourself some time to make up for it the next day.

Equipment

Get the PDF eBook editions of the books you need. You can never lose them, forget them at the office, spill coffee on them, whatever. They’re instantly searchable and much easier to work with in a nightly home school setting than paper books. They’re sometimes cheaper than paperbacks, you don’t pay shipping and you can get them instantly via the web. I have a blend of paperbacks and PDFs — I’m much happier with my PDFs, especially when traveling.

If you’re serious about programming, you’re going to need a second monitor as well, unless the one you already have is enormous. One day you’ll have real projects to work with, which means a debugger window, some documentation open at all times, and plenty of other clutter. A second display will make your life manageable. During your programming school, having a second display for your eBooks will make working through your exercises on the main monitor much easier.

Finally, you’ll need a notebook. As you work through books and exercises, make note of the important, central concepts and create lists of basic vocabulary. You’re going to have a lot of new knowledge to sift through. Make it easy on yourself by building your own cheat sheets to reference in the middle of exercises or when you make the jump to the next level of learning. It’s a lot easier to consult your own notes than try to figure out which book had which handy tip.

Start

Just get started. Pick a book, pick a time and start. It’ll be weird at first, especially if you’re new to programming. That’s okay. Wikipedia is close by with a wealth of technical articles on anything you might want to know about. If you have questions and don’t know who to ask, Stack Overflow is filled with knowledgeable (and not so knowledgeable) members who will be eager to point you in the right direction, no matter how specific or arcane the query.

Good luck! This is an exciting time to develop for mobile devices. The iPhone is the most potent and exciting handheld computer ever. You’re going to have a great time — once you get started.

(Note: Apress didn’t sponsor this post or anything but I notice they make up almost all of my recommendations. Kudos to them for hiring outstanding writers who care about relating their wisdom in a clear, enjoyable manner. Their books have great layout and intelligent structure, so they work as well for reference as they do for sequential, hands-on learning. Truly a great publisher who understands the needs of its audience.)

I’ve hated Flash for the better part of five years, a bigotry mostly inspired by how poorly it has worked for me as an end-user. It’s even worse for people who need to maintain web sites in Flash, as I later learned professionally. An essential tool for any computer I use more than five minutes is Flashblock for Firefox or the outstanding ClickToFlash plugin for Safari.

Then it dawned on me: If I hate it this much, surely Adobe, who is responsible for maintaining it, must hate it even more. Surely no amount of money is worth this much pain, right? There must be another reason Adobe prolongs this shared internet misery.

Drawing equal parts inspiration from 2001, Terminator 2 and Babylon 5, I present to you: Flash is My Keeper.

For years I’ve been saying this:

Only two things have made flying safer [since 9/11]: the reinforcement of cockpit doors, and the fact that passengers know now to resist hijackers.

This week, the second one worked over Detroit. Security succeeded.

EDITED TO ADD (12/26): Only one carry on? No electronics for the first hour of flight? I wish that, just once, some terrorist would try something that you can only foil by upgrading the passengers to first class and giving them free drinks.

Bruce is referring, of course, to the new, rumored security procedures said to be rumbling their way out of the TSA’s nightmare bureaucracy and onto your next airline flight.

In a nutshell: planes must disable their seat-back in-flight entertainment, passengers can’t use electronics, get up or access their bags during the last part of a flight. Oh, and you can’t have anything in your lap.

Keep in mind, this is in response to a dim-witted “terrorist” who snuck a weak explosive onto a plane… inside of his pants.

Remember when shoe bomber Richard Reid tried to blow up his Reeboks? That resulted in a limit of one carry on bag per passenger, despite the fact that Reid’s plan had nothing to do with carry on bags. Then there’s the whole liquid limit for carry on bags, which also makes no sense given the simple reality that liquid re-combines very easily, even if you do happen to carry it aboard in small containers instead of big ones.

So the recent rumors of new policy, while wildly stupid, are just stupid enough. They carry enough non sequitur authenticity to be utterly believable. I was ready to believe them. Then a source contacted me. He’s inside the TSA and was desperate to leak the internal memo that brought the new rules into existence. Now it all makes sense: the non sequiturs, the absurdity, the utterly incomprehensible creation, amendment and abandonment of these policies.

The good news, if you can call it that, is that in a few places, it would seem the TSA exercised forbearance when it seemed like, even by their standards, they’d crossed the line. Here’s the document, reproduced without further comment:

Lego was an instant bullet train to any world I could imagine. Space ships, robots, lunar colonies, pirate treasures, ancient castles, you name it. These were mine to explore. I could spend days at a time perfecting some imaginary construct made real through the magic of Lego bricks and the exertion of my crude abilities. I treasured the rarer pieces, protecting closely my little snap-on magnet linkages and battery-driven light bricks. Regardless of whatever turbulent nonsense might have been happening elsewhere in my little world, Legos were an inviolable source of joy.

Joy, you know, that feeling that lives somewhere between the pit of your stomach and the tip of your smile. That vague something that builds a simple, contented glow inside of you that’s like a thousand perfect, extra-gravy-save-me-some-pie thanksgiving dinners with none of the bloated aftermath. Maybe you just saw the most beautiful vista in all of the world. Maybe you just fell in love. Maybe you’re ten years old and you see exactly what you were hoping for under the Christmas tree. You know what I’m saying, right?

Joy.

The Macintosh came a bit later. At age 7, I got my hands on a borrowed Macintosh SE. And the joy was there, too. It could do so many things. It could produce clean, perfect type that was huge! I made a lot of paper signs. It could store all of this information and then show it to me again later. It could show me pictures and organize them into this tidy scrapbook.

And sounds! It made all these noises. I was most enamored with the quacking duck.

It was this whole world inside there that I could barely understand. I knew only one thing for certain: I wanted more. So much more of it.

Eventually, through about three years of begging and cajoling, I convinced my mom to plunk down the tidy sum necessary to secure a Performa 6116CD for our exclusive home use. (The fact that I kept spending a lot of time at the home of a neighbor kid who had his own Mac and whom my mother intensely disliked probably sped things along, too.)

The 6116 was an even greater magnitude of joy. An 8x CD-ROM drive and a huge bundled library of multimedia content like encyclopedias and interactive atlases. Plus creativity applications and, wonder of wonders, Sim City 2000. I had so much fun exploring this new world. I spent an inordinate amount of time learning every piece of software I could get my hands on.

It was joy.

And then, I grew up. Like so many, I lost my capacity for the discovery of simple joy. It became the exception rather than the rule of life. Go to school, then go to work, do your job, go home, repeat.

Then I found programming. It occurred to me tonight, as I struggled, quite happily, to grasp how the hell it is block arguments in Ruby work, that I’d rediscovered a simple, consistent source of joy. Programming languages are infinite bins of Lego blocks, waiting to be assembled to my liking. Programming is a limitlessly fascinating Performa, waiting for me to learn and harness any language for any task I can imagine. There’s just so much to learn and enjoy in programming computers.

Even after a few years of it, programming makes me feel joyfully like a kid again.

DCSoundServices.h:

#import <Foundation/Foundation.h>
#import <AudioToolbox/AudioToolbox.h>
 
@interface DCSoundServices : NSObject {
 
}
 
+ (void)playSoundWithName:(NSString *)fileName type:(NSString *)fileExtension;
+ (void)vibrateDevice;
 
@end

DCSoundServices.m:

#import "DCSoundServices.h"
 
@implementation DCSoundServices
 
+ (void)playSoundWithName:(NSString *)fileName type:(NSString *)fileExtension
{
 
	CFStringRef cfFileName = (CFStringRef) fileName;
	CFStringRef cfFileExtension = (CFStringRef) fileExtension;
 
	CFBundleRef mainBundle;
	mainBundle = CFBundleGetMainBundle ();
 
	CFURLRef soundURLRef  = CFBundleCopyResourceURL (mainBundle, cfFileName, cfFileExtension, NULL);
 
	SystemSoundID soundID;
 
	AudioServicesCreateSystemSoundID (soundURLRef, &soundID);
 
 
	AudioServicesPlaySystemSound (soundID);
 
	CFRelease(soundURLRef);
 
}
 
+ (void)vibrateDevice
{
	AudioServicesPlaySystemSound(kSystemSoundID_Vibrate);
}
 
@end

Assuming you’ve got a sound file named click.aif in your application bundle, you can play a sound in just one line of code:

[DCSoundServices playSoundWithName:@"click" type:@"aif"]

Or, vibrate the device:

[DCSoundServices vibrateDevice]

Much tidier than having to import AudioToolbox into every UI that ever plays back a sound.

The structure works like this:

The first row of your CSV is considered to be the header. The code will use content from the header row to create key names. For every subsequent row, the code will create a dictionary, associating the content of each column with the key names from the header. The dictionaries live in an array which is written out to a Plist file.

This is handy if you’ve got a bunch of spreadsheet-type data you’d like to use as the basis for a static reference in your app. Say, data about the periodic table, airport listings, trivia questions, whatever. You can sift and sort your data in a user-friendly environment like Numbers or Excel, then dump it out to CSV and put this code to work.

It uses cCSVParse to read the CSV file.

//	NSLog(@"Converting %@",pathAsString);
 
	CSVParser *parser = [CSVParser new];
	[parser openFileWithPath:pathAsString];
	NSMutableArray *csvContent = [parser parseFile];
	[parser closeFile];
 
	if (pathAsString != nil)
	{
 
		NSArray *keyArray = [csvContent objectAtIndex:0];
 
		NSMutableArray *plistOutputArray = [NSMutableArray array];
 
		NSInteger i = 0;
 
		for (NSArray *array in csvContent)
		{
 
			NSMutableDictionary *dictionary = [NSMutableDictionary dictionary];
 
			NSInteger keyNumber = 0;
 
			for (NSString *string in array)
			{
 
				[dictionary setObject:string forKey:[keyArray objectAtIndex:keyNumber]];
 
				keyNumber++;
 
			}
 
			if (i > 0)
			{
				[plistOutputArray addObject:dictionary];
			}
 
			i++;
 
		}
 
//		NSLog(@"Plist output array %@", plistOutputArray);
 
		NSMutableString *mutableString = [NSMutableString stringWithString:pathAsString];
		[mutableString replaceOccurrencesOfString:@".csv" withString:@".plist" options:nil range:NSMakeRange([mutableString length]-4, 4)];
 
		NSURL *url = [NSURL fileURLWithPath:mutableString];
 
//		NSLog(@"Write to URL %@",url);
 
		[plistOutputArray writeToURL:url atomically:YES];
 
	}

That’s from a simple desktop app I built for the purpose. It takes the path of your CSV, via drag-and-drop, then spits out the Plist beside it.  You can grab the source at Google Code. You can also download this compiled binary if you want to get crackin’ right away.

That’s a big number.

I can’t tell you the secret to success in the App Store. I haven’t discovered any magic formulas. The one thing I can tell you with 100% certainty is this: if you ship a product with bugs that genuinely piss off your customers or, worse, make them unable to use some portion of your hard work, the road toward success just got much longer and a lot more miserable. Even with “prioritized review” requests, once your buggy app is on the store, the review queue means you could be waiting a long time before your customers can enjoy your bug fix.

You will not sleep well at night.

The good news is that this problem has been solved a thousand times over. A thorough beta test can save you from this terrible outcome and the sleepless nights that come with it. With a bit of diligence, you can ship an app with awesome stability to match your great ideas.

I’ll share how I run my betas. This is about process — the technical side of Ad Hoc distribution is thoroughly documented by Apple and others. The tools I use are simple and free. They work. If you have suggestions for better ones, I want to know about them before my next test! Please share in the comments.

Gather Your Testers

You’re going to need testers. If you use a volunteer testing pool, figure that 80% of testing will be done by 20% of your volunteers. That means to have any hope of gathering meaningful feedback, you’ll need at least 10 volunteers. 15 or 20 would be the ideal minimum.

Next, you’ll need to start early — but not so early that your testers’ enthusiasm cools by the time you ship your first beta build. Try to get the word out between three to six weeks before you’re ready to test. If you have a particularly strong network, you may need less time. If you’re relying more on the kindness of strangers, though, make sure to give yourself plenty of lead time. Use your website, your blog and your Twitter to solicit volunteers but don’t be a pest.

Most importantly: if you have contact with existing customers from previous versions or perhaps other products entirely, send a quick, polite email explaining what you’re going to test and encouraging them to join up. Customers who have emailed you in the past with feedback or feature requests may be especially keen on seeing your latest work.

Understand Your Testing Pool

You need to know things about your testers. What kind of hardware will they be using? What version of iPhone OS? What’s their geographic region? (International testers are crucial for finding your screwups with localized formatting and other geographic issues.) Most importantly, you’re going to need to collect their UUID.

I use Forms for Google Docs to collect most of my feedback. It’s an easy-to-configure way to store structured data. Since you can designate required fields, you can ensure your testers don’t forget to include anything crucial when reporting issues. Best of all, you can embed the forms into existing web pages, allowing you to include them alongside testing guidance, version history or other information that might be useful.

Here’s the form I use to collect beta tester info:

It’s not short. The other benefit to using a form is to ensure you only get testers who are reasonably skilled at providing detailed information. Everyone who makes it past this filter has a decent shot at actually telling you everything you need to know later in the beta.

Betas Worth Testing

If your app doesn’t look somewhat close to the final product, don’t distribute it for testing. If you’re relying on a volunteer testing pool, you want them eager to use your stuff. If your overall UI is incomplete, you’re not ready to test. You’ve got a limited amount of time and attention with your testers. Don’t squander it on early builds you could easily test yourself. The closer you think your app is to shipping, the more useful your testers will be to you.

You do yourself no favors if the last bit of functionality you add affects previously-solid features that now need a whole new round of testing.

Believe me.

Distributing Your Binaries

So you’ve toiled away and you’ve finally got an app you feel is ready to be tested.

Don’t email the binary.

Depending on the size of your app, the attachment may not be properly delivered to the recipient, especially if they’re using Exchange-hosted email. Instead, host your app and the necessary provisioning profile on the web.

I also recommend a simple checkout system. When you’ve got a new build ready for testing, send your testers a link to a one-question form that asks for their email address. On the form confirmation screen, you can provide a link to the binary. This lets you get an idea of who is participating. It also lets you answer an important question: am I getting zero feedback because there are no bugs or because there are no active testers? With a checkout process, you’ll know for sure.

Use clear versioning with every distributed build. You need to be certain you and your users are talking about the same build when they give you feedback. Beta phases, version numbers, dates, whatever you need to make things clear for everyone involved. Make sure that somewhere in your app, your code pulls the version number out of your app’s Info.plist file and displays it in the UI. Here’s some code to get that string:

NSString *currentVersion = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];

Update your Info.plist’s version number religiously before distribution. Even better, update it automatically.

Communication

You need to communicate with your testing pool. Keeping them regularly updated, without being spammy, is crucial to keeping them excited about what’s going on.

When you send out a new build, explain what’s new. Give specific testing guidance so that your testers know where they should focus their efforts. New method of rendering cells you strongly suspect has a bug or two? Share your hunches. Built a new import subsystem you’re suspicious might break with legacy data? Provide an example data set or encourage existing users of the old version to give it a whirl. If you’re manipulating data that lives only on the user’s device, tell them to back up their iPhone before running your beta. And tell them why. Don’t be a douche on this: never take for granted the importance of your testers’ application data, especially if you’re lucky enough to have your existing customers helping you. Yes, we all know, betas are risky. Still, the iPhone isn’t the desktop and if you’re testing an upgrade to an existing app, your customers may have data they created before accepting the risks of a beta.

If it has been more than seven to ten days since your last build, send a quick update to the pool. Call out awesome testers and let them know they’re making a difference. Share the score of resolved issues you were able to fix thanks to the pool’s feedback. Most of all, thank them. Their efforts are helping you to not look like an idiot.

Sandboxing Helps

If you’re making an all-new app, you can skip this section. If you’re testing an upgrade to an existing app, read on.

Your early beta builds should use a different app identifier than your shipping app. This way, your beta will be installed as a distinct application alongside your currently shipping version on the user’s device, instead of overwriting it. This lets you ensure that no shenanigans happen to legacy data if you’ve got customers from previous versions in your testing pool. Toward the end of your beta, after much internal testing, you can start distributing builds that overwrite previous shipping versions. You’ll want to ensure that the app properly imports legacy data and preferences and, of course, ensure nothing otherwise disastrous happens when iTunes distributes your updated app to existing customers with existing data.

Gather Useful Feedback

You need to know things about how your application is failing. The forms I use are inspired heavily by what I saw once upon a time during the iPhone OS 2.0 Enterprise AppleSeed beta test. I think it covers the basics. Of course, don’t be afraid to add other questions specific to your application’s circumstances. For bugs, measure how well you can reproduce the bug and its overall severity while capturing the reproduction steps. For feature or enhancement requests, measure the tester’s impression of the request’s importance along with what they’re asking for.

However you gather your feedback, ensure that every single message you send to your testing pool includes brief instructions on how your testers should report their bugs. Never make them hunt around for it.

Ship

You haven’t added or changed anything for a couple of builds. You’ve fixed plenty of bugs and no one has reported regressions. You’ve sent emails to your top-performing testers and they’re giving you a thumbs-up.

Give it one last test yourself. Thirty minutes, minimum, actually doing things your users are likely to do. Is it kosher?

Then ship it.

Then, while you wait for approval from Apple, test it some more, informally, yourself. If somehow a show-stopping bug pops up while you await approval, you can reject your binary and submit a fix before it ruins anyone’s day.

The universal trial, of course, is money and I’m hardly exempt. There’s a sixty day delay between me making money from an iPhone app and Apple actually paying me. That leaves immediate, painful gaps in my cashflow.

The obvious solution to this is consulting — I’m privileged to know how to do a lot of things that are useful to people. Unfortunately, I’m still learning how to market, grow and manage that particular end of my business, so I’m painted into the most dread of corners: retail.

I live by the axiom that no honest man is too good for honest work. So while retail is often the dullest, most imagination free work you can do before hitting manual labor, that’s not the part that I hate most about my seasonal job.

No, the worst of it is this: I have to call my customers “guests.”

This is some of the most odious corporate newspeak bullshit in recent years. It has always irked me. Guest means a specific thing: certainly it implies hospitality, which may explain the intent, but it fails to properly convey the truth of the relationship between the store and the customer. Being the guest of another places the guest in the inferior position and the host in the superior position. While manners may require that hospitality be extended, being termed a guest in the final equation simply means that the customer does not belong there. It suggests they belong somewhere else.

This is the wrong view.

The customer is not a guest of the store. A successful retail experience means that the customer is at home in the store.

Somewhere, somehow, having “customers” became a distasteful condition for large corporations. This is unfortunate and I wish they would cut the crap. The truth is that there is honor in having customers. There is honor in upholding the sanctity of the customer relationship. Being a customer of a business means something very specific that no other English word can capture. Being a customer means being the lifeblood of a business. Being a customer means being the motive force behind a powerful organism that provides products, services, livelihoods and, ultimately, the basic existence of others. Being a customer is being part of a tradition that keeps babies nourished, families housed and people clothed.

That means something. Something potent. Something that must be continually venerated if we’re going to keep moving forward as rational people. Does any of this sound remotely like having a “guest” to you?

I’m proud to have customers. I’m proud to respect their importance to my business and their contribution to the fact that I’m not sleeping outside tonight. That is essential to my work ethic and it will never, ever change.

The end of my seasonal retail job can’t come fast enough. I’m not sure my teeth will survive the grinding required for me to get the word “guest” past my lips on every shift.

Let’s start with this: I’m an idiot. I’m 24 years old and I don’t know anywhere near as much as I need to. I convince myself otherwise because without the strength of thinking I know at least something, I could never get much done.

That said, I do know this: there are only a few people who you should take advice from. I mean life advice: advice on how to be who you are, how to manage your world, how to grow as a person.

1. People who have demonstrated an interest in your success and years of loyalty. You’ll be lucky if you get one of these. I hit the lottery, and I have two. You’ll know them with this test: If they asked you to drop everything and save their ass (business, product, family, life) for a month, you’d do it without hesitation.
2. Your significant other. This is someone who spends a lot of time with you and sees all that you struggle with, all that makes you happy. You’ve been through good and bad and get wistful recalling both. My luck continues: my girlfriend is the wisest counselor I could ever ask for.
3. Yourself: If you cut the crap and take a long walk alone, you can ask yourself anything and usually get the right answer. Make the time to know your own thoughts: you might be surprised how much is waiting in your own brain.

That’s all. Here are people who should not be trusted for advice:

1. Some dick with a blog (even me). If you’ve ever read a top-ten post on a blog, you know the content is cranked out to drive pageviews. The author probably slapped the content together in the space of two hours to benefit an audience of thousands. Like with drive-by legal or medical advice, you’re a fool to assume you can get something directly applicable to your case from a one-size-fits-all post.
2. Parents. Your mileage may vary but parents are often too invested in your safety and security to be able to weigh the benefits of those risky life decisions with huge payoffs and incredible experiences. If your parents are batshit insane (thankfully not my case, but I have seen this) that investment may yield terrifyingly bad advice. Even if the advice you get is reasonable, there’s plenty we don’t need to tell our own parents.
3. Your social circle. Excluding a choice best friend or two, your social circle can’t tell you anything useful about how to run your life. Groups breed conformity and breaking from that might be consciously or even subconsciously discouraged.
4. Penelope Trunk. (cf. #1)

Penelope Trunk wants to tell you how to run your career. She presumes to be an expert on this subject. She’s not.

Once upon a time, as a young man desperate for growth and success, a blog specifically like hers, geared toward shameless career ambition, seemed like crack. Loyal readership taught me otherwise. Penelope Trunk is someone barely in control of her own life. That she is honest and open about her flaws is endearing but doesn’t change the fact that she cannot provide viable career advice based on personal experience. She’s proudly a trainwreck and while that may be great for her blog’s readership, would you trust a fitness trainer who doesn’t exercise and can’t stick to a healthy diet? Mental health counseling from a patient in a psychiatric ward? Computer advice from someone who uses Windows 98? Come on. I may be an idiot but at least my bullshit detector works.

Only when Penelope Trunk is viewed as a cautionary tale will you find viable lessons for your own career. I would never claim to be qualified to advise you on how to run your life. Nonetheless, if you take the things Trunk has done with her life and imagine the opposite, you may find valuable guidance.

Read on for these lessons.

Bullying is Okay

Earlier this year, Trunk was complaining about her kids. I don’t blame her — parenting doesn’t seem like a lot of fun at times and blowing off steam via Twitter is cheap, easy relief. Things got complicated when our thin-skinned heroine was sassed by some jackass in flyover country. What did Trunk do? For most people who aspire to the public eye, ignoring this would be right move. Maybe using Twitter’s block feature, if you’re an especially petty kind of douche, would have been called for. In any case, it’s hardly worth more than a few seconds of thought. I guess Trunk wasn’t busy enough with her family and leading her startup because instead of doing the grownup thing, she called his place of employment and saved their number with the intent of “ruin[ing] his life there if [she] ever felt like he needed to be taught a lesson.”

(I’m not sure crazy internet lady calling out of the blue and whining about 140 characters of abuse is something technically capable of ruining anyone’s life. I leave it as an exercise for the reader to determine what her true plan really was.)

Next, she called his wife. From the blog: “There was no answer. Maybe by then he had alerted his wife that he is being pursued by a psycho who maybe will kill her kids or maybe will kill him. Maybe they will never answer their phone again.“

(My emphasis.)

This is professional? This is what we do with our careers? There’s a word for this: unhinged. Self-revelatory stuff, right there.

Finally, Trunk penned a seething, rage-soaked blog post naming names and even the guy’s home town. She was impressed with herself, though, for having the maturity to not post his home phone number. Trunk was happy enough to ruin his Google mojo forever. She is, in fact, proud of that post to this day. (Notwithstanding the flurry of posts that came next, lasting just long enough to push the hatefest off her front page.)

Anti-Lesson: When you build a blog readership and a meager Twitter following, you should use these tools to bully the hell out of those who dare disagree with you. Anyone who tells you your behavior is unacceptable just doesn’t get it. It’s worthwhile to spend a significant amount of time and effort persecuting a grudge. You can use bad behavior to impress other people by appealing to the worst within them.

The real lesson: Self-control is important. In your life, especially as you become more successful, more and more jackasses will come out of the woodwork. How you respond to the least courteous of those around you speaks volumes about your true character. You can spend a lot of time getting vengeance against those who piss you off but the payoff is rarely worth it. If you want to make yourself seem smaller than you are, the best way to do it is to give attention to someone who doesn’t deserve it.

“Online Stars” Are Important

We’ve all been in this predicament before:

“So, D, who is really attentive and normal—two traits I have never had in a boyfriend, ever—is scary to me because I’m giving up the chance to enhance my brand by dating an online star.“

Yeah, I guess maybe not so much. Trunk is still in high school — approval of the internet cool kids is so important to her that not dating one who can improve her standing is a quandary worth blogging about. She has since resolved the quandary by electing to marry a farmer. He must be the retired co-founder of Skype or something.

Speaking of quandaries and farmers, the internet cool kids caused a conflict there, too. After accepting a reconciliation date from this then-estranged farmer fellow, Trunk realized she was double booked!

When I came out of my giddy stupor from his email, I realized that [the date] was the same weekend as maybe the biggest schmoozing event of my life: Guy Kawasaki invited me to spend a weekend on the USS Nimitz with Michael Arrington, Robert Scoble and others.

I said yes to the weekend, of course. Because how can hanging out with these guys not be great for me? It’s probably what I’ve been working up to my whole career: a weekend like that.

Guy Kawasaki is apparently a friend of hers, so we’ll skip him, but wow, Michael Arrington and Robert Scoble! Connected guys? Sure. But you know what? They’re also douchebags. 40-something Scoble, for example, sees no problem getting touchy-feely with 17-year-old female entrepreneurs. Arrington is just a pompous weiner who can’t handle other people’s low opinions of his douchery. Trunk ultimately did what anyone with healthy priorities would do: she spent the weekend with someone who loves her instead of with a self-important group of perpetual children whose only interest in Trunk is how she’s able to further their own interests.

Invitation to dine with the Obamas? With Steve Jobs? With the late Norman Borlaug? Yeah, the farmer could take a hike. But these guys on the Nimitz? No one will know who they are in 20 years. There is no conflict. These guys were a group of assclowns who have never made any meaningful contributions to humanity. They’re worth skipping for someone who cares about you. If you’ve spent your whole career working toward a weekend with them, you need a new career.

Anti-lesson: People who have convinced the internet they are cool deserve our time, reverence and attention. If you’re going to waste your time with people who aren’t internet cool kids, there had better be a good reason. You should spend your whole career getting to the point where you can possibly one day hang out with these cool kids.

The real lesson: Often with little meaningful or useful accomplishment, people can convince the internet they are cool. Maybe they truly are. Just as often, these flavors of the minute will be forgotten within a decade. Either way, they’re just people. You have your own people. You should measure the value of your people by what they contribute to your life rather than their Twitter follow count. If your career is itself focused on convincing other people you’re cooler than you are, you should switch to a career where you’re actually doing meaningful work.

You Kind of Suck and Can’t Be Incredible

Penelope Trunk wants you to know: “[Dooce] is a marvel. And you are not.”

Dooce is, in fact, a marvel: a blog that pays her bills, millions of Twitter followers and a self-directed life right from the comfort of her home. Without even meeting you, though, Trunk dispenses the above defeatist advice: you’ll never be that, even if you want to be. Dooce is not an overnight success by any stretch: she has been writing her blog for eight years. While she is certainly talented in relating her thoughts, one of the greatest contributors to her success is her simple willingness to keep showing up, year after year. Woody Allen will tell us: 90% of success is just showing up. He should know — a large swath of the population finds his self-indulgent New Yorgies unwatchable. (I am on the fence.)

Anyone with a modicum of interest in an activity and a willingness to keep showing up over and over again will become a marvel. Malcolm Gladwell calls this the 10,000 hour rule.

Imagine if Penelope Trunk had given Dooce that advice, before she became a marvel? Imagine if she had told a young Heather Armstrong she’s not much of anything and should stick to doing jobs she doesn’t much like. Imagine if Dooce had believed it. (Not that it seems she would — by all accounts, Dooce is someone who does whatever it is she wants.)

Dooce is exceptional because she chose to be, not because a supernatural event anointed her with that status.

While the overall advice of Trunk’s post is so blindingly obvious as not to need saying (blogs won’t immediately make you money), the evidence used is part of an overall theme of her blog: Penelope Trunk thinks you kind of suck and you should just quit trying to build your career if the path you’ve chosen isn’t immediately marketable. But I’m getting ahead of myself.

Anti-Lesson: Things that are hard aren’t worth doing. Other people are better than you. You shouldn’t even bother trying. You kind of suck.

The real lesson: You’re in control of how great you are (or aren’t). You decide how quickly you reach 10,000 hours of anything. You’ll become incredible only if you choose to be: by doing the near-impossibly difficult work necessary to get there. Just like everyone else who ever chose to be incredible.

Unethical Behavior is Just Fine

If a company pays you to say something about them, Trunk says, there’s no real reason to disclose that. That’s for newspapers. You should just trust that she’s making money from smart companies, and that makes it all okay.

The trust of her readership is for sale to highest, smartest bidder.

The FTC, unfortunately, doesn’t agree that this is acceptable behavior. They’ll be going after companies who pay bloggers to endorse their products without disclosure.

Is it unethical? Of course it is. There’s a big difference between caring about a product or company for its own sake and caring about it because you’ve been paid to. Penelope may dance around this by saying she only picks good companies but that doesn’t change the fact that she failed to disclose a paid relationship. Her estimation of a post’s value after the fact doesn’t excuse the lapse, either. This kind of ends-justify-the-means rationalization is the hallmark of a crook.

It doesn’t matter if the conversation is between a newspaper and its readers, a blog and its subscribers or a friend and a friend. When one party is giving advice that could be influenced by an outside force, it is essential that the influence be announced openly. Anything less is simple dishonesty.

Anti-lesson: It’s fine to build a loyal readership and then sell their attention without disclosure. The rules of ethical behavior only apply to old media. You make your own rules — honesty is less important than cash money.

The real lesson: Don’t build trust and then quietly sell it for money.

Don’t Do What You Love — Do What is Easy Based on Your Existing Resume

“One of the worst pieces of career advice that I bet each of you has not only gotten but given is to ‘do what you love.’”

Yeah, she said that. Supporting evidence: “I am a writer, but I love sex more than I love writing. And I am not getting paid for sex.”

Trunk even had a talent for combining these things, writing “the best sex scenes” her writing professor had ever read. She gave up on her erotic literature career, though, because she believed it wasn’t important enough work.

“So if you are overwhelmed with the task of ‘doing what you love’ you should recognize that you are totally normal, and maybe you should just forget it. Just do something that caters to your strengths. Do anything.”

Hmm. So because Penelope can’t do it, there must not be any way at all to find a way to build a life and career around what you love, huh? Because you can’t immediately find a way to make your work impressive to other people, it must be impossible to find greatness in it?

Bye, Adam Savage. You love scifi, building things and using your imagination. Can’t think of any way you can parlay that into an enormous, satisfying career. Be a bricklayer.

Bye, John Gruber. You love details, design, Apple, and writing. There’s no way those things can possibly come together as a lucrative blog that lets you be your own boss. Go scrub toilets.

Bye, Phil Tan. You love music? What do you think you’re going to do with that? Go buy some CDs or something.

Bye, even, to my mother. Someone who didn’t even have the benefit of a complete high school education somehow found a way to turn her love of animals into a career that let her be her own boss while keeping me fed, clothed and housed my whole childhood. Seriously: there is not a thing this woman loves more than animals, as her past ownership even of ostriches will clearly demonstrate. The result of that and years of hard work is that she’s the best pet groomer in whatever city she’s in, bar none. She can do that because she cares about her clients’ animals in ways that other groomers, just paying the bills, never could.

I guess she should have just gotten a retail job and stuck with that, right, Penelope? Hey, you said do anything.

Anti-Lesson: Don’t do what you love. It’s hard! Since Penelope Trunk never figured out how, you shouldn’t bother, either. Instead of dedicating yourself to something you’re great at doing, absolutely love doing, become the founder of an also-ran social network for young people that provides none of the value of its competitors while alienating the sort of older, more accomplished professionals those young people need to meet.

The real lesson: Your passions give you deep, generous, unique insight into specific problems. With some luck, a little imagination and a ton of hard work, you can focus your career around the things you care about. There’s a significant chance that career will matter a whole lot more to you than just “doing anything.” You’ve got a better chance at finding happiness in work you find meaningful rather than trying to fit into roles that other, faceless people will deem great.

Does Penelope have a strong writing style and a compelling blog? Absolutely. Does she have a gripping sense of honesty and transparency? Sure. But let’s be clear: as a vendor of career advice, she is a charlatan. If a career of settling for second-best, letting other people decide the value of your passions and giving up on your dreams is what you seek, then you seek Penelope. If you want your self-worth to be short-changed, then get yourself over to Trunk. If you want to improve your brand image by writing psychotic screeds against nobodies in Ohio, then boy, do I have the role model for you!

In the final equation, the case of Penelope Trunk is a sad one. By letting other people decide what matters, what’s important, she took her passions out of the driver’s seat of her career too many times. By worrying constantly about other people’s estimation of her potential greatness, she condemned herself to a life of mediocrity. Her blog and its continual churn of the latest misery, the most recent stress, is a chronicle of the results of those decisions. I don’t want that to be me.

Trunk needs to do everyone a favor, herself included, and cut the career advice crap. She is at her best when she writes about herself. The drama queen schtick all on its own is more than enough to build content around. Her sycophantic hoards of hysterically, irrationally loyal commenter fans are evidence enough of that. While her bad choices make for poisonous, self-defeating career advice and a needlessly stressful life, they nonetheless make for entertaining, instructive, even inspiring reading. That’s a great focus and the best part is that it doesn’t presume to be qualified to tell other people how to manage their lives.

I have met men and women who have done incredible things. I have found role models in people who came from nothing, who had nothing but passion on their side, and who now spend their days being paid to do incredible things they absolutely love. It’s real. It’s possible. But I, for one, will never find that place by listening to someone who says I can’t. Who comforts herself by telling you that you’re not good enough. That’s poison. That’s quitting before you start. That’s being someone else’s person, fitting into someone else’s expectations, living someone else’s shortcomings, instead of being who you yearn to be.

My advice? Don’t listen to me. Don’t listen to anyone who tells you things online. Make your own decisions based on your own values, your own passions, your own drives, your own strengths. If you must, get advice for managing your life’s direction from people who know you, who care about you, who you can trust. Most of all, get it from people whose lives and careers approach a level of sanity and stability you’d like to emulate. If you must get advice on running your career from the internet, this is the only source I’ve seen with viable information:

Merlin Mann and John Gruber at SxSW ’09. They’re talking about blogs but their advice is broadly applicable to any career where you choose to do what you want to do.

Final advice, which you also should not take just because I’m saying it: Instead of writing comments on someone else’s blog when they piss you off, write your own post. Your content is yours — don’t fuel someone else’s blog with it. That’s their job. Also, don’t wait years to write that post. You’ll be stuck writing a long-ass screed like me.