I've visited many websites belonging to coders who have been coding for decades, who have individual and corporate clients across the world, and who think their opinions are beyond reproach.

I'm not like that. I've done programming in a corporate setting. For the last twenty or so years, I've written applications for my company (I own it) and my family. I programmed in PHP for years without being sure I was doing it right. Sure, the programs worked and I studied the examples in the books I bought. But that's not the same as comparing your code to code written by other programmers. Turns out I had nothing to worry about. My code, regardless of the language, was just fine.

But I hadn't studied computer science at some expensive university. I was self-taught all the way. Once in a while, some bit of programming theory would ping my radar, and I'd go look it up. Most of it was so utterly theoretical, that I still can't work out why anyone would theorize in that direction. A lot of it was heavy on mathematics, so much so that it was beyond my patience to decipher. I did well in math in school, except for calculus. But I'm not an engineer either, so I don't regularly use advanced mathematics in my job. And for the most part, I fail to see the need to abstract concrete events into the mathematical realm.

And almost entirely, those theoretical underpinnings of some aspect of programming don't and wouldn't affect how I code. They're probably way kewl if you're a university professor, but otherwise I just don't see the point.

I sort of keep a finger on the pulse of the industry, and I hear about and glance at new trends. But almost all of them seem designed to solve problems you wouldn't have it you'd just hire people who know how to program right in the first place. And the rest seem designed to impress academics and perennial fad-followers, but not really assist in making better or faster code.

Back in the 60s and early 70s, a lot of universities didn't have degree programs in computer science. You had to do electrical engineering or somesuch if you wanted a crack at computers. As a result, there was a lot less theorizing. As soon as universities instituted computer science programs, there were a lot more computer scientists, and therefore a lot more theorizing. (That's their job, you know. They get paid to make up stuff that impresses others of their ilk.)

So when I write something about programming, I don't write it from the vantage of an isolated tower somewhere. I write based on my experience with actual coding. Now, a lot of authors do the same thing, but their programming experience is broader or deeper than mine. But I still find most of what they write tinged with that "look at how smart I am" brush.

Maybe worse, if I write something about programming today, I may change my mind in six months. It happens. My first code in PHP was all in one file. Worked great. Then I found out about MVC, and it seemed like a good approach for the most part. So my next code followed that pattern. I took it for a spin and decided what I did and didn't like about it, and modified my approach to it over time. Each project was a refinement. Now most of my projects have a fairly templatized aspect, with each new project being slightly better executed than the last one.

What I write about programming is therefore based on my experience in programming, and I have no problem tipping over sacred cows along the way. I don't care about the theory. I just want something that does the job I ask it to.

And when I ask someone to reason through an idea with me to make a point, I use regular old logic. Not theoretical doodads from some academic papers.

So the question of how good my advice is is up to you to answer. In your context, my advice may suck. I don't mind being wrong. I don't know everything, and I don't know you and your projects.