As a beginning programmer you spend most of your time building single purpose methods. Your code is very limited in both scale and scope, but as you continue to grow, your projects continue to grow: they require more files, more classes, more methods, etc. This growth comes with possibilities, but it also comes with vulnerabilities.
Components
If you visit any Biology 101 class, you will likely hear the phrase “Emergent Properties”, a property of a system that is not shared by its component parts. It’s a really cool concept that can be scaled and regressed infinitely. You can find emergent properties at the atomic level or the planetary level; or to stick with Biology, at the cellular or human level. A quick example is the protective properties of a tissue surface that an individual cell does not have.² One important note about these surfaces is that their protective value depends on their form or their arrangement of individual cells.
Programming has similar concepts of emergent properties. Programming languages have predefined meaningful words. A randomly typed string of letters in a console is unlikely to have meaning. By this token, a correct form of a string of characters is a prerequisite for its function — the function represents an emergent property. But meaningful words are only the beginning of programming functionality. You have to be be able to string together many meaningful words, also in a meaningful order before you can accomplish even the most basic tasks.
The ordering is a property of the overall ruleset of the language, or syntax. You need to have proper syntax to build methods that have functionality beyond a single meaningful command. And in order to build a full program, both the methods you choose and the order of the methods you choose matter. As a reader you can notice the pattern in these relationships and as a developer you can attest to them.
Programs are summations of their parts. A basic program has a very low sum and is very easy to debug — as long as you read the error message. But, as you increase the scope of your program you increase the scope of your failures. An error in a very big program can be extremely difficult to find the source of, let alone solve. This increasing complexity of errors is true so much so that when asking higher-level developers about the debugging process they use terminology like “intuition” and “hunch”, as opposed to more prescriptive answers:
As a beginner it can be difficult to comprehend why bug finding can get so difficult. This is because as a beginner you spend most of your time working closely with the programs individual components and can forget how complexity arises. See, no one is surprised at the complexity of a medical diagnosis, despite the ability to break the body into component parts. This is where the scope of analysis comes in to play.
One method should do one thing.
I’m not going to go into debugging techniques, because it is a massive subject that I know nothing about. But I am going to touch on Abstraction: a concept that you can implement today that will help prep you for your debugging adventures.
In programming, Abstraction is concerned with ignoring what is not relevant to a method. It is a concept that when understood, greatly helps in organizing your code. It is not a tool for searching out errors, but it does help in the debugging process because of the compartmentalization of methods. Abstraction says that a method should only know and do what is relevant to its purpose. This is the number one way of reducing unnecessary complexity.
Abstraction is Storytelling
As we’ve already stated, a method is rarely isolated. As the size of the the program increases, the number of methods that exist, intertwine, overlap, nest, etc. increase. With it, the importance of abstraction increases. If we have a Basketball game program that tracks the game’s quarters, player’s points and shots, there will need to be a method that tracks points, a method that tracks shots, and a method that tracks quarters; but how do we increment the quarters without losing track of the shots and points? A bad example, I know. I’m sure you can figure that out. But now imagine you are tracking all of that information for all of games of all of the teams for all seasons they’ve played. The code gets complicated quickly because of all the different scopes. This is where abstraction comes in.
In order to keep up with your program you have to constantly make sure your abstraction is up to date with your model. You should always be able to read your program like a book. In the sense that you know what’s going on as each step is executed, line by line, method by method. Therefore when you do come across those bugs, you know what chapter you’re in.
Debugging isn’t easy. There are entire books on the subject, spanning from beginner to highly advanced. As a developer you have to learn to keep your code formatted in a way that is functional and legible. That way as you build you can continue to integrate new functionality and still be able to locate bugs when they arise. Abstraction is your friend. Tell your story.
