"What should I test? What E2E test should I write?" - These were the questions that I heard from a teammate who was working on a task after a week. It reminded me of a bigger question: until when, or at what role, should you tell developers that they need to “brush their teeth”?
Because there’s a difference between asking someone to do the basics and asking them to do the basics with quality.
Doing the Basics:
These are the hygiene factors — the equivalent of brushing your teeth:
Write tests: unit, integration, maybe even some E2E depending on the context. At the very least, there’s a baseline every project should meet.
Monitor and observe your deploys: it’s 2025 — observability shouldn’t be optional. At a minimum, you need visibility into your system’s behavior after a change.
Deploy beyond your machine: “it works on my machine” isn’t enough. Your code should prove itself in a shared environment.
Follow the pipeline: commits build, tests run, deploy happens. No skipped steps.
Get a code review: not for perfection, but at least for another set of eyes.
These are necessary, but not sufficient.
Doing the Basics with Quality:
This is where the difference shows up. Instead of just asking “did you do it?”, the framing becomes “does this give us confidence?”
Tests
Not just “are there tests?” but “do these tests cover critical paths, edge cases, and failure scenarios?”
“If this service crashes under unexpected input, will our tests catch it?”
Monitoring & Alerts
Not just “did you add metrics?” but “are these metrics tied to user experience and business outcomes, not only system health?”
“Would this alert wake up the right person at 3am with enough context to act?”
Deployments
Not just “did you push to dev?” but “did you test this under conditions that resemble production scale and data shape?”
“Do we have a safe rollback plan if things go wrong?”
Code Quality
Not just “is it working?” but “is it readable, maintainable, and resilient against change?”
“Would another developer, six months from now, understand why this was written this way?”
Documentation & Communication
Not just “do we have docs?” but “would someone new to the project be able to follow the reasoning behind this decision?”
“Did we make tradeoffs explicit so future us won’t repeat old mistakes?”
Reviews & Feedback Loops
Not just “did someone approve?” but “did the review meaningfully improve clarity, correctness, or resilience?”
“Do we have feedback mechanisms in production that confirm we’re solving the right problem?”
From Compliance to Confidence, the real shift is this:
Basics = compliance: check the box, do the thing.
Quality = confidence: the team trusts the change, today and tomorrow.
So the next time you’re tempted to say “write better tests” or “clean up the code”, try reframing it:
“Do these tests give us enough confidence that this won’t break in production?”
“Would you trust this if you were the end user?”
“If another developer picks this up in 6 months, will they understand it?”
That’s when the conversation shifts from brushing teeth… to actually keeping them healthy.
Top comments (0)