This is a list of a few best practices I try to apply to myself and recommend to others. As much of life these are goals and many times :Reality is these are my goals and many times not a reality (yet).

Avoid Suck

Remember nobody wants to deal with or make things that suck - but making things that do not suck is work.

suck to not suck

Don’t be hard on yourself or others while you work through the hard part to make something awesome.

One time a brilliant brain storming where we took apart a bunch of hard problems and had a plan of attack this was said:

 "now all that is left is everything" -- Mark


Remember you aren’t the only one wanting to make life better for yourself and others. Sometimes you can be surprised at who else wants to join and what they can contribute. Make it easy for others to collaborate with you even if it creates a bit more friction in your day-to-day life.

I have a whole page on collaboration tools.


Here are a few things I’ve read over the years that helped course correct myself:


I lose at email. At some point in 2009 I started drowning in it and I realized I can’t follow up at the engagement level I expected of myself. This is why I love collaboration tools, like BaseCamp and GitHub, that capture and open up engagement to a wider audience.

However email is core communication utility and when I do follow up I try to have the following approach plan:

Open Data and Open Standards

Tricky topic here. You know there are best practices and standards to go with those but there appears to be a proliferation of incompatible standards that have a fundamental approach that doesn’t pay attention to the ‘Avoid Suck’ attitude for themselves and those being subjected to their standards.

Pay attention for and take note when you see somebody making tangible progress on setting or recommending standards that you agree with.


Curate a log of the notible changes in projects in your life.

Not just code projects but the other projects you participate in work and life : platforms, partnerships, and organizations (I should have kept a CHANGELOG for GINA over the last 10 years). Think of it as a journal you share so others who want to work with you can track progress and better collaborate with you.

To get leveled up fast check out:

Unrelated except by name - check out the awesome podcast:

Semantic Versioning

You of course have a revision control and data management plan for any content handle in life. Right?

To keep straight for yourself and others the data you are providing you will want a sane version numbering system. I personally fit into one of two buckets for my versioning:

commit messages

Have inteligent commit messages. Try following the udacity/git-styleguide