Lara Schenck

Please note:

I literally did not edit this post at all….well, a little bit. Yikes! One of my takeaways from this last month was “perfect is the enemy of complete,” so in keeping with that lesson learned, I hit publish and will – maybe – read through this later.

---

Ah, I’m definitely late getting to this installment of the Designgineering Chronicles…which means there is sooooo much to write about! These posts are already long, and this one will likely be longer and I’m writing this not only in haste, but stream-of-consciousness-like, so buckle up.

I’ll start with a bulleted re-cap of Designgineering Chronicles: The Second Month:

• Learned some lessons about the importance of spreading knowledge on teams and the importance of processes at big companies
  
• Detailed some naming practices and custom property usage for IndieWire’s pattern library
• Got my hands into some Node.js, building a wrapper for node-sass and other modules in order to standardize the build configuration among brands

Okay, not onto this month…

I got the job!!!!!!

Up until a couple of weeks ago, my position at PMC was a contract. Now, I’m officially a full time employee!

Let me start out by saying this is a very big deal for me. It’s the first time I have had a full-time job since working at a startup for $12/hr after college, from 2011-2012. That’s for a variety of reasons – on one hand, I was great at working for myself, on the other hand I had tried to find a job a couple of times but never found a position that was quite right for my mostly-developer-but-also-designer skill set (don’t you dare say unicorn…seriously, there are more people than you might think with skill-set).

Choosing My Job Title

Job titles have been a thing for me. That started largely with the Tales of a Non-Unicorn / Designer That Failed FizzBuzz business back in 2015. I made a Github repo to gather ideas for standardizing job titles, I made a job post calculator, and a Myers-Briggs-esque job title quiz thing. In the last five years, I’ve gone from calling myself a ‘Web Designer’ to a ‘Web Designer/Developer’ to a ‘Front-end and WordPress Developer’ to ‘UX-oriented Front-end Developer‘ then to ‘Design Engineer’, the name of my contract role at PMC.

So, when the job offer for full time came through, I had the opportunity to choose my official title. Official job titles only really matter on paper – I can call myself whatever I want now, but this is the title that’s in the system at PMC and thus on my resume later. Given the history I have with job titles, I did not take this decision lightly and ended up choosing an incredibly flower-y and inflated title that will either be impressive or confusing on a resume:

Hi, I’m Lara, a Senior Design Operations Engineer at Penske Media Corporation.

Depending on my mood, I’m either like, “F*&K YEAH, GIRL!” or I’m rolling my eyes real hard when I think about that. Job titles are bullshit, but they do matter…? At the end of the day, I am 100% a front-end developer, but for whatever reason – maybe ego, maybe the fact the “front-end developer” can mean 10,000 different things or the fact that writing PHP is a large part of my job – okay, so several reasons, that doesn’t seem quite right. I’ve been jamming on the Design Engineer title lately, but then I chose this “Senior Design Operations Engineer” mouthful!

Let me break down my logic:

Senior

Here’s something you might find interesting: I asked to have Senior in my title.

Lol!

Am I a senior developer? Maybe…kind of…but also…not really. Senior-ish, perhaps. I have a lot of technical knowledge and I’m great at working with people and sharing that knowledge, but I’m still pretty young (29) and growing in a lot of ways, especially when it comes to the challenges of working at big companies on big projects with lots of people. I have less than 10 years of industry experience, and most of it has been working independently.

So, why did I ask to have Senior in my title when, by my personal standards, I am not a “Senior” developer? Well…there are a lot of people with the “Senior” title who, by my personal definition, would not be “Senior”. At the end of the day, I can choose to call myself Senior when it suits me, and it’s entirely possible I’ll be totally comfortable with the title with a little more experience. It’s there for when I want it.

Design Operations / Design Ops

What about the nice, simple, Design Engineer? Where did this “Design Operations” business come from? Well, Design Operations is a thing right now, and I want to capitalize on that. Plus, I am doing Design Ops. My job isn’t really in implement designs, it’s more about working on tools and processes that make it easier for design to happen in the first place. Right now, that consists of what I’ve been calling ‘Front-end Ops’ (definitely milking the ‘Ops’ term): implementing front-end standards and tooling consistency in unique code-bases preparing them to, someday, become one code-base.

Engineer

Ugh. Deep-down, it makes me uneasy that programmers call themselves engineers. To call building software ‘engineering’ is just one way of describing what we do as developers, and at the end of the day, it’s a metaphor (I highly recommend watching this talk on the subject). No matter what way you spin it, ‘engineering’ a web-app is not the same as engineering a bridge. In my opinion (which changes on an almost daily basis, please note) developer and programmer are quite a fitting terms for what we do on the web. I guess?

That being said…the term “engineer” has a certain weight in the tech industry, namely at larger companies. Who am I to exclude myself from that, especially since I am part of an underrepresented group? I should not risk having my role seen as anything less than “engineering” for the sake of a principle about a word.

Sheesh. This post is already long! There’s a lot more to cover, so please stay with me.

Perfect is the Enemy of Complete

a.k.a. The Black Hole of Refactoring JavaScript.

I have perfectionist tendencies, and that can be a big problem when you are building something that really just needs to work. I am referring to the build step project I introduced in last month’s installment. I mean, it needs to be readable and in a form where other developers can understand it in order to contribute, but it doesn’t need to be perfect. My refactoring workflow went something like this:

1. Get everything working nicely with callbacks. Callbacks are fun!
2. Learned about Promises and experience the beginnings of callback hell. Refactored all of the callbacks to be Promises and wonder, is there a Promise hell?
3. Ask on the js.la Slack about the existence of a Promise hell.
4. Learn about async functions and try/catch blocks. Finally, a project where I can use cool, new JavaScript stuff!!
5. Couldn’t get one specific node_module to return a Promise when Promisifyed. Got frustrated and found try/catch blocks to be hard to map to tool’s requirements where the main data being passed around was messages to be logged to the console.
6. Didn’t look at it for 1 week.
7. Refactored back to mostly Promises, but left 1-2 async functions that weren’t broken, so I did not fix them.

I’m sure there will be more refactors in the future, and hopefully by someone who is not me. My role in the standardized build step – what is now called pmc-build-utils – is to make it exist and make it work. And, hey, it exists and it works and it’s commented and tested…mission totally accomplished!

There is another project starting PMC that will be using pmc-build-utils and improving it as part of the project. This is very exciting because me building a Node wrapper for webpack is fun, but it’s not what I do. I’m very glad to have others work on it.

On that note, what do I do?

I just really, really love writing CSS

“Okay, Lara, we know. You love CSS. Good for you.”

Fine, but I really do love writing CSS programming boxes, and in both my work at work and outside of work, I’m just having the grandest time figuring out ways to 1) make writing CSS easier for other PMC developers who do not love it as much as I do, and 2) more love-able in general for web developers at large through my recent talks and writing.

For 1), this has manifested in the form of a few different projects (so many projects! yikes!):

PMCSS Standards

Our CSS standards at PMC! I outlined some of these in last month’s installment, but let’s have a bulleted run-down of the SCSS coding standards that will be making their way into PMC’s code-bases:

• No BEM selector concatenation
  
• Nesting reserved for pseudo-elements and pseudo-selectors
• A PMC variation of ITCSS for naming conventions
• BE or BM, not BEM – i.e. only .x-block__element or .x-block--modifier (I have a lot more to say about this, but not in this post)
  
• Atomic utility classes, a la SUIT CSS
  
• Preference for longhand over shorthand syntax
• Preference for min-width breakpoints
• Numbered directories to maintain the ITCSS ordering
• KSS-node comments for documentation

Let me just mention that these are PMC’s CSS standards, and they won’t necessarily make sense for others. For example, I’m sure lots of people have great success with BEM selector concatenation. In our code-bases, it becomes unwieldly over time and makes pull requests difficult to read.

A few noteable, coding practices that have evolved in the wake of the IndieWire pattern library:

• _scratch-pad.scss – A file that exists to prototype patterns before incorporating them into the system. This should always be comitted empty, or with a brief comment. Inspired by Harry Roberts’ shame.css, but for a decidedly different purpose.
  
• A legacy/ directory in the pattern library for loading legacy CSS on patterned templates. This safely indicates that the styles should be phased out without requiring them to be rewritten.
  
• .u-glue!! A so-far successful CSS positioning algorithm. I wrote about that in a separate post, here.

Oops, I made another pattern library

As happened with IndieWire’s pattern library – which I ended up building without entirely planning to, a similar event has happened with another of PMC’s brands, Robb Report. I can safely say there is perhaps no content I am less interested in than that of Robb Report, but nonetheless, I am here to comment on the CSS, not on my feelings about “Top 100 Watches Over $100k” listicles.

This pattern library came about in very different circumstances than IndieWire’s and, I think, will prove to be an excellent model for approaching the gradual refactoring of other brands’ SCSS code-bases. Whereas IndieWire was undergoing a “design refresh” that catered to the development of a relatively fully featured set of patterns, my task with Robb Report was more along the lines of re-purposing an existing set of templates while maintaining the current design.

It turned out that the battles with the existing CSS and templates were so frustrating that I said, “eff this”, and created pmcss-scaffold, a drop-in version of the modified ITCSS architecture used in IndieWire (which will be on Github, someday!). I then went about creating patterns using our naming conventions for the existing designs and, essentially, rewriting all of the CSS for these specific templates.

There are a few things to note here. Completely re-writing someone else’s code because it doesn’t match what’s in your brain is generally not the best way to go about development. I think this scenario is different, however, because 1) at PMC, I am the developer most proficient in CSS and that’s why I was hired, 2) it is part of my job to come up with coding standards, and 3) this particular feature was written in haste (quite like this blog post) so code quality and modularity wasn’t a priority to begin with.

Strangler Vine Refactoring

A huge time-suck in working on different brands’ sites is that their CSS is architected quite differently (or not architected at all). They all need to be using the same naming conventions and the same directory structure, at least for this stage. Then, in a strangler vine-esque approach to refactoring, new CSS can be written in the pattern library and old CSS gradually transformed into patterns. Strangler vine?

I learned about the strangler vine pattern when asking a question in the Design Systems Slack a couple of months ago, and it makes a lot of sense for the sites we work on at PMC. They get a ton of traffic and have so many moving parts and hands in the pot, so to speak, that it would be a costly and risky undertaking to do a refactor all at once. The strangler vine pattern for refactoring was coined by Martin Fowler and inspired by the intense sounding vines that strangle their host trees after a few years. In terms of software, he writes:

This metaphor struck me as a way of describing a way of doing a rewrite of an important system. Yet they are always much more complex than they seem, and overflowing with risk….An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.

StranglerApplication, Martin Fowler

My hope is that each brand at PMC will contain what Martin calls a StranglerApplication in the form of the scaffold of our PMCSS architecture to house the gradual creation of patterns to replace the existing SCSS code-base.

Then, after some time, the code-bases will reveal redundant patterns such as layout algorithms (like .u-glue and .u-flex-list), mixins, and named components, and we can start moving that code to a centralized location. This is something all developers can contribute to, and that is very important. I’m guessing this will happen sooner than later, too, as there are several snippets I’ve already found myself and others copying between SCSS code-bases.

That’s the tentative plan, at least! Things change…

Core Tech and Estimating a Design System

So…I’m not going to write too much about this because it’s still in the works. Basically, there have been conversations about Core Tech and core components at PMC from way before my time. The value of a centralized code-base is not something that needs to be proved. However, the value of centralized design and its corresponding front-end code-base does need to be proved.

I had an exciting meeting with some folks about determining a “menu of components” for a design “refreshes” that could be pitched to the various PMC brands. My suggestion was to build out these components ahead of time, and in their own code-base apart from that of each brand (which are in various states of new and not-new), and build them so that they could be lightly themed (hooray custom properties!! I love them so much!!!) for each brand. Product liked the idea, and there was mention of proposing it to the higher ups to get specific budget for building out the component library.

I worked with one of the excellent project managers at PMC to come up with a rough estimate for the cost savings that would result from including front-end in Core Tech, but we’ve put that on pause for the time being – there needs to be a bit more experiential evidence that this approach to front-end works. I’m not 100% sure what this looks like, but it might just be a matter of time and figuring out the right people to talk to and the right way to describe the role of design and front-end code in the previously back-end-only Core Tech initiative.

This is uncharted territory for both PMC and myself, so it will take some iteration and exploration, and I would do well to not be in too much of a hurry; time seems to vet ideas better than anything else.

What’s coming up?

Whew! You and I made it! I think that’s everything I wanted to cover in this post. The only thing I didn’t talk about which I will save for later is that naming classes well is so gosh-darn important. That’s not a fully formed thought yet (and I can already hear someone saying, “just use atomic CSS!” 🙄), so perhaps it will reveal itself in “Designgineering Chronicles: The Fourth Month”.

Oh! I almost forgot about another exciting thing – browser support standards. That’s a big one. We will be following the route of A, B and C grade experiences where brands with > 10% usage of a browser will require an A-grade experience, 2-10% a B-grade experience, and below 2%, a progressively enhanced C-grade experience. What exactly this entails I’ll have to figure out over the next couple of weeks because it’s in this sprint!

Other than that, here’s what’s coming up:

• pmcss-utils – a place to collect utilities, Sass functionality, and atomic classes via npm.
  
• Publishing PMCSS Standards and pmcss-scaffold on Github once they are ready (this might not be until month 5 or so).
• Code reviewing the Core Gallery refactor CSS – I didn’t talk about this much, but this is a project I’m not entirely part of, and a big step in the right direction toward obtaining “experiential evidence” to support the development of core components and patterns. The developers will be using both pmc-build-utils and the PMCSS architecture/standards, so this will be a great test.
  
• Getting together a specific guide for Strangler Vine refactoring that will be evident in every code-base – i.e. notes in the code that essentially say, “Hey! You’re writing CSS! We have standards now, and we recommend you do it like this to help this code-base look like the others.”
• Moving back to NYC in Feb or March…shhhhhhh…
• Implementing pmc-build-utils in other brands – perhaps in conjunction with pmcss-scaffold for a setup for strangler refactoring.
• Figuring out what the heck to do with JavaScript…there is also a ton of redundancy in JS, and I’m guessing that can also be remedied with a pmc-js-utils or similar.
• Accessibility!! Help, I’m drowning in important things to do! But for real, at least in the Robb Report ticket I worked on recently (a video player thing), I’ve been testing with screen readers and keyboard, incorporating a11y patterns that will hopefully make themselves useful to others in the form of code reviewing and, ultimately, an a11y standards outline.
  

Okay, done and done! I’m going to hit publish now because…why not. If any of this resonates with you, reader, I’d love to be in touch, and maybe we can brainstorm some ways to help each other out in our designgineering missions.

Oh yeah, last thing! I’m going to Clarity Conf in December (after WordCamp US where I will be speaking!) – if you’re into this stuff, maybe see you there, too :)