Over the last three years I’ve been on both ends of job offers at startups. One thing that’s struck me is how little most applicants know about what to expect in a job offer, and in many cases, what the written offer they’ve received actually means. I was extremely fortunate that the first startup job offer I received was from a pair of founders who had the utmost integrity and explained things very clearly. Since then I’ve learned that not every employee is so lucky.

This post doesn’t aim to teach you negotiation itself, but rather to acclimate you to the standards and vernacular of startup negotiations. It assumes you’re a startup newcomer.

I wrote a bash function that prunes a git repository’s ancestral branches, helping you keep your local and remote repos tidy.

This function removes all branches, local and remote, that have been merged into your current branch. Simply run “rmb” from the command line. Don’t worry - prompt safeguards are in place to show you what you’ll be removing before it deletes anything. And it won’t let you delete “master.”

Add this to your ~/.profile, run “source ~/.profile” and you’re good to go.

One correction that I’ve updated in the slides: I mistakenly referenced Shareaholic using Hadoop MapReduce. Shareaholic uses Amazon’s Elastic MapReduce, which works similarly to Hadoop but is a separate implementation. My reference is intended only to distinguish it from Riak’s MapReduce implementation, which is substantially different.

In 2006 I participated in NOLS’ Summer Semester in Alaska, a 75-day kayaking, backpacking and mountaineering course, which helps students gain wilderness and leadership skills.

A few days in I got my first review. I was a wreck. I packed my backpack as if I were paying homage to the Leaning Tower of Pisa. The most palatable meals I cooked were the ones that were burned beyond recognition. I might have been able to properly affix a rainfly to a tent, but I’ll never know because nobody trusted me to keep their tent dry. You know that guy who played on your middle school basketball team who had great hustle and personality but couldn’t make a layup? The guy the coach wanted to do well, but would never take chances with in the 4th quarter? That was me at the start of my first NOLS course.

Last year I wrote about the importance of writing for people rather than search engines, two target audiences that often compete with each other on the web.

A similar problem occurs when authors write for companies instead of people. I see this most at business-to-business companies, where the customer is another company rather than a human. It’s important to remember that it’s always a human who will be reading your copy.

Leaders show themselves in various forms. There are rhetorical magicians (Barack Obama) and iconic revolutionaries (Steve Jobs). There are also workplace leaders - the silver-tongued employee who can articulate issues several steps beyond what others are thinking, or the clever, diligent coworker whose performance alone encourages others.

Whatever the kind, leaders have three priceless skills: they’re doers, they persuade, and they inspire.

As Wordpress has evolved from a writing platform into a full-blown CMS, theme developers have followed suit by using big header images, multi-level navigation and dozens of widgets that make sites look bigger they actually are and more complex than they need to be. It’s unclear to me how any of these things make blogs a better experience to read or authr. Do you click on tag clouds? Do you read embedded Twitter feeds? Do you browse old content by clicking on individual months listed under past years? For me, the answer to each of these questions is a resounding “no.” Blog design has become superfluous and distracting.

Yesterday, Michael Pope posted an article titled Technical Cofounders Are a Myth. He argued that software engineers don’t finish what they start, and that you’re better off paying a technical person than partnering with one. His frustrations are valid and not uncommon, but his conclusions are way off base for a lot of reasons.

Yesterday, Wordpress founder Matt MullenwegdebatedThesis Wordpress Theme founder Chris Pearson over the ethics, legality and benefits of using the GPL license for the Thesis theme. Matt argued that by not using the GPL license, Thesis is disrespecting the Wordpress community, violating the Wordpress license agreement and hurting its own business. Chris contends that Matt has no right to tell him how to license something that Chris built himself, even though he built it on top of the Wordpress platform.

I’m not an attorney, but I am a human capable of reading and inferencing. The legal issues concerning the GPL seem pretty clear to me. There’s a reason why Dan Rivcher is cited by the Software Freedom Law Center’s compliance guide. There’s a reason why the SFLC sides with Wordpress. There’s a reason why lawyers at big companies tell their engineers not to use GPL open source projects. There’s a reason why the LGPL exists. There’s a reason why many communities, like the Ruby community, have moved to use the MIT license instead of the GPL. All of these reasons are the same: the GPL is a highly viral license that infects everything it touches. If your code uses GPL, your code needs to be GPL. I don’t know this because I’m a lawyer; I know it because every credible lawyer I talk to or read about or am influenced by reaches the same conclusion.

And I’m reminded of how well I know this, because I gave up healthy means of income in order to abide by it.

Nearly all commercial web sites perform Search Engine Optimization (SEO), whereby they alter their site to be more Google-friendly, with the hope of receiving higher search rankings. Many of these changes are purely structural and invisible to users. For instance, using tags like <h1> or microformats like “hreview” can help Google make more sense of existing content without any changes being made to the text.

Mature, profitable sites often take SEO to the next level by altering their visible content as well. In effect, they write their copy for machines instead of for people. From a user experience perspective, it shows. There is often an inherent conflict between what is best for a user and what is best for Google.

One of them in particular got under my skin —- a recitation of the the counterintuitive idea that success is the enemy:

Most celebrate success, and criticize failure. That’s 100% backwards. Do the opposite, and your edge will be 100x sharper.

Quotes like these get lots of attention in the startup world because they are shockingly contrarian and counterintuitive. Paul Krugman explains this method of distinguishing oneself:

For a long time, there’s been an accepted way for commentators on politics and to some extent economics to distinguish themselves: by shocking the bourgeoisie, in ways that of course aren’t really dangerous. Ann Coulter is making sense! Bush is good for the environment! You get the idea.

The problem is that eventually, it does get dangerous. He continues:

Clever snark like this can get you a long way in career terms — but the trick is knowing when to stop. It’s one thing to do this on relatively inconsequential media or cultural issues. But if you’re going to get into issues that are both important and the subject of serious study, like the fate of the planet, you’d better be very careful not to stray over the line between being counterintuitive and being just plain, unforgivably wrong.

The “celebrate failure” contrarianism may not be “fate of the planet” bad, but it’s dangerous for startups because it trivializes setbacks to their goals and ambitions, which are already overwhelmingly difficult to achieve. If you’re running a startup, you will fail plenty. You needn’t obsess over it, let alone strive for it, or – worst of all, as Umair asks us to do – “criticize” yourself when you avert it.

Entrepreneurs far more accomplished than myself have made this point. At SXSWi 2010, Jason Fried concluded his speech with “‘Fail often’ is probably the worst advice I’ve ever heard.” (I don’t have a link to that, but here’s a similar tweet). His sentiment is highly reflective of my experience. All of my successes (and partial successes) in life have come from drive and determination. Whether it’s as big an undertaking as climbing Denali or as small an undertaking as writing this blog post, I’ve succeeded by thinking about what success looks like and aiming straight for it. I’ve never found dwelling on or romanticizing failure to be a useful compass for navigating hard problems.

Certainly there are valuable lessons in failure. Josh Bokardo points out that rather than “celebrating failure,” we should “celebrate learning.” Brad Feld has written several astute posts on improving on failure, covering his own experiences and arguing that it’s better to fail quickly than slowly and that failure is often worthy of introspection. These are all excellent points, none of which advocate the bizarre philosophy of striving to fail repeatedly.

Contrarian thinking, by definition, implies that conventional wisdom is wrong. If you’re going to challenge the status quo, you should use more than a pithy expression to do so. Otherwise you may as well be telling us to look west to find sunrise, or to saltwater to quench our thirst. If you’re going to talk about the virtues of failure or any other counterintuitive concept, please follow the Brad Feld strategy of thorough reason, and avoid the Umair Haque strategy of shocking contrarianism.

Facebook is in many ways the hedge to Google’s bet that social machines are oiled with the trust of their users. As competition between Facebook and Google becomes increasingly visible, so too will the issues of trust that separate them.

The kerfuffle between Twitter and its third party developers has been discussed, analyzed and debated ad nauseum over the past week. But aside from jokes of awkwardness, there has been surprisingly little talk about what it means for Chirp. What do third party developers want from the conference in light of recent events? What’s a win for Twitter?