Programming ideas I have discovered through reading and programming extensively
This article describes programming ideas I have discovered through reading articles, books, and other resources I could find online. With my extensive research driven by curiosity, I have some ideas for becoming a better programmer. As a disclaimer, I may not be correct regarding some of these, and I am aware of that. A programmer stays humble, learns, and improves. As Bjarne Stroustrup said, chasing perfection is pointless. Trying to make something perfect for eight years, and after eight years, when it becomes perfect, a new thing will come out, and it won’t be perfect again. Perfection is the enemy of good.
A year and a half ago, I used to think there were already predefined things or ways to use to solve programming problems. The reason I believed in that was because of tutorials. Whenever I needed to do something, for example, create a CSS animation or write a program using ReactJS or anything else, I would search for a tutorial. A tutorial gives a set of steps to make it work, which made me believe those steps were the right way to do it. However, over time I learned that isn’t the truth. Instead, there is an infinite amount of ways to solve a problem.
For example, when I was trying to create a ReactJS setup using Webpack, Babel, and other tools that we need to do that, I followed some tutorials here and there. But I couldn’t make it work and didn’t know why. Much later, I realized I couldn’t make it work because I didn’t know how it worked. To put it all together and make it work, I need to know what everything I use does. Once I can tell how everything I use does, I can reason about it. Then, I can put it together and have an excellent guess on why it works or doesn’t.
A couple of months later, I listened to a talk by Bjarne Stroustrup, and he said that programming is understanding. Based on my previous experience, I could relate. I tried to set up a toolchain following the tutorials. I couldn’t make it work because I didn’t know how it all fits together conceptually. To make a program work, I need to understand why it doesn’t work.
Only people who have had the same or similar thoughts as the ones I express in this article will know what I mean. For others, it might be too unfamiliar if they have yet to experience what I’m talking about and may choose to trust me or don’t, whichever is preferred.
So if there is no predefined way to do something in programming, how do you know if you are doing it right? My current belief is to truly know what every piece of logic does and use Software Engineering Principles and Practices. I used word logic because we need to know how the logic works and, after that, the code. The code consists of two parts, written and unwritten part. A programmer’s job is to figure out an idea of a potentially working solution on the conceptual level in his mind. A programmer is supposed to write code after thinking and understanding what the problem is. Once the programmer understands what the problem is, he then tries to figure out a solution which is the algorithmic solution, a set of steps that a program can execute. Once that solution is laid out, a programmer writes a code for the solution he came up with.
I often see programmers jump into the code before they know the problem and the solution. I used to do that before as well. I still need to feel more comfortable approaching problems from the idea’s perspective and afterward from the code. Actually, approaching an unfamiliar problem is frightening, but that is in human nature. Going first time to a place I’ve never been before will make me uncomfortable for sure. Therefore the first step is to get familiar and comfortable with the problem. The next step would be to understand the problem. If I cannot understand the problem and hold it in my mind, I should try to do it in any way possible. Once that’s ready, I need to think of a conceptual solution, an idea that may work. Once the idea is ready, I could write the steps on a paper, notepad, or anywhere, in the sense of pseudo-code. Many resources use pseudo-code, often a shorter and less concise version of actual code. Pseudo-code allows for a vague description of the solution, which I can use as a guideline to write the code. Pseudo-code is a good use of time because it will take much more time to write real code based on that. Especially if I need to learn how to write it. Then I have to figure out how to write the real code based on the pseudo-code.
When a programmer jumps into the code to solve a problem he doesn’t truly understand using a solution he has yet to learn, the code becomes messy. That is easily explainable by the fear of modifying the code. That fear means the programmer doesn’t know what his code does and how the change affects it. As long as a programmer fears changing the code, the solution could be improved greatly. A programmer should be able to delete the code and rewrite it again from scratch. That means he knows the problem and the solution.
Using Software Engineering Principles is extremely important, and I have to work on that. I have recently realized how important SOLID principles are. This is just a fresh idea that I’ve had. I’ve read on Quora that the code will be good if you apply SOLID principles as much as possible where it makes sense. The guy wrote in the answer that we should use them sensibly, as with anything else in programming. For example, I’ve read an article on the Open-Closed Principle. A class or module is open for extension but closed for modification. For example, we can add something to the class or module if it works without changing the class or module. If such an addition requires change, it is time to split the module or class. These ideas sound good, but I feel like I never used them. A year and a half ago, I felt like my code was a mess and that I always had to refactor when an addition was required. Something tells me that’s because I didn’t know how to use SOLID principles.
These were my thoughts, ideas, and conclusions based on previous experience.
