Why Coding is Like Spelunking, And How Knowing That Can Help You
This article uses the analogy “Coding is like caving” to explain what coding is, what it isn’t, who it’s for, and how to succeed at it.
My mind works in analogies, and this is one that’s been growing on me for the past few months, up to the point where I needed to write it out.
Okay, here we go: Coding is like caving.
This article builds on that analogy to explain what coding is, what it isn’t, who it’s for, and how to succeed at it.
Of course, I can’t speak for the entire population of people who program computers, but I do feel solidly about the points below in the WordPress world. Here’s how this article can benefit you based on your role in WordPress:
- WordPress developers: Give you a nice thing to talk about at your next meetup. Reassure you that you’re in the right line of work.
- WordPress assemblers/implementers and aspiring WordPress developers: Help you understand if leaning more deeply into coding is a good fit for you, and what to expect as you lean in.
- WordPress users, clients, and others: Know what to look for in a coder or developer.
By the way, caving is also called “spelunking.” As great a word as that is, I think I’d get tired of writing it, so let’s use “caving” from now on.
What Coding is Not Like: Surfing
When you see coding in TV and movies, it usually looks pretty cool. Coders are almost always “hackers” (not the people who wrote the software being “hacked” in the first place), and they spend their time zooming around weird UIs, finding backdoors and exploits, shutting off laser defense systems, and so on.
(Do you like unintentional self-parody more than actual parody? Here’s a clip from a real movie.)
We all know the movies aren’t real, but I found that a related misunderstanding of what a coder actually does really did distort my perceptions of coding for a fairly long time.
What I Thought Coders Do
I thought coders worked by:
- Thinking in short bursts of brilliance and inspiration.
- Knowing the secret shortcut. My genius backdoor hacks will do in ten lines what other coders do in ten thousand.
- Unlocking hidden possibilities with overwhelming knowledge and talent. Step aside and let a real expert get to business—we’ll use Haskell to backtrace the mainframe.
I’ll call this the “Surfer Model of Coding”: coding is all about style, speed, grace, talent, spontaneity and improvisation.
What Would Make a Good Coder (if the Surfer Model Was Real)
Want to be a good coder? In the Surfer Model, come equipped with lots of:
- Obscure tools and tricks. You should know the secret backdoor to any problem.
- Leaps of sudden inspiration. The whole code was doing this but wait there’s a much cooler way.
- Raw talent. You’re simply the smartest guy in any given room, and that’s what makes you the hottest coder around.
As it turns out, Surfer-Style Coding doesn’t actually exist, at least not as far as I know. It certainly doesn’t exist in WordPress development.
Perhaps because using technology is flashy, easy, and cool, it’s easy to assume that writing technology is flashy, easy, and cool. Nope.
How did the compelling fiction of Surfer-Style Coding come to exist? My theory is that perhaps because using technology is flashy, easy, and cool, it’s easy to assume that writing technology is flashy, easy, and cool. Nope.
Here’s what coding is actually like.
What Coding is Like: Caving
This is what coders are actually like:
And, because you can find anything on the internet:
The name I’ll give to all coding I’ve actually seen in the real world—even amazingly cool stuff by amazingly talented people—is Caver-Style Coding.
What Coders Actually Do
Getting started on a coding project is very much like preparing to enter a cave. Here’s what Caver-Style (or, if you prefer, “real”) coders do in their actual work.
- Read the map. Understand, in as much detail as possible, the entire landscape of details that make up the project, and how different pieces connect to one another.
- Make a plan. Weigh difficult decisions between multiple possible routes to a goal, then develop an overall roadmap that will guide the entire project.
- Set up multiple safety systems (version control, automated testing…) that will catch them if something unexpected happens.
- Get, and stay, organized. Nothing random, everything consistent and for a reason.
- Take one step at a time, verifying at each step that their safety systems are giving back the expected response.
- Leave a clear trail, so that they always know where they’ve been, where they’re going, and why.
- When something unexpected happens (wait, this path should slope down, not up…), understand in depth why it happened. Then address the root cause, not just the immediate problem.
- If a route turns out to be blocked, backtrack as far as necessary and plan another way forward.
These are the behaviors—steady, consistent, methodical, planned—that writing good code in the real world actually involves. And the people who write that good code have lots in common:
What Makes a Good Coder in the Real World
These are the traits of good real-world coders. Not to get personal, but David epitomizes these traits and is one of the strongest coders I’ve ever met.
- Clear and systematic thinking. Random flashes of inspiration are basically irrelevant. What actually matters is developing a clear understanding of every piece of a complex system: what it does, how it works, and how it talks to the other pieces.
- Consistency. The ability to set conventions and then follow them exactly the same way every time: coding, syntax, commenting, workflow, and more.
- Diligence. Taking delight in moving in a measured, consistent way—walking and sometimes even crawling, not skipping, jumping, flying, or surfing—toward an established goal.
So, this is coding. Much of becoming a better coder boils down to two main components:
- Developing better personal systems: better ways of conceptualizing and moving through problems that allow you to be clear, consistent, and methodical in your work.
It’s not very glamorous, in some sense.
Put differently, if you think this is glamorous, you might make a good coder.
So you’ve inched forward on your stomach for an hour and a half. What’s the reward?
Because of your clear planning, consistency, and diligence, you’ve made it to a place that is simply inaccessible to other people—people who don’t make a plan and carry it out, step by step and inch by inch.
The rewards are exactly what you planned on at the beginning of the project, but on the other hand they might be surprisingly awesome once you’re actually there.
Of course, now it’s time to inch your way back out (the code works in staging, now the client wants it deployed onto the Windows server in his basement). Fortunately, you have a plan for that.
Like caving, the not-fun side of coding is dominated by one very specific experience: getting stuck.
Like caving, the not-fun side of coding is dominated by one very specific experience: getting stuck.
There’s ample video on YouTube of people getting stuck in caves. I watch them from time to time, and I read the comments (which are basically “NOPE” and “Why?”) to make sure I’m still sane, and that it’s the people in the caves who are crazy.
The thing is, being stuck on a coding project is pretty much like this: you’re in the middle of a long journey and you’ve got places to be, but you’ve somehow ended up in a situation where you can’t go forward and you can’t go back.
The people in the video above at least have companions, a light, and a rope: see below for what those elements are for a coder. Having none of those things is often what being stuck alone, with no plan, on a challenging coding project is like (though hopefully without the immediate fear for your life).
How Not to Get Stuck
The best ways not to get stuck are exactly the practices outlined in “What Coders Actually Do,” above. They’re things like:
- Have a plan going in. As much as possible, you should always know your route through the problem and where you are in it.
- Use safety systems, like automated testing and version control. You should always know what led you to this point, and be able to get back to where you were. Real stuck begins when your disorganization means that those things aren’t the case.
- Get and maintain clarity on every step within the system, one by one—for example, through consistent coding practices and thoughtful commenting on your own code.
Still, the reality is that there are surprises on any coding project.
How to Deal With Getting Stuck When It Happens
Just like being stuck in pitch blackness 150 feet underground, being stuck in the middle of a coding project is best addressed with a very specific set of responses—most of which, to be most useful, you should have had in place from the beginning.
Bring a Friend
This is the biggest one. Don’t get stuck alone. If you work at an agency or otherwise have access to other developers, this could mean fining opportunities for pair programming, for example.
If you’re stuck and you didn’t bring a friend, you can yell for help (on Upwork, at your meetup group…). Just make sure to introduce the cave itself in as much detail as you can, so your friend’s advice can be helpful.
Retrace Your Steps
If the cave is looking weird now, are you sure that you didn’t take a wrong turn a bit back? Retrace your steps to a place you have confidence in, and move super-slowly through every, single, step from there, testing as you go.
Break Out the Map
Questions like, “How do I make this path go up instead of down?” are just about always the wrong ones, but they’re surprisingly common among stuck coders and the clients who hire them.
You don’t need a quick fix: you need to better understand the overall situation. In coding, that means getting a better grasp on the existing software—and even hardware—environments, coding languages and paradigms, and any other systems that could be affecting the behavior of the code you’re looking at. Get used to reading lots of documentation and Googling heavily.
Can’t read the map? (In other words: feeling absolutely buried in information that you don’t know what to do with?) That’s where friends come in, free or paid.
Don’t Do Random Stuff
You know what’s not going to get you where you need to be? Random stuff. “This side path goes up, and the cave entrance is also up!” is exactly the kind of thinking you should not be doing. That’s the real meaning of “hack,” and it’s a bad thing.
Good coders are diligent, systematic craftspeople, who do things the right way because it’s the right way.
Good coders are, ultimately, diligent, systematic craftspeople, who do things the right way because it’s the right way.
They can inch through miles of darkness, never panicking or getting lost, because they’ve taken the steps required to understand exactly where they are and where they’re going.
They also don’t start improvising out of impatience when consistency is what’s required—and, deep in a cave, it always is.
Does genius play a part in coding? What I described above is the genius.
Does genius play a part in coding? What I described above is the genius: being able to make a deep and intimate relationship with various kinds of complex systems, such that one doesn’t get lost or tangled up in them, and such that the next step forward is naturally clear.
But if we’re talking about, like, guessing someone’s password by mentally multiplying ten-digit numbers, then no, genius doesn’t play a part in coding. Certainly not in WordPress development. It sounds like you’re looking for a Surfer-Style Coder, and those exist only on the internet itself—not among the people who built it.
If all this sounds like a good fit for you, there’s a good chance you’ll love coding. You might love caving, as well, although you wouldn’t catch me dead in one of those things. Thanks for reading!