I am a college student currently residing in Katy, TX. I don't own any spurs, horses, or oil wells (yet), but I do write country songs and own a gigantic cowboy hat. I also roped a jalapeño once.
A competent coder familiarizes himself with the natural behaviors and plugins of the engine he is working in, doing just enough to alter them to his needs. If an object naturally exhibits gravity, he does not tell it to do so; he only tells it when to ignore or work against gravity.
For efficiency, this is ideal. However, if elements of the engine begin to behave in ways they shouldn't, his programming falls to pieces. Most dangerously, his programming falls to pieces in ways he can not readily understand or anticipate, because he has not familiarized himself with the inner workings of the engine's natural behaviors and plugins, only how they affect his job as a coder. In other words, he does not know the code thoroughly, only partially.
This problem is less of a threat to a coder who has programmed his own engine. He has painstakingly built every behavior and manually recreated every function that would be a plugin in a pre-manufactured engine. He knows the code thoroughly. There will still be issues, and in fact, there may be more issues with his hand-built engine than with a professionally pre-manufactured engine, but his ability to troubleshoot and alter the issues at their source is what sets him apart from his lesser competition, baffled by issues within the engine and helpless to correct them even when they are identified.
In application, we can not all build our own engines from scratch. We can, however, familiarize ourselves throughly with the coding, understanding the natural behaviors we work with and not relying on plugins until we can recreate them manually using the engine's natural behaviors. In other words, we have to know the engine so well that we could build it ourselves; our choice to utilize the pre-manufactured engine must be one of time limitations, not ability limitations. The ability to troubleshoot and alter the problem at its source is paramount; nothing is too sacred, too established, to be redefined or replaced if it does not serve the needs of the coder and his programming.
Legislation is no different. A masterful lawmaker is a masterful coder. He can not simply create laws based on the natural behaviors and plugins that constitute his constituents' culture, history, and so on. He must anticipate what will happen if and when the source code is pulled out from underneath his feet; he must assume nothing, expect nothing, and have a contingency plan for everything that could happen and everything that probably couldn't. He must know humanity thoroughly, not partially, enough to step in for God, not just enough to do his textbook job. If all goes well, he'll never need to exercise his capabilities, but when his world is coming apart at the seams, his partial or thorough understanding of human nature will make history.
Though not as technically taxing as a coder's work, a legislator faces one major issue a coder normally does not: the source code is constantly changing, without his consent, and often without his knowledge. Most disturbingly, it is changing without any self-regulation or particular sense of direction. A coder only has to understand his own work; a legislator must understand all of humanity's.
No blogs were found matching the criteria specified. We suggest you try the blog list with no filter applied, to browse all available. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.