You don’t develop code. Code develops you.
During a recent lecture via Zoom in the Flatiron School software program, I attempted to crack-wise on the chat as my fellow students and I often do. I can’t exactly remember what prompted me, but I wrote:
“You don’t develop code. Code develops you.”
Although I was trying to make a joke, this stuck with me. I believe it’s true, if you’re serious about learning how to code (well).
What do I mean by “code develops you”? A few things come to mind, but the overarching truth about code development for me is:
“A computer is literally as dumb as a rock. It literally needs to be told how to do EACH. AND. EVERY. LITTLE. THING.”
Because computers are dumb, it’s often necessary for you to break down a problem and its solution into smaller, simpler pieces to ensure your code will do what you want need. You also quickly learn how tedious, frustrating, aggravating, exasperating and humbling this process can be. Turns out, instructing a rock how to manipulate the DOM and persist changes in the back end can easily drive a person insane. I know. Trust.
In order to avoid going insane, I’ve had to develop myself in several key areas, many of which overlap and relate to each other:
Discipline (aka “Code like everyone one is watching?”)
Unless you’re disciplined in structuring your application and writing your code, before you know it you’ll have thousands of lines in a jumble of files with comments few and far between. If you’re lucky enough to somehow get it working, fixing the inevitable bug will likely have you cursing yourself in the wee hours too many times. Let’s hope you’ll never need to add to or modify its functionality, or need to explain how it works to the poor soul tasked with maintaining it.
Thoroughness (aka “Meet my nemesis: The Infamous Corner Case”)
Just when you think the code demo is going flawlessly, in walks nobody’s friend, Corner Case (it’s telling that it’s also know as pathological case). Either due to your laziness, a bad assumption or an incomplete grasp of reality, one of these nasty buggers WILL decide to make its presence known, as it often does, AT THE WORST POSSIBLE TIME.
Clarity (aka The What, The How and sometimes, The Why)
You need to be clear about the problem being solved and how to solve it (and sometimes, why to solve it), hopefully before you type your first line of code. If not, the risk is great that you’ll soon find yourself wondering: “What the f*ck is this function supposed to be doing? How the f*ck is it supposed to work? Why the f*ck am I up at 3AM?”
Efficiency (aka “Nobody’s got time for that”)
One of the main selling points of these dumb rocks is that they can do stuff quickly, the same way every time, for a bazillion times in a row. Therefore, if we can save one step each loop, we will have saved ourselves and the dumb rock a bazillion steps. “A bazillion here, a bazillion there, and pretty soon you’re talking about real gigaflops.”
Perspective (aka “There’s got to be a better way”)
Unlike loading a dishwasher, there are often several “right” ways to perform a task. Developing the ability and discipline to examine a problem from several angles will often lead to a better solution. The key is to explore your options before you charge ahead down a dead end path. (Yeah, I know, I usually do charge ahead, get stuck, curse, try to untangle the mess, cry, eat ice cream, delete everything, repeat…)
Pattern-recognition (aka “Have we met before?”)
People have been telling dumb rocks how to do things for millenia, so it’s rare that a solution to your problem hasn’t already been told to a million dumb rocks long ago. The only things that have changed is that our dumb rocks are typically smaller, faster, cheaper and are powered by electrons rather than steam or some animal. So the ability to recognize a problem and a tried-and-true solution is valuable in that you’re not reinventing an inferior, bug-filled wheel, and therefore can spend more time sleeping, eating right and taking the occasional shower.
Analogies and Metaphors
Related to perspective and pattern-recognition, analogies and metaphors help me to visualize a problem and possible solutions using familiar everyday objects and situations. A recent favorite analogy is how a callback function is like a self-addressed, stamped envelope. The recipient of the envelope can be as dumb as a rock and the sender of the envelope will likely have returned what it needs (assuming the USPS is still functioning).
K.I.S.S. (Keep It Simple, Stupid)
Computers are dumb as rocks. The more complex your code, the more likely it will be that errors will creep in as you try to explain a complex operation to a dumb rock. Did I mention that computers are literally as dumb as rocks?
The Perfect vs. The Functional (aka “If it ain’t broke…”)
I don’t know about you, but sometimes when I notice a small thing that’s just not right, I’d like to ignore it… BUT IT’S NOT PERFECT. Most times, making it “perfect” doesn’t come back to bite me in the ass, but when it does, it’s typically AT THE WORST POSSIBLE TIME.
Reduce, Reuse, Recycle (aka “Laziness is a virtue”)
Related to pattern-recognition, it’s best not to attempt to create a “better” mousetrap. The mousetrap has been around so long that the design has been optimized, debugged and improved by legions of better and more experienced mousetrap developers and “tested” on untold numbers and species of mice. It’s unlikely that you’ll be able to create a better one. My ego has tempted me to “roll my own” many times, but I don’t believe I’ve ever recreated a better version of anything. Best to spend your time on the bits and pieces that you can’t get off the shelf, as well as showering and sleeping, eating right and exploring the world.
And, lastly: “You’re always in development, if you’re doing it right.”