Seasoned developers resist the temptation to believe what they read in code. Yeah yeah, so your professors told you that commenting code and using descriptive variable names are good practice. It won’t save you when reading someone else’s code. It’s true, these things can help guide you to truth, but they’re not truth in and of themselves. When you’re heads-down debugging a mysterious problem in code you didn’t write (or maybe you did), you might as well replace all that helpful text with hieroglyphics. Because you’ll save time by eliminating red herrings.
I saw this transpire with a recent news story, allegations of wrongdoing backed up by evidence from configuration files. The allegations were later debunked. It all centered around the word “throttle”, assumed to have a meaning that turned out to be inaccurate. The accusers had to rescind their story, presumably to much embarrassment.
When I first read the story, I cringed. Not because of the alleged wrongdoing, but because the accusers were being sloppy. They trusted what they were reading, that it meant something that was obviously true, and did nothing to verify those assumptions.
Seasoned developers don’t make this mistake. And there’s an interesting social awkwardness that results. When you are brought in to debug a problem you’re not familiar with, you face a social dilemma: be nice and accept what people tell you without skepticism, or question everything in what appears to others to be a pedantic ceremony of wasted time. Good developers accept nothing and question everything in the face of social scorn, and they’re right to do so. Here’s why: if assumptions accepted as truth are in fact correct, why hasn’t anyone solved the problem yet? On average, unsolved problems are far more likely to be based on invalid assumptions than to have inexplicably invisible solutions.