A Code Review, Or Yet Another Reason to Love the Web

I’m in the early days of creating a design system for a big organization. Last week I posted some of my initial form markup to Codepen:

See the Pen PzEZwr by Brad Frost (@bradfrost) on CodePen.

And asked for feedback on Twitter:

I got a lot of fantastic, actionable feedback from lots of people, which by itself is amazing. But I was particularly blown away that Jonathan Snook — author of SMACSS, world-renowned CSS developer/thinker, and all-around fantastic human being — took the time to record an almost 20-minute long video review of my code.

I’m practically jumping out of my seat because this embodies so many of the principles that I care about. So let’s talk about ’em!

Frontend Prep Chef

One of the things Snook touched on was that he typically doesn’t prefer to mark things up before having any designs in place. I can certainly appreciate this sentiment, as it’s tough to know how things should be structured without knowing what the end goal is.

But! I’m a massive fan of getting into the browser on Day One of a project, and I feel that frontend developers can and should play the role of prep chef. Rather than coming in *after* many (often bad/limiting) design decisions have already been made, developers have a huge opportunity to establish UI pattern markup and crude CSS upfront so they can spend more time collaborating *with* the project’s designers to create the design system. Doing this prep chef work gets designs into the browser — the project’s final environment — as quickly as possible so the team can address essential aspects of design like responsiveness, performance, true type and color rendering, ergonomics, and much more.

This means frontend developers have to fly blind for a bit, be on their toes to adapt to evolving designs, and get comfortable iterating.

Iterative Design, Iterative Code

Establishing this more collaborative, pattern-driven workflow means iterating over frontend code becomes a core and necessary part of the process. In my consulting work, I encounter a lot of developers who are uncomfortable with this notion. They think they have one shot to get things right or the whole effort falls apart. There are a lot of factors that contribute to this mindset, but maybe they just watched too much Star Wars as a kid?

We do not have just one shot at getting the code right. Crafting frontend code should be as iterative an endeavor as the rest of the design process. I talk about this type of workflow as being akin to subtractive stone sculpture, where a giant slab of stone is chipped away at and refined over time.

So make something. Learn lessons (from mistakes you’ve made, from implementing patterns in new locations, or from Trained CSS Professionals like Jonathan Snook). Then revisit and refactor.

Yes, this does require being vigilant to keep your code clean. Build tools can help with this, but reviewing and grooming your codebase on a regular basis is a good practice to get into anyways. In my consulting experience, I’ve found it often takes as little as a week for developers to get comfortable writing code, rewriting it, tweaking it, and constantly improving things.

After a while you begin challenging your own techniques, embracing critiques, and actively look for ways to tweak things to make the system stronger. I don’t see Jonathan’s review as “Brad’s doing things wrong.” but rather as another opportunity to iterate over my work to make it better.

Creative Exhaust

We have the choice to share what we know or not share what we know. Thanks to the web (that thing we help make every day), there’s an opportunity to share more things for the benefit of ourselves and others.

In my TEDx talk, I talk creative exhaust, which is the idea that the artifacts of our creative work can often have much bigger impact on the world than the actual work we actually produce.

In this specific case, the artifact I chose to share was some basic markup I wrote in the first week of a project. For all I know, this code won’t even find its way into the final work. But that little snippet has already caused a ripple effect, causing Jonathan to create a video, which caused some additional conversation on Twitter, which inspired me to create this post, and which may result other thoughts and ideas.

This, ladies and gentlemen, is why I do what I do. I suspect this is also why Jonathan decided to take valuable time out of his busy schedule to share what he knows. And this is why I think so many of us love working on the web. Let’s never take for granted the incredible, collaborative power of the web, and let’s continue sharing what we know.