On Different Types of Programming Styles

Software construction is the part of the software development cycle in which you actually write and debug the code. For code writing, an Integrated Development Environment (or an IDE) is used. This is the program used to enter your program, and run the build process. The software build process creates the object files from the source files through compilation, and the binary through linking. Once the binary file is generated, it can be loaded into the processor of an embedded system IoT device or simulator memory and executed.
During software construction there are two classes of errors, build errors and runtime errors. Build errors include compiler or linker errors. They are usually the result of syntax or configuration errors in the project files. Run-Time errors are errors in the actual operation of the program. When errors are found, the programmer edits the program and repeats the process. The number of iterations through this process can vary tremendously, partly due to the complexity of the problem and partly due to programming style; which brings us to today’s story.
The other day I was driving in my car, and the song “Who Are You” by The Who came on. For some still inexplicable reason, I started to ask myself “Who are people in the context of programming styles?” Following are examples of two extremes in programming styles that people may recognize.
The Code Hacker:
A code hacker is a programmer who cannot wait to type and run some new code. The hacker makes no effort to find the actual source of programming errors or to design a good solution. The first line of code that has any remote relationship to the problem is changed, the file is saved (sometimes), and the process is repeated. Usually this haphazard approach adds more errors than it fixes, but if the code hacker works on it long enough, a working solution will eventually appear. Once the program works, the code hacker will send the code to someone else and announce proudly, “I’m done.”
The Computer-Shy Perfectionist:
Some programmers actually take error messages personally. They will try to write a complete program in a single iteration of the construction process. This type of programmer is terrified of the keyboard and will avoid it until he or she can prove that the program design will work. The program design has pages of flow diagrams, state diagrams, and even source code snippets written on paper. The keyboard still has not been touched, however. These programmers usually cannot be found – they are in seclusion until they are positive their program works.
No doubt the best programmers are those that put sufficient thought upfront to do careful design of the solution for a given program, and that also use the actual hardware system as a learning experience to gather valuable run-time information to understand, not only that the program works, but also why it works, and how it works.