I hate design portfolios because they are a symptom of a myth that helps no one. The myth is that a designer’s portfolio somehow gives you insight into how well that person does their job. This is about as true for a portfolio as it is for a resumé. Neither tells you the important information about a person, and if you are thinking about hiring a designer you should be aware of what you’re not seeing.

Myth: The portfolio showcases the designer’s sense of style.

If the designer is at all experienced in their field, their portfolios will represent their clients’ tastes more than their own. Any creative professional who imposes their own style onto their clients isn’t doing their job very well. Every client needs something different, and portfolios do the injustice of removing the work from the context of the project or brand identity it was meant to be a part of. The designer used their judgment to create something that suited the needs of their client. They may not even like it very much, but that doesn’t mean they didn’t do their job well.

Myth: Great designers will make a great portfolio for themselves.

The slicker the portfolio, the more time the designer has on their hands. Think about that for a moment. A talented designer in high demand is using their creative energies on their clients, not themselves. This is why you see spectacular portfolios on people coming right out of school. College gives you the time to fritter away tweaking your personal site, but the real world doesn’t. Most top designers don’t even maintain one (Jeff Veen, Amy Hoy, and Jesse James Garrett, among others).

Myth: An attractive portfolio indicates a good designer.

Have you ever worked hands-on with a designer? If so, you probably understand that the final work is a product of their ability to work with you and to extract the essence of what you need from your head. A portfolio is a bunch of static images on a page. It doesn’t tell you one whit about their ability to work with you. This is why people test drive a car before buying it. It’s not enough for the car to be beautiful; it has to work the way you want it to or you’re just going to be unhappy with it.

Myth: The portfolio shows you what a designer has worked on.

Wrong, wrong, wrong. The portfolio shows you what a designer has worked on, and is allowed to post publicly, and has actually shipped, and is visual in nature. This is likely a small portion of what they have actually done in the course of their career. Sometimes a designer sells all rights to a work and can’t use it for self-promotion in any way. Sometimes (often) the project they worked on never saw the light of day. And let’s not forget the important fact that most of what a designer does is research. They talk to their clients, they analyze competitors, they draw diagrams and sketch and make flowcharts. None of this critical planning makes it to the portfolio, but could easily represent six months of work.

Okay, so how the hell do you hire a designer then, if the portfolio is so useless?

The same way you hire anyone. Treat their portfolio like you do a resumé. It’s a good start for screening, but it doesn’t give you enough information to decide between qualified candidates. Try conventional hiring approaches to get a better sense of who they are.

1. Have a quick interview with the designer. They should be willing to answer some questions over email or the phone. It almost doesn’t matter what you ask them; what matters is how well you can establish a comfortable conversation and mutual understanding.

2. Google their name and look for blog entries or articles they have written. You can learn a lot about a person this way, as well as gain a sense for how they approach their work. Are they active in communities related to their field?

3. If hiring for a long-term position, try a trial project or contract-to-hire situation. (Thanks Daniel Jalkut for this idea.) There’s no substitute for actual hands-on experience working with someone. But be aware that not everyone is willing and able to do this sort of thing, and it shouldn’t be a strike against them if they aren’t. It’s a more situational evaluation tool.

4. Ask for references, and actually contact them. You can afford a few minutes to fire off some emails, and this feedback can be critical to your decision.

A word to designers

Ya know, I hate to say it, but portfolios are still a necessary evil, at least until you are famous enough that your clients are willing to take it on faith that you’ll do a good job. But responsible clients will want to see more than that.

Don’t sink all your time into it. Don’t redesign it constantly. Start simple and keep it simple. Make sure you have a traditional resumé and keep it linked in plain sight. When you can, give a few words of context about the project. And then let it go. Focus on your work, not your image.

And on that note, I should get back to it. I promise I won’t work too hard on it. After all, I’ve got better things to do.

Chapter One: Rates and Finances

Rule #1: You have to budget.

The first thing you should do (nay, must do) is to sit down with your favorite spreadsheet application and write up a budget. Figure out what your monthly expenses are, how much spending money you’d like to have, how much you want to save, and the cost of your health care (either estimated expenses or private insurance if you’re buying it). Add them all up and divide by 0.6 to account for taxes. Voila! That number is about how much you should aim to earn per month.

Remember this number. Cherish it. It’s your new best friend. Look at it when you get anxious about money - it will comfort you.

And I hope you caught that bit about taxes. You don’t have a company withholding money for you anymore, so you’ll have to be responsible in order to be ready when April comes around. Don’t worry though, I’ll explain how to prepare for that in a little bit.

Rule #2: Don’t work forty hours a week.

Now, what I mean is that you shouldn’t work forty billable hours a week, especially if you maintain multiple clients at the same time. There are a few reasons for this. First, people are simply not productive for that much time. It’s required in an office because of the inevitable inefficiency that happens in any company of reasonable size, but you are independent now and you can be a lot tighter about when you work and when you don’t. Work when you’re productive, rest when you’re not. What a novel idea!

Second, you should plan to spend about 5-10 hours a week doing off-the-clock work. This includes finding potential clients, writing estimates and contracts, and networking with your peers. This is absolutely essential to your success and if you don’t give yourself time to do these housekeeping tasks it won’t be long before you’re burned out and signing up to flip burgers at the local In-N-Out.

Rule #3: Be pragmatic about your rates.

Many people struggle with setting rates, especially as it can be difficult to figure out what others in your field are charging. A good starting point is to take your current salary, convert it to an hourly number, and multiply by 2. (Note: a commenter below points out this should be closer to 2.5 or 3. This is more in line with what your company pays for you and is necessary if you have overhead to cover. When in doubt, take the higher multiplier. It is far better to start high and adjust down than to start too low and have to scramble to make up the difference.)

Divide it into your magic number from Rule #1, and then divide by four to find out how many hours a week you’d have to work to make your target. You should be aiming for 20-25 hours a week, so adjust accordingly. If you want to work less, you have to charge more. If you want to (or have to) charge less, you have to work more. Work out an ideal balance that you’re comfortable with.

Now get out there and find some clients. The only way to find the sweet spot with rates is to do some actual work and collect data. Note the kinds of companies that you’re working for — you will probably find that smaller companies have less money in their budgets but more work to offer. Bigger companies often come with good rates but a lot of overhead. Many consultants have a sliding scale depending on the size and visibility of the company. Over time you’ll naturally develop a small range that gives you some wiggle room for negotiation.

Rule #4: Don’t be afraid to negotiate.

When quoting rates, always start high and negotiate down. I’m going to teach you a trick of sorts that can be used when a client is gunshy about your rates. Read the interaction below for an example of this trick in action.

Let’s go over what has just happened. First, Joe now has a data point about his rates. XYZZY was a little nervous about $75/hour. That doesn’t mean he should lower his rates for all clients, of course. But it does help inform his decisions about XYZZY or companies similar to it in the future.

Second, let’s discuss why Joe got a good deal even though he lowered his rates. Notice that he negotiated from an hourly rate to a flat rate - $1,600 for the whole job (up to 25 hours). In some ways this is a false discount for the company. It’s only $65/hour if he takes the full 25 hours to do the work, and if Joe is smart about how he uses his time there is a good chance it won’t actually take that long. He was also careful to quote the upper bound to the client. If you think a project will take 20-25 hours, always quote them 25. It’s good “potentially saving your ass” practice.

So let’s say he really boogies and it takes him 20 hours to finish the job. Doing the math, we find out Joe got $80/hour for that work, even higher than his original estimate. And the client is happy because they got it done on their budget. Everyone wins.

Now let’s say it really does take him 25 hours or more and ends up being $65/hour. It’s not such a good deal anymore, right? You might be surprised. Keep in mind that every client you have brings some amount of unbillable overhead in the form of communication, estimates, and contract writing. This means there is an advantage to taking fewer, longer projects. The fact that Joe now knows he will get at least $1,600 for his time is worth something.

Let’s take a detour and quantify what a longer-term contract is worth. I usually estimate about 5 hours of overhead for a new client. That includes the work I do to get that project rolling as well as the work I have to do to find them. At Joe’s rates this is about $375 worth of his time. He’s essentially saving himself this money in taking a steady project, so it is still worth it to him even if he has to lower his rates a little.

Of course, this isn’t quite as cut-and-dry as I’m making it out to be here. There are many factors that go into what you charge for a job. Here are just a few possible scenarios:

1. Web design for John’s startup. John is a friend of Joe’s and his company doesn’t have a lot of cash. Joe decides to discount to $60/hour.

2. Building a CMS template in PHP for a local school. Joe really hates PHP and quotes $120/hour, because that’s what it would take for him to actually do it.

3. Design contracting for BigCorp, Inc. Joe raises his rates a little to $85/hour, because he knows the large company can afford it and he has to deal with their annoying marketing team.

The more work you do, the more you’ll know how far you can push different kinds of clients, and how much you believe your time is worth. Use your monthly magic number (see Rule #1) as a guide, and remember that you’re free now to make your own choices about what you earn. No more begging for raises - you just have to earn them yourself.

Rule #5: If you’re not turning away clients, you’re not charging enough.

This is related to Rule #4. Negotiation is good and can improve your relationship with the client. However, if you find that you’re negotiating a lot and not often getting jobs at or above your target rate, you probably need to toughen up a bit and push harder for the higher rates. Some clients won’t be able to afford you and will go elsewhere. However, assuming your rates are fair and appropriate for your experience and work, some will stay and pay it. You never want to be in the situation that you are known for your low rates. Competing on price is the kiss of death.

Think of it as a form of supply and demand. The more you work and the more experience you have, the more your time will be worth. Your rates will go up over time to match the increased demand for your services. Think of it as a promotion, indie-style.

Rule #6: Give yourself a salary out of the “company” bankroll.

One final rule that will help keep you prepared for tax season. You probably want to set aside about 40% of everything you earn for taxes. One way to make sure that you do this diligently is to deposit your checks into a “company” bank account. (You did set up a fictitious business name, right? Of course you did!) Give yourself a “paycheck” out of this bank account once or twice a month, making sure to leave at least 40% of what you earned. If you find that you need to take out more than that to cover your expenses, you need to go back to Rule #1 and revisit your budget. Maybe you need to work more hours or ask a higher rate in order to make your target.

If you’re feeling saucy, you can use the company bank account for business-related expenses as well. Come up with a fair wage for yourself and leave everything else to reinvest into the company — purchasing advertising or office supplies, for example. Working for yourself takes discipline, especially financial discipline. Keeping your accounts separate is a good way to establish a mental boundary between what you earn and what you actually get to spend.

And as a corollary, doing your taxes as an independent is extremely complicated. You will probably want help in the form of a small business accountant. They can help you plan, deal with expenses and invoices and keep your taxes under control.

***

Well, that was a hefty chapter! But finance is a hefty topic when it comes to being your own business. The next chapter will cover writing contracts, details of invoicing and payment, and making sure your butt is covered legally. Feel free to leave any comments or questions you might have and I’ll try to answer them here. Angry tirades also accepted. Everyone is welcome!

That’s all for now. See you next time for Chapter Two: LeChuck’s Revenge.

Hair gel and bobby pins: $7.

Package of corn starch: $3.

Dressing up as your favorite liberal pundits: Priceless.

Colin doing his “Keith face.” If only one picture could capture the act of wadding up a piece of paper…

My “Rachel face.” Things I have that Rachel does not: a billion bobby pins in my hair. Things Rachel has that I do not: jackets that fit, and a TV show.

The news better run!

This editorial interested me because I struggle with the same issues as a designer at Google. I’ve watched the web 2.0+ world evolve around us, but our design mentality remains rooted in the early days of the web. Black text, white background, blue hyperlinks. And it’s not just Google and Jakob Nielsen - this aesthetic persists all over the web, despite many designers’ attempts to banish it forever.

Speaking for myself, the sites I use every day are still very much in line with Nielsen’s view of good usability. Google web search, Gmail, Reddit, Wikipedia, Twitter. Black and white and blue all over. Why does it work?

The interface needs to stay out of my way

Every application has a function. Assuming that function is well-implemented and something that I need to use, I will want to use that application. The interface should only be a tool that helps me get to that functionality. The moment I have to think about the interface - even to marvel at how cool the drag animation is - the application has failed in it’s primary purpose. It exists for the function, not the design.

“Now Anne,” I can hear you saying. “What if the point of my application is the experience? My Flickr/YouPorn/Facebook mashup is super-slick and fun to play around with. I get like ten thousand hits a day!”

Okay, yes. These apps do exist, and should exist. They can be anything from neat toys to richly detailed digital adventures. I’m not really talking about these kind of apps, because a user isn’t really trying to do anything with them. They are there simply to experience it.

When you have problems is when you get the bright idea to make your practical application, say a webmail client or a news aggregator, and make it “experience oriented.” A rich, novel interface can certainly give your site impact and memorability. I might tweet about how cool it is and it will probably generate a lot of interest and hype. These are good things, but they reside in the sphere of marketing, not usability. Designing for the launch is a mistake. Getting people to log in on day one is only half the work; getting them to stay is the other half. You want them to come back every day and the novelty of the rich user experience is only going to last so long. When it wears off, can they do what they need to do on the site quickly and easily?

Yes, latency is still an issue

…unless your target demographic really is rich, technologically savvy people with fast internet connections in the United States. Hey, it might work if your margins are really high, but if you’re writing a web app, chances are good they aren’t.

Reddit is… well, Reddit, but I keep going back to it as a source of things to read because it does what it does and stays out of my way the rest of the time. It is literally just a list of links on a page, which is exactly what I’m looking for. I want a service like that to load instantaneously, because I’m likely to hit it many times throughout the day. Waiting for an image to load annoys me. Waiting for a page full of them makes me want to go somewhere else.

If your app is going to have a rich artistic element, it had better damn well be customizable

Imagine if Apple set your desktop image for you. You use your computer every day, and even if it was the most beautiful photograph in the world, you would get pretty damn tired of that image. This situation sounds ridiculous when talking about client products because it’s well known in that world that customization is an important part of a happy user experience. I don’t understand why web developers haven’t picked up on this yet.

iGoogle is a good example of how to do this right. This is an application you’re meant to keep open in a tab all day while it pulls in news feeds and tracks your email and whatever else you configure it to do. When they realized iGoogle wasn’t exactly the prettiest thing to look at, they added user-customizable themes with colorful, rich banner images behind the Google search box. Even better, the image changes throughout the day, so every time you click over to that tab to check your email you might see something different. The end result is that it takes a while to get sick of a theme, and when you do you can always just switch to another one.

User experience is not all about the clicks, but revenue is

You don’t have to take my word for any of this, you know. You can use any number of free tracking tools (Google Analytics and Website Optimizer are my favorites) to learn more about the behavior of users on your site and run experiments with the design. Usage statistics certainly can’t tell you everything - they can’t tell you if your users are happy, for example. And there are some pretty ugly and/or misleading things you could do that would almost certainly increase the number of conversions on your site. I’m not trying to tell you to do these things. The negative impact to your overall user satisfaction and brand would not be worth the increase in clickthrough.

Even still, you have to be running these numbers and aware of them if you want to be an effective designer. “But the green links make users feel good!” is not an effective argument if blue links increase clickthrough by 5%. ROI is not a dirty word; embrace it, and if you keep a record of the data you collect and the tweaks you make, you’ll have a lot of ammunition handy when talks of a redesign come up. The first question you should ask is “What problem are we trying to solve?” and the second is “How can we prove that we solved it?”

The moral of the story

“So Anne,” you ask. “Can I use images or what?” The answer is, it depends. Pretty graphics and colors and AJAX and slickness are all great, when they don’t get in the way of what your app is supposed to do. No matter how you approach it, things that are clickable should be easily identifiable as clickable. Things that are meant to be read should be clear and easy to read. I’m stating the obvious here because it is the precise reason the text + hyperlinks paradigm is powerful and shouldn’t be overlooked.

Just look at Wikipedia. In many ways, it is the perfect web application. How empowered do you feel when you use that site? You have easy access to almost anything you could ever want to know, and anybody who has used a computer in the past twenty years can figure out how to navigate it. Even my grandmother knows blue underlined text is a hyperlink. It’s a big flag that says “you can do something here!”

Now, I know you need AJAX and pretty gradients and buttons to make your webmail client usable and attractive. Do what you have to do to make it work, but at that point you might want to ask yourself if the web is the appropriate platform for that application.

Remember, design is equal parts marketing and usability; approach it as such. Be pragmatic. Don’t mindlessly decorate. And don’t be afraid to use what you know works - even if you are in danger of Valleywag calling out your “so 1990s” design. Own it!

As a side note, it’s amazing how many of these stories begin with the Apple ][. But more about that later.

How old were you when you started programming?

I suppose that depends on how you define programming. I was eight when I wrote this little gem in AppleSoft BASIC (the referenced "Sarah" is my older sister):

10 PRINT "SARAH SUCKS"
20 GOTO 10

I'm not sure if you can count that as programming, however. It's more like electronic vandalism. (Watching her figure out how to stop the loop was always fun.) I also liked to make pictures on the Apple ][ monochromatic greenscreen by painstakingly plotting every point; again, this "program" can only dubiously be labeled as such. At the time, I didn't even know how to save my work, so they were all blissfully transient.

BASIC nuisances aside, the first program I wrote that a normal person could actually use without having to shut off their computer to stop it was a calendar application I built in PHP many years later. I was 19.

How did you get started in programming?

It all started with this machine, still in usable condition over twenty years later: the Apple ][.

These pictures were taken only a few months ago in my parents' basement. Depicted is the ineffable Colin Barrett poking through the user's manual and trying to get it to load AppleSoft; unfortunately, the floppy itself had long since gone bad. In an era where most of us get an AppleCare plan on anything and everything, it's pretty amazing to think that this machine has outlived the very media that its operating system is printed on. But I digress.

What's amazing about the Apple ][ (and // and other related models) is that it provides excellent affordance for programming. As soon as you boot it up you are provided with an inviting, blinking cursor, a prompt at which you can type straight-up BASIC and be immediately gratified with a response. The built-in BASIC interpreter was probably the single most influential factor on my technological growth, and judging from the articles others have written I’m not the only one. Think about it; in today’s era a child using a computer has to take several complicated steps to get to an environment in which they can program. Back then, all you had to do was turn on the machine.

What was your first language?

BASIC and Logo. I learned both from a children’s guide to programming (unfortunately I can’t remember the title anymore).

What was the first real program you wrote?

The first “real” program I wrote was a trivia game written in BASIC when I was about ten years old. The user could input their name and then answer a series of multiple-choice questions, mostly about animals or science. Since the whole program operated on GOTO loops (hot tech, I know), getting a question wrong meant only that you would go back to the question and get another opportunity to answer. It was therefore impossible to get to the end with anything but a perfect score. It was, uh… a very forgiving game.

What languages have you used since you started programming?

BASIC, Logo, Pascal, C, HTML, JavaScript, AppleScript, ASP, PHP, Ruby, Python, Objective-C. As you can tell, my experience is definitely skewed towards web development and the Mac OS.

What was your first professional programming gig?

My first real job in college was working as an assistant webmaster for the school of Mechanical and Industrial Engineering at the University of Illinois. I had been making web pages in my free time for quite a while, but this was my first exposure to web programming. I was mostly hacking on existing ASP code the previous webmaster had written. It was scary, to be sure. I was an English major at that point and considered myself more of a designer than a coder. But reading and debugging this person’s code was actually a great way to learn, and I put myself through college with various HTML/ASP/PHP web development positions.

If there is one thing you learned along the way that you would tell new developers, what would it be?

I want to re-state something that Aaron Hillegass often says in his book Cocoa Programming for Mac OS X. This is hard work. It’s tough thinking and sometimes the problems are hard to solve. But you are not stupid. Repeat that to yourself. You are not stupid. Don’t give up before you’ve even given yourself a chance.

I feel that what keeps most people out of programming is fear. Fear that they will fail, that they’re not smart enough, that they don’t understand what makes the computer go. You need to understand that it’s not a strange new world; it operates by predictable rules in a predictable system. Learn the rules and use your brain. Don’t be afraid to think, and don’t be afraid to take risks.

And finally, don’t bite off more than you can chew. Any learning process is best taken one step at a time. Learn to type before you code.

What’s the most fun you’ve ever had programming?

That would actually be quite recently. As much as I love engineering, computers and problem-solving, I’ve had quite the love-hate relationship with programming over the course of my life. I’m fascinated by the power it gives you, but often appalled by how it is implemented. “This isn’t intuitive at all!” I would exclaim whenever a particular programming language’s syntax confused or frustrated be. Syntax in general has been a large barrier for me, and as a result I’ve often avoided programming whenever I could.

But then, in April of this year, I came across a project at Google that demanded automation. There was simply no other way to do it. I needed to generate over a thousand static HTML files and over four thousand screenshots across 14 languages. It was the largest marketing campaign we’ve ever done. And I needed to do it in just under a week, also accommodating time for QA and bug fixes. Doing it by hand was simply not an option.

I turned to Colin and said, “There’s a way to automate this isn’t there? There has to be. Otherwise it’s just not going to happen.”

He knew of a FireFox extension that could be accessed from the command line to take and save screenshots, so that’s where we started. He showed me some Python; it was my first exposure to the language. But Python is Python, and I was up and running within hours. And much to my surprise, I loved it. I took to it immediately. It was stupid, procedural programming, and certainly didn’t take advantage of Python’s more sophisticated OO features, but it worked. Within a day I had a script that processed the data files out of the spreadsheets they were in. In another day I was running one that would open the URL in all the appropriate languages (command line), take the screenshot (FireFox extension), open the screenshot in Photoshop and run an action on it for cropping/resizing (AppleScript), save the file and scp it to the proper location on the server (command line), and then move on the next one. Python was the glue that held all of these parts together; os.system was my friend.

A few days later I had made HTML templates that represented the static files in the project, and had another script which inserted the proper strings for all the languages and send the generated HTML files to the server.

For perhaps the first time since I was eight and using BASIC to harass my sister, I was really enjoying programming. It was empowering me. I didn’t feel trapped by it; Python is a beautifully intuitive language and quick to learn. And if I got stuck, I could ask Colin or find resources online. I realized what a large support network I have for programming, and how valuable of a resource that is too. It was wonderful.

And it worked. At the end of the day, the campaign launched successfully worldwide, when by any other means it would have been impossible.

Since then, I’ve had a better relationship with programming. I respect it, and I feel like I know how to make it respect me. I also know better how to approach learning it, and understanding it. And I know now that it’s worth it.

Phew. Sorry to ramble so long, but this is actually a subject quite near and dear to my heart. It’s an important part of my history and even my identity. Now then, here are a few people I would like to hear tell their story:

Mark Dalrymple
Aaron Hillegass (a pipe dream, I know… but I’m sure he has a good story to tell)
Mike Lee
Joe Heck
Jonathan Wight
Victoria Wang
Elliott Harris

I’ve done some fake anti-aliasing to soften the edges, so these icons will look best on a very light or white colored background. They all fit into a 16×16 square and I have prepared a .png that contains them all in a grid for easy CSS sprite-sheeting. Here’s an example of how you might use these in a webpage, and here’s the sprite sheet with all 36 icons. Feel free to use them however you please.

Enjoy!

And if you’re looking for an easy way to manage your custom icons I highly recommend CandyBar by Panic. It’s fun to use and will work with the sets at the Iconfactory as well as the .icns files I’ve posted here. Enjoy!

P.S. I’ve gotten a few requests for other icons in this style, but these are the last ones I’m going to do. Arcade Daze rightfully belongs to the Iconfactory, so we’ll just have to anxiously await the next application set!

Cyberduck, iTunes and NetNewsWire icons

Enter ExpanDrive (MagnetK, $29). This nifty little app is built on the MacFUSE core (but uses its own proprietary file system) and allows you to mount any directory as a drive over SFTP, and it looks and behaves like one with the help of some aggressive and intelligent caching. I set it up to point to my home directory and created a TextMate project for a good 1,000+ files and it worked like a dream - I never noticed any lag and it didn’t beachball like crazy when I switched focus off the app.

What I love most about it is how invisible it is. It was clearly designed to make me forget that I’m working on a remote drive, and allow me to interact with it as though it were on my local computer. It succeeds beautifully at this, and after only a week of use I already can’t live without it.

You might ask what it has over MacFusion, a free open-source app that allows you to interact with SSHFS in much the same way. MacFusion is also a great piece of software, but it doesn’t do any caching or automatic connection management. The result is an experience that is a lot less invisible, and you will still see plenty of beachballing apps if you try to do a lot of live editing. Still, MacFusion will definitely do the trick for many different kinds of work, and it’s worth trying out both to see what works for you.

As an interesting side note, ExpanDrive is written in Python with only the GUI in Objective-C.

I myself grew up quite pudgy and have always been so. I was a stubborn mule about it too. Even though I knew it was unhealthy and I was unhappy looking the way I did, I refused to do anything about it, both out of laziness and the ridiculous notion that being concerned with my physical appearance was somehow shallow. For years I trudged on this way until I realized, as many people in my aging generation are starting to, that my lifestyle could go on forever, but my body certainly wouldn’t.

So earlier this year I made it a resolution that I was going to get myself to a healthy size and stay there. I signed up with a clinic specifically designed to treat obesity, and started a four month program over the course of which I lost about forty pounds. By no means am I out of the woods yet; any behavior change takes time, and I’m attending courses on weight maintenance for the next six months just to ensure I don’t return to my old Mountain Dew-swilling ways and gain it all back.

It has been an experience the likes of which I can’t adequately describe here (but I’m always happy to talk about it if you ask). But I have learned a few basic things that I thought I would share, as someone who’s been through it.

Five things you probably already know about weight loss (so no more excuses, right?):

1. Reduce the number of calories you eat. I don’t care how you do it - give up sugar, give up fatty food, portion control. Whatever is easier for you. Your body only needs a certain number of calories a day to keep you going (approximately your weight in pounds times ten) and if you routinely exceed this number, it will start storing the excess energy as fat. Keeping a food diary is immensely helpful - I highly recommend calorieking.com.
2. Exercise frequently with low intensity. Find something easy and enjoyable that you will do every day for 20-30 minutes and do it. This will help keep your body burning fat for energy instead of muscle. Just don’t push yourself too hard or you’ll actually start burning glucose stores instead of fat, which will only make you feel hungry.
3. Drink at least 2 quarts of water a day. Not only does it help you fight fatigue (a common symptom of dehydration), but it also serves to make the fat-burning process more efficient. Flavored water counts, but black tea and coffee don’t - and watch the caffeine.
4. Eat lots of lean protein. White fish and white meats like chicken and turkey breast are low-fat and relatively low-calorie. Even better, they are loaded with protein, which will help you feel full even if you’re cutting calories.
5. Don’t let yourself get really, really hungry. If you’re dieting, you will be hungry from time to time. What you want to avoid is the situation in which you let yourself get absolutely starving, and then start making bad decisions about food. Eat a healthy snack in between meals, or eat smaller meals more frequently.

I won’t lie and say that it’s easy, but it does get easier. 90% of the battle is education. If you’re interested in learning more, I recommend The New Fit or Fat and Thin for Life. Both are fairly technical and don’t have too much of the usual pseudoscientific nonsense.

And if you’re trying out a Wii Fit, let me know how it works for you.

Yeah. This stuff is in my blood. It’s probably in yours too, if you’re reading this.

Old Mac users have more than just a shared history. We have intense cultural pride. There were times when it was a 45-minute drive just to get to a store where you could buy Mac software. I can’t even imagine what it must have been like to try to make the stuff, much less sell it. While I was milling around the SFMacIndie party at Jillian’s last night I was astounded by the sheer number of developers there. There are people who converted because of the excellence of the developer tools, or because they see opportunity in the market, or because they are attracted to the explosive growth of the iPhone. Actually, these are all pretty legitimate reasons to develop software for a platform. It’s not just folks doing it for the love of it anymore.

There’s no way this is a bad thing. More developers means more choice, more innovation and a better experience for Mac users everywhere. It’s just different, and it’s easy to be wistful for a world that has gone by.

To me, the rainbow logo is the icon of the Old World of Mac. The world of Mac that I fell in love with is different, both simpler and more complex, than the glossy technoporn world we know now. So I’ve decided to take it back (with all due respect to Clerks 2). I want to remember the richness and color of that shared history, even as we move forward into what looks to be a Golden Age for the company who’s products have shaped my life in so many ways. So henceforth I’ll proudly display the old logo in place of the new one wherever I can, as a simple homage to the culture that brought us here.