In dealing with databases, there are times when one must do some level of programming. With the rise of the variety of ETL, data pipeline, and data platform tools, programming elements have become mushy, confused, and scattered. This confusion has arisen because of what happens, and where that “what” happens has devolved into everything, everywhere, all at once.
But on occasion, a database-oriented function, a macro, a trigger, or even a stored procedure becomes an option to be explored, if not implemented.
Currently, it often seems as if programming is considered an inconsequential task. Grab bits of code from the internet or have AI apps generate code for you. Slap things together. Heck, people are more likely to use an AI bot to write a poem for them instead of wishing to truly express something of themselves. If the first attempt doesn’t run properly, try again and again.
Apparently, testing is almost as inconsequential as programming. If a module executes without error, then that piece of code must be correct, right? If there is something wrong with one’s code, someone, somewhere will eventually let you know. (Then you can grab some different code to perform whatever task is at hand.)
These attitudes seem to express that no one should really care about getting a coding task accomplished correctly and well. Do we live in a world of diminished consequences?
Back in the early days of programming, right after the dinosaurs died off and we finally figured out how to create fire, computer cycles were not cheap. The process of getting code gathered, executed, and results ready to evaluate was lengthier than one can imagine. Therefore, writing bad code was very much something to be avoided. Reworking, redoing, re-executing was burning time. How did one avoid that circumstance? Bad code and failed programs were circumvented by pausing and thoughtfully planning ahead.
Before one starts to write a program of any sort, they should be clear about the goal of what is to be done. If ambiguity exists, this is the time to ask questions and investigate needs. Is the problem even framed adequately? This adventure falls under a general category of both functional and technical requirements-gathering. If you do not feel you know what you need to know, take a breath and start exploring. Are there subjects that ought to be more thoroughly researched? Are there questions that need answers?
One doesn’t need to physically create a flowchart for every solution, but that level of detail should exist within the developer’s mind before they begin coding. If not, missing that level of detail is a significant problem all by itself.
There are enough issues arising as one writes, executes, and debugs code. Removing typos and getting the syntax correct can take time. Let the errors simply be things that one can easily track down and fix. Minimize the other issues that may be at play too, like the whole approach being wrong. If the result of one’s programming efforts is a right answer to the wrong problem, there will never be an error message to address a need for a fix. Making sure one has defined the problem properly, examined the approaches that may be needed, learned a new keyword or two to make a process work as expected—these are the chores that bring programmers to a result that smells strongly of success.
Some tasks can fail and not be a very large issue; others, not so much. Who would accept one’s bank losing one’s money? Likewise, should we expect a hospital monitor to misinform an attendant or cause a wrong action to be taken? Do organizations need to work against the natural inclinations of their own development staff to force rigorous testing to prevent failure? Every engineer should strive to create tight, correct code every time they start working at their keyboard. It begins with a proper attitude and attaining confidence in one’s goals.