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.

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

Collaborate

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.

Read

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

• The Phoenix Project
  • How to not make IT suck for yourself an d others - this is written as as story and if you’ve been in the trenches of IT it can hurt to read the first half of this book as you read the reflection of the challanges you’ve faced as an IT person.
• Pragmatic Programmers
  • Programming is hard - being a good programmer is an art form (that I’ve personally not mastered but respect and rely on).

Email

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:

• Know what the topic or the goal of the thread before creating or replying to it
  • Stay on topic - random questions or seperate topics should go into a new thread
  • If the topic/goal of the thread is fuzzy to you try to reframe what you think it might be and ask the thread to confirm - many times that will provide clarity to yourself and others.
• Have a thesis statement or question you pose at the top of your email (and description)
• Make the email description exactly that: descriptive and relevant to the goal of thread
• Avoid writing a huge block of text - new paragraphs are great for organizing thoughts and helps others scan the email for the key points.
  • The return key is your friend and will only make your emails easier to parse for others.
• Write in complete thoughts
  • For me this means re-reading at-least once since my thinking method can leave me with half fleshed out paragraphs/sentances

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.

• Whitehouse - Project Open Data
• Whitehouse API - Pragmatic and not crazy recommendations for federal government developers for generating and consuming APIs. I they are using :octocat: and their use of the term “Pragmatic REST” in their README sold me on paying attention to them.
• ADIWG]()

CHANGELOG

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: keepachangelog.com

Unrelated except by name - check out the awesome podcast: thechangelog.com

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:

• date based : YYYY-MM-DD
  • Use only as much as you need, so if you expect to update no more than once or twice a year and never more than once a month use YYYY-MM
  • note: use - or . as a separator : 2014.09 or 2014-09-13
  • If you the data is just one of many parts in the name you are capturing then crunch it down to YYYYMM or YYYYMMDD
• version based : v3.2.0
  • This is well documented at: SemVer.org

commit messages

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