Breaking Stuff – A List Apart


Do you know that horrible fear when you’ve broken something on a client project and you have no idea how to fix it? I do… Sometimes I’ll have been wading through templates on a site, getting it all up to scratch, then suddenly I’m faced with a page of doom—a whole page of garbled semi-English that sort of resembles an error message, but nothing I’ve ever seen before.

Article Continues Below

As a freelancer, I’ve always been proud to have the time to dedicate to learning. Keeping up with the industry, and being able to level up my skills on each new project, is very important to me.

But sometimes I struggled when I pushed myself that little bit too far. A few times I’ve had to request a lifeline from kind people on Twitter to pull me out of a hole. And then I feel a bit daft, having to admit my inadequacies on a social network in order to save myself from a worse situation.

Some of us designers write code, and some of us don’t. For some designers, the limit is HTML and CSS. They’ll write markup, but they won’t write JavaScript. For others, it’s front-end technologies. They’ll work on the client-side, but avoid anything with databases and other back-end technologies.

Most of us seem to have a boundary somewhere that defines what we think we can’t do. Working for and by yourself, you are limited by your own experience and skills.

For me, it was the all-powerful and uncommunicative command line. It terrified me. I thought I would probably find a way of deleting everything on my hard drive if I made a typo in the command line.

My fear of the command line was burdensome when it came to using Git. A lot of people I knew used Git on the command line, but I preferred to use a GUI tool. I found it easier to understand the concepts of staging, branches, pushing, and deploying with a visual representation of the actions.

However, when I was using Git with the rest of the ind.ie team, trying to debug issues when I’d committed files to the wrong branch, I was assisted by developers who would fire up Terminal (the command line tool) to look at the problem.

The wonderful thing about working with these developers is that they’d explain what they were doing as they went along. I wasn’t expected to sit quietly to the side until they’d used magic to fix my problem. I would stay in my seat, and they would dictate to me what I should type. Typing for myself, and understanding what I was typing, I was learning to do it for myself.

Learning from other people in this way is a rich and rewarding experience. I started being able to use Git on the command line with confidence. Having seen Andy, one of the developers I was working with, look up some of the less-obvious Git commands on the web, I suddenly didn’t feel so exceptionally useless. It gave me the confidence to do the same without feeling like I was a failure because I didn’t know all the commands by heart.

My developer safety net made me more willing to try new things. Now, when I’d come up against intimidating error messages, I had people who could easily rescue me in five minutes, rather than having to put out a call of shame to Twitter.

But my confidence wasn’t exclusive to ind.ie. Feeling more secure in my new abilities improved my confidence in my client work. I knew I was now able to do loads of stuff with Git, so why could I not handle some of these other problems?

One day I found myself debugging a JavaScript error through comparing the code with another page that was working. I fixed it! Me! Doing JavaScript! My confidence grew that little bit more.

Stepping over the line#section4

Job titles can be used to put us in our place. I’ve been told I’m just a designer, so I shouldn’t do development. You’ve been told you’re just a developer, so someone else will handle the design. It’s too easy to forget that we’re working on this web platform together, and a crossover of skills is incredibly valuable.

Technical problems shouldn’t just be reserved for those with technical job titles. As designers, it’s our job to be familiar with our platform. Print designers know a lot about paper and inks, and architects know about building materials and regulations. Web designers should understand their medium, even if they sometimes need a hand with the tricky stuff. Other industries have their parallels: prepress technicians and building contractors are available to help designers pick up the technical details.

Exploring the working environment#section5

You’ll get a lot more out of your job if you don’t feel like your job title has put you in a box. It’s fun to learn new things, and explore unknown territories. Get in an environment that pushes you, but gives you a safety net. You owe it to yourself to learn more, be ambitious, be better at what you do, and strive to be the best you can be at your craft.

You wouldn’t like it if someone else said you were “just a designer,” so don’t say it to yourself.

Scroll to Top