A little Debugging Guide
I'm a community-minded engineer based in Berlin, originally from Romania, and I grew up in sunny Spain. I combine the best of both communication and technical skills, with experience in both the engineering world and the business side of things. I'm proficient in a wide range of technologies like JavaScript, React.js, Redux, TypeScript, Node.js, HTML/CSS, Styled Components, SASS, and REST APIs. I love going beyond just writing code by sharing knowledge with my team through Communities of Practice (COPs), Employee Resource Groups (ERGs), and detailed technical documentation. My main interests are in frontend frameworks, web standards, accessibility (A11y), and Clean Code. My passion for programming started in high school when I built my first website. Since 2019, I've been working as a professional software developer, thriving in agile and iterative environments. Nearly five years later, I'm still excited to dive into code and collaborate with my colleagues. I'm very open and friendly, good at turning technical concepts into easy-to-understand information for everyone.
To fix a bug, you first have to understand the story the code is telling you: why it was built, and why it was organized this way. Code is never random: every file, every data structure, every reference exists for a reason. The bug is the moment where the story the code tells and the story you assume stop matching.
Debugging is the work of finding that exact gap. My lead, Fernando, explained that we can think of tackling this 2 ways:
- 🌳 The Tree Way (Local View)
Imagine a tree, the file you are located, or the one you start from, that is the single file you have open in front of you. This is deep, you need local understanding: what does this exact function do, what does this line return, what is this variable holding right now - why in our case is it not behaving as expected. When you're on the tree, you're asking narrow, precise questions and you can answer them with certainty because everything you need is on the file(or view).
The danger of the tree is tunnel vision. You can read one file perfectly and still have no idea why the bug happens, because the cause lives in a different tree - somewhere upstream that you haven't looked at yet. Staying too long on one tree is how you spend three hours convinced the bug is in code that was never the problem.
Key traits:
Deep understanding of one file/function
Precise, answerable questions ("what does this line do?")
Certainty, because all the info is local
Risk: tunnel vision - the cause may live in another tree
2. 🌲 The Forest (System View)
The forest is the whole system: how files relate to each other, where data is born, how it flows, and where it finally gets stored or rendered. When you're in the forest, you stop asking "what does this line do?" and start asking "where does this data come from, and where does it go?" “what is the shape of it?” “how does it get store” “what triggered that storage?” “how many files are involved?” “how is it being shaped and passed down?”
The forest is where you understand why the code is organized the way it is. You see that the binary references are saved in one module because three other modules depend on them, or that the context is built early so it can be passed down everywhere. This is the architectural story.
“You can't fix a bug if you don't understand the shape of, and the shape only appears from the forest.”
The skill of debugging is not living in one view: it's switching between tree and forest on purpose.
Stuck on a tree? Zoom out and trace the forest.
Lost in the forest? Pick one tree and read it line by line.
The bug is almost always visible from one altitude and invisible from the other.
Key traits:
Understanding relationships between files, not just one file
Reveals why the code is organized this way
Answers "where does this data come from / go?"
