Breaking the rules

I recently had the pleasure of collaborating on a bit of responsive front end / WordPress work with a colleague at Thrillworks. This highly experienced developer’s strengths lie mainly in back end, so I played a supporting role initially, and took over the project when he went on vacation. Collaborating always proves to be a massive opportunity for learning, and this didn’t disappoint.

Through tag-teaming on code I learned about one of the most important rules about being a front end developer.

Teaming up with a senior back end developer was especially interesting. If our roles were reversed and I was required to do some high level programming the results wouldn’t have been a fraction as impressive as the work he did here.

When I took over the final leg of development I learned a lot about the way I code by looking at this very left-brained approach to front end development (and particularly responsive layous). I find I underestimate how many gotchas I know; and front end development is full of them. One thing I do differently really stood out when I compared our approaches: breaking the rules.

The rule about breaking rules

Photoshop is one of the most wonderful tools in the industry, but it’s also capable of being a complete fantasy when it comes to replicating what the browser is going to do in reality. Sometimes it’s a complete lie! My back end developer friend built a site following the comps nearly perfectly – but in some cases I believe it would have been better to actually ignore them!

(I love saying that out loud.)

I started at Thrillworks on the design team, so somehow I have the brazen gall to ignore the direction of the designer and build something differently. I feel entitled by my experience as a designer, and almost every single time the designer agrees that these decisions are practical for the build.

Here are some reasons I like to break rules:

LESS CODE
Some modules would require dozens of media queries to look 100% great at every resolution, alternatively they could look 85% great (still an A!) with only 2 media queries. This is way more maintainable and scalable.

LESS ASSETS
I don’t like to use images where I don’t have to – particularly if they’re 100% text images. If I can have a module equally functional, but just look slightly less cool I will. This is a battle I only wage when brand guidelines are on my side 😉

LESS EFFORT
One of the first lessons they taught us in graphic design was to actually be lazy! There’s no sense in reinventing the wheel. This of course can be taken way too far, but applied sensibly this is the difference between a project being profitable and meeting a deadline.

I’ll admit this can sound terrible, so here’s a simple example to illustrate what I mean: I recently ran into a case where a CMS would output image captions a certain way. By skinning this rather than implementing a much more labour intensive direction we saved hours.

Breaking in new rules

When my peer went on vacation I inherited some feature requests and realized that I could cut the work in half if I gave the front page a major overhaul. I ran this by the designer before starting and told him I’d stray from the comp in “that way that I do”. His response made my day: “I wouldn’t have it any other way!”

It took me years to get to this point however: A decent track record, proven results, and most importantly trust are needed to make this fly. Even then, I don’t get my way every time. In my experience though, it’s ALWAYS appreciated that I am looking at the big picture, and trying to think of efficiencies while hitting all the project’s objectives.

It’s not how you do it, but what you do. Whatever it is, you can sometimes do it better if you break the rules a bit.

Categorized in: Personal

This post was written by ArleyM