Came In For Unit Test But Went Back To The Drawing Board

We were supposed to be talking about unit tests.

Thirty minutes in I'm reading through his PR comments and I notice something. The early ones from his lead are detailed, pulling at the problem, asking the right questions. The recent ones are "it's wrong, go back and fix it." Same lead, same engineer, completely different signal.

He came to me because he couldn't figure out how to write better tests. What he actually needed was to figure out which problem he was even supposed to be solving, because without that context the tests didn't matter and neither did the implementation.

We scrapped the original plan and started over. I caught myself saying "I don't know, but here's how I'd find out" more times than I can count. That was the session. Not me having the answer, both of us reading the paragraph before we tried to pick the numbers.

You know how math word problems work? You get this whole story with a dozen numbers in it and if you just grab the ones that look familiar and plug them into an equation you half-remember, you get the wrong answer every time. But if you read it first and pattern match the story to the right equation, the numbers you actually need jump out at you.

The tricky part is knowing how to read it that way. Some people figure it out from the textbook. Some people need someone to sit down and work one problem with them before it clicks.

I'm here for the second kind.

#SoftwareEngineering #DevOps #CareerGrowth #CodeReview #SRE