Nasif Imtiaz

We often embark upon a feature based on a *purpose*. But while coding, it may feel tempting to do extra that is adjacent to the core purpose, or to even lose track of the boundary of the purpose. I have definitely done extra just via the sheer “inertia” of doing things. The catch here is that, we probably haven’t evaluated if this extra thing actually fits the purpose.

Nasif Imtiaz · Follow 1 min read · -- The semantics of your logic can be clear, but that may not align with your data structure. Not understanding the data structure you’re working on is a signal for danger. Properly understand the input data you’re working on and attack it from all angles. For example, once, I became lazy and wrote a graph query to find certain types on node that are “reachable” from a given node.

When working in large codebase, you come across something that doesn't work for you. You regret for your lost time and curse the person who wrote this bug. This stupid bug! You quickly make the "fix" that works for you and you are tempted to check in your fix so the world knows how smart you are. But behold! Think for a moment why this code worked for someone else. It must've worked, in no matter how niche a path, for someone to have checked in that code. And yet, it didn't work for you.