Stoked how these data visualizations came together last week at Buffer. Lots of data science, content, design, and design engineering went into these social media engagement insights.
Check out the full page: buffer.com/insights/sta...
Had a breakthrough recently with getting decent CSS from agents. Let's call it HTML-Driven Development:
- Craft unstyled HTML to control the structure, semantics, accessibility, and even class names
- Then, ask the agent to style it, using existing styles and variables CSS as reference
Much of the value of coding agents comes from interpreting natural language requests and deciding which traditional software tools to use in response. They are increasingly useful as a flexible adapter/coordinating layer for existing, efficient, predictable software.
In essence, we're automating the wrong things. Sure, it can be helpful to get lots of ideas and discover something surprising. But, there's a risk in starting with high fidelity. It constrains our thinking. It implicitly embeds hundreds of tradeoffs without our involvement.
The challenges of design and engineering aren't creating high fidelity designs or writing the code. It's finding the value, making tradeoffs along the way, and knowing what still needs polish.
There's a disconnect with generating high fidelity designs with AI.
The bottleneck of design and engineering isn't ideas, it's gradually defining the right idea.
A single content section can be packed with animation, interaction, layout, and accessibility considerations.
I just published a behind-the-scenes of building Buffer's homepage hero: buffer.com/resources/ho...
And here's a companion video: www.youtube.com/watch?v=1yDT...
It was really handy for quick demos and examples in a recent talk I gave. Using a `<style>` block inside an element with `@scope`, `:scope`, and plain element selectors was fast to iterate without having examples affect each other.
Today I needed to scale an element I couldn't directly style.
`transform: scale(0.5)` doesn't affect layout, which leaves empty space around the element.
Then, I learned about `zoom: 0.5`, which is a newly supported CSS property that does exactly what I needed: scale an element and affect layout.
My team at Buffer is hiring a Senior Engineer – Growth Marketing.
We'll work closely together on projects like referral programs, internationalization, and tracking/experimentation systems.
- Fully remote
- 4-day work week
- $156.5K–$202.3K
Apply: buffer.com/journey/a661...
Dark mode isn't just to look cool. It's an important accessibility feature that makes the experience better for everyone.
Light mode causes eye strain and discomfort for me across a day. Dark mode solves this and makes content more legible for me.
Stoked dark mode is now available in Buffer!
Eventually, I arrive at the lowest level with ridiculously simple utility functions.
I get those low-level tests passing, then climb back up (inside-out).
I go up a level, use my new functions, get tests passing, and keep climbing until my top-level functionality is done.
(4/4)
Instead, I start with top-level functionality and write tests for what the final expected output/behavior is (outside-in). These tests will fail.
To get these tests to pass, I descend down, writing failing tests for simpler and simpler pieces of functionality.
(3/4)
Outside-in means writing high-level tests about the expected functionality, then testing and extracting smaller and smaller pieces of functionality.
Inside-out means testing and writing the smaller pieces of functionality and composing them into larger functionality.
(2/4)
With testing code, there are competing approaches of outside-in vs. inside-out.
Instead, I work outside-in *then* inside-out:
(1/4)
I was originally thinking of the implementation process, but both could be interesting. I've learned a little about the prioritization process, but I hearing the approach to gauging feasibility and how features are spec'd (such as test criteria/acceptance tests) would be great as well.
I would love to learn more about the process of developing features for browser engines. What are the languages? What is the testing approach?
You're too busy to fix your problems because you're too busy to fix your problems.
The reason why you can't slow down to make improvements is because you never slow down to make improvements.
Playing around with animation and content ideas for an upcoming Buffer feature. If people have animation enabled (accessibility-first design), comments spawn in random positions. Might include a button to clear the comments and a scroll-driven animation that ties into the page.
Staycations are underrated. I took this past week off and spent my time wherever my interests took me. Without any worry of productivity, I still:
- Practiced piano
- Read
- Organized my digital life
- Rearranged garage workshop for upcoming projects
- Worked on creative videos
If 10x engineers exist, they pair on their work.
Engineers who pair grow rapidly from cross-mentorship, keep each other unblocked, create focus and motivation, and offer continuous code review. This is more efficient, higher quality, and yes, faster than working solo.
A 10x engineer isn't what you think
If 10x engineers exist, they don't work 10x faster or create 10x the output. Speed and output without quality are waste.
A 10x engineer creates 10x the value with the same resources.
Read more in my latest blog post: luhr.co/blog/2025/09...
There's all this hype around generative design tools enabling teams to create prototypes before committing to high fidelity design and empowering designers to build and ship directly.
This opportunity has always been there. All it requires is designer-engineer pairing.
I often get stuck using `position: sticky;` and forget the requirements:
1. Element must have an `inset-` property set
2. Element only sticks within its containing block so the parent must be taller than the min content
3. No ancestor element can have `overflow` other than `clip`
Sneak peak of my work this week: rich, interactive charts with follower growth, posting frequency, engagement, and reach benchmarks we gather at Buffer.
This project got me deep into charting/dataviz libraries and SQL queries. Excited to launch it soon!
I recently built a new homepage hero section on Buffer.com with this fun interactive animation. I'm writing a post to break down the build since there are lots of cool tricks I learned along the way.
What do you want me to cover? What questions do you have?
Not sure if I'm part of an A/B test, but really excited to have faster playback rates available on YouTube. My playback options now go from 0.25x to 4x.
I usually listen to informational content at 3x so this is a nice accessibility win! No more manually setting it to 3x with JavaScript.
Read the full article on 10 things I've learned from 10 years of studying lean manufacturing: luhr.co/blog/2025/07...
10 things that shaped my work:
1. Everything is a process
2. There's always a customer
3. Blame the process, not the person
4. Learn to identify (and not tolerate) waste
5. Stop and fix
6. Make daily improvements
7. Prioritize improvements
8. Mistake-proof
9. Follow one-piece flow
10. Achieve flow
We're hiring for 3 engineering roles at Buffer!
- Senior Product Engineer (Frontend)
- Senior Product Engineer (Backend)
- Senior Backend Engineer (Platform and API)
These roles offer $156.5K - $202.3K + equity. We're a fully remote, global team with a 4-day workweek.
Apply: buffer.com/journey
