Know It When You See It

Chris Cristie's response to reporters when asked what success would look like in the New Hampshire primary was, "I'll know it when I see it."

A phrase that leaves room to justify continuing to run even in the face of impossible odds, but really means I'm wasting everyone's time and at least a some people's money.

In the design and development world clients love using the phrase and it there is an attempt to imply that the only thing they will pay for is this ephemeral concept that they will leap out to them when they see it, but until then keep wasting time.

Explicit Development

Historically, I've worked solo. I have a vivid memory of working on a important project with an impending launch date late at night. The project was simple and I was using a static site generator, Harp.js, I ran a compile command incorrectly and destroyed the entire project. Because it was a single page project, I was able to recover it by meticulous copying source data from my browser, but it was the last time I ever worked without a safety net. Before that I had dealt with many of the same mistakes we've all suffered. Someone overwrites work with an FTP upload, a client edits files in the WP admin while you are uploading or any of another million things that go wrong. I committed to GIT and have saved myself a lot of agony as a result.

Since then I've worked with a lot of teams and companies, and am perpetually amazed by the number of successful development firms that are not using process management to ensure stable and reliable development practices. A client I've recently begun working with and who has a number of prominent clients has relied on Codekit exclusively for running preprocessing. After rescuing a couple of projects I recently ran my first with the company and as result introduced the lead developer to the Sage theme. I like Sage for many reasons but the most valuable part of Sage for WordPress Development is how easily it can be used in a team setting.

Success in team based development is about coming to consensus. It is not important what patterns you set for your team but that you follow the patterns you create. I have a set of patterns that work well for me and have worked for several other teams.

You Are Never Alone

Often, we work with that attitude that we are the only person thats every going to use this code. This is a fundamental mistake that we all make. If you assume that no one else will need to edit or extend the codebase you've started, you are planning for failure, for you or for your client.

Plan for success, institute build practices that elevate those around you and enable everyone to succeed by assuming that others will be extending what you've started.

Be Explicit

Communication is the most vital aspect of working as a team. There is no loss in asking questions or agreeing to an internal "best practice". Often you may find your team works in relative silence, but don't work in a vacuum. If you are working with a remote team you are probably using Slack or, God forbid, HipChat to communicate. When you come across something you're not sure how to handle in a way that's best for everyone, take 5 minutes to involve the group and come to a consensus, you'll never regret it.

Be explicit in your code, your commits or your QA. Taking the time to be clear will never hurt a project. It probably will not result in a project taking any longer and might keep everyone just a little happier.

GIT committed

I don't think its a stretch to say that using version control is critical to team based development. GIT is complicated and has a significant learning curve. After you slog through the basics, you may also need to handle structured commit messages, merges, pull requests, conflicts, and code oversight. I'm a big fan of pull request based merges and an agreement that when working in a team, if possible, you shouldn't merge your own work. I'm also a fan of explicit commit messages.

When working with GIT it is important to commit regularly and to include concise and descriptive commit messages. The goal of commit messages is to provide information about what the commit involved.

  1. First line should include less than 50 characters and act as a title.
  2. Never use the -m flag (It encourages abbreviated messages)
  3. Messages Should be in present tense (Fix bug vs Fixed Bug)
  4. Answer the Following:
    • Why is the change necessary?
    • How does it address the issue?
    • What side effects does this change have?
    • If related to an issue provide a link to that issue


Clear Errors on Modal Close

Clear JS errors when User closes login or Registration modals.
Change in behavior requested by client.
Listen to .close class and empty() .js-errors & removeClass('error') from .required

Original Issue:

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch bug/clear-errors
# Your branch is ahead of 'origin/bug/clear-errors' by 1 commit.
#   (use "git push" to publish your local commits)
# Changes to be committed:
#       modified:   example/file/path.less

Branch Out

Don't be afraid of branches. I branch a lot. I did a recent Startup Weekend in 2 days we generated around 20 branches. Created a naming pattern and when in doubt created a branch. You can easily merge things together as needed and when you run multiple branches you don't need to worry about lost work.

When crafting a clear branching strategy its important to manage your funnel. Master branches should be a pretty clean history. the merging should take place further up. I typically run a base level dev branch where I handle all merges and initial testing. Depending on my environments I might also have a staging branch between dev and master.

Be explicit in branch names, explain what you are trying to accomplish. A few examples of possible branch names:

Share a Tool Belt

It is a lot easier to build together if you share a tool belt. Grunt, Gulp, Webpack, etc. build tools abound, but if every member of the team is using a different tool belt it makes working together virtually impossible. Every time another developer gets involved they will either need to build additional tools or deal with the learning curve of a new tool set.

One of the best parts of Gulp or Grunt is how easy it is to pass build tools around the team. Even if you don't use a consistent base template for projects, the tooling created at the beginning of the project can be handed and extended by each developer.

If you prefer to forgo tooling, it is still important to manage processes within the team, and it probably means the whole team will need to be tool free. I haven't ever heard a good argument against build tools, prove me wrong.

Up a File Tree

Finding things in a project is a major time suck. If you work in WordPress or any web development framework its a lot easier to work together if you place folders, functions, templates and assets in a patterned structure.

Discuss with your team and consider the logic of folder structures, consider the MVC model and how that can be applied even with in WordPress. Separate concerns to making getting in a groove based context a little easier.

CSS Class

There are almost as many options for CSS structure as JavaScript frameworks. It doesn't matter what your team uses so long as your whole team uses it. No matter how you write CSS it is a lot easier to keep track of things if you can edit parts of your site in context. Think about the element you are building, split up page layout styles or post styles in logical file groups.

Name space components whether or not you use BEM methods, (I don't right now), you can namespace your CSS particularly within components. Prepend sub elements with the parent name to prevent conflicts with a teammates styles on pages you may never see.

  height: auto;
  width: 100%;
  background-color: $brand-primary;



JavaScript Patterns

If you are using tooling adding a Linter like JSHint or similar can be a life saver. Sometimes it will tell you something is broken before you even make it to the console to find out for yourself, other times it might just keep you from being murdered by your team lead.

More than just keeping things neat and tidy writing JS as a team is a lot easier if your explicit in your function names. Be descriptive in your function names to make using JavaScript across your team a little easier. Odds are you are minifying your JavaScript and that will take care of any performance loss in using the extra characters.

var a = '4242-4242-4242-4242';

// vs

var defaultCreditCard = '4242-4242-4242-4242';

There is also value in a name spacing custom JavaScript in a simple object can save a lot of headaches, especially if work is moving across teams or being carried forward by another team.

  var siteName = {
    navStyles: function(element){
      // Do something
    submitNewsletterForm: function(form){
      // form logic

  siteName. navStyles(document.getElementById('primary-nav'));

I Can't Be Comprehensive

I can't provide a comprehensive list of steps or processes for your team. I don't know you, the best I can do is tell you to take the time talk to your team about what standards you are going to put in place. A 1 hour meeting and agreement to follow processes in place together will save your entire team a lot of time over the life of any project.

Limiting WP Editor Character Count

A little script to create a character limit on a post or post type (just swap out the post type class)

This hasn't been 100% optimized, if you have suggestions let me know.

Gist on GitHub

Email is an Authenticated Action
Getting Started with Gulp.js
Anchor vs. Ghost