During the past few weeks, I’ve been continuing to read through “The Complete Software Developer’s Career Guide” and I’ve finally reached the section about “The Maintenance Phase.” Sonmez has offered an incredible perspective on the world of software development, but arguably the most important lesson I’ve learned is the mindset and strategies behind problem-solving. Throughout my coding journey, I would almost always jump into the debugger when trying to fix errors or bugs. It ended up becoming a habit and sometimes cost me countless hours because I didn’t fully understand the problem’s source and the steps to solve it.
Sonmez states that the debugger should be your last resort, “If you can’t reproduce the problem, there ain’t no point in debugging it.” At first, I wasn’t sure about this idea because I’ve heard from many developers that you should always have the debugger open while you’re working and displaying the code in the browser. It might depend on the scale of your application, but I do agree with Sonmez to an extent. Sometimes the initial mindset to problem-solving is finding the solution because of instant gratification, but there can be many solutions to one problem. We code our applications in different stacks, languages, frameworks and still reach a successful outcome. It’s not just about whether you know the programming languages, but there are several algorithms that you can sketch and implement to build a stable platform.
When I was first learning to code, my reaction to receiving any type of error was “what’s the solution.” This confirms Sonmez’s statement about how early developers are eager to solve the problem. I would start playing with my code until something worked and the error message disappeared. The biggest issue with this is that you can alter the functionality of your application critically without even knowing it. If you don’t take the time to understand how the problem occurred step-by-step and line-by-line, it will likely lead to more frustration once the project scale increases.
One of the strategies that Sonmez discusses for fixing errors is brainstorming hypotheses and writing a unit test to determine if they are correct. This ties back to the benefit of writing tests on your own without relying on other resources. Almost all of my GitHub repositories have auto-created tests so as I continue to build more mini projects and applications, I hope to focus on writing tests. As Sonmez states, this will give me a greater awareness of what caused the problem and how to fix it as well as reading error and syntax messages thoroughly. I think this can add a lot of value for any developer because they will have more experience in testing.
If you’re working with existing platforms, you also want to make sure that the code is stable and that every change is effective instead of creating larger problems for you and your team. Sonmez says that if this means “writing an extra unit test to make the code a little more robust for the next developer, do it.” This also explains the importance of git commit messages, something that I’ve significantly improved on since I started programming. When you’re working across multiple branches and files inside of a project or repository, communication is a key component. If other developers can comprehend what you fixed and its context, it overall prevents the time spent on debugging.