Reddit reviews PHP Objects, Patterns, and Practice

In this order:

1. PHP for the World Wide Web
   
2. PHP 6 and MySQL 5
   
3. PHP Objects, Patterns, and Practice and/or PHP Object-Oriented Solutions
   
4. High Performance MySQL: Optimization, Backups, Replication, and More
   
5. Introduction to PHP PDO
   
6. Model-View-Controller MVC

I've noticed this is a fairly major problem with people like us:

• We're self-taught
  
• Have worked alone almost 100% of the time
  
• Have not had any formal training whatsoever
  
  This hasn't stopped me from slowly, but surely, climbing the totem pole job/salary wise, but there's always that nagging feeling in the back of my head of
  
  
• Am I doing this right? These ~200 lines of code ... is there a native function I'm not aware of that handles it in a single line of code that makes mine look stupid and amateurish in comparison?
  
• This tutorial I'm reading ... is it written by someone who knows their stuff? Are they using best practices? (1)
  
• What's my next logical step? I'm comfortable with what I know, but I need to up my game! What do I do now?!
  
  We're like the 21st century's hermits... and it's not really our fault. Most of my job interviews can be divided into three different types of companies:
  
  
• Remote, long-term freelance/contract work,
  
• In-house, replacing a company's contractor or replacing a programmer that is leaving/fired/whatever,
  
• In-house, to join a huge company's team of programmers where I'll be simply another faceless employee delegated to a chilly back office away from most human interaction except for my fellow programmers
  
  I've done a ton of #1 work, but it feels fleeting and doesn't give me a sense of security. #3 seems to be the best way of gaining access to more programmers where theoretically I learn from them and this would solve the 'hermit' issue I feel I have, but having worked for large companies before that really doesn't appeal to me. So, I'm most comfortable with #2, even though I'm always the only programmer there and all the work that I do goes right over the heads of the people I share the office with (secretaries, designers, managers, owners, etc).
  
  So, what have I done so far? Well, 6 months ago I tightened my belt and decided to move away from my procedural-style comfort zone and finally wrap my head around OOP. I bought Object-Oriented Solutions and went through it. I felt I learned a ton of useful information that I previously couldn't understand. I've also purchased PHP Objects, Patterns and Practice but I've yet to start on it. Why? Because it wouldn't look good for me to sit in my office at work and go through a book to teach myself, so the only option I have is doing it all at home where my wife complains I'm no longer spending enough time with her. It's the problem with learning by book, instead of learning by example which I would have if I was surrounded by programmers, but it's the price I have to pay I guess!
  
  Anyways, learn OOP. If you know OOP, learn about namespaces. If you know about namespaces, dive into MVC theory. If you're comfortable with MVC, learn yourself frameworks. If you know one framework, learn more. Companies are paying big money to programmers who can say, "I know Zend Framework/CakePHP (ugh)/CodeIgniter/Symfony inside-out". I mean big money (as in, upper 5 figures, lower 6 figures).
  
  Once you know a good selection of frameworks and are comfortable with them, start (or you can probably do this concurrently) donating time developing to an OSS project of your choice. It makes your resume sing!
  
  Trust me, you have a lot to learn if you've only 3 years under your belt (unless you've skipped bathing and working and socializing for those 1095 days, then you may actually be a guru already).
  
  Sorry about going off on a semi-related tangent!
  
  (1) - For my most recent example of this, I'm "learning" the whole MVC thing, with frameworks. I've jumped around with, I'd say, at least 10 different PHP frameworks. I settle in to try to learn it, and pick up a few pointers, but then I find I'm not comfortable in that particular framework (CakePHP, too many arrays), or there's simply not enough documentation to walk a newbie through the whole process (Zend Framework, newest version, and ESPECIALLY Kohana), or the writing style is still a little over my head (namespaces! namespaces everywhere!). Anyways, one thing I noticed on reading tutorials is that many framework tutorials say we should build big great monolithic controllers, and the "model" should only be used to do simple CRUD work. But then Zend Framework books/tutorials tell me the model should be nice and fat, and the controller should be very small, which makes a ton of sense to me since the model will be reused over and over by different controllers, so why on earth would I stick a bunch of logic in my controllers? Controllers should be like the office manager - doesn't really do much of the heavy lifting, but directs everyone towards a common goal.

PHP Objects, Patterns and Practices is a great book on advanced topics.

Also, for non-book learning, dive into some frameworks and see how they are built. I'm not saying steal their code, but look at how they document code, naming conventions, use inheritance, abstract classes, interfaces, and design patterns.

If you think you can make it through what is probably a boring book, there are a lot of books that would take you from where you are to objects and design patterns. I bought this one:

http://www.amazon.com/Objects-Patterns-Practice-Matt-Zandstra/dp/1590599098/ref=sr_1_4?s=books&ie=UTF8&qid=1310948102&sr=1-4

> One single database object is not bad design.

It is bad design. Read this guide: http://misko.hevery.com/code-reviewers-guide/

This book will help you to understand, where is your mistakes:
http://www.amazon.com/Objects-Patterns-Practice-Matt-Zandstra/dp/1590599098