"Pixel perfection is slow."

A Head of Design told me this recently, and I had to pause. Usually, it’s the engineers complaining about the pixels.

But they were right.

If "pixel perfection" means manually checking every margin, hex code, and padding value in a code review, then yes—it kills velocity. It turns engineers into pixel-pushers and designers into police officers.

The fix isn't to lower the quality bar. The fix is to automate it.

• The Manual Way: ❌ "Can you move this 2px left?" (Slow, fragile, subjective)

• The System Way: ✅ "Just use the spacing-sm token." (Fast, consistent, standard)

When we invest in a strong Design System, we get "good enough" automatically.

The goal isn't to build a perfect UI by hand every time. The goal is to build a system where the default choice is 95% perfect, so we can spend our energy on the last 5% of "delight" that actually sets the brand apart.

Don't fix the pixel. Fix the system that renders it.

Early in my career, I thought being a Senior Engineer meant having all the answers. I spent a lot of time telling people exactly how to fix their code.

Now, I operate by a different rule: Ask, Don't Tell.

If I tell a junior engineer exactly how to write a function, I fix the code for today. But I also ensure they will need me again tomorrow.

If I ask them, "How would you handle the error state here?", it takes 5 minutes longer. But next week, they won't need to ask.

The same applies to Product stakeholders:

❌ Telling them a deadline creates friction.

✅ Asking them to help rank priorities creates partnership.

My job isn't to be the smartest person in the room. It's to ask the questions that make the whole room smarter.

The line between "Design System" and "Production Code" will disappear.

We are actively watching the "Frontend Developer" role evolve into "Product Architecture." If you are still building components in isolation, you are building for the past.

Here is the stack I’m betting on to bridge that gap:

1. The Engine: Next.js
   We aren't just shipping HTML anymore; we are streaming UIs. React Server Components (RSC) have fundamentally shifted how I think about data fetching. Moving logic back to the server isn't a regression; it's a maturity cycle.

2. The Interface: Modern CSS
   We over-corrected with utility classes. With browser support for Nesting, @layers, and sophisticated Variables, the need for heavy abstractions like Tailwind is fading. The future is semantic, readable CSS that uses the platform, not a framework.

3. The Safety Net: TypeScript
   If it’s not typed, it’s technical debt. The confidence to refactor a massive codebase relies entirely on the strictness of your types.

4. The Source of Truth: Figma
   This is the controversial one. I treat Figma as part of the stack. If the component structure in Figma doesn't match the prop interface in the code, the system is broken.

I’m not interested in the "Best Framework" wars. I’m interested in the stack that lets teams ship high-quality software without friction.

In 2006, I became the sole breadwinner for my family of 5.

I wasn't an engineer yet. I was a web designer living in a single-wide trailer who figured out that if I hacked together PHP and CSS, I could build custom WordPress themes. That skill didn't just feed my family; it launched a career that took me from freelancing to high-performing agencies.

But eventually, I realized I had hit a ceiling.

I didn't want to build websites anymore. I wanted to build software.

So, I took a gamble. I left the comfort of the ecosystem I knew and dove into React.

It was a risk, but it paid off. That pivot took me from "making it work" to leading engineering at companies like TrueCar and B-Stock. It bought my house. It built my life.

Today, I’m a Senior Product Engineer. I don't just theme; I architect.

I use Figma to bridge the gap between design and code. I use Next.js to build performant, scalable applications. I use Design Systems to help teams ship faster.

My focus is now entirely on defining the next generation of digital experiences. I am committed to pushing the boundaries of component-driven architecture and building interfaces that are not just functional, but transformative.

The future of the web is composable, and I am excited to lead the way in shaping it.

I’ve worn a lot of hats in my life.

I'm a mom; I've raised three incredible women (still working on it!). I’ve been a minister, guiding women and young people through life's challenges. And for the last 20 years, I’ve been an Engineer.

At first glance, those roles feel completely different. But I’ve realized they all revolve around one core truth:

Clear communication is where assumption dies.

In code, an assumption creates a bug. In a team, an assumption creates resentment. In a family, an assumption creates distance.

My top three values are Honesty, Communication, and Integrity. Not just because they sound nice on a poster, but because they are the only tools I’ve found that actually solve problems.

Whether I’m architecting a Design System or helping a team navigate a difficult retrospective, my goal is always the same: close the gap between what is said and what is heard.

When you kill the assumptions, you build trust. And when you have trust, you can build anything.

We often talk about "cutting scope" to meet a deadline. But there is a difference between reducing features and reducing quality.

When decision-makers push for "time-to-ship" over "time-to-quality," they often treat UX as a coat of paint that can be fixed later.

What they miss is the Unconscious Bias of Competence.

When a user encounters a layout shift that makes them miss a click, or text with poor contrast that forces them to squint, their brain doesn't just register a bug. It registers indifference.

It unconsciously signals: "We didn't care enough to make this easy for you."

Friction isn't just annoying; it is exhausting. Every moment of confusion—every "where do I click?" or "what did that error mean?"—is a micro-withdrawal from their emotional bank account. Eventually, they go bankrupt and churn.

Poor UX is not just an annoyance; it is a signal of low integrity. You can fix a bug in a sprint, but you cannot refactor lost trust.

The take: If you have to cut something to ship on time, cut the feature set, never the fidelity.

There is a specific magic in opening a blank Figma file.

Before a single line of code is written, the identity has to exist. Who are we? What do we sound like? What do we look like?

I've been working on a series of logos recently—from ProVenn to FamilyPlate—and it reminded me why I love early-stage product building.

You aren't just moving pixels; you are defining personality.

As an engineer, having the ability to execute on this layer means I don't have to wait for assets to start building. I can dream it up and ship it out.

I don't mind that ChatGPT gets things wrong sometimes. Hear me out:

AI chat bots are not fact spewers. This is derived from the first adjective: AI. "Artificial Intelligence" can be simply put as "faking intelligence".

Intelligence is a collection of knowledge and skills. Knowledge does not necessarily equate to facts. I am an intelligent person, but not everything I tell you is going to be free of bias, opinion, and personal experience.

Therefore, it's important to keep in mind that ChatGPT, as a "faking intelligence chat bot", will also answer you with bias and the opinions and experiences it is taught. With that comes the opportunity for being wrong.

If we then adjust our mentality towards ChatGPT with this understanding, maybe we won't be so offended by its existence.

The first ~12 years of my career were mostly WordPress-centered. It worked for me. WordPress allowed me to boost my service offerings by a LOT, and in that golden era, I came in super high demand, super quickly, which rocket launched my career as well as access to learning and gaining experience. (Aside: I remember being amazed by, "17% of the web runs on WordPress". That percentage today is now up to 43.5%. Undeniably astounding.)

Then I changed to React to get into the higher pay, higher reward world of frontend software development. I've had no hesitation locking into that platform as it has brought on a new era of enjoyment and success.

As I get deeper and deeper into frontend tech, I find myself "locking in" on certain tools that I enjoy. It sounds scary, but the risks really aren't that high; It's just technology. I do, however, tend to favor open source and MIT licensed tools and "owning your data". (Thank you WordPress community and dogma.)

Tools, platforms, vendors... they all come and go. The attitude and mantra that I relate to most is "strong opinions, loosely held."

• Know your stuff

• Know what you want, what you like, and what works

• Don't be afraid to let go and change

• Know that change may be necessary, and sometimes dramatically urgent

Oh and btw:

• Websites running on React: ~5%

• Websites running on Next.js: 0.509%

• Websites running on Strapi: less than 0.1%

I've been a little fuzzy on what my mid to long term career goals should be, but this current job search has the topic consistently front-of-mind. I had an "Ah ha!" moment during an interview today and upon further reflection, I think I've finally nailed down what my true goal is.

Lead

I've tossed around the idea of management because I know I want to press beyond a basic individual contributor role, but my people management skills just aren't that great. Not because I'm bad with people, but because—in my opinion—I'm good with people.

I'm not good at being critical of others, but I am good at thinking critically. This doesn't really apply to people management per se, but it does lend nicely to project and product leadership.

So what's the difference between management and leadership?

For me, management is about execution and leadership is about innovation. I excel in research and discovery and don't mind taking calculated risks for the sake of advancement. I like to see projects and products prepare for the future and scale into success.

Let me clear: I'm not necessarily interested in people leadership. I can inspire and "rally the troops" as needed, but my focus ideally would be on projects and products with a particular specialization on UX and tech.

This is all still new and fresh for me so I have more to buff out, but it feels good to have a direction to point myself in!

I'm pro-alphabetize in code.

For most things, such as keys, props, and imports (within groups). But when it comes to CSS properties, I am completely anti-alphabetize.

For one thing, CSS cascades (duh), so when you alphabetize, you run the risk of incorrectly overriding styles within the same property list.

Secondly, I prefer to group my properties. I'm not super strict on this, but here are the rough groups I use:

• display (flex, flex-direction, gap, etc.)

• position (absolute, inset, z-index, etc.)

• size (width, height, etc.)

• appearance (color, background, padding, etc.)

I also put an extra line break between the first three groups and the appearance group. This helps me quickly reference the styles I'm specifically looking for when scanning back over CSS.

Building this TypeScript/React/Remix/Strapi project is going to be one of the most shining highlights of my career. I've been having such an awesome time working on the #HeirOfDragons design, but I'm getting a little antsy and wanting to dive into the code.

1. I have high hopes for the quality, stability, and scalability of the design system I'm going to develop: DragonScale

2. I've been wanting to get some real experience in Remix

3. I'm all in on React/TypeScript as I am highly advanced in both

4. Strapi is going to launch me light years ahead in terms of managing content and offering a dependable API for running a small community

5. Most importantly: I expect great success for Chloe's project. She has been working so diligently on it for so long and her passion for bringing the story to life is pure and admirable

Alas, I will continue my due diligence and focus on finishing up the designs. I'm getting very close and layouts are starting to snap together quickly as the foundation I've laid is super tight yet malleable.

Prepare to be amazed!

For as long as I can remember, I've used Title Case for button text. It seemed correct, and it was a style mandate at one company I was at.

In my most recent role, the standard was Sentence case. It took me a long time to get used to this, but eventually it came naturally to me.

Now it just makes sense. A button should be a verb at the minimum and anything after that should be treated like any other sentence, sans punctuation.

When I started on the #HeirOfDragons design, I tried out Title Case for button text, but just couldn't get over the fact that the text in a button isn't describing something like a title does, it's telling you to do something, like a sentence does. Thus, I've decided to stick to Sentence case.

I was just thinking about how glad I am that I switched my focus from building websites to building web apps. I took it upon myself to learn React and it was a life altering decision for the better.

One of the biggest moves I'm grateful for was the chance that Thomas Breese took on bringing me on to his team at TrueCar, Inc. He was my engineering manager there and even during my technical interview, he patiently introduced me to Redux so I could complete the exercise. His instruction was just what I needed and he found me worthy of hiring.

I learned and grew so much during my time working with him. He also taught me to create custom hooks and how to use context in React.

My skill intensified so much during my time at TrueCar, and I'll be forever grateful. I can't wait for the next chapter that is coming in my walk with software engineering.