It was just one short year ago that I began a new job working as a "programmer;" prior to that, I'd styled myself a "Web developer" or something similar, but the new job meant that I'd be doing something much different than before. During the interview, terms like "object-oriented programming" and "SQL" were tossed about, and I truthfully acknowledged that I understood and used such things in my working life, although not terribly frequently. (My previous job was a Filemaker and procedural programming shop.)
When I arrived and began programming Web applications, I took a look at CakePHP, and suggested we use it. Soon, it was implemented for basically all new development projects. I quickly realized, though, that I had a huge knowledge gap. Sure, I know what object-oriented programming is, and even done a bit of stuff previously, but when my boss suggested we might use things like an observer pattern on some legacy code, or when he talked of extending CakePHP's controllers in various ways, I knew I'd need to expand my skills.
And even with the database side of things, where I felt a bit more comfortable, I found that my knowledge of SQL was a bit rusty in spots—such that I couldn't decide if what CakePHP was doing (say, with joins) was correct or whether I'd need to do things differently.
Frameworks like CakePHP, Zend Framework, and Symfony allow you to quickly and easily write a "real" application, but in doing so they tend to shield you from things like raw SQL and obviate the need to manually load or extend classes, for example. I contend that this is a good thing, but only if you understand the "guts" of the system—that is, OO and SQL, for example.
Why? Consider what happens if your framework loads data into a variable in a completely unexpected way. If you don't understand the SQL that's going on under the hood, what chance do you have of determining whether the framework is wrong—or perhaps you're not calling the data in the right way?
In a similar vein, knowing how to program in an object-oriented way is also vital. I've looked at the Lithium framework recently, and confess to not understanding a lot of what's going on. Sure, there's some documentation, but I'm certain my learning process would be helped if I understood things like singletons, or lazy loading, or even anonymous functions.
This goes beyond mere debugging or learning new technologies. As in the example I gave earlier, it's quite possible that you're going to hit a point at which you want to do something the framework doesn't do natively; in this case, your OO skills come into play, letting you get the job done. Or what if the framework can't handle the poorly designed legacy database you inherited? Suddenly your SQL-fu doesn't look so useless, since you'll be able to write occasional custom queries when the framework falls flat.
But even beyond that, there will be times during which you can't (or don't want to) use a framework. I recently took a look at CouchDB and PHPillow, and I confess that I still can't get PHPillow to work. My OO chops are simply not up to par. That experience taught me that I really need to start taking my favorite PHP book to bed with me a little more frequently.
So, even if you use a framework, take the time to get to know object-oriented programming and SQL (useful even if you're using a document-oriented database, I think). They truly form the building blocks of programming.
Image of building blocks from Flickr user Artful Magpie. Published under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 Generic license. http://www.flickr.com/photos/kmtucker/3355551036/
It was just one short year ago that I began a new job working as a "programmer;" prior to that, I'd styled myself a "Web developer" or something similar, but the new job meant that I'd be doing something much different than before. During the interview, terms like "object-oriented programming" and "SQL" were tossed about, and I truthfully acknowledged that I understood and used such things in my working life, although not terribly frequently. (My previous job was a Filemaker and procedural programming shop.)
When I arrived and began programming Web applications, I took a look at CakePHP, and suggested we use it. Soon, it was implemented for basically all new development projects. I quickly realized, though, that I had a huge knowledge gap. Sure, I know what object-oriented programming is, and even done a bit of stuff previously, but when my boss suggested we might use things like an observer pattern on some legacy code, or when he talked of extending CakePHP's controllers in various ways, I knew I'd need to expand my skills.
And even with the database side of things, where I felt a bit more comfortable, I found that my knowledge of SQL was a bit rusty in spots—such that I couldn't decide if what CakePHP was doing (say, with joins) was correct or whether I'd need to do things differently.
Frameworks like CakePHP, Zend Framework, and Symfony allow you to quickly and easily write a "real" application, but in doing so they tend to shield you from things like raw SQL and obviate the need to manually load or extend classes, for example. I contend that this is a good thing, but only if you understand the "guts" of the system—that is, OO and SQL, for example.
Why? Consider what happens if your framework loads data into a variable in a completely unexpected way. If you don't understand the SQL that's going on under the hood, what chance do you have of determining whether the framework is wrong—or perhaps you're not calling the data in the right way?
In a similar vein, knowing how to program in an object-oriented way is also vital. I've looked at the Lithium framework recently, and confess to not understanding a lot of what's going on. Sure, there's some documentation, but I'm certain my learning process would be helped if I understood things like singletons, or lazy loading, or even anonymous functions.
This goes beyond mere debugging or learning new technologies. As in the example I gave earlier, it's quite possible that you're going to hit a point at which you want to do something the framework doesn't do natively; in this case, your OO skills come into play, letting you get the job done. Or what if the framework can't handle the poorly designed legacy database you inherited? Suddenly your SQL-fu doesn't look so useless, since you'll be able to write occasional custom queries when the framework falls flat.
But even beyond that, there will be times during which you can't (or don't want to) use a framework. I recently took a look at CouchDB and PHPillow, and I confess that I still can't get PHPillow to work. My OO chops are simply not up to par. That experience taught me that I really need to start taking my favorite PHP book to bed with me a little more frequently.
So, even if you use a framework, take the time to get to know object-oriented programming and SQL (useful even if you're using a document-oriented database, I think). They truly form the building blocks of programming.
Image of building blocks from Flickr user Artful Magpie. Published under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.0 Generic license. http://www.flickr.com/photos/kmtucker/3355551036/
