A Programming Hook
Object-Oriented Programming's strength is Modularity; and just about everything coded today follows the OOP design. Except Python and JavaScript--sometimes.
So I've coined a term "Hook"; not to be confused with a fishing-line-hook, or the literary tool where you write the most interesting part of your whole story into the first sentence.
A [Hook] in this regard is a [Space for Something]{to go} like a nook or a closet. You don't know *what* might go into that nook or closet; you just know there are *things* with which are properly displayed or stored in a Nook or in a Closet.
And this is the same concept.
There's a *whole* lot of features that we'd might *wish* to add to a coding project, yet time and funding constraints, oftentimes, makes it hard to include every feature one might want.
In this vein; we add space for the features we might want to add *after* we finish all the important bits.
This is very important in [Software Engineering], because there will be a time in a project where you make it to an important feature that you cannot implement *without* having had re-written the *whole* thing.
And so, you want options available when that inevitably comes to pass.
Now. I developed this whole making [Training Simulations] in the [Air Force] and when I tell you; one day somebody asked me to do something that may have added several weeks to the development time.
They asked "How long will this take to [fix]?" To which I responded; "I'm not sure. I think I remember adding some hooks that would make this easy, and it could be done tonight. But as it wasn't a requirement *at the time* this may take 2-4 weeks to implement if I have to rework it from scratch."
To which, they were very upset with my best time "4 hours, or the end of shift, whichever comes first" or "several weeks, because that would put us behind schedule."
"I'll get back to you at the end of day Chief!"
Non-developers, Maintenance Professionals like myself *actually* who're used to every little thing being documented and not *created on the fly* were rather upset with those timelines.
And I had already been reprimanded several times based on my timeline predictions.
Which uh. Were accurate. They just weren't particularly accurate *for me* whom'st {is/was} a very well educated developer... In a sea of maintainers who have not studied the code as I have done.
My timelines were usually off at this stage *because* I was getting my understanding of how the coders (who were also rather green) and the (maintainers become coders) would be able to understand the timelines.
I have to make clear; I was, in-fact, doing *my* job to the best of my ability, and even better than *your{my supervisor's}* ability despite them being very concerned about my time estimates being [too long].
Communication isn't bad on my side... Even when I appear to be bad at communicating.
One of these days I will not be so defensive! Yet the Anti-Trans sentiment remains, so will the SALT!
Anyway; these particular [Hooks] were contextual triggers. Things that would/should be called at certain times during certain steps in the simulation.
Custom CallBack functions mostly.
And these particular callbacks were rather complex for a simple one-function call event.
Luckily for my OCD brain; I had stopped to asked the question about this exact feature they wanted to add *now* that they had been worried about adding earlier, until the customer made it a [Need to have].
I had asked the question, at that time; "What happens if *this* particular feature *becomes* a Necessary addition."
Because my [awesome predictive abilities] were spot on about what they need that particular simulation to accomplish.
Luckily I had been stumbling through various frameworks and implementations of the Squadrons Honorable Historical Developments. (Part of the job was updating and modernizing old Adobe Flash 2.0 projects) And had stumbled across a few implementations of these features *both* before it was necessary *and* after it seems to have taken a week to tack on at the end.
And that's when I started adding the concept of "Hooks" to my personal development checklist. Everytime you ask yourself; "How might this feature be used outside this implementation" or "What happens if I need to add something *somewhere* that might break Modularity" is an opportunity to add in hooks.
"Can I go back, and reuse this feature to make my job easier in the future?"
Or you know; Object-Oriented Design (And Modularity) in a nutshell.
