Advice for front-end developers for 2015

People who know me in the non-internet world, know that I’m prone to giving advice. I try and do it gently, and I always try to make sure I’m not preaching. My wife will absolutely disagree with that last sentence, but what do you do? The simple fact is when I find something I like, I tend to really like it and want to show everyone around me how awesome it is.

I have just two pieces of advice for front-end developers in this brand new year:

1. If you’re not already using Sass, start.

If you’re still writing plain-old css, make 2015 the year that you make the switch. If you’re using less, switch from that to Sass. This is 100% my opinion, and I mean absolutely no disrespect to the less team, but Sass really feels much, much better to me at this moment in time.

I give this advice as a long, long time writer of styles. I was actually (relatively) late to the pre-processing party, seeing it as more trouble than it was worth for a long time. When I finally saw the light and found a simple tool to do my preprocessing for me, I happened to choose less. I have no idea why now that I look back on it. Maybe it was because less was Javascript and Sass was Ruby and so it seemed easier to get started with, but no idea really. In any case, I was a preprocessing convert in literally minutes. Almost instantly, writing vanilla css seemed like a chore.

As a long-time less user, why do I recommend Sass now? I’ve really only been using Sass for just shy of a year, after several years of being quite happy with less. I actually tried Sass several times in those years, but really couldn’t see the benefit. It wasn’t until I realized that everyone I knew and followed online was using Sass that I forced myself to switch to see if I was missing out on anything. Turns out I was.

I was missing out on these 2 major things:   community and breakpoints or “named media queries”. First, in short, the Sass community is awesome and active. Have a look through The Sass Way for many examples of this. Second, breakpoints are amazing. It will change the way you write and think about media queries.

2. Start using Grunt. 

I know, I know. Grunt is weird and hard, even though Chris Coyier told you it isn’t. You still find it too developer-y, or too finicky, or too much effort than you have time for, or all kinds of other legitimate reasons. I completely understand. I tried to “get” Grunt for a long time before it finally clicked for me. But now, after just a few months, I’m quite comfortable with Grunt and hate working on projects without it.

My best advice for getting started with Grunt is this: just get it to compile your Sass for you. No more than that. Don’t worry about compiling Javascript, or minifying  or uglifying or anything else for the time being. Just get Grunt to watch and compile your Sass for you as you write it and get comfortable. If you follow that 24ways post, you shouldn’t have too much trouble getting going. If you get errors just google them and work through it. I swear it will pay off in the end. If you’re a WordPress theme developer, I’d strongly, strongly recommend using 10up’s Grunt starter theme. It’s extremely bare bones (you’ll see what I mean when you install it), but it will give you a great example of how to set things up when you get a little more familiar with Grunt. Combine the barebones setup with templates from Underscores, and you’ll be a theme master in no time.

Why? 

I was happily writing css with less for years, and before Grunt I was very happily using LiveReload to compile it for me. But Sass and Grunt are much more than a replacement for these things — they’ve opened me up to so many more tools and workflows and best practices that I didn’t even think about when I started. The Grunt ecosystem is massive — filled to the brim with useful tools for so many things that you’d want to do. But until you start to use Grunt in even a basic way (like compiling Sass), you’ll never be exposed to any of it.

These days, I use Grunt for all kinds of things: processing and minifying Sass and Javascript, making sprite maps, cross-browser testing, highlighting unused css rules, minifying images, and much more. It will become an essential tool once you get over the initial hurdle.

I’ve been pretty shy on details here because a post like this could almost turn into a book if I started going through examples and how-tos, so I’ll just end it here. I wish I’d read exactly this advice on January 1st 2014 or earlier.

ps: #1 Like most people, I actually use the scss syntax.  #2 I have no idea if it’s SASS or sass or Sass / LESS or less or Less.

Working remotely

In the wake of a brewing storm around an essay from Paul Graham about immigration (of all things), I got thinking about the last three months at work.

Graham argues in Let the other 95% in that immigration laws in the US (and likely Canada as well) are excluding 95% of the best programmers from emigrating and working with all the great companies in the US. Many have since argued that through effectively building a remote workforce, these 95% are still available for hire. Matt Mullenweg started it off:

I started working remotely with 10up in September and thought the three-month mark was a good time to reflect on how things have been. Some observations:

Working remotely is extremely flexible. This has been unbelievably good for me. If I need to take our little guy to the doctor one morning, I just tell my team when I’ll be back and fit those hours in later in the day. No problem. I can also go for a run or work out whenever I want. I can put supper on in the afternoon before my wife gets home from work. It’s a huge plus.

Working at night “counts” now. For as long as I’ve been computer-ing, I’ve been working at night. Client projects, personal projects, redesigning this site, learning something new, etc. My wife is a teacher, and spends time most nights preparing for the next day, so we both generally do at least some work every weeknight. Now that I work remotely, I can fit in 2, 3 or 4 hours in a night to catch up on hours that I’ve missed for whatever reason throughout the week. It’s fantastic. This time I work in the evenings “counts” now, adding to the overall flexibility benefit.

In the past three months, I’ve worked on some crazy projects, for some huge clients. I’ve been exposed to tools I’ve never heard of, and (quickly) sharpened my skills in the tools I’d been using all along. I thought I knew Git before starting at 10up, for example, but I really, really didn’t! Within two weeks, I’d made a thousand mistakes and really fixed and solidified my workflow.

The range of people I work with is incredible. Almost every day, someone will try and convert me to their favourite tool or way of doing something. Having access to so many knowledgable and experienced people keeps you constantly curious and on your toes.

Communication is lightyears ahead of (the) standard offices (I’ve worked in). When you work with people all over the globe, you just need good communication tools. At 10up, we use the best tool for every job. People are constantly evaluating new tools for meetings, calls, screensharing, group chat, etc. The combination of all these tools allows me to collaborate much more efficiently with my co-workers than I ever have in a standard office. There are very, very few emails, and 99% of communication happens in real-time via HipChat or a face-to-face Google Hangout.

chicago

Team meetup in Chicago, Oct. 2014. Also definitely in the “pro” category.

 

So those are all the pros, but what about the downsides? Honestly, if you’ve been reading along, waiting for the bit about being isolated from co-workers and longing for “real” interactions that you have in normal offices, I don’t have it. At least not yet. I feel extremely connected to the people I work with — and generally to the outside world as well. Granted, it’s only been three months, and I may feel very different in a year’s time, but so far it’s really been great.

If I had to list one downside — or more of a difficulty really — it would be dealing with timezones. In Newfoundland, we get the first sunrise in North America, so I’m often up hours before my west coast co-workers. It can be a bit of a challenge when I need to ask them a question, but have to wait till lunchtime for an answer, but it works both ways. If I want get up and go for a run, and start my day at 10:30am that works perfectly. Doing this in a regular office setting is almost impossible — unless you want to get up at 5am.

So that’s how remote work feels, three months in — just great. If you’re getting discontent at your current office situation, you should have a look around for remote opportunities. Honestly, the idea of working remotely seemed absurd to me just a year ago (actually, it still kinda does). I thought it was only for people in San Fransisco or Portland. But really, it’s a very legitimate option these days for certain careers. If you’re actively searching, CSS-Tricks has a new job board, and WeWorkRemotely is a more established board. Have a look. Of course, if you’re into WordPress, you should definitely have a look at 10up!  

Movin’ on up (x10)

If you follow along in the WordPress space at all, you’ll almost certainly have heard of 10up. They’re a very quickly growing digital agency, focusing almost completely on WordPress. This has been in the works for a while now, but I’m finally happy to report that I’m one of 10up’s newest team members! I’m really looking forward to meeting and learning from some of the sharpest minds in WordPress. It’s only been 3 days so far, but already I’ve met some of the smartest, nicest people you’ll find anywhere.

In the meantime, that means that the shop is closed to new clients here at WaterstreetGM. If you have new projects though, feel free to get in touch — if they’re a good fit for 10up then I’ll send you up the ladder here, or if not, I may have a few friends who can help!

Last, if you’re thinking about taking the plunge into a new job, 10up is always hiring. Let me know and I’ll put in a good word for you  :^)

 

Wrestling with the WordPress Toolbar

Of all things WordPress that I do, dealing with the Toolbar has to be the most tedious. I’m never happy with the defaults (Themes, Widgets, Plugins, etc…). I only typically use those during site setup. Here’s a dead simple tidy-up that should serve you and your clients.

 
**
 * Clean up and add items to the Toolbar
 *
 */


function waterstreet_remove_admin_bar_items( $wp_admin_bar ) {
	$wp_admin_bar->remove_node( 'themes' );
	$wp_admin_bar->remove_node( 'menus' );
	$wp_admin_bar->remove_node( 'customize' );
	$wp_admin_bar->remove_node( 'widgets' );
	$wp_admin_bar->remove_node( 'background' );
}
add_action( 'admin_bar_menu', 'waterstreet_remove_admin_bar_items', 999 );


function waterstreet_add_admin_bar_items( $wp_admin_bar ) {
	$args = array(
		'id'    => 'pages',
		'title' => 'Pages',
		'href'  => site_url(). '/wp-admin/edit.php?post_type=page',
		'parent' => 'site-name',
		'meta'  => array( 'class' => 'all-pages' )
		);
	$wp_admin_bar->add_node( $args );
}
add_action( 'admin_bar_menu', 'waterstreet_add_admin_bar_items', 999 );


That first function waterstreet_remove_admin_bar_items works just as you’d expect — it removes items from the main “site-name” dropdown. The second function adds back the items you want.

If you have more than one item, you can just put one after the other in the function:


function waterstreet_add_admin_bar_items( $wp_admin_bar ) {
	$args = array(
		'id'    => 'pages',
		'title' => 'Pages',
		'href'  => site_url(). '/wp-admin/edit.php?post_type=page',
		'parent' => 'site-name',
		'meta'  => array( 'class' => 'all-pages' )
		);
	$wp_admin_bar->add_node( $args );

	$args = array(
		'id'    => 'posts',
		'title' => 'All my Posts',
		'href'  => site_url(). '/wp-admin/edit.php',
		'parent' => 'site-name',
		'meta'  => array( 'class' => 'all-posts' )
		);
	$wp_admin_bar->add_node( $args );


}
add_action( 'admin_bar_menu', 'waterstreet_add_admin_bar_items', 999 );

Ideal line length

I had a discussion the other day about ideal line length for reading content. I’ve got an ideal number in my head, but I wondered if there was any consensus out there on how long lines should be. With so many sites going responsive these days, there’s a tendency to let the max-width on the content container be huge — often upwards of 1200px. That’s just way too wide for me. On sites that do that, I’ll normally resize my browser window to pull things together a bit better. Seems to matter less for others, and some research is indicating that it matters less online overall.

It certainly matters to me! Google “ideal line length” to find more than you’ve ever wanted to read on the subject.

Out of curiosity, I went to some of the sites I visit with some regularity. Here’s what I found:

Seems that at least the news sites are in alignment with where I like things to be.