Scratch the Itch
Today I had the opportunity to practice a favorite technique: scratching the itch. By this I mean I let my curiosity take charge, quieting the know-it-all that typically runs the show.
The itch
I was working on a section of frontend typescript code. I had noticed a few days before that my editor was complaining that a type was undefined. That is, for
let x: Foo;
my editor put squigglies under Foo and complained. This isn't unusual, as I am used to typescript errors appearing temporarily when switching between branches: the in-memory diagnostics haven't caught up to the filesystem changes yet. Besides, this code was already merged into develop, with CI checks passed. It must be my editor.
It must be, right? I suddenly felt the itch. The itch is molded with experience, but experience isn't required: the itch may better be framed as childlike curiosity. During service at my Buddhist monastery, I realized with delight that children in the audience asked questions that I was too ashamed to ask. And how does that shame serve me, when it holds me back? Adopting a position of innocence and curiosity can be a rewarding endeavor.
To scratch this particular itch, I actually looked at the error message: cannot find name Foo. I won't be too proud to admit that I sometimes glance over error messages, jumping to conclusions with a presumed root cause. Here was my (abbreviated) thought process:
This error message was strange, how could Foo not be found? Let me check the editor: reload the file. Error still present. Okay, is Foo not defined? Indeed, it is not! How does that make sense, if type checking in CI is passing? Let me run type checking outside the editor, with the CI command. Oh that's odd - the type checking command instantly succeeds. I'd expect it to take a few seconds - it's a hint when a tool succeeds too quickly. Let me check the typescript config.. hmm, I'm not familiar with this config approach, but I recall that we recently migrated from webpack to vite - let me ask gpt quickly. Aha - gpt suggests that running tsc with this tsconfig will not perform project type checking. That explains why typescript errors are present on develop - CI was passing on broken code! Ah, with the build flag, tsc should work.. yes, I now see the typescript errors!
This took about ten minutes. There are a dozen engineers on the team, and the misconfigured typescript check had been present for three months. It's not a dig on the team that it wasn't found until now - it's a signal of how much differentiation this small technique can provide for an engineer.
Lessons
The story is representative of years of applying this technique. I'll summarize a few takeaways/lessons:
- When something seems off, investigate. I ignored the error for several days before taking a look.
- Double check assumptions. I assumed that the problem was local, because CI must be passing.
- Time box. I stopped at identifying the broken type check command - surfacing the issue is valuable, and my teammate who configured the new system will be better suited to fix it.
Most of the time, these investigations don't pay big dividends: it's usually my implicit assumptions that are proved wrong in the end. That's fine, the active learning process itself is rewarding, as I hone my understanding of the system in addition to my investigation skills. Sometimes, though, the payoffs are big. As an example, I once found a password bypass in production when I scratched an itch.