Informing Engineering Decisions with Bite-Size Data

By Joel Dare - Written September 21, 2025

I think a lot about shipping fast, low-maintenance web content. But those ideas can feel extreme when writing modern software in a team environment.

I don’t think I’ve been very good at sharing some of the values I write about with my co-workers.

Someone asked me about techniques to sell these practices to their team

A newsletter subscriber got me thinking about this recently. I have a small email course where I ask subscribers, “What would make the course a total win for you?” One subscriber responded:

If I learn techniques that allow me to sell it to my team, that would be awesome.

I’ve been thinking about that ever since.

Surface small, timely metrics in the workflow

If I want developers to understand my concerns about size or speed I need to meet them where they are. And I don’t think I know a software engineer who doesn’t love data.

What if I added some information to a pre-commit hook or a build step?

I don’t want to be pushy, I want to be informative. So, I’m not talking about blocking a commit. I just want to nudge developers in a way that makes them aware of the software’s impact on their users.

I recently wrote about the 14kb problem. The basic idea is that only about 14kb of data is allowed on initial request and then it ramps up from there. That means that files above 14kb will require multiple round-trips and will incur latency for each trip.

If I wanted to show my team the impact this has on the user I could add a pre-commit hook, a unit test, or something else in the build process that surfaces the data. I could output something like:

Your index.html file is 56.34kb (800ms load time on a 3G network).

I’m not sure the 14kb issue is where I want to spend my credibility, but it’s a clean example that’s easy to quantify and share.

I could use this to surface package manager bloat

With package managers, one dependency can add others and it cascades. Often, we’re not aware of all the dependencies we’ve added. I could make developers aware of how deep their dependencies go with something like:

New dependencies: +329 (1 direct, 328 transitive, +7,436 lines)

Then if the dependency we added saved us from writing 10 lines of code, we might think twice about the complexity it added.

The same tactic would work for positive reinforcement too

It would probably feel pretty good to get messages of encouragement about your code too.

Test coverage up: +42 tests (coverage +8.1%)

HTML payload down: −12.1 KB

Build your next site in pure HTML and CSS

Want to build your next site in pure HTML and CSS? Join the free Five-Day Neat Starter Email Course and build a lean, production-ready page before Friday.

Email Me the Crash Course