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.

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.

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.

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?

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.

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.
• Exercise.

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.

Wrapping Up

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.