While writing code, whether it is some solution to a coding challenge or it is an industry grade software written to scale, there will be an inevitable occurrence of bugs and errors. A developer would resort to various means to resolve those issues at the earliest to make sure the software is working properly. However, there will be certain instances when the developer stays stuck on that particular issue for hours, or even days. These are the few things I keep in mind as a developer which helps me diagnose code a little faster.
What is coming in and what is supposed to come out
Analysing what are the inputs of your program and what it is supposed to do with that, is pretty obvious, but somehow most developers miss out on this basic principle. It is self explanatory, however, for the sake of clarifying, I will take a moment to explain what this principle means. If you write a function which takes in a string and an array as parameters (input), it is imperative you provide the same, and that too in the right order, in case the type of data is relevant within the function for each of these parameters. In case you pass in a number instead of a string, it is expected the function to misbehave, perhaps the output might still be valid, but it won’t be as expected. Such inconsistencies are common with a larger software with more complexity.
Understanding how the data structures behave
In continuation to the previous point, if the data structures used in the code are not behaving the way it’s expected, it’s possible we are using the wrong ones. For example, in JavaScript, an array and an object share very similar syntax (an array and object both can be expanded using the spread operator [...]), however, their behaviour is different, as an array is iterable and an object is not. Even though such basic errors can be thrown by the system to notify the developer, but at times with much more complex structures, either built in or custom, it is very common to lose track of such subtle behaviours which may lead to a different output altogether, if not a direct error.
Understanding the language itself
If I speak Tamil to a person who speaks Sanskrit, chances are that the other person might not catch everything I want to say, even though there might be similarities here and there. Similarly, if you are used to a particular syntax over time, doesn’t mean it is interpreted the same way. For instance, ECMAScript keeps coming up with new features being added over time. The direct implication of this is that JavaScript and related languages keep evolving too. So, even if a developer is seemingly trying to use a valid syntax, chances are that the same thing can be done in an efficient manner without causing confusion to the machine or the coder. Therefore, knowing the language, and its tools, that you are working with becomes fairly important while debugging the code.