Moving from Designer to Development Team. A primer.

On my first day working at OrgSync five years ago I brought a Ruby on Rails book with me … and the developers chuckled, saying it wasn’t worth the time. As a just-out-of-college web designer without any production-level app experience — they thought I wasn’t going to ever be an integral part of the code side of things. Over the last five years no one’s pushed more code to master than this lowly designer has. Here’s a few things I’ve learned about working as a designer on the development team:

Developers Love Code.

Like they really love it. The way you love perfectly placed pixels. So be nice to their code. Treat it with respect. They don’t jump into your photoshop and play with your layers so don’t jump into their world and tinker with things you don’t understand. Indent your code. Match their styles. Follow naming conventions. When in doubt, copy their code. Leave comments when necessary. Sometimes we don’t learn all these rules in design school.

You will learn to love code.

While you may never love it as much as they do, writing clean code will make sense, it will be something you strive for. In this day and age of developer/designer combinations writing clean code is a part of your job description. There is a small difference between the code quality standards of that wordpress theme you’ve customized for your mom’s church group to writing production-ready code for a web application, so pay attention.

Push.

Push code up and get it reviewed constantly, push in small chunks because they’re easier to review and digest. But also push the envelop on the types of code you are writing, then walk a developer through what you were thinking when you wrote it. You don’t have to stay in the markup & css bubble. Maybe your branch is running behind because a developer can’t get to it — I give you permission to take a shot at it yourself (of course, then get it reviewed).

The worst case scenario you have for pushing code for review is that you get something wrong, have to revert it, and then you learn something.

Find your safe place, and then make it grow.

Working in a production environment is scary. What if you break the site? What if you push that line of code that brings everything to a screeching halt. Learn what it’s safe for you to touch and what you need more eyes on before deploying. Having a firm understanding of what is ‘dangerous’ and what’s not will let you move quickly, nothing hampers your progress than every deploy feeling scary and not pressing that deploy button. The real reason you want to do this though is so you can be self sufficient, you won’t keep your deploy privileges very long if you bring the site down all the time.

Learn the tools

I had never really used the command line before, I had never worried about things like asset compilation, or the scripts we use to deploy. You’ll have a completely different set of concerns working on an application than you would on a small site on your own. Embrace the tools the developers use because if you don’t you will be lost and you won’t feel comfortable developing along side of them. If I was not able to play around in our database, or manipulate objects in a console, or just interacting with our dev-environment servers I would never be able to troubleshoot problems without a developer’s eye — I would be inefficient and they would be annoyed.

Become a developer

You’ve heard it before but I agree — designers need to code. They need to understand what is going on when the developers are talking. It will help them when they’re working day-to-day —- but it also helps the product by allowing a designer to have input in the higher-level development discussions. Let’s be honest, the developers need help sometimes and the best way to give it to them is to be a contributing member of the discussion.

In the last five years the developers have also made it easier on me, we have come to a sort of middle-ground on how our processes fit together and we’ve melded into one functioning unit, and that’s the important part, to stop considering yourself as an extra piece separate from the development team but an important cog to make the wheel spin around.