At some point in one's career, a typical developer would encounter the procedural vs. object-oriented programming (OOP) debates. For instance, this page explains why it is preferable to do procedural programming over OOP, while this page tells of the so-called benefits of object-oriented programming over procedural. So, which one do you believe? Or which one do you prefer?
It is not a surprise that there are developers who claim to know OOP yet code in a procedural manner. I came from a company wherein the top tech man espoused the practice of having few classes each containing lots of methods...and static methods at that! Just because the code is in C# doesn't mean it's object-oriented. Most of today's development platforms (Java, .NET, PHP, Ruby, etc...) are OO-capable, yet how come it seems not many really know how to think and design the object-oriented way?
I put the "fault" here on programming languages like C++ which treat class methods as if they're just glorified functions (or procedures, in VB- or Pascal-speak). In my opinion, by making class methods appear just like regular procedural functions and putting forth the oft-repeated mantra that objects = code + data, they made it easy for programmers used to procedural programming to slide into an object-oriented language without really understanding the OO paradigm. I also partially put the blame on learning institutions that teach an OO-capable language (like Java) as the introductory programming language for their students.
I'll take myself as an example. I've "known" OOP for about fifteen years already, my curiosity piqued after reading full-page ads about them (oh, how magnificent Borland was back then!) and the "objects = code + data" thing. Yet it was only in the recent years of my software development career that I could claim that I truly knew what it was to be object-oriented. Why is this so? Because I thought that all it takes to be object-oriented was to have code and data in the same place. I thought back then that classes were just glorified structs (having learned C first, then C++). I thought of OOP in procedural terms, and it showed in my code and designs for many, many years.
What I believe new programmers should learn is that OOP is all about objects sending messages to each other. Yes, sending messages, not accessing properties and fields and calling methods. If I only think of it as accessing member fields/properties and calling methods which look just like ordinary procedures/functions, I fall into a trap and tend to think in a procedural manner -- the only difference being my data structures located inside the object/class itself instead of having a separate struct. This article about the design principles behind Smalltalk is a must read. It helped open my perspective about what objects should really do and how they should collaborate. Only then did design patterns begin to really make sense to me. Programming principles such as "Tell, Don't Ask" are a must-learn for those interested in OOP. And hopefully as an industry we can stop churning out POOP but truly OOP designs.