In the earlier days of computer programming, where punch cards were used to store our applications, there were a variety of ways to keep your code in order. One such method was to draw an arrow on the side of the card, and you would visually be able to see that your card stack is correct or not, another such item was the IBM Card Sorter. The card sorter would inspect the cards and sort them based on the punches, this helped reduce a significant amount of time for manual sorting of punch cards and freed up application developers to work on the problems their applications were designed to solve.
So what does the short history lesson have to help us in this modern age of software craftsmanship? Tools, use them! Some developers have built up a measure of pride that they do not use any help from code analytic aids; they can do everything they need in a simple text editor. The ability to write an application with just a text editor and have it working is great, but when the typical program is over a 100 lines of code, knowing that you had written the right code without any side effects become difficult. And pride does not write applications that are maintainable pride produces artifacts that feeds itself. Leaving challenges and problems to be solved, so it can say I solved this problem, or I was able to add this feature in what appeared to be impossible. So leave your pride outside and use the tools that exist to write your applications.
We have a large number of tools that have been produced to help aid with the development of JavaScript applications, for debugging, linters for coding practices and catching unintentional side effects, etc. The list is more extensive today than it was ten years ago, where the best way to debug your code was to throw alert statements in your application and try to see why it was breaking.
Add to your development pipeline all the tools you need to help your code to be the best it can be. Remember the code we write is not written for machines to understand, if that were the case we would still be writing in binary perhaps assembly, it is for humans! And as humans, we need to communicate the intent of what we expect the application to do so that when someone else comes in to fix a bug, they do not have to spend hours figuring out the code’s intention and focus on fixing the bug or adding the new feature quickly. All this, in the end, is so that our customers gain the value from our applications that we have written.
