“Ladies and gentlemen, come inside, have a seat. I bring good news! After a lifetime of travel and research, I’ve returned, having finally uncovered the secret to writing successful, maintainable programs.” He taps his temple. “And it's all in here.”
“Let me tell you,” eyeing each member of the audience, one by one, for two seconds too long. “It wasn’t easy to get my hands on this secret. No, certainly not. You see, they - and we all know who they are - don’t want you to know about this particular secret. At least, not for free, that is. But, worry not; I drained my bank account to cover the cost of their three-day $1,499 workshop. Now, I, too, know the secret. And I’ve brought you all here today to share it with you.”
“…For $1,599. Need to recoup my costs.”
I kid, I kid. And, yet, doesn’t it often feel that way? Like dangling a carrot above your head, the next level in your programming journey is always one expensive course or workshop away. The next “aha” moment is surely tucked in the shadows of that new, confusing programming acronym that few people actually understand. Or, if you could manage to learn this brand new paradigm, only then would your glorified CRUD app become something you could truly be proud of. Hmm, and while we’re at it, we should probably throw some TDD in there. There simply aren’t enough acronyms in the codebase at the moment.
Here’s the rub. There are pockets of value in all of these things. Clearly. Here’s a question: even if you ultimately decided that a strict adherence to, say, Domain Driven Design (DDD), isn't right for you, would you still be a better developer for having learned it? I’ll save you the energy. The answer is an emphatic YES.
But - and this is a big BUT - be careful of a common trap in our world. An endless array of "learn this next" steps await, if you so desire it. Perhaps each of us needs to decide, as programmers, if our job is to build products and solve problems, or to write code. It sounds odd, but I’ve begun to realize that these aren’t synonyms. They are two incredibly different mindsets.
When I think of the programmers I’m reasonably friendly with, they typically align with one of the following two categories:
- Product: The first category is what you might call “product people.” These are developers who enjoy building products, designing new features, wrapping it all up with a bow for the world. To these folks, programming is a tool, not the goal.
- Art: The second category is what I call “lifetime learners.” Less focused on any one product, they deeply enjoy the art of programming. You’ll often find them diving into a new niche programming language, exploring a novel approach to tracking events, researching alternative ways to query data, and more. The code takes center stage every day of the week for this group.
As a community, we need both groups. Neither is better than the other. They, I imagine, simply represent different personality types.
Still, no matter the category, both groups are left with the endless reminder that they're...missing something.
It's like an alarm clock that's forever set to snooze. Every nine minutes, you hear it. Only, it's not a beep. It's a repeating sentence. "You're missing something. You're missing something. You're missing something."
It’s a Woozy
The pursuit of elusive secrets and deeper understanding isn't exclusive to programming, of course. It applies to food diets, music, psychology, practically any industry. And it makes perfect sense; if I'm unhappy with my current results, then there must be a higher - more secret - technique that I haven't yet discovered. One more book should solve this problem, right? Hey, maybe if I pay enough visits to Barnes and Noble, I'll find the secret.
But what if the secret is bullshit?
"It's a Fugazi. It’s a hazy. It’s a woozy. It’s fairy dust. It doesn’t exist. It’s never landed. It’s no matter. It’s not on the elemental chart. It’s not f**king real. - Wolf of Wall Street
What if each of us was granted the keys to the castle during the first year? Or, better yet, what if the castle was never locked to begin with? Those basic fundamentals that were so prominent and cliché that you glazed over them… what if they were the real deal?
Time and time again, spanning all of my interests, I find that I repeatedly return to the fundamentals. It blows my mind. It’s like a slow-moving realization that the generic, throw-away advice your teacher gave you was actually deep, ancient wisdom for how to live a proper life. And you brushed it off, like dust.
Somehow, I convinced myself that “fundamentals” was a fancy term for “beginner basics.” Not true. Sure, the word “basic” might exist in its definition, but I think of fundamentals as the underlying structure from which everything grows. You want that base to be rock solid. Most of us offer a passing glance, and then skip to intermediate.
Only When You're Ready
It’s just as well; it seems to be the case that what you’re mentally able to grasp from the fundamentals is largely dependent upon your current skill set. Here’s an example. Two developers, a beginner and a 10-year professional, walk into the room. If they awkwardly sit next to one another, while reading any “Object-Oriented Programming Fundamentals” book, they will both learn something. But what they learn will differ drastically.
The fundamentals are like a giant tower in the sky, where all floors but the first are locked down. As you mature as a developer, each level consecutively unlocks, revealing new insights and "aha" moments. It's the same wording, but somehow you now understand it on a deeper level.
I often explain this general concept to my seven-year-old daughter, as we watch one of her favorite shows. I’ll tell her, “stories can exist on multiple levels.”
“What do you mean?” she obviously replies - probably with a subtle eye roll that she doesn’t realize is forming. And fair enough; I’m not offended. Let me do dad duty for a bit.
“Well, when an adult watches this show, they’re noticing particular remarks and facial expressions that fly right by you - or any child.”
“I don’t get it.” she responds.
“Of course! And that’s the entire point. Bluey is an incredible show because you and I can appreciate it on completely different levels. When you nostalgically come back to this show years from now, as a mom, you will know exactly what I mean.”
To further emphasize this general point, OOP is something that I personally continue to study and research. Over fifteen years ago, I read my first introductory book. When I reached the last page, I ignorantly exclaimed to my silent bedroom that I knew and understood object-oriented programming.
…No, I didn’t. I understood how to create classes and perform basic dependency injection. I possibly had a basic recognition of objects sending messages to one another, but nothing more. I had a long way to go. I bet if I read that book again today, I'd still learn something new.
Back to the Fundamentals
My assertion is that, if you wish to - as I do - improve, your time is likely best spent not on that hot new tool or paradigm, but instead returning to what you already know. Pay it a visit, and see if you can dig up any new realizations.
Let's stick with the OOP example a bit longer. That would mean continuing your study of messaging and naming. Re-read those chapters. Are you sure that you ever truly nailed that piece of the puzzle? I didn’t the first time around (or the second). In fact, I'm still working on it.
Focus on the little things (which aren't so little).
- Is this line clear?
- Could that method name be more precise?
- What are the nouns?
- Should this be its own class?
- Why does this section feel awkward?
- Why am I embarrassed to show a co-worker this one file?
- How would this function in a perfect world?
Give it a shot the next time you find yourself staring at your code editor with a bit of disgust on your face. Focus on one line at a time. “Is this clear?” If not, how might you make it clear? And then look at the class API you designed for a feature. Why did you pick that particular method name? Is there a better one? If you were starting from scratch, would you still use the same name? Or, in other words, in a perfect world, how would you interact with this API? Can you see it? How do we nudge the code in that direction?
A programming veteran - whose identity I embarrassingly can't pinpoint at the moment - once remarked that he didn’t draw a distinction between small and large refactors. In his mind, they were one and the same. The small decisions are the big ones. The big refactors are nothing more than collections of little ones.
And trust me, I attempt and fail at these questions daily. That’s why I keep returning to them. That's the whole point. The fundamentals are the fundamentals because they are hard to master. They are the foundation for every decision you make.
The greatest musicians didn’t become great because they learned a secret mode or exercise that the rest of us aren’t privy to. They’re great because they practiced the fundamentals so consistently to the point that the entire fretboard or keyboard is now muscle memory.
Put it to the Test
Let's put this fundamentals-first thinking to the test.
Consider your diet. Each of us wrestles with it in some form or another, yes? And we've all seen them: hundreds upon hundreds of "How to lose weight effectively" books. Okay, if we acknowledge and set aside the reality that "there are many different body types and dietary needs," would it generally be fair to say that the best method for losing weight consists of a few simple - but hard to follow - steps?
- Eat real foods.
- Not too much.
Others can correct me, but I imagine this represents the fundamentals for weight loss. It's so simple to the point of being a joke. And yet, I'd wager that it's mostly true. There's just one problem. It's hard to follow. And worse, you can't sell a $29 weight loss book with only three bullet points. And, so, we all default to the usual routine: ignore the fundamentals and search for the real secret.
Mark Manson once casually remarked on a podcast, "the concepts and frameworks that sell well are often counter-productive." I pulled over and wrote that line down the first time I heard it. He was of course referencing something unrelated to programming, and yet I was struck by how beautifully it applied to my world. The concepts and frameworks that sell well are often counter-productive.