Along the road to enlightenment, I’ve had some superlative teachers, professors, and friends instruct me on the best ways they knew to implement everything from Levenshtein Distance to Diffie-Helman compression, from polygon intersection to Relational Division. These lessons weren’t always apparent, and hardly ever enjoyable, but the knowledge and satisfactoin at the end of the project often put me years ahead of self-study.

Several times, I’ve been asked questions to which I’ve had absolutely no idea as to the solution. Yet, right then and there, an answer was demanded of me. It’s difficult and embarrassing, but situations like these are more about the reasoning than an off-the-cuff answer. This is an important concept, since it is a large step on the road to Doing Big Things.

Such occurrences were relatively commonplace, and for a long time I couldn’t figure out why someone looking to help me was asking a question that I either obviously had no business answering, or that was completely over my head. Then, just a few days ago, I stumbled onto the concept of zen. Zen, for want of a clearer definition, is the internal feeling and state of mind which is, in rudimentary forms, omniscience about a subject. It is the absence of bounds or form of knowledge in an area of concentration or meditation.

Zen and the art of programming was an interesting thought experiment, and until then I had no idea zen was being taught to me the entire time.

A mondo is a component of zen scripture where the roshi (`roh-shee) [teacher] asks the student a question, demanding an immediate answer. Since this question is often complex or multi-part, the process of developing the answer is more critical than the answer itself, akin to the Biblical scripture of teaching a man to fish. Had the pupil regurgitated some decade-old algorithm learned in Intro to VisualBasic doesn’t further the understanding of the problem at hand. Just because you may have learned bubble sort first doesn’t mean it’s the best choice for your production code base. A mondo would solve whether insertion sort would suffice instead of spending two days of company time implementing heap sort; and, more than that, it should help you realize the patterns in the future to prevent the same questions from needing attention again.

This insight, the ability to anticipate or at least keep pace with the business’ needs, is one of the most efficient ways to show off one’s skill in a profession. Especially now, when employers need to “cut off the fat” out of their budgets and reign in on ambitious funding of pipe-dream projects to stay competitive.

And there’s no reason you shouldn’t want to continue to learn. If nothing else – and trust me, there’s plenty else – you will bring those skills back to the workplace every day, inspiring those around you and impressing your superiors. That’s not even counting the personal satisfaction of reasoning through an enigma and coming out the upper side with a better solution or clearer understanding of the problem.

This is not to say, however, that they are insurmountable. Often, in fact, when we stop trying to over-engineer our system and evaluate the situation as it is, we can make optimizations beyond our expectations. As a simple “for instance,” presuming we have a determinant for a conditional that is initially a free-text entry. According to this pretense, Boolean evaluation can take as little as the first byte in the string or as much as the full text of the string; thus, for sake of computation time, memory, and most of all maintainability, it should be avoided at high cost. Compare this with replacing this free-text with a numerically-indexed list of choices and the Boolean evaluation drops to a static value. (Even better, most implementations of bit-wise integer comparison are executed as close to machine code as possible.)

But, inevitably, there are cases which solutions such as these are not so prevalent or obvious. For instance, when implementing join-context SQL conditionals as PHP, it can take a tremendous amount of derived and out of band knowledge to perform the translation. Combine this with already complex logic, (nested XORs, negated string comparisons, and cross-table lookups), and the code can get slow and ugly very fast. So what do you do as an engineer with an email, the SQL, and a pat on the back? Get a game plan.

It’s more important to pencil in a strategy for defining your criteria than going off of pre-existing assumptions. For one measure, repeated calculations in the original may be consolidated as a single conditional whose value is stored and later addressed; the processing efficiency alone is worth the change when scaling up to enterprise-level datasets. Additionally, as I stated above, changing data types of pre-existing conditionals can be a great boon as well, and performing integer arithmetic is always faster than strcmp.

Once the parameters are defined, we zoom out to observe the algorithm. Keeping in mind the practice degrades maintainability, nesting some repeated conditionals can save processing power down the line. But don’t get nesting-happy; (especially with code you’re simply translating and didn’t have the mental inception for) you’ll forget why two conditionals had been nested or why their order mattered so much. This is where your formal logic class enters the picture. Class, what is {A, B, C, D} & {A, B, C}? Of course it’s {A, B, C}; it’s also ¬{D}. The optimization, however slight, of changing

if($var == A OR $var == B OR $var == C) { something_true(); }

to

if($var != D) { something_true(); }

may not increase performance by leaps and bounds, but if you’re deep in the code anyway why wouldn’t you shave off the time?

Now, after the code is written and tested, there is much rejoicing. The only thing we now have to contend with is if the translation needs to change. And while we may not, (and hopefully will not), go back to square-one with our evaluation, we should at least take the time to consider where we may have gone wrong in our previous implementations and where we can continue to go right.