Open jackmakesthings opened 9 years ago
patrickbjohnson
commented
9 years ago Truth to this!!! So many times have I found myself in a position I've trying to "stir change" to be thwarted. This this is a great idea to a very common (I assume) problem that proposes practical solution. Would loveeee to go to this talk!
misscs
commented
9 years ago The take away from this exciting and so relevant to many and even to me on a personal level with my work. I really like how this talk focuses on leveraging the features of Sass to manage work/process constraints
Polyfill your Job: Tips for doing great work (in not-so-great situations)
Working title, anyway. Might revise.
Type of Presentation (required)
[ x ] Standard Length Talk
[ x ] Lightning talk (second choice, if all the full talk slots are taken)
Description (required)
There's no shortage of ideas out there about all the ways developers should make design choices, all the things we can do to make our projects run smoothly, all the workflows and strategies and tools we can embrace. There has never been a greater wealth of information out there about how to craft a design system, or direct a work environment, or negotiate with clients. And that's great!
What I don't hear being discussed is what to do when that's not an option. The question gets asked sometimes, but the answer always seems to be one of two:
or
Last September, I left a company of 5 to work at an agency of 500. Suddenly design isn't up to me and the one designer in the room. Suddenly, if I want a different workflow, it's not a matter of just telling the person next to me what we should change. I can make all the same points and arguments as ever, but if I'm calling for change, I have to do a whole lot of convincing. And waiting.
I know I'm not the only one in this position, so I'm hoping I can share my experiences and help out others who want to improve the way they work, but may not be able to win (or even fight) every battle along the way. In other words, making the best of what you're given.
One example I'll talk about involves working with designers who were prone to doing their designs in Photoshop. We'd code from that, and upon seeing how those designs looked in an actual browser context, the designers were constantly asking for small, arbitrary changes. You know the kind. "Can we see it with this button five pixels lower?" ad infinitum. For myself and my fellow front-enders, this was a source of constant frustration - how could we keep the designers happy without sacrificing the modular, consistent code we wanted to write?
The solution we landed on was _specs.scss - a file, and later a multi-file pattern, for keeping tabs on just what our designers asked for. Whenever they specified a dimension - any dimension - it was recorded as a list of three values, one for each breakpoint we were addressing. Soon we had a whole set of variables that looked like this:
and a lot of declarations like:
and this did two very useful things:
One, it gave us a record of who had strayed from the original designs, where, and when. specs.scss was strictly for numbers the designers gave us - no inferences or best guesses on our part. In a way, it kept the designers accountable, and helped cut down on those "I don't know, it just doesn't look right"_ debates.
Two, and this was arguably even better, it helped us find consistency where there initially seemed to be none. With all of our specs gathered and formatted that way, it was suddenly much easier to find patterns and places of repetition, and in some cases even to enforce a standard. If our designer wanted something 35px tall in one place and 40px tall somewhere else, we could now see that and question it, and make a concrete case for unifying the styles. It became both a tool for analysis and a starting place for conversations with the design team.
(That's just one example; there will be several more. I can talk about the times we called the designers over and showed them how to tweak things in Dev Tools, or some of the ways we explained things to bosses/designers/content providers that helped them understand what we needed from them, or the refactoring we did once we knew where we had more flexibility...I have a lot of stories and a lot of solutions to problems most of us run into at some point. )
The key takeaway: Our designers didn't really change how they worked. Our company, our department, none of that changed to suit what we wanted. That wasn't really an option we had. So we got creative. We leveraged Sass and its structures to shape the aspects of the project that we could control, and in the end, it worked out pretty damn well.
Ultimately, I want to give a talk that leaves people feeling optimistic and empowered, especially those who can't or are uncomfortable with the premise of stirring up change in a large organization (as well as those who are trying; these things can move slowly even at the best of workplaces). I want to use practical examples and experiences to illustrate that even when we aren't our own bosses, even when we don't have the final say in all aspects of our work, we can still find ways to use what we know and create code we're proud of.
Speaker Info (required)
More Info (optional)
Social Media:
Bio:
I'm jack. I'm a front-end developer and code enthusiast, and frankly, I never saw that coming. I wandered into the world of code, coming from a fairly traditional graphic design background. These days I'm a Web Engineer at Huge, working in Brooklyn, living in Queens. When I'm not coding, I'm usually teaching others about it, reading up on the web, or building something in my apartment. (Or, I'm trying to code, but can't, because there's a cat sitting on my laptop.)
Photo: