Before you build a house, you design a blueprint plan that shows how the house will be laid out. Once completed, you use a variety of tools to build the house according to that plan. Solving a programming problem is no different from this approach.
When you encounter a programming problem, your first step should NOT be reaching out for the bulldozer that is a programming language. Instead, plan out how to solve the problem in human language (i.e English), then implement that plan using code. In this manner, a programming language is solely a tool used to implement logic.
This isn’t to say that “you shouldn’t think like a computer”. Rather to highlight that “thinking like a computer” is NOT equivalent to “thinking in a specific programming language”. A computer is composed of hardware and software that runs programs by processing 1s and 0s. A programming language is a tool that helps you create those 1s and 0s in an efficient manner.
Reinventing The Wheel
When it comes to software development, there is no need to reinvent the wheel (unless the wheel isn’t sufficient). While creating software that already exists may provide you programming practice, chances are that you’ll progress faster using established tooling. Let it be known that a programming language isn’t the only developer tool that exists. The significance of the existence of other tools is that you must keep an open mind while approaching a problem.
When you are restricted to an interview format but need persistent storage, creating a data model from scratch is your only option. However, when you work on an actual project, why not use a database? Of course, this requires you to understand what a database is. How can you acquire knowledge about a tool without knowing what it’s called? That’s where your plan comes in. While you may not have the exact name of the tool you need to use, you still have a “Plain English” description and a Search Engine at your disposal: Use it.
How to Fix an Error
Debugging is the process of finding and resolving errors. It’s common for amateur programmers to freeze up when an error is encountered. Others start searching the internet for various solutions. In doing so, you forget that an error is simply a message which indicates that “a program did not function as expected”. In other words, an error message presents a problem that you are able to solve.
Reading the error’s message is the first step to solving the problem. This phrase sounds obvious, but you would be surprised how many people encounter an error, then immediately rush to their browsers to copy and paste its message elsewhere. While this strategy works for common errors, you’ll hit a wall when an obscure error occurs. In these cases, you must understand what the human who wrote the error is warning you about.
Sometimes, you’re required to search for an “error” directly: Humans make mistakes, so it’s possible for an error to occur, but not be recognized by the man-made program that caused it. In these cases, you must remember that — as discussed in The Evolution of Programming Languages — any computer operation comes down to the bits (1s and 0s) that are being processed. In other words, there is a line of code that is causing your problem, so the fix to your problem involves fixing that line of code.
When you are working with a program using an Integrated Developer Environment, your error can be solved by analyzing the stack trace of the program. In other cases, you will have to read the log files which the program outputs; if logging output has been implemented in the program in the first place. Using this information will allow you to find the origin of an error in its respective codebase.
Programmers have created tools that are used to debug errors called debuggers. However, using a debugger is not always available or necessary. In these cases, it’s important to understand the code you are working with at a fundamental level. Doing so will allow you to work back from any error message that you receive.