Causa Justa is an Oakland-based organization fighting for housing rights, immigration rights, and racial equality on behalf of Latinx communities in Oakland, CA. These are all issues which I’ve spent a great deal of my 3 decades on this earth examining, analyzing, and fighting for. I would be honored for any donations made to Causa Justa on my behalf. Everything helps.

If you work at a company which is matching charitable contributions, consider donating there, i.e. Benevity. Apple has matched my 3k contribution with an additional 6k, bringing the total thus far to 9k.

I’d like to contribute another 3k from friends and family. Let’s give this bread.

Thank you all for being a part of my journey. I’m grateful for each of you.

How with one too many drinks or one dark thought my reality can be shifted to a inescapable place of pain and heartache.

Pain has always had a home in me. And it likely always will. It lays dormant on days when I am much too busy to acknowledge its plea. Begging me to indulge in its truth.

To scratch it’s belly and to stroke it’s spine.

It curls up at my feet while I attend to my routine. Sometimes I might forget it’s there but it’s hair is no less tangled or matted than it was four, five months ago.

I just hold my head a little higher. Just so it’s out of sight.

It works, too, until we lose the lights. Then my senses wrap around it and I know we’re here…alone with one another again.

Pain is my prickly partner and my best friend.

My literal ride or die.

Stay tuned on Twitter (@nrrrdcore) for updates (or feel free to just say hello!). If you’re looking to connect with me elsewhere on the Interwebs, you can find me on Dribbble, and/or Instagram, or at my personal email address jannhorvath@gmail.com.

Read on to learn more about my past work experience, educational background, and passions related to design and web development.

Hey there, I’m Julie. Friends call me Jules. My mom calls me Juliebug. And my Spanish speaking friends and family call me Julieta. If you’re reading this post (Thank you!), it’s likely that I’m interested in working with you.

A little about me: I’m a multi-disciplinary product designer who enjoys designing and building user interfaces that help make information accessible, consumable, and beautiful.

I’m a designer who codes. But that doesn’t make me any less of a designer. In fact, coding and thinking about design through the lens of dynamic and component-based systems allows me to design scalable and usable experiences that don’t just look good, but feel and function well, too.

My educational background in writing and literature introduced me to the world of design. It empowered me to develop and hone the skills to design successful products around the foundation of every good user experience: words. Throughout my career, I’ve found that my passion for design always comes back to the ability to enable all people to use, access information and resources, and publish on the web.

I’ve had the opportunity to work for some tremendous companies doing great work in these areas. Some of them are:

Clef

June 2015-Present

As Clef’s Head of Design I lead and execute design work across the Clef native mobile applications, developer tools, and consumer-facing websites. In addition to UX, UI and Visual Design work, I’m directly responsible for growing and iterating on the Clef brand. In my short time working at Clef, I’ve managed to design, build, and ship a brand new mobile experience for logging in with Clef, an improved developer dashboard experience for users who want to install Clef on their website, and new pages on getclef.com to launch features like Distributed Authentication and our new pricing model, all under tight deadlines.

Some other projects I’ve worked on during my time at Clef include the standardization of our CSS and a front-end styleguide, contributing to our blog, Two Factor Authenticity, as well as experimenting with an interactive web security project for which I created assets and animations and prototyped with animate.css and wow.js.

Amazon

March-June 2015

While freelancing in early 2015, I had the opportunity to work with the Browse User Experience team at Amazon. Originally contracted to teach two junior designers to code and design-in-browser, after a successful bootcamp, I then stayed on with the team to design widgets for Amazon.com’s browse pages and to build out a responsive library of customizable components with CSS/SCSS, HTML, and Middleman to empower rapid prototyping in-the-browser for the team.

“As the manager of a team UX designers and web developers, I know first-hand how hard it is to find people who are truly exceptional at either craft. But Julie is truly remarkable and rare: she not only raises the bar as a practitioner of interface design and front-end development, she’s also a passionate and inspiring mentor with a proven track record of helping others improve their own skills. Not only did Julie do excellent design work on my team, creating interfaces that Amazon shoppers around the globe used in a variety of different retail categories, she also taught two junior designers with no previous coding experience how to design in the browser, prototype with HTML, and collaborate with my web developers on production front-end code. Julie’s impact as a mentor and a design leader was profound, not just for the designers she was teaching, but also on the entire team, who got to benefit from the significantly increased quality and quantity of design work output. The only regret I have from my time working with Julie is that I wasn’t quick enough to open a full-time position before she moved back to the Bay Area!”

PJ McCormick, Design Manager, Amazon

&yet

March 2014-January 2015

As &yet’s Senior Designer, I redesigned our customer-facing website to improve the way in which we communicated, through design, the products and services our consultancy offered, how we reached and effectively engaged with our community, and how our website and products generate new business.

“Julie is an outstanding designer and front-end developer…[She] works extremely hard and seems able at any time to engage a mental focus gear that few people get to. After strategy conversations with Julie, I often left with a long list of new ideas and a whole lot to think about. She is driven to write cruft-free copy. In the best way, she’s positively ruthless as an editor — keeping the copy always focused on the goal. She is driven to make whatever she’s working on better, clearer, sharper, more effective. Julie is sharp-minded — one of those people who is already about five steps ahead of everyone in the room. She gives detailed, cogent feedback and is always able to make a strong case and explain her points when expressing an opinion — but she is also eager to listen and open to having her mind changed.”

Adam Brault, Founder and President, &yet

Read the full recommendation on LinkedIn

GitHub

March 2012-2014

At GitHub I delivered on several different projects ranging from marketing sites for new products and features, well-designed documentation for open source projects, GitHub.com, GitHub for mobile, the GitHub Blog, and GitHub Enterprise, as well as internal tools to enable our (mostly remote) team to communicate more effectively.

I was also responsible for launching and running GitHub’s first diversity initiative, Passion Projects, as well as its first free public speaking workshop for women where we brought together a diverse set of mentors, public speakers, and leaders in the web community from around the world to work with aspiring public speakers in the SF tech community.

I was a well-recognized diversity advocate and public speaker who represented GitHub at conferences all around the world to speak about effective design tools and processes, the GitHub “flow”, designing in-browser, and the importance of working as a team.

“[Julie’s] creativity, technical experience, and willingness to build up the people around her made her an fantastic collaborator who I would love to work with again. Julie combines an intentional approach to understanding and reasoning about a problem with creative vision for getting to a solution. Similarly, she balances thinking about problems at a high level with diving into the details when a solution comes into focus. Her talent as a designer/developer has been honed by experience on a wide variety of projects, and her skill at making complex applications into a conceptually straightforward UI has been demonstrated again and again. Additionally, her developer background has made her an easy collaborator across the team.”

Rachel Myers, Software Developer, GitHub

Read the full recommendation on LinkedIn

Yammer

February 2009-August 2011

As an early employee at Yammer, I served as a technical resource for the marketing team where I built Yammer’s first lead generation system using HTML marketing campaigns, static web pages, and free resources like Webinars and other materials generated and designed by our team.

I was also responsible for aiding our Senior Designer in designing and building everything from printed sales sheets to billboards to online ads and landing pages.

“When I first started working with Julie, when she was intern, I thought “She would make a fantastic copywriter.” Then after awhile I realized she would make a fantastic anything. I’m excited to see what she does next and look forward to (if I’m really lucky) someday hiring her for myself. Because she will totally rock the anti-matter plasma ray at my secret Mars base.”

Thea Boodhoo, Content Strategist, Yammer

View this recommendation on LinkedIn

Community Is Everything

In addition to having designed and built products for some great companies, I’m also an active advocate for diversity and inclusion in the tech industry, a volunteer, an advisor and a published author online.

I currently help organize the Oakland CreativeMornings chapter, and I sit on the Board of Directors of the print publication Nat. Brut, “a journal of art and literature dedicated to advancing equality and inclusivity in all creative fields.”

I also write here on Medium and have recently had pieces published on the Absurdist, on my personal Medium account, and again, on Two Factor Authenticity.

Exploring Ideas Through Writing

Beyond writing specifically to publish and share with my peers and communities online, I do a lot of writing around product design. I find a lot of value in writing about design problems and potential solutions. When I started my most recent position at Clef, I focused on building a healthy amount of writing into my product work both to draw ideas out and onto paper, but also in an effort to engage other designers and engineers in my process and to get early buy-in on product direction from stakeholders and co-conspirators alike.

In addition to writing, I tweet about and start discussions around good examples of user-experience design on the hashtag #UXSCHOOL.

Other Human-Type-Things

Outside of designing and building neat stuff, I dabble in cooking, playing Pokémon cards, hanging out with my dog, King Pup, and rock climbing.

I also love to read. A few of my favorite authors are Christopher Moore, Chuck Klosterman, and Flannery O’Connor. In addition to creative fiction and pop culture criticism, I have a lot of love for graphic novels and comics, most recently Monstress, written by Marjorie Liu and illustrated by Sana Takeda.

What’s Next

I’m looking to work with a team of awesome designers to build products that empower and connect people. Some things that are important to me when working with other people are: Trust, respect, openness, and a collaborative working environment.

Thanks for taking the time to read my résumé. You can find a condensed PDF of this résumé here, online portfolio here (full high-res portfolio on Dropbox), and a live version of my work experience on LinkedIn. If you’re looking to connect with me elsewhere on the Interwebs you can find me on Medium, Dribbble, Twitter, and/or Instagram, or at my personal email address jannhorvath@gmail.com.

What is it exactly?

It is the discrimination and harassment that Women in Tech experience in the workplace.

A small note: This is the first part in an ongoing series about workplace harassment and the toll it takes on Women in Tech. I reached out to my followers on Twitter to see if anyone would be willing to talk with me about their own experiences with workplace harassment and discrimination and was overwhelmed by the responses. I’ve decided to write a series of pieces that address harassment in tech and to help some of these women tell their stories to the world, anonymously.

Falling Out of Favor

One of the most dangerous things about speaking up about harassment and discrimination in the workplace is falling out of favor with our peers. In an interview I gave to Model View Culture last year, I mention that speaking up internally at a company comes with a ton of risk.

“If you raise awareness [internally] about one issue, and you want to keep your job, you can do that like once in a year. Otherwise it becomes less credible, and that’s fucked up because we’re only allowed to share a little bit of what we’ve been through.”

Speaking up internally is scary. But you don’t even have to raise concerns around sexism per se to risk falling out of favor. Even participating in “diversity work” or pointing out the underrepresentation of women and other minorities in your workplace can put a target on your back.

“I’ve had things said about me like ‘I don’t think [she] actually cares about getting more women in engineering. she’s just using this as a political play to gain power in the organization.’ But I don’t even know who it was. Or if it was my manager hiding under the guise of anonymous feedback.” — Anonymous Woman of Color in Tech

Vocal women are often labeled complainers. And it’s scarily common to have coworkers and even managers accuse you of doing diversity work as a means to gain power. Tech companies too often make witches out of vocal women. You don’t necessarily have to be told you’re not welcome to start feeling alienated in the workplace, either.

Not comfortably being able to bring up concerns in your workplace and have those concerns addressed in a way you feel is productive and fair can take a huge toll on you emotionally and psychologically. When raising concerns also makes it harder to do your job, the problem becomes much more complicated and the risk of losing your job can escalate very quickly.

“If you weren’t on the good side of upper management, it was a pretty hard place to work.” — Anonymous Woman in Tech

When We Choose To Speak Up

When you become that woman, the complainer, the social justice warrior, people start taking your actual work, you know, the job you get paid to do, less seriously. You’re stripped of your responsibilities and in a lot of ways your agency. People rarely talk about this part. You could even be the public-facing image of diversity at your tech company and still be disrespected, discredited and have your work trivialized.

At this point it rarely seems like you have any option other than to leave and start over someplace new.

The Non-Disparagement Agreement

So what happens when you want to leave? Well, friends, if you’re a white dude? Typically, nothing. You say your peace, do your exit interview, and make your way on to your next venture, all bridges still standing.

If you’re a woman? If you’re someone who has filed as few as one complaint with HR?

“The non-disparagement agreement issue is such a big deal. I don’t think people realize how many times a non-disparagement agreement is brought in right away when there is wrongdoing that’s happened and discrimination and inequality is involved.” — Shanley Kane, Founder and CEO, ModelViewMedia

I have several friends who are Women in Tech who have signed non-disparagement agreements with popular tech companies. Some of these companies are even ones we talk about as leaders, unicorns, and having great company cultures. They are companies the industry continues to laud for their work in diversity and the releasing of their dismal diversity numbers.

“A week [after sending a complaint to HR], I was given an offer for a chunk of money attached to a gag order, which I turned down, and [I was] told I had to leave the company immediately. [I] left with very little money…I simply can’t defend myself against a multi-million dollar corporation’s legal team, or afford to get blacklisted from my industry (which happens, all too often).” — Anonymous Woman in Tech

Not all of us can say no to the money that often comes with a non-disparagement agreement. And in my opinion, there is absolutely no shame in taking it. None.

Sharon Wong on Twitter

@EricaJoy @nrrrdcore said it much better in a post somewhere -- the folks who have important stories to tell are the ones who need the $$$.

As a result of my experience being so public, women often reach out to me when they’re dealing with difficult situations in their workplaces. Some of them are dealing with more nuanced discrimination and some of them have been repeatedly sexually assaulted by their coworkers. Again, all at popular tech companies.

When women ask me whether or not they should take their stories public, like I did, I mostly advise against it. Sure, sometimes it feels right, like it’s the only thing you can do to protect yourself. It may change the way people look at the company where you experienced harassment, but it won’t get you justice. It may stop the same thing from happening to the next woman who joins said company, but it won’t help you heal.

What does happen? You become a public spectacle. One that any and everybody within shouting distance of your industry will feel entitled to comment on, dissect, and analyze. Both your professional and personal lives are dragged out into the open and scrutinized by strangers online. You receive death and rape threats.

Temporarily, you lose your faith in humanity.

I tell women who come to me for strategic advice that the best thing they can do is to take care of themselves first. As much as I like to see companies held accountable for how they treat their people, I like to see other women living their best lives a hell of a lot more.

Would I Do It Again?

I honestly don’t know if I would.

Shortly after I began receiving rape threats in 2014, I was diagnosed with PTSD. I could no longer be intimate with my partner. I had repeated episodes that left me laying on the floor clutching my chest because I felt like I couldn’t breathe. I couldn’t sleep. I couldn’t eat. And I wanted to die.

I couldn’t imagine life ever being OK again.

And so, at the request of my friends and my family, I chose to move on. To start fresh. Much, I’m sure, to the relief of my harassers and the people who victimized me the same.

A Different Path

It takes a much stronger person than I am to seek justice. It takes someone who, in a moment of incredible pain and uncertainty, can see a clear path to it. It takes a stronger person than I’ve ever been to know and truly accept that they deserve justice.

This is what left me in awe of Ellen Pao this past year. It is why I will always feel grateful for her journey and her courage. When one of us fights this battle, whether they win or lose, they’re fighting for all of us. They’re fighting for those of us who couldn’t risk our careers, what little resources we have, and/or our health. They’re fighting for those of us who, because of our circumstances, felt like we couldn’t.

A Friend Who Needs Your Help

My motive for writing this piece is not purely to share my own or others’ experiences with you. I wrote this piece for two very specific reasons:

1. To remind you that just because you don’t read about it on Twitter or on TechCrunch, doesn’t mean women aren’t still being harassed and discriminated against at tech companies.
2. To help raise money to cover the legal fees for a friend who was fired from her workplace after years of dealing with discrimination.

In her own words:

“I’m a Black woman in tech who is raising legal funds to fight an ex-employer over racial discrimination…After a year of struggling (couchsurfing, not being able to afford to eat for weeks on end), and coming quite close to homelessness (I owed about 6 months in back rent as I couldn’t find a job), I’m finally getting back on my feet. And I’m ready to speak up. And after searching, I’ve found a fantastic lawyer who’s willing to fight for me. He specializes in discrimination cases and he’s willing to work with me, but I need to come up with $7500 for his fees.”

Read her whole story here and please donate what you can afford to.

Thank you to all of the brave women who continue to inspire me to be vocal about my own experience and to use what time and resources I have to build a better industry for the women who will come after us. And thank you to those of you who have allowed and trusted me to help tell your stories.

The Stories of ‘Women In Tech’ That We May Never Hear was originally published in Endless on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here is something I see happening too, too often:

1. Privileged Person speaks or acts in a way that is harmful and/or hurtful to marginalized people.

2. Privileged Person takes structural criticism personally.

“I’ve done so much for your people!”

“Do you really want to alienate an ally?!”

“I’m not a bad person!”

3. Privileged Person feels criticism is unfair based on their own understanding of, and experience with race, gender and/or socio-economic class.

4. Because Privileged Person fears this criticism may damage their “good standing” with marginalized communities, Privileged Person demands marginalized people educate them on how/why their comments are harmful and make him or her feel better.

Criticism that addresses an oppressive power structure or system is never personal. If someone takes the time to criticize something you’ve said or done through the lens of one of these power structures, they are doing so to point out an inequity or an unconscious bias that is being put on display, not to personally “attack” you.

As someone who is privileged in many ways, I have been on the receiving end of criticism with regards to race, gender and socio-economic class. And unfortunately, I have, in the past, reacted in a way that is not productive or supportive to marginalized communities, friends, and peers. But in doing so, and being held accountable for it, I learned an important lesson: Regardless of whether I think criticism is fair or warranted, it is always within my power and my responsibility to listen to, respect, and process it.

While you may feel that you’ve acted in a way that is unoffensive, you may, in fact, be wrong. Don’t be defensive. Don’t ask a friend from a marginalized group to defend or cape for you. And please, please don’t demand that whoever you offended educate you. Just listen.

“Allyship is not an identity — it is a lifelong process of building relationships based on trust, consistency and accountability with marginalized [folk]…an arduous practice of unlearning and re-evaluating.” — The Anti-Oppression Network

Mandatory reading: How To Be A Better White Ally by Ocean Gao.

Your Most Problematic Fave Might Be You was originally published in Be Yourself on Medium, where people are continuing the conversation by highlighting and responding to this story.

You can learn almost everything you need to know about inheriting someone else’s code from the Seattle Underground.

When I moved to Seattle in 2014, I learned a lot about the city’s history. This is mostly because in the year and a half that I spent living there, several of my friends and family came to visit. And they wanted to see things.

Of all the tourist attractions I took my friends and family to in Seattle: Brunch at the top of the Space Needle, Ride the Duck tours on Lake Union, a spin around the Great Wheel, catching fish in Pike Place Market, chilling with the harbor seals at the Seattle Aquarium, the tourist t̶r̶a̶p̶ attraction that quickly became my favorite was the underground tours.

From what I’ve been told on these tours when settlers first colonized the Puget Sound, they built their new city, and consequently also, its sewage system, a little too close to the body of water we now call Elliot Bay. So, unfortunately, when the tide rose so did the city’s sewage, which people quickly grew tired of.

After the Great Fire of 1889, Seattle had a second chance at building a town better-suited for living (and plumbing) and they re-built all 29 city blocks 12 to 30 feet above where its first streets were originally constructed.

Seattle 2.0, as I like to call it, was built on top of the foundation that survived the fire, meaning there were and still are underground passages, buildings, bank vaults, and of course, trap doors, sitting beneath the high-trafficked streets of today’s downtown Seattle.

Guided tours of this “underground” are a big attraction in Seattle’s first neighborhood, Pioneer Square, where I leased my first apartment in the Emerald City.

I loved these tours. The first reason being that these secret corridors gave my new home a real Gotham City/underbelly feel. The second reason was because the tour guides who lead us through them were never anything short of amazing. They made surprisingly funny puns and cracked jokes while we traveled through underground Seattle. They reveled in telling us stories about the seedy post-reconstruction underground scene, where prostitutes threw johns through trap doors after cleaning out their pockets (very my aesthetic) and Seattle’s first madame ran everything south of the byline and accumulated more political influence in her lifetime than any actual politician (also my aesthetic). I’m paraphrasing, but as someone who rarely gets nostalgic about the past, and who often points out that doing so is extremely suspect, our tour guide’s depiction of a woman-run underground sounded like my kind of place. It lit up my imagination and connected me to a new city I had no roots in.

CSS at Clef

I consider myself extremely lucky, my teammates at Clef have done a pretty excellent job of writing CSS over the past few years. They started with a strong foundation (no literally, Foundation), they’ve continued to use sane and practical naming conventions, and everything in our /SCSS directory is well-organized. By the time I joined the team 5 months ago, we were already using a z-index scale à la Medium, we had well-defined and reusable color variables, and things were feeling generally object-oriented. Fresh.

This all said (and deeply, deeply appreciated) our CSS ecosystem continues to grow in complexity with each line of code we commit.

The great/amazing/excellent thing about front-end frameworks like Bootstrap and Foundation is that they give programming-focused teams, especially those without designers, a starter kit for front-end design and CSS. What can quickly become frustrating about them, however, is that in order to deviate from their pre-packaged styles, and furthermore, to do so without ripping the framework completely out of your app, you wind up having to “override” them.

I can’t tell you how many apps out there have styles overriding styles, overriding more styles, overriding even more styles. But I’d be willing to bet it’s a significant number of them. Overriding styles can be a slippery slope. And one that can have a big impact not only on front-end performance, but also on your team’s ability to track down and fix bugs.

Take styles affected by state changes for example. What does a typical nested block of CSS for something like a unique hover state transition on an element or displaying an element on top of varying background colors look like? As front-end engineers, sometimes we’re asked to write CSS that does both of these things, increasing the complexity of the CSS we’re writing by an order of magnitude.

“Overriding” styles to hack together new ones can generate a ton of CSS that’s deeply-nested, over-engineered, and difficult to both read and debug.

Almost every codebase I’ve ever finagled my way into has a measurable and significant amount of technical debt with regards to its CSS. Now that I think about it, assuming and inheriting technical debt is probably the only truly equitable thing about the technology industry.

Throwing it all away and starting completely over starts to look really, really appealing to a problem solver like myself. But let’s take a moment to be super honest with ourselves: Rewriting all of the code in a codebase is rarely a practical thing to do.

Rewriting all of the code in a codebase is rarely a practical thing to do.

Instead, we can consider how the architects of Seattle 2.0 capitalized on the sturdy foundation the Great Fire left behind and proceeded to build a better, stronger city on top of it. Sure, they could have started from scratch in a new place with more protection from the rising tide of the Bay, but in weighing their options and the cost of relocation, they chose to work with what they had. They raised the city almost two stories over the next 17 years, and the Seattle they finished in 1906 is the one that still exists today, sordid tunnels and all.

A Resolution

Instead of tearing or ripping out Foundation from our app and re-writing our CSS from the ground up, we’ve decided to write down a set considerations and standards for our CSS that we can work towards and aspire to. Our very own CSS 2.0, if you will.

Carefully Carving Out Considerations

From now on whenever we commit to our CSS we’re going to focus on following a specific set of considerations. These considerations are a mix of things we’ve learned as a team and things people in our industry have documented or written about.

One specific styleguide I want to give a huge shout out is Sezgi Uluçam’s CSS Best Practices. In it, Sezgi steers away from stylistic preferences and fads and instead focuses her best practices on writing clean, easy-to-read, and scalable CSS. To me, focusing on clean and scalable CSS is what allows a group of people to write CSS better as a team.

So, when I started writing our front-end styleguide at Clef, I made these things my focus as well. Front-loading the effort of writing clean and scalable CSS and asking programmers, who may or may not be passionate about CSS, to apply a set of considerations when contributing to your app’s front-end code is, in my experience, always worth the work.

But I’m also writing these things down to hold myself accountable to them too.

Sometimes it’s easy to write a bunch of really poorly written CSS and to not comb through your code, especially if you’re in a hurry or you simply need to make something work. But writing these considerations or best practices down means that they’re real and that, as the Head of Design, and our resident CSS expert, I need to hold both my team and myself to a higher standard.

Hopefully, going forward, this will allow our team to move quickly, debug efficiently, and update styles easily. It should also make it easy to dive right in and contribute as we grow our engineering team.

A Few Important Tenets

Our styleguide is open-sourced on GitHub here. Below are some of my thoughts around best practices and things I believe will help you and your team write better CSS too.

Rule #1 to be a boss ass bitch: Write semantic and descriptive class selectors.

“Follow the rules of semantics — make classes descriptive and not reliable on appearance of the given element.” — The &yet Styleguide

Rule #2: Specificity over brevity. As noted in Sezgi’s CSS Best Practices, research has found that the delta, or difference, in the best and worst cases of class selector performance is actually only 50ms.

“Keep performance in mind, but don’t worry too much about it. The main advantage of using performant selectors is that it increases readability and modularity. For example, .container * is terrible not just because of performance, but also because it hurts flexibility and requires future styles to use hacky overrides.” — CSS Best Practices

I 100% believe that by prioritizing specificity over brevity we can write better CSS as a team. A unit. For every engineer who is currently contributing CSS to our codebase, as well as for every engineer who we’ll add to our team, ideally this styleguide should help them jump right in and start writing (objectively good and scalable) CSS.

A little more on naming class selectors: We use the BEM, or “block__element — modifier”, naming convention. The blocks we name our class selectors after should be reusable and component-based and not specific to the page or template where a component is being displayed. While we can have page-specific CSS file names, our actual CSS should be modular and reusable.

Pro Tip: We’ve also found that using the BEM naming convention has paired nicely with React.js’s JSX templating. However, we’ve decided not to mimic JS syntax in class selectors that use two words in one block name or descriptor. Instead of camel-casing class names, we hyphenate them so they’re easy to scan or read.

Beyond these considerations, there are behaviors we want to try to avoid all together. Here’s a few of them:

• Using the !important declarative
• Styling IDs
• Targeting descendant selectors

“The descendant selector is the most expensive selector in CSS.” — Dave Hyatt

• Excessive nesting (eventually I’d like us to avoid doing this completely)

I’m excited for our front-end styleguide and our team at Clef to grow and evolve over the coming years.

In this checklist, we allow users to copy their API key and/or “app secret” to their clipboard with a button a la GitHub.

The copy-to-clipboard functionality is built into a React.js component in our web app on top of the Zero Clipboard library, “an easy way to copy text to the clipboard using an invisible Adobe Flash movie and a JavaScript interface.”

Some Design Thinking…

One can hope that copying something to a clipboard is a design pattern or interaction, that users, or even more specifically developer users, are familiar with. But by making that assumption, in my opinion, we might be relying far too heavily on the strength of the “copy” iconography to communicate to the end-user that pressing the button will in fact copy their API key or app secret to their clipboard.

I’m a huge believer in supplementing or reinforcing visual language/iconography with text that helps give the end-user more context. I find this super !important when designing first-time user experiences. Sometimes iconography just isn’t enough, especially considering the vast differences in how people who speak different languages might process visual language.

One great example of this across the web is an “information” icon.

While working with the Browse UX team at Amazon, this came up in a conversation around how much iconography can and should be used across international or (non-english) language-specific editions of a website. One interesting point Dustin Boudreau brought up in this conversation was that in non-english languages “i” often fails to translate into something truly meaningful and actionable.

If your user-base is both 100% english speaking and American, then maybe you don’t have to consider these things when designing user-experiences. But it’s always nice to be thoughtful about how much context you’re giving your users to accomplish what they came to your website to do. Even if your site doesn’t serve international communities right now, it may in the future.

Why Use a Tooltip to Solve this Problem?

Tooltips are a common design pattern on the web and they enhance the experience of a user, and provide additional context without obstructing a user’s path or initially overwhelming them with too much information.

They can also work to reward the curious and/or engaged user. A clue, if you will.

Transitioning Tooltip Text with CSS…

As a front-end dev I try to use as few block elements on a page as is possible and/or productive.

So, when I started designing the click-to-copy functionality in-browser, I opted to use the button’s ::after pseudo element to create my tooltip in pure css. I used the ::before pseudo element to create the caret, or triangle, at the top of the tooltip, in pure css as well. Here’ s a neat how-to on a simple css caret/triangle on CSS Tricks.

The trick with hiding and showing a tooltip in pure CSS is simple; you can simply “hide” and “show” the element with its `display` property. Here’s a simplified version of the code I used to hide and show the pseudo elements for the caret and the tooltip body nested inside of the button class selector CSS:

I shipped an early version of the tooltip to my teammate, Mark, who was wiring the design up to the React component using Zero Clipboard.

Something I had forgotten about entirely was changing the text of the tooltip to reflect the user’s state from “Copy to Clipboard” to “Copied!” when they click the button. Mark then asked me to design an “after” state static-ly and he’d wire it up in React.

When I started coding the alternate “Copied!” state of the tooltip, though, I realized that because we were using a <button> element as the target, instead of creating an entirely new element for the copied state, I could simply pass in the “Copied!” text with a different `content` property on the `::after` pseudo element when the button was in both the “active” and “focused” states.

The `content` CSS property or generating content with CSS pseudo elements has about 96.99% coverage across browsers, according to caniuse.com.

I created a Codepen with the complete HTML & CSS that you can play around with here. The full Gist is here.

You Can’t Spell CSS without Caveat…

Because we used button states to trigger the text changing in the tooltip, the “Copied!” state remains active so long as the button is still in a “focused” state. In my opinion, this actually does make sense UX-wise seeing as users can’t necessarily “uncopy” something from their clipboard with the button.

Another downside is that the state change doesn’t work on mobile.

A little less of a caveat and more of a wish-list item; I really wish I could resize the width of the tooltip when the text changes to a shorter string.

If you, brave CSS warrior, can hack together any fixes for these CSS caveats, please to be forking my codepen and give me a shout on Twitter. I’d love to send you some Clef swag for your contribution!

I’ll admit that to have some level of disagreement amongst teams about open roles and responsibilities is healthy (yes, dissent!), but if I’m telling hard truths (a thing I do), I’d say that what I’ve experienced while searching for full-time employment, with the exception of just a few teams, was surprisingly not so great.

Based on my experience over the past several months, I’ve come up with a few ways for companies to improve their hiring processes…

How companies can be a little more kind to candidates:

Have a clear understanding of, and a consensus around, the skill-set you’re looking for.

I will say that the best way, in my opinion, to respect the time, and subsequently the stability, of your candidates is to start with a clear idea of what you’re looking for. There should be a clear consensus about the role you’re hiring for, as well as regarding the skill-set needed to succeed in that role. Check these things off your list before you begin your search for the perfect candidate.

Develop an efficient hiring process and be responsive and communicative.

Consider that when you leave a candidate hanging (double your concern here if you’re looking to hire a diverse team) some people literally can’t afford to be left out of the loop. If you want your hiring process to be truly inclusive, you need to accommodate people with different backgrounds, socio-economic classes, as well as people with families, disabilities, and health conditions. And a lot of being accommodating means keeping an open line of communication with candidates and being candid about timing and decision-making processes.

Don’t make your candidates pay for expenses out-of-pocket.

Yes, time is money. But so is… money. As someone who has experience booking travel accommodations for others, I know that it’s possible to pre-pay almost all travel and lodging expenses. If you’re flying someone out to interview with your team, try not to unknowingly force your candidates to front any money for their accommodations. Or, at the very least, come up with an easy and efficient way to reimburse candidates for the cash they dish out to interview with your company.

It’s also important to communicate these things before a candidate comes to interview, so they can plan and/or budget for their trip.

Transparency is everything.

Sure, there are legal boundaries around telling a candidate why you can or can’t hire them. But increasing the transparency around, let’s say, whether you’re interviewing other candidates for the position, what you’re looking for in a potential hire, and/or when you’re looking to make a decision will all help set better expectations with the people you interview and avoid resentment or bad blood between you.

Beyond merely being kind to candidates, another important thing to address with your team is how bias affects your hiring process. There’s a growing body of research dedicated to deconstructing unconscious bias in the workplace, all of which is worth examining closely before you start filling out your pipeline. In fact, if you’re a hiring manager, I would go as far as to say it’s your responsibility to build a hiring process that is fair and balanced with consideration to unconscious bias. You can start with this talk “Unconscious Bias at Work” by Ken Norton.

Now, for interviewees looking for something new, here’s a few things to consider before you start the sometimes long and arduous journey to your next big thing…

How candidates can ease the search:

I recently got to sit down with a friend and someone I consider a mentor to chat about life and what was next for me. When I told her I was starting to interview with a handful of companies that had reached out to me, she recommended I take a step back and consider what I wanted out of my next job. “You want to be on the offensive” she told me.

I actually hadn’t considered this. Maybe I wasn’t having very much luck because I’d only gone after things that had fallen into my lap or into my inbox and I hadn’t been aggressive or intentional enough with my search.

She advised me to sit down and think about not only the size of the company I wanted to join, but what kind of problem I wanted to solve, and where I wanted this job to take me.

“Think of it as being an investor in the next company you join, because you totally are one. You’re investing your time, your energy, and your talent.”

This was probably the most formative piece of advice I received during my hunt and going forward, I made a list of requirements that my next job had to fulfill for it to be worth me investing in:

• I want to work at: A medium-sized, fairly established company (post series-B) or a small, focused team at a startup.
• I want to work on: A problem or product that hasn’t yet been solved or where I can touch a bunch of different aspects of experience design, across multiple platforms.
• I want to work with: A diverse team where women are hired into leadership positions.
• I want to work toward: A design management role.

One of my biggest concerns while interviewing was that I would make the wrong choice and either wind up in a position where I’d be hired to defend a company’s culture or working in an unhealthy environment (again). Sitting down and defining the things that mattered the most to me made the decision to join a new team a bazillion times easier.

Give in to the process

Waiting to hear back from a company, especially if they’ve gone silent, is probably one of the worst parts of interviewing. Or at least it was for me.

Julie Ann Horvath on Twitter

Me every time I get an email and it's not THE email pic.twitter.com/rcYrqiiAn3

After a few panicked messages to a friend while waiting to hear back, he replied to me with this helpful note:

“The key is to know that the process itself is meaningful work.”

Try to keep this in mind when you throw yourself into interviewing.

Don’t waste your time wondering.

Throughout this process I found myself reflecting on my interviews and trying to guess what I did right and wrong and whether or not I could have done things differently. And the truth is, I really didn’t have the time to.

Interviewing is a huge investment of your time and if you’re like me and you have very little cushion to work with, sometimes you just gotta keep it moving.

A small note on self-care: Try to remember to be kind to yourself. The world may not always know when you deserve a break, but you do.

If you’re lucky, you’ll make some friends along the way.

I’m so, so thankful to the team I contracted with last who were super supportive and understanding about me taking time to interview and to take care of myself.

Shout out to PJ McCormick & the Browse UX Team @ Amazon for their patience, support, and for providing a positive work environment for me during some pretty big life changes.

OK, so who’s hiring?

Here’s few teams whose rad-ness I can personally vouch for:

• Chain
• 18F
• Etsy
• Slack
• Pivotal
• Mode Analytics

And I also tweeted to ask if anyone who follows me is hiring and wanted some help getting the word out. Here’s a compiled list of companies from people who replied to my tweet:

• Weebly
• Big Viking Games
• Amazon
• MicroEdge
• Marvel
• Khan Academy
• AeroFS
• WillowTree
• Stack Exchange
• Massdrop
• nclud
• Nylas
• iStrategyLabs
• Jukely
• Canonical
• Axiom Zen
• Emma
• Microsoft Edge Dev
• Indiegogo
• VSCO
• Chartboost
• Mattermark
• Loungebuddy
• Soundcloud
• Digital Ocean
• Vimeo
• Venmo
• The Working Group
• Pinterest

Happy hunting, Internetters!