Developer. Front End Dev. Designer. User Interface Designer. Javascripterino. We all have a place in the WordPress ecosystem. We contribute to core, the plugin/theme repos, help out on forums and attend WordCamps. There’s a new kid at the pool, and he’s ready to mix it up a bit. The Amalgamator.

Making things easy… too easy?

WordPress lowers the bar for creating digital work. It began by lowering the bar for content publishing, and has grown to enable users with relatively low technical skill sets to create remarkably powerful websites. This is one of the key reasons it succeeds as a platform. This ability to take mere mortals and make them website creating superfreaks is its most promising attribute. They can buy hosting, and one click install. They can hit up Themeforest and grab one of a million themes. They can peruse the plugin repo and configure the crap out of a settings panel. They can crop a logo in Photoshop, and set hex colors for links. They bootstrap stuff together using whatever combination of plugins, snippets and duct tape that they can find.

They don’t know what they don’t know

Amalgamators don’t know PHP. They could browse the codex but not know what the crap it means. They certainly don’t know how to properly enqueue a javascript file. They know copy. They know paste. When something goes wrong, they come looking for your email, support forum, and twitter feed.

You and I may scoff at this skill set. If you’re in the deep end of the pool, these amalgamators seem like needy, whiny jerks with no sense of appreciation for your hard work. Think for a moment about how their friends, family, and clients see them. Remember the average person doesn’t know what an .htaccess file is and couldn’t give two shits about it. WordPress has enabled these Amalgamators to create incredibly powerful, beautiful, and feature rich web sites. “You’ve got an idea for a terribly doomed to fail Pinterest clone? Great, let me show you my dear friend BuddyPress and 15 different plugins and this $45 theme. You dream the dream, and I can make it happen.”

The Gall!

We may see that as hubris. But frankly, that’s besides the point. When we nerd out about WordPress taking over the internet, it’s these Amalgamators that are making it happen. They’re the ones supporting the premium theme marketplace, and the burgeoning plugin marketplace. When a corporate middle manager sees his grandmother rocking a WordPress blog, and he needs to pick a cms for that big budget upcoming gig, do you think he’s going to favor Drupal?

We can look down on these Amalgamators, and dismiss them as annoying noobs. But I see myself in them. I see people that have drunk the kool-aid. They want to build wonderful things, just like we do. They want to help their clients achieve their dreams, just like we do. They want to do good work, just like we do. Maybe they’re over reaching, but I respect that. We do it all the time too.

I am trying to find a way to embrace these folks. Our own success is tied to theirs. We may not be able to help every one that posts on our forums, but we can respect all of them. I can give them props for dreaming the dream.

Amalgamators. We salute you. Welcome to the pool.

Peter has been yammering on and on about Daniel Kahneman’s book Thinking Fast & Slow. Rather than read the book, I hit up the Ted talk instead. Kahneman’s examination of the delta between experience and memory is rocking my socks off right now. The video was posted in 2010, so you know I’m right on the cutting edge here.

Here’s the gist in case you don’t have time to settle in for a complete viewing. There’s essentially two versions of me. The experiencing self – that’s the me that is actually chowing down on a delicious burger. The remembering self – that’s the me that is sitting back reviewing my instagrams memories of that delicious burger that I ate. According to Kahneman, these two versions of you have vastly different perceptions of happiness, and consequently different perceptions of pain.

“We don’t choose between experiences, we choose between memories of experiences. Even when we think about the future, we don’t think of our future normally as experiences. We think of our future as anticipated memories.”

His example paraphrased – You’re at a symphony, listening to beautiful music that you love for an hour. At the end, there’s an incredibly unpleasant loud shriek. You leave the evening and exclaim “my night was ruined.” When of course, you experienced 60 minutes of pure joy, and but a few minutes of unpleasantness. Your experiential self loved 60 min hated 2 min but your remembering self can only take away the completed story. It’s a solid explanation for why we’re all staring at our camera phones during life’s precious moments. Record and capture. It’s a technicolor memory on demand in my pocket that has a greater impact on my perception of happiness than the very experience itself.

How can we take this kind of understanding and apply it to what we do? We have long raging internal dialogs about how to create tools that delight our users. But I wonder if we get hung up on designing only for the experiencing self, and forget to pay attention to the take aways that the remembering self will leave with. How do we create not only delightful interactions, but delightful memories? I can see how a single UX fail could ruin an otherwise delightful experience, but how do I flip that thinking around? Do I aim for a single truly amazing feature or expereince, give them enough to make a memory or create a story behind, and let the rest settle into place behind it? Should the goal be 90% not-crappy with 10% amazeballs?

If my metrics revolve around user satisfaction and they only truly remember the 10%? This goes against my natural inclination to believe that our work should be amazing all the way through. That we should detail and lovingly craft every nuance of our interface. That we should spend countless hours designing and coding custom checkboxes and radio buttons…

I wish I could leave you with some bullet points, but this one ends with a head scratchers.

The topic of RFPs came up in our local WordPress user group a few weeks ago. They eat up a ton of our time, and more often than not result in absolutely squat. Worse than that, often I get the feeling that we never really had a shot at it in the first place. The evils of the RFP process have been well documented, and I don’t need to beat a dead horse.

For context, I just finished a proposal in response to an RFP. Between the four of us, we spent 4 hours on the phone with the client, 15 hours working on a vision and estimate, 6 hours writing the actual proposal and that was swift. It can be a ton of time. In our eyes, if you are going to go for it, then really go to go for it. Not giving it everything you got pretty much guarantees what ever effort you do give it to be wasted time.  That’s a whole lot of time that I could have been napping (or doing something else productive). So how do you decide when it’s worth it?

When to say yes

Our default answer to the RFP question is, “nah, we’re cool.” That said we do respond to them on rare occasion, and have landed wonderful gigs via them. We have a very simple litmus test for whether or not we should participate. “Can I make a buddy?” If there’s an opportunity to create a personal relationship as part of the RFP process, we’ll often go for it. If the RFP process ends with your proposal in a big pile of other proposals, then forget it. If you can connect with the decision maker, and personalize your submission your odds of success sky rocket.

How do you do this?

Ask questions. Lots of em. No matter how well written an RFP is, it likely is leaving out large aspects of the work. That’s why they’re hiring. They need vision and execution. Talk to the stake holders. Find the decision makers. See what the root problem is. Ask personal questions. Think about the number of times you’ve built a tool for someone and its actual purpose was to make their own job suck just a little bit less. If people resist this process, bail – you’re not going to win. On occasion, they’ll welcome you with open arms. Suddenly, you’re not just a faceless pdf in the stack. You’re Peter, the friendly dude who took the time to get to know how the project actually effects them.

How do we win?

Ask this. Straight up. “How do we win?” Ask it 3 times. It can be an awkward question. The first time that I saw Peter ask it, the look of befuddlement on the client’s face was hilarious. But then a surprising thing happened. They told us exactly how we could win. “Actually, price and features are fungible, what we really need to focus on is our launch date because we’ve got internal pressure to ship something. The team that can propose a solution that guarantees a launch date is the team that we’re going with.” Isn’t that a handy little piece of information when writing a proposal? If you work it just right, your response to an RFP becomes your first draft at a contract.

How much you got?

Don’t guess budgets. Ask. “So, what do you guys have in terms of budget?” If at first you don’t get an answer, ask again. Ask for t-shirt sizes. Tell them the project could cost between $10k and $500k depending on the scope, scalability, etc. That gives a set of low and high expectations to start with. Tell them that you’ve done similar projects for $150,000. If they flinch, then assure them that this can be done for less. At this point, since you’ve obviously gone over their limit, they will be much more likely to let you know what they are looking for.

If they really won’t reply, you can always use Shane’s backup plan. “Oh, so $150k is too much, how about $140k? $130k? $120k?…” If you can’t get a budget range then you’re talking with someone that looks at this process as some kind of Las Vegas bidding game that they can “win”. Forget that.

What do you think?

They worthwhile? Should I just suck it up as part of the dance that we all play?

Managing Support for a Premium WordPress Plugin with Rob La Gatta

Rob’s slides has an odd malfunction, so check out the slides while you listen. This is his first public talk to the WordPress audience and we are super duper proud of him.

Managing Distributed Teams with Shane Pearlman

Often the magic of a trip is in the moments in-between. Its the personal neuroses you share as the barriers break down over the 6th beer. It’s singing wheels on the bus and painting nails with a bunch of 3 year olds. Its screwing up your best card trick while everyone is watching and playing it off with panache. Its the warning before a lightning talk that this slide deck must never leave this room and will self destruct in … 10, 9, 8 … and knowing who’s presenting, you know he’s not kidding. You can get to know people pretty well with IM & skype video. You have regular conversation. You share stories. Thought, despite all the amazing innovations of this digital era, you still need to meet people face-to-face.

Peter nailed it.

If you lean off the balcony, you can see Land’s End, where two oceans meet. Julie & I walk down to the sand following our daughter as she practices her skipping. It is early morning and the sun is cresting over the ocean. Sassy (that’s my little lady) throws her sandals off, grabs her sand toys and settles down for a proper castle building session. We ease into seats next to Reid and Darcie, after sharing hugs with everyone. Chillaquilles Rojos please – my favorite breaky ever. The horse trading starts with the partners trying to decide what to do during the 1/2 day work-session and when they could break us free to go play. Another fabulous breakfast completed, sunscreen applied, plans to go snorkeling and paddle boarding arranged for later, and we grab the crew to kick off the days session. Hot tub, check. Laptops, check. Apple Care, check. Bring on the wisdom.

Let Me Break This Down For You

Each year (except last year as we were so overwhelmed with the influx of new babies) we take our core team somewhere warm and tropical to hang out and talk shop. We are a distributed team and often this is our first chance to meet face to face with new and even long time team members. It is a family event and most people bring the whole clan. We’ve been on easy trips to places like Hanalei, Hawaii & here in to Cabo San Lucas. Two years ago brought us to Sayulita, Mexico – a bit of an adventure as we had to ford rivers and drive up some pretty intense dirt and gravel roads to hit the chick little hotel we took over. The dancing horses, mariachis, fresh made churros and fun small surf made it all worthwhile. El Salvador, where our surf rack included 4 boards and 2 shotguns was a whole other story, and the island we rented in Panama was quite bad ass. I love these trips. We so deeply believe that the entire purpose of being in business for yourself is to shape the life you imagine. We’ve shaped Modern Tribe to deliver that. I love the adventure! And if no one gets pregnant in the next few month, I think we are due for a proper adventure on the next team trip.

L’Chaim, Good Food and Fun To You

Daniel wins the contest for most brutal trip, weighing in at 43 hours due to a missed flight with an 8 month old little lass. It is a good thing that he gets to put the somewhat mighty dollar to work while living in Argentina. We sit down for an hour, with our feet in the hot tub and look at architectural plans for the 3,000 sq ft home they are about to start construction on.

The fish tacos are good. Especially the smoked marlin taco, which is a whole culinary experience unto itself. A group peels off for an afternoon to take a traditional Mexican chili cookoff course. Chorizo making. Stuffed peppers omelet thing was yummy. We hit the supermarket on the way back. They have a band in the market and a guy on a loud speaker pitching products.

The team talks are timeless. You see, you’ve got 10 minutes to teach us something… Go!

Peter gives us a tour of creating digital music using an ipad. We groom a horse with Leah, taste a flight of wine with Ryan & explore human memory hacking with Tim. Sassy decides to join me for my talk and we dive into the basic of real estate investing. Kyle clowns it up, followed by baroque music theory as a parallel to code design patterns by Jonathan, beer brewing with Lucas, and love and communication with Brad. We are lead through the journey of Rob’s food truck experiment, and why not to start your own. We really dig deep and examine motivation as we go from couch to marathon with Reid. We promised not tell you about Daniel’s, suffice to say that it was ridiculously funny. You should be here. Come the next zombie apocalypse, I have the edge up.

After a bunch of debate between a drinking bacchanalia on a pirate ship and a full seafood catered dinner and bonfire on the beach, the booze cruise looses out. The food is a remarkable surprise. All you can eat jumbo shrimp, steak, lobster,  marlin, chicken, and vegetables. The kids run around, well most crawled, and  I fire up the beach bonfire. Someone offers pink strawberry marshmallows. Not half bad. The families with young kids slowly peel off to leave the die hards and me, as my wife is being super awesome. We pull up two pineapples and grill them. I coat one in marshmallows and create a crisp candy shell. In the background the bar tender pours fire from his bottles while drunks shout in glee.

To Good Friends

Something must be in the water. For some reason, perhaps due to the youth of our industry, or the distributed nature of our endeavor, we keep hitting similar life milestones throughout the team. Despite a 12 year age window, we had 7 babies on the team in 2012. Those babies sure do change the dynamic of these trips. And yet, the more things change, the more they stay the same. I’m surrounded by artful people who really care about building great things. They are happy, helpful, curious and accountable. I am grateful.

To great families, to kind people, to awesome teams living the life. And to a new adventure next year…

Curious about why we do this crazy and expensive jaunt abroad? Peter laid it out nicely in our second annual retreat summary.

bbPress side of things

Let’s concentrate first on how the bbPress search should work. Specifically, what should you get when you search for a keyword. There seems to be three main approaches:

Search all, return all

When you search for a keyword, bbPress looks for its custom post types (Forums, Topics and Replies) and will return all items that match the keyword. It should show in the search results template what kind of element each link corresponds to. Maybe it’d make sense to show results for Forums at the top, and Topics+Replies next. For this kind of search, returning items ordered by recency seems to be the logic way to go.

Search replies, return replies

Pretty much the same as the last approach, but the results will only contain links to replies. I think someone mentioned phpBB does this, but I’m not sure. This approach seems best suited for a forum where recency has a lot of weight (news, tech, etc).

Search replies, return topics

In this case bbPress will look for the keyword in replies, but return only the parent topics of those matched replies. Of course it’d show each topic only once. Interestingly, here, the results could be ordered by relevance instead of recency (the count of replies in that topic that match the searched keyword). I’m totally biased, because almost all my experience with bbPress is implementing big scale support forums, and for support this approach wins every time.

Regardless of the approach, we should also consider the idea of having an advanced search mode out-of-the-box, where you could, at least, filter on which Forum you want to search. Maybe make it context aware? If I’m in a Forum, it searches within this forum. If I’m at a Topic it searches within it’s replies.

Let’s not forget pages & posts!

The second part of the discussion is harder to solve. How bbPress search should integrate with the standard WordPress search? Here we agreed this seems more like an UX problem than a technical one. Again, a couple of different approaches:

Independent

By far, the easiest to implement. Let’s just have a different search box for bbPress, use a different query_var, keep the bbPress custom post types defined as exclude_from_search and off we go. (Actually, jjj showed us that this is kinda already implemented, at least for topics: example)

Independent but unified

Use the same WordPress search form, but when the users initiate a search from a non bbPress page, run the normal search. If the user searches from inside a bbPress page, run our search. I’ve implemented this in the past and I don’t like it. It’s quite confusing to get different behaviors for the same action.

Integrated

Again, totally biased, but I love how we resolved this here at Modern Tribe (example). I think for some sites it’d be a killer feature the ability to combine results like that. To be honest, I can’t think of a bbPress implementation I’ve done that would not be well served with a search results page like this one. On the other hand, the general consensus was that making something like this look good in any theme would by quite impossible. Specially when you realize we need to take into account custom post types, different ratios of content in each content type, etc.

I’m probably forgetting parts of the discussion, and this is getting long, so I’ll shut up now and make room(?) for you in the comments. What do you think?

As someone who does a pass through The Events Calendar forum each week, and having compared it to the bbPress install we’ve got running to power the forums here on the Modern Tribe website, I came up with a short “wish list” of the features that would help improve the support experience from both an admin and a user perspective:

But, as we grow and our user base does the same, we’ve struggled with setting support expectations on the WordPress.org forum for users who’ve never asked for help before. After some discussion last week, we came up with one solution that would work well for us: a simple text area where plugin devs can enter a “support expectations statement” that appears directly above the first page of forum results on WordPress.org. Here’s how we envision it:

Last night, The Events Calendar received it’s 300,000th download. This was a significant milestone for us at Modern Tribe and finally gave us an opportunity to break out the champagne. But 300,000 users also gave us pause. With this many potential support inquiries, how can we be helpful while setting boundaries? How can we make it clear that while we appreciate and value our core userbase, the bulk of our support resources are routed to paying customers? And how can we draw the line between what we’re really looking for when browsing the dot-org forums — namely, bug reports so we can improve the plugin — and those requests (custom queries, new page templates, etc) that we really only have bandwidth to address when the user has paid for PRO? We feel the support expectations statement proposed above could help with all of these.

For those who aren’t familiar with our support process, we generally break it down like so:

• For free/non-paying users, we hit the WordPress.org support forum for The Events Calendar about once a week. We’re watching for bugs exclusively, but will point users in the right direction if they ask a simple question.
• For PRO/paying users, we monitor the forums here on Modern Tribe’s website daily to ensure nothing goes more than 24-48 hours without a response. Beyond just bugs, we also help with customizations and other more in-depth, time consuming tweaks.

In his 2012 WordCamp SF Keynote, Matt reiterated his vision of of WordPress as a system that silently updates itself without requiring user input. This delightful utopian dream, however, relies on excellent code contributions from the massive international WordPress developer community.

The problem is, this community has formed precisely because of the low barrier to entry that WordPress provides. I posit that we will NEVER achieve this vision if it is dependent on improving code habits among developers. What we need in order to achieve this vision is a system to support it. This system may consist in part of a review process for plugins and themes and some automated testing. But above all, I propose that WordPress needs an upgrade history / versioning framework for plugins, themes and possibly even core.

Picture this scenario:

I am a blogger. I have a self-hosted site with some plugins and a theme. Either I manually update core, plugins, and the theme or perhaps it automatically updates. Either way, I'm shocked to find that after my last update, my site crashed. My first thought is that I need to undo that update. But I have no idea how to revert!!!

Ok, picture this alternative scenario:

My site upgraded itself and its various components and ran a test on itself after each component upgrade and figured out that PluginX caused a fatal error. It reverted pluginX and sent me a notification with a link to the versioning dashboard. It also sent the developer a notice and since the developer received dozens of these notices soon after a deployment, the developer is already working on a fix.

Let’s provide peace of mind by building a system that can foster a retractable upgrade of any plugin, theme or WordPress core. This system will implement the following components:

• Upgrade versioning history UI and framework with the ability to revert a plugin/theme/core to any recent prior version.
• An automatic test of various screens after an upgrade including at least the following screens thus ensuring that we can undo the damage if there are any problems:
• • Home
  • Plugin admin
  • Theme admin
  • Upgrade admin
  • History manager
• WP administrator notification
• Optional plugin developer error report ping
• Bonus: offer a url endpoint to run the site in “safe mode” thereby offering a simple and secure back door to the site for administrators. (This would not make WP run in safe mode for everyone, just for one logged in admin)

Thus far, I’ve encountered three primary concerns to regarding this proposal:

1. What happens when you revert and there has been a DB change?
2. What happens when an upgrade causes the infamous white screen so that the system can no longer fix itself?
3. Won’t this make it even MORE likely that people will stop upgrading?
4. What about sites with a lot of custom code (plugins and/or themes)

1. Database Sanctity

One of the biggest concerns with regard to reverting code is that the code may have altered data. Ideally we would do something like make a backup so we could revert to it but this won’t work for most cases. Some WP installs are simply too big to demand a backup. Or they are sharded. Or… one may want to revert by more than a single revision. Or revert back to something from a couple days ago even though there has since been a lot of site traffic, posts published, etc.

In short, the database problem is certainly the weakest part of this proposal. However, here are a few approaches we can take to addressing this:

Don’t worry about it.

Even if we ignored this problem completely, we’d be better off than we are today by a long shot.

I suspect that the vast majority of upgrades don’t require any changes to the db. Today, people upgrade and not only do they not have a simple way to revert, they are blindly taking a chance with the new code and its effects which sometimes result in partial or even complete system failures. Even without worrying at all about the db problem, we’d be reducing the risk involved in upgrades dramatically simply by offering a mechanism to undo the upgrade.

If a new version of a plugin causes 90% of sites to crash, odds are that reverting it will only leave a small fraction in the dumps. Even if it leaves 10% damaged, that’s a reduction of crashes on that plugin version from 90% to 10%.

This is especially true if the upgrade causes a fatal error. It is likely that the fatal error is actually preventing the db updates from even being executed in the first place.

Negligence is not the best way to handle this, but it shouldn’t be a showstopper.

Data version API ( and testing suite )

The cleanest way to handle this is to build an API that supports upgrading the database as well as reverting it. The only problem with this is that it again puts the responsibility of customer confidence on the masses of contributing coders.

This is better than simply not worrying about it, but if a dev is sloppy enough to have baked a fatal error into a plugin they probably won’t have implemented the data versioning API. And frankly it might be a lot to ask unless we also make an easy to use versioning testing suite so people can test their work.

I’ve looked over how core handles this in wp-admin/includes/upgrades.php and wp-admin/includes/schema.php and in both cases it’s pretty well manually managed with a giant conditional and a bunch of version numbered functions.

What if we did something, dare I say, a little more like the Ruby on Rails ‘migration’ in this regard?

http://guides.rubyonrails.org/migrations.html#migrations-are-classes

If nothing else, we should at least provide some hooks for versioning to set a standard.

Conditional Upgrades

Another idea is to give some easily managed power to the developer such that they can define a simple toggle in the readme/plugin header that declares a version as having db changes and requires the admin to actively upgrade (hopefully prompting people to make db backups). This is not mutually exclusive with the versioning API.

Any Other Ideas?

If you have any other ideas on how we can manage to safely revert code without causing database problems and without relying on the developer, please let me know.

2. Defense Against the Whitescreen

In order to ensure that the upgrade system works even when the rest of WordPress doesn’t, the upgrade will have to run on as little core code as possible and without activating the theme or plugins. In fact, it should probably run in SHORTINIT mode. We can probably assume that whatever happens before SHORTINIT is safe from the whitescreen in its own right.

Independent Upgrade Endpoint

One key ingredient to this proposal is an independent upgrade endpoint. This is a php file or WP endpoint that relies only on WordPress to the extent that it has loaded in SHORTINIT mode, that can securely manage to revert recent upgrades in the event that the fully loaded WP site is crashing.

Upgrade Test Ping

When an upgrade is performed, WordPress will spawn an independent CURL to the upgrade endpoint url to start up an independent test process. If the tests fail, then the code is automatically reverted and appropriate notifications are sent.

This request is made independently so it should not, itself, fail. In the unlikely case that the request itself fails due to timeout or miscellaneous server error, we’ll need some sort of method for re-invoking the test automatically. Here’s one idea:

When an upgrade is initiated, an autoloaded option is set indicating that a test of the upgrade is needed.

When a test is started, that option is updated to be the timestamp of the start of the test.

If that option is subsequently read AND the timestamp is older than X, then we can assume that a test was attempted and died. We can either try again (a limited number of times) or we can assume that we need to revert the last upgrade.

WordPress can take on this logic during load but it would probably be best to try and use cron for this.

3. Don’t Stop the Party

Mike Schroder, who is a bit of a liaison between WordPress and Dreamhost, voiced a concern stating that currently it is very common that users and developers install a WP site and then never upgrade it. This proposal attempts to address this in a few ways:

1. Fundamentally, this is a system that is intended to set the groundwork for auto upgrades. By giving people a way out, we can move forward with opting them in. But the key words here are auto upgrade
2. I am proposing a default of being opted in. You have to choose to opt out of auto upgrades.
3. If an upgrade fails, and you have auto upgrade on, it should revert the offending code and await another upgrade so that it can skip the offending upgrade. It should NOT simply stop upgrading.

In effect, this is a framework that can be completely ignored by the consumer. They install WP and install plugins and themes and never even know that this feature exists. Because the upgrades are checking themselves for errors, often when an auto upgrade happens, the consumer won’t even notice. If it fails silently, the consumer can revert that upgrade when they notice the problem and in doing so, they will likely be notifying the developer. The developer will likely be getting lots of these notices and will be quick to fix the problem. As such a small % of consumers are protecting the masses. Most consumers won’t even know there was a dud upgrade because the developer will have been prompted to quickly fix it.

4. Upgrades Might Break My Custom Code

Here’s another scenario:

I am a blogger and I hire a developer to make a custom plugin / theme. Once they're done, I'm afraid to upgrade other code because it might not work with my aging custom code.

The thing is, the blogger can let the updates role until an update fails or until the blogger happens to notice a bug on the site. In either case, whatever update caused the problem, it will be reverted and the blogger will likely have been notified of this if they didn’t intentionally do it. In the mean time, the blogger can arrange for the developer to take a look and once resolved, the upgrade process will continue again.

If anything, this system offers a way for the blogger to have enough control that there is some chance that they will continue to upgrade whereas the existing system is so terrifying that there is no way that the blogger would attempt upgrades on their own.

Wrap it Up

As I write this I can see a lot of opportunities to expand on the proposed feature set. For the time being, let’s keep it simple and to the point. The goal is to take the stress and maybe even the entire consciousness out of upgrading code. If it upgrades by default and people don’t have to worry about it, then people will surely be more likely to keep up to date.

Cheers from Tybee Island, GA!

Postscript: I'm honored to be writing this from a hotel in Tybee Island, GA at the WordPress Community Summit. I would have liked to have refined this a bit more before publishing, but I found out tonight that "automatic upgrades" will be a large part of tomorrow's conversation. This topic, possibly this post, and probably all the ensuing conversation really ought to live here: http://make.wordpress.org/plugins/. But for the time being, I am posting it on our blog. I will likely make updates to this post over the next few days.

I gave an hour and twenty minute talk at How Design Live / Creative Freelance Conference in Boston on the art of the start. This talk has some serious meat on its bones. The organizers were kind enough to provide me the audio and I then paired it with the slides to create a video to share. We always give our educational content away for free to our audience and this isn’t going to be any different.

I started freelancing full time out of necessity during the dot bomb in 2001. There were no blogs on freelancing, no conferences, but I was deeply blessed to find a mentor who helped me avoid the worst mistakes my first year. While you shouldn’t get paralysis by analysis (just get started), certain key tips often make the difference between navigating a successful freelance career and a lot of sleepless nights. Whether you are dreaming about freelancing or in the thick of bootstrapping, be practical and be intentional about running a business and you will be successful.

• Why you ALWAYS get a deposit
• What to spend money on and what to skip
• How to get a business license and what form of business to choose
• Don’t be a cowboy, get input from the right people
• Why you should clock your time, even if your aren’t paid for it
• Contracts matter – finding a template you can use
• The IRS is watching: separate bank accounts and track your finances
• Planing makes you real money: think about deductions and expenses now
• Avoid the bad projects and evil clients with a project checklist
• 6 months in the bank = freedom to define your terms
• And so much more…

“The Tribesterly” (its a working title)

Reid & I have been wanting to publish a quarterly trimersterly collection of high quality content for a while. Expect thoughtful articles from the Tribe on the art of business, the science of art, the engineering of products and the prose of a life well lived.

Drop in your email below, and you’ll get a link to the video for “The Freelance Primer”. When it is ready, we’ll send you a copy of The Tribesterly.

With The Right Setup, Anyone Can Kick Ass

I included the table of contents for the talk below as well as a small additional set of thoughts on the biggest mistakes freelancers make. Hope you enjoy.

You might also want to check out other articles & videos we have on the topic of freelancing (there are tons more beyond these):

• What should I charge?
• Working Remotely with a new baby.
• Marry your clients.
• Be Dependable
• Contract Template
• Freelancer’s Guide to Sales: followthrough
• Measuring your pipeline

The Why
The Vehicle
The 6 Fs
My Dreams List

The Setup
Business Type
Biz License & other paperwork
SBDC
Professionals pay off
Your up-front costs
The IRS is watching: separate bank accounts / cc
Track your finances: Quickbooks, Quicken, Freshbooks …
You MUST pay taxes
What can you deduct?
#1 goal: 6 months in the bank

The Patterns
Rhythm
Daily Habits
Work Comfortably
Home Vs Coworking Vs ?
Clock all your time
The Calendar
The Daily minimum
The Urgent Vs The Important
Balancing the Fs
Back your shit up

Finding Your Customers
Make a list – contact everyone
The perfect voicemail
Agencies
Marketing – website, portfolio etc
The project checklist
Sell when you need it least
Fixed Vs Hourly
Managing your load
Experiment with your rate: Supply & Demand
My income per year
“Do Good Work & Tell People About It”

Working With Customers
How do we win?
Contracts
Deposit
1 out of 3: why they fail
HHCA
Management Slides

bonus thoughts for this post:
(not in the video as I had to cut it due to time):

Most Common Mistakes
Not clocking
Taking on too much
Waiting to sell until you need it
Failing to experimenting with your rate
Forgetting to save for taxes or tracking expenses
Setting expectations poorly
Pretending to be what you are not (an agency)
Wasting money on the wrong things
Not getting the legal biz basic in place (but not obsessing about them)
Allowing the urgent to trump the important
Going with the torrent rather than creating a pattern to live and work by
Not having a backup in place
Working without a contract (or neglecting to read it)
Not getting paid a deposit up front
Finding out how to win a project after you have it