There’s an enviable quality of great engineers I’ve known: they seem to get things right the first time. When you ask them to do something, and they say “It’s done”, it is, almost always. How?

Here, I think there actually is “one weird trick.” It’s a bit tedious, but it compounds and is dead simple. It’s checking your work before delivering.

Agile Foundations

I did not invent this idea. It’s core to many folktales and fables, and also to Agile software development.

Many Agile methodologies prescribe the concept of “verification.” A unit of work isn’t released from an engineer’s care until it’s verified.

What does this mean? The owning engineer logs into a production-like environment and proves that it works by following the acceptance criteria to the letter. Work checked.

A Real-World Example: “Can You Help Me?”

I think this applies just as well to the many “Can you help me?” requests we get as engineers.

Scenario: a person on my team is experiencing a white screen on a webpage we maintain. They collect information and conclude that a database migration needs to be run. Perhaps I’m the database SME, and so they ask me to validate their conclusion and run the migration.

I log into the server and run the migration. It reports that it succeeded.

Then, I go back to the person who asked for the migration and say “It’s done.”

The big question here is, “Is it done?” I expect my opinion is starting to soak through. No, it isn’t!

Truthfully, I don’t know if it’s done. I know that I ran the migration. I don’t know if the migration error went away, or if the site is accessible. This level of service, “I did the thing you asked”, is common in software engineering.

The missing step is checking your work. And so, after I make the change, I verify it: logging into the web application that the requester is viewing and checking firsthand that it’s accessible.

Counterarguments That I Buy

“But it usually just works!” Accurate.

“I won’t remember to do it!” I’m a detail-oriented person by nature, so this way of thinking came easily to me once I recognized its power. For some, it can be more of a struggle. I’d still recommend trying, because over time it leads to less work and back-and-forth conversation for you, which I’d hope would be appealing to most engineers.

Counterarguments That I Don’t Buy

“It takes more time!” I agree, with a major caveat. Yes, every time I do it, it takes me a few seconds, and that’s time I could be using to do something else.

But, I get a ton out of doing it:

  • I gain empathy for the person
  • I build complete confidence that it is fixed
  • I increase overall trust in me from the requester
  • I reduce the chance of rework

Sign of Teams That Don’t Do This

Have you ever seen a conversation like this in chat?

Developer A: “I fixed that thing you asked for.”
Developer B: (minutes later) “It still doesn’t work.”

This is a symptom of teams that don’t check their work. I can’t count the amount of times I’ve been Developer A and B; you probably have, too. In the former case, it makes me wonder if the person helping me even tried, and if it happens repeatedly, reduces my confidence in them a tiny bit.

Next Steps: Check Your Next Task

So, the next time you have a software task to complete, ask: “How can I verify that this is done myself?” Here are a few examples:

Request: “Can you give me access to the analytics dashboard?”
Solution: Log in, add them as a user, and then verify that the “Add user” page says “invite sent” to their correct email.

Request: “Can you upload this PDF to our shared drive?”
Solution: Upload it, then click on it to make sure that it’s there, opens, isn’t corrupt, doesn’t require additional software or permissions to open, etc.

Request: “Can you share a link to those docs?”
Solution: Post the link, then click on it to ensure it’s the page and HTML anchor you meant to share.

When you do this every day, you become an engineer that people trust will get it right the first time.