📝 CSS-Tricks 204: Patterns, Developer Experience, and Complex CSS Animations

View this newsletter on the web.

Howdy folks!

[Robin]: This week I’ve been working on a number of refactoring projects at Sentry, where I work as a designer/front-end engineer person. The first job was focused entirely on our colors, as over the years a certain amount of debt had been accrued until we had a ton of random hex values everywhere and horrid variable names such as offWhite2.

I’m not dunking on anyone. We have all written code like this. In our darkest moments, we all have to admit that we’ve actually written worse code than this.

In fact, tech debt is a good sign: your team built a thing that customers use and pay for, but now we have to think about scale rather than panic code just to make ends meet. The way I’ve started to think about tech debt is that the problem isn’t necessarily the debt itself, all codebases are bad, and getting used to that fact is the difference between being a junior and senior engineer in my opinion. The real problem is the conversation, or the lack thereof about that tech debt, and making a viable plan for the future.

All these variable names and confusing color schemes had become a running gag at the company. We all dunked on them because we knew they’re not part of an organized system and we all knew it had to be fixed. Some day at least. Well, the time had come. I had finally had enough and was going to fix this dang thing. Thankfully an audit had already been made of our colors—matching our completely bonkers older variables with a new color palette made in a Figma doc.

So I did what I do with all refactor projects now: I made a new a spreadsheet and started documenting things. I made a list of every existing color variable in the app today and paired that with the colors in our new palette from Figma:

The columns on the left signify the two codebases that we have and if an instance of a variable had been removed (Done) or if that variable had been removed entirely (Removed). It’s a pretty nasty spreadsheet, please do not @ me. The important thing about this is that I could understand the system and how much work was left to be done.

Next up, I added all our new variables into our theme.tsx file. We use emotion at Sentry and our theme file is where all our common variables live. Then I started removing the instances from both codebases and then removing the variable itself, updating the spreadsheet as I went. This stuff is long and tedious work but thankfully we had Percy setup so that with each commit I could see the impact that the color swaps had on our components.

Now, after a week or so of work, we finally have a brief list of variables to use everywhere and we can see them in the codebase, in Figma, and also in Slack. But to make a rather long story short, I think the moral of this story is that all design systems projects should begin and end with a spreadsheet. Boy, I love spreadsheets.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s