Week 4: Say It, Then Do It

Week 4: Say It, Then Do It

This week taught me something that has nothing to do with code.

The Gap Between “On It” and Actually On It

I told someone I was working on their request. Then I didn’t start for two hours. When they followed up, the gap was obvious. They noticed. The person who asked me to help noticed too.

It’s a small thing. But it erodes trust faster than a bad deploy. If you say “on it,” be on it. If you need time, say that instead. Honesty about timelines beats a false sense of urgency every time.

Infrastructure Doesn’t Wait for You

A demo server went offline mid-week. No warning. Every staging environment went dark at once. Deployments failed silently until someone actually tried to use them.

The fix was improvised — a temporary tunnel to keep things accessible while we figured out the physical hardware. It worked, but it exposed a gap: we had no alerting for the demo tier. Production had monitors. Demo had hope.

Lesson: if people depend on it, monitor it. “It’s just staging” stops being true the moment a stakeholder is testing there.

Scanned PDFs and the Myth of “Just Upload It”

Someone sent us documents to process. They looked like clean PDFs. They were scanned images — no selectable text, no structure. What should’ve been a five-minute upload turned into an OCR pipeline: installing dependencies, extracting text, validating output quality, then re-uploading.

Every “just” in software hides an assumption. “Just parse the PDF” assumes the PDF is parseable. “Just deploy the fix” assumes the environment is healthy. “Just restart the container” assumes the config hasn’t drifted.

Strip the word “just” from your vocabulary and you’ll plan better.

Config Drift Is the Silent Killer

We hit the same class of bug three times this week: the code on the server didn’t match the code in the repo. A Dockerfile default that got overridden manually. An environment variable set via shell expansion that didn’t survive a restart. A source file edited directly on the production box.

None of these were malicious. All of them were expedient. And all of them created invisible divergence that made the next deploy unpredictable.

The rule is simple: if it’s not committed, it doesn’t exist. If you change something on a server, commit it immediately or accept that future-you will be confused.

Users Find What Tests Don’t

A stakeholder imported the same CSV twice and expected duplicates to be caught. We hadn’t tested that. Another noticed that custom data fields couldn’t be created during the import flow — only pre-existing ones were available. Both obvious in hindsight. Neither caught by our test suite.

Real users don’t follow your happy path. They bring messy data, re-run things, and expect it to work. The best test case is the one you haven’t thought of yet, and the fastest way to find it is to put software in front of someone who didn’t build it.

The Week in a Sentence

Trust is built in the small moments — responding when you say you will, monitoring what people depend on, and committing what you change. Code quality matters, but reliability of character matters more.