pcmag.comHaving immersed myself in the WordPress publishing platform and its accompanying coding languages for intensive stretches while working on websites over the years, 2009–17, specifically, for posterity, (in case any of my fervid readers are wondering), I gained appreciation, disdain, and affinity for the various aspects of writing computer code and what it—computer code—can do and the extreme leverage it can provide. The programming languages used for writing code are similar to written languages (e.g., English, Mandarin, Tuvaluan, Crustacean) in that they serve as means of communication possessing inherent flexibility and thus can be deployed discretionally. Conversation between human and computer can proceed circuitously, linearly, verbosely, or concisely to the same end, much how an author can dispositionally lead a reader to feel, think, or behave a certain way. Here, amidst the 1s and 0s, the objective is to make the computer act a certain way.
To demonstrate the latitude a programming language can provide for achieving an end, below is CSS (cascading style sheets) code, which controls the appearance of an element on a webpage:
#sample-element {
border-top: 1px solid black;
border-right: 1px solid black;
border-bottom: 1px solid black;
border-left: 1px solid black;
}
This can be written instead, for the same effect, as:
#sample-element {
border: 1px solid black;
}
Lo! The four-liner condenses into a single property–value pairing.
Generally, when coding, the ideal is to have written less to achieve the end, whatever it may be, as demonstrated above—but for the sake of clarity for the human who might later be attempting to parse or revise the code, (which human may be and is often you), more lines, characters, and specification can be preferable. Another reason for the long-windedness: manipulation. In the first code block above, defining the top, right, bottom, and left borders separately allows more readily for the customization of each—that is to say, individually; during software development, it’s common to incessantly tweak attributes in the search of “just right.” Above, it’s totally plausible that (1) various border colors, types, and widths were fiddled with, (2) a rather unimaginative 1-pixel solid black border was deemed satisfactory for enclosing the element and (3) by the time the code was deployed to the production setting (i.e., live) the four discrete border attributes remained in the code, uncondensed into the superior one-liner.
This is ok. Yes, the shorthand definition is more elegant, but the form factor here matters little to the end-user (the person visiting the webpage where this style sheet is located). In the 90s or even 00s, the compactness of front-facing code like this was a bigger deal because (A) the internet was slow (think: download speeds under 56Kb/s) and (B) the front-facing code must be downloaded. (The attentive reader will have pieced together that the more compact the code, the faster it is downloaded.) But with download speeds averaging over 1000Kb/s globally now, in 2018, the penalty for an inflated style sheet is unnoticeable. Case in point: The main style sheet for this website at the time of writing is 10KB (kilobytes; 1KB = 8Kb) and I made no efforts to streamline its code. On a below average internet connection, this equates to a less than 0.1s download time. Comparatively, the “organ donor” photo of myself is 19KB, the thumbnail images on the homepage add up to somewhere around 200KB, the typefaces alone account for 325KB…and very quickly the 10KB style sheet is trending towards nothingness and a consequential state of nirvana. This file, the style sheet, also loads only once and is cached (stored for X period of time locally on the device) by most browsers. It is a drop in the digital ocean. So I do not enjoy writing CSS because the language tends to neither reward nor demand scrupulosity of me. Until internet connectivity is throttled to oblivion, which, who knows, may happen, and the size of a webpage becomes relevant again, I will continue to write lackadaisical, semi-bloated, -sloppy CSS.
Other languages that interact with databases (i.e., query them) I feel do reward the meticulous and attentive programmer for writing “better” code. For those unfamiliar with databases, they are essentially spreadsheets: rows and columns with cells full of data. Querying a database retrieves the data contained within these cells under specified parameters. To pull data from a database takes time. To process that data for display on a webpage also takes time. This runtime, or “wait time,” can actually be felt—verifiably perceived—by the end user in many instances, unlike the style sheet download mentioned above, because the querying process typically happens on the constrained server-side. It can only go so fast, and until it has completed, the end-user is left idling with a white screen in their face. Faster internet does nothing to mitigate the wait time. Until the webpage is generated, it cannot be loaded.
As a workaround, webpages are often served statically, which involves pre-generation, storage, and then retrieval of the pre-generated pages. This eliminates the runtime. In other cases, such as when logged into a website or app, the content will be served dynamically to tailor the display. This means the webpages will be generated on the fly and necessitate querying and data processing—wait time. The wait time hurts in two ways:
- Websites become less functional the more slowly they serve content (humans don’t like waiting)
- The slower the website, the higher the runtime (and thus web hosting costs)
Since querying and data processing are often what bottleneck the transmission of a webpage to the user, I think it’s especially important to optimize the two for any website that draws traffic or anticipates longevity. To illustrate conservatively: Suppose 0.1 seconds can be shaved off of a query and that query is executed 1,000 times per day. This equates to 100 seconds of runtime saved per day, which adds up to roughly 1 hour per month and 10 hours per year. (These are plausible figures for a low-traffic website.) I am absolutely content to emerge with a gain of this magnitude. And it’s often possible to reduce the runtime of a rogue query further than one tenth of a second. The savings can be dramatic. In the vacuum of a single runtime instance, the time-savings aren’t always noticeable, but the repeated occurrences add up. I won’t delve into the language of queries, like I did above for style sheets, but strategies for optimizing queries often involved eliminating queries (e.g., running them less often by storing results for a period of time) or tweaking comparison methods (e.g., resolving from the opposite angle). Shrewder processing of the data returned by queries increases efficiency as well.
So: I became particularly interested in page generation optimization after realizing the tangible utility of and return for deconstructing queries. A day spent remediating a slow query into a more lively one would translate into a net savings of hundreds or thousands of hours.
en.wikipedia.orgAfter burning out on my job and the internet in general last fall (see: “Drugged Out”), the physical, actual, verifiable (“Pinch me—ouch.”) environment around me materialized into view as I distanced myself from technology, and through the lens of query optimization I realized I could reduce the time and energy I spent on recurring tasks within this environment—the tangible one—much like how I felled inefficiencies within the digital realm. Actions or tasks are essentially the same as queries. What we are trying to reproduce—or, more analogously, “retrieve” (to borrow from the digital sense above)—are specific states with regularity and precision. Consumed during these real-life processes are resources too. For the sake of example: I boil water at least once per day. State retrieved: water @ 212°F. To refresh to this state from ambient water requires X time and Y energy, which variables hinge predominantly on the construction of the heating vessel (material, shape, capacity, etc.) and type of stove (gas, electric, conduction, etc.). By manipulating these factors (vessel and stove), water can be brought to a boil at varied rates—and why not attempt to raise the speed, (reduce the time), if possible, for a comparable amount of, or even less, energy? (“He’s right!”) Rather than modify my stove, I upgraded cookware. Implied with the acquisition of a new, more efficient pan is a moderate upfront cost, but if I am saving (1) time, because the water boils faster, and (2) energy, because less electricity or gas are spent, why not invest? The water only needs to come to a boil 30 seconds faster for the pan to save me 3 hours per year, and at that point, one year in, I’ve already seen a comfortable return on investment; the water does boil at least that much faster, and I value my time. To make this switch seems like a complete no-brainer to me in retrospect, and I wish I acted sooner. I would be remiss not to mention that there are other considerations inherent to any item besides how quickly it functions—read: you can’t microwave everything—but time is often the prevailing factor. Energy can be renewed; time cannot.
To express the idea of speed, or time-saving, in another format, listed below are generalized comparisons of common objects, concepts, and attributes. Each should be situationally scrutinized, selected, and discretionally employed:
- writing: click pens are faster than capped pens
- stationery: notepads are faster than journals
- laundry: hanging is faster than folding
- enclosures: the zipper is faster than the button
- footwear: slip-on is faster than tie-on
- containers: transparent and bare is faster than opaque and adorned
- objects in motion: lightweight is faster than heavy
The usual solution-seeking pattern is to deconstruct an action, identify its components, and reduce the friction precluding its end state. Forming a comparison base like this can help ramify creative channels. There is infinite possibility. In the case of boiling water, eliminating friction (or, more accurately, conserving energy) saves time. This strategy can also be used to form new, positive habits, rather than just reduce the time it takes to complete old ones. (Or, conversely, by increasing friction, bad habits can be broken.) To provide another example, which demonstrates habit forming and incorporates bullet points #1 and #2: I write down thoughts daily. (“Dear diary…”) Or I try to at least. I’ve found that if I don’t, I get stuck. Repeated thoughts will fester in my brain. I enter states of helplessness, inaction and delusion without regular extrication. It can get bad. I tend to perceive issues more clearly when they’re a foot or two away; left in my own head, I’m blind. And there’s something specifically therapeutic about transmuting these thoughts in my own handwriting, so I scribe with pen and paper rather than an electronic device. The pebble in my path is that I’m rather kind of unenthusiastic about recording these thoughts. It’s at times painful to confront reality or what I’ve initially perceived to be reality, and so I will avoid doing so. Unless I have paper sitting out in plain sight, within grasp, ready to be written on, and pen, too, I’m unlikely to write—so that’s precisely what I do: I leave an open-faced notepad with clean sheet on the top of my desk with engaged pen alongside ready to jot. Bound, covered journals require too much fuss; I can’t be bothered to flip open to my last spot. Serendipitously, the sheets of the notepad necessitate displacement once filled (i.e., tearing off), adding further distance to the thoughts. (“What’s in the past has passed.”) This may sound like psychobabble but in practice I’ve found the philosophy to be sound. Capped pens I am aware can be left uncapped; click pens have the edge in portability, which can matter, but this is largely a personal preference. To get to this point, where journal-keeping has become a sustainable habit, for me, I identified the high-friction aspects of the activity—(1) retrieval of paper and (2) engagement of pen—and attenuated them. There’s more to it than that, but this is enough to be illuminative.
In short, I am far more likely to establish a desired habit when the end state is nearer (e.g., with faster cookware, I am more likely to cook; with faster stationery, I am more likely to write) and it is easier to get started (think comparably of the activation energy required for a chemical reaction to proceed). The ability to establish and sustain new habits leads to personal growth—increased awareness and heightened potential.
To bookend with an extrapolation on the role of efficiency: As blatant hold-ups in action are addressed, previously imperceptible bottlenecks surface. These subsequent hold-ups warrant remediation, induce new ones, and so on. (Picture a metaphysical game of whack-a-mole.) As this sequencing progresses, and perceptual mastery is borne, habitual attentions begin to shift. Words like “routine” and “menial” give way to “variable” and “meaningful.” The less time and energy required for an individual to sustain an existence, the more favorable the conditions for them to flourish.
Strategies for identifying routine actions involve distancing oneself from them. Distancing inherently involves velocity (see: time) (see: space) and displacement. Traveling helps disrupt routines or forces the performance routines in new situations, which can highlight or make more obvious what is limiting about them. If traveling isn’t possible, time and space can still also be manipulated by varying the order, frequency and direction in which tasks are performed in their home environment. Writing, talking with a friend, and speaking into a voice recorder are other methods for distancing oneself from a situation and interpreting it in a new form.
The aforementioned “programming languages” are accompanied by mostly static manuals detailing the limited number functions and components the language possesses, which, when sequenced together strictly, can draw or manipulate query results; the real world is in flux, undefined, infinitely detailed, and incomprehensibly complex. But just as the database query and its corresponding functions may stifle the request for a webpage,—making it inefficient, less functional, and less likely to be used,—so do the minutiae of routine tasks preclude end states, and both are worth scrutiny.
By way of this process of translocating digital ideals to the physical plane, I’ve come to realize: Everything is kind of the same and reflects back what we see in it,—“If the doors of perception were cleansed…,”—and with each experience the apertures shrink or grow.
