After 25+ years in the IT industry, I've developed a mental model that completely changed how I approach any codebase. This is the framework I wis...
For further actions, you may consider blocking this person and/or reporting abuse
the productive-looking vs actually productive framing is the one. I fell into this so hard early on - open ticket, grep for the thing, start editing, wonder why tests break in 5 unrelated places. now I spend the first 20-30 minutes just reading. not even searching, just following the execution path from the entry point. feels slow but you catch the assumptions the previous dev made, which is usually where the real bug lives
Yep, catching the assumptions is the whole game. Half the time, the bug isn't even a bug; it's two devs who had different mental models of what a function was supposed to do, and nobody wrote it down 😄
the undocumented mental model mismatch is the hardest one to debug because there is no error message. just two people who thought they were talking about the same thing and weren't
Step 3 (follow the data) is the one that took me longest to internalize. I used to treat code like a text adventure game - just navigating function to function. But once I started actually tracing what the data looks like at each step, everything clicked differently.
One thing I'd add: git blame is underrated for step 6. When you see something weird, checking who wrote it and when often leads you to a PR with context you'd never get from the code alone. Sometimes it's a bandaid from 3 years ago. Sometimes there's a whole Slack thread linked. Either way, you're not guessing anymore.
The payments example is painfully relatable. Nothing humbles you like silently breaking something that touches money.
"Sometimes it's a bandaid from 3 years ago" - yes, totally agree, how many times have you seen a //ToDo comment in some code from years ago 😅
Short-term speed is always a trade against long-term consequences. Know which one you're optimizing for.
YES. I'm currently watching my kid learn how to play the flute and they keep wanting to go faster. And I keep reiterating that speed is a natural byproduct of proficiency. Once you understand, and are proficient in something, you naturally will move faster. And so speed should never be the thing that is prioritized, lest you will sacrifice your understanding
"Speed is a natural byproduct of proficiency" -Totally agree, when I was learning to play the guitar and wanted to play fast. After I slowed things down and got muscle memory, I was able to start playing faster.
Really solid advice here. The distinction between asking 'where do I add my code' vs 'what is this system trying to do' is something I had to learn the hard way early in my career. Taking 30 minutes to read before writing anything has saved me countless hours of rework on large codebases.
Thanks. Yes, I think we all made that mistake; I know I did!
Agreed 100 percent, but well:
"Next time you open a codebase — don't type anything for 30 minutes. Just read."
No-brainer - who in their right mind would not do this when starting to work on an entirely new codebase? For something substantially big and complex, change "30 minutes" to "at least a day" ...
Yes, it was born from observation of some of the juniors I have mentored. They were so eager to get started, they would literally start refactoring code as soon as they opened the IDE... 🤔
Great tips Mark!
Thanks Scott, appreciated