This is the second workflow post in what I hope to be an ongoing series that explains a little about how I work so that others can perhaps learn something and that those with more experience than me can point out issues or tips for better productivity and ease of use.

Last time I wrote that I used Coda 2 for my day-to-day coding needs.  This remains true.  I work for a small company within The Richards Group, a full service advertising agency, called Click Here Labs.  We specialize in digital work for the agency.  This can mean anything from websites to native apps to HTML5 ad units.  We make up a little over 10% of the 700 people employed by The Richards Group.

I am specifically on the Front End Development team although I also have the title of Technical Product Manager which describes my role in overseeing all technical aspects of our WordPress focused products and services.

That all brings me to what I do all day and the technologies that help me achieve the company’s and our client’s goals.

Bread and Butter

Daily, I work with a combination of HTML, CSS, JavaScript, and PHP.  I write all of this in Coda 2.  Coda lets me not only write all these, but has autocomplete and understands the syntax either natively or with free add-ons.  As a side note, I’ve also occasionally been assigned as the front end developer for .NET or Ruby on Rails projects.  In these cases, Coda mostly can handle the work, but there have been circumstances where I’ve used Visual Studio on a virtual machine RubyMine if necessary.

We write mostly to the HTML5 spec at Click Here Labs.  Occasionally we receive a request for something else, but all of our developers are trained and familiar with HTML5.

We also write to the CSS3 spec at Click Here Labs.  This allows us to do some pretty cool things on client sites as well as use things like polyfills for older version of Internet Explorer.  We currently support back to IE9 unless otherwise needed by a client.  Our rule of thumb is once usage drops below 3% globally or specifically to a client’s audience, we drop support for it.

Within CSS, we currently use a combination of native CSS or the LESS preprocessor depending on the project and developer.  We are currently working on bringing our best practices and coding style guides up to date with these technologies in mind and are hoping to publish something very similar to 10up’s Engineering Best Practices very soon.  We chose LESS before SASS was included in the WordPress core.  LESS is a lot easier to digest and dive into for most developers and allows for easy onboarding of new developers.  We have, however, been playing with switching to SASS for all WordPress specific development.

Coda 2 provides some add-ons which can act as preprocessors for LESS, but I haven’t found one to my liking yet and so I use CodeKit in addition to Coda to process my LESS into CSS.  I’ve also been known to use several different CLI tools for this process, but am trying to use CodeKit for the sake of our team’s workflow sanity. 🙂

That’s our HTML/CSS workflow.  Next time I’ll cover what we use in terms of JavaScript and PHP and some of the linting and standards that we are putting into place to help our code be more standards based and WordPress VIP friendly.