Related
I have been coding php enterprise applications from many years but still i would like to take a feedback.
Usually when i get the functional specifications, i create a worksheet of how long it will take to finish the project. I don't have a team and i code start to end.
Almost in most of the big applications after reaching the midway, i figure out that the database should have been designed slightly in a different way. So i create or delete or modify few tables (sometimes more than few tables) for better optimization and data fetching.
So in my experience, i always have to do a rework somewhere in the mid way.
Below are the steps i follow for big applications.
Visualize the database. I prefer sketching them.
I have coded my own PHP MVC Framework and i use that.
Create unit tests (if required)
Do some optimization.
Code cleaning.
Deliver.
My question:
I was never taught programming. I learnt everything through mistakes and experiences and ofcourse Stackoverflow. Am i following the right pattern ? Or is there a better approach to avoid rework. I am sorry, my question might sound noobish, but i am seriously looking for some helpful advice.
This ended up waaay too long for a comment...
Take StackOverflow with a grain of salt. Yes, there are some very smart, well-written answers, however there are also many cases of 'blind leading the blind'. You generally don't ask a question on SO if you know the answer, and if someone gets a terrible solution to their problem, but it works and they don't know any better, they can mark it as accepted like anyone else. There are a lot of people on this site in the mindset "if it's accepted, then it must be correct" and that will bite them in the ass eventually.
Find someone in your field that you personally respect and ask them to look over your DB design/methodology in detail rather than posing vague questions on SO. Your process sounds just fine in the broad strokes you've outlined, but who knows what kinds of devils are hiding in the details.
If there are certain small portions of code you'd still like to be reviewed by internet strangers you can try CodeReview.StackExchange.com. CR questions on SO get closed faster than you can blink.
I think your steps are good. You may consider posting some of your working code for review to get experienced programmers' opinions on design, best practices, etc. There are also chat rooms with lots of active users who are specialists in specific languages, if you don't have an expert on hand.
My understanding is that asking for a work sample is a good way to determine if someone has the skillset you are looking for, as some people just interview well. So I want to ask potential developers to write some sample code for me.
I'm looking for ideas on what kind of small project would be something they could do in an hour or two, and would show that they have a good grasp of OOP, good coding practices, etc. And what to look for once they finish - how to evaluate it fairly and usefully.
For context, I'm a small business owner, interviewing prospective developers, for PHP development on internal projects. I can code PHP but am not an expert (some of the work is refactoring code I've written to be better structured and consistent), and so I'm also looking for what to look for when evaluating the samples, given that I'm not a trained or super experienced programmer.
Especially for people who have done hiring of this type before and used this method.
I was also thinking I could give them some code to refactor, and see how they do on it. Has anyone ever given a refactoring test as part of the hiring process?
Clarification:
I'm not talking about coding during an interview. I'm talking about coding instead of an interview. For context the inspiration for this question came from this article in FastCompany about how work samples are better predictors of job success than interviews:
Why It May Be Wiser To Hire People Without Meeting Them
http://www.fastcompany.com/magazine/136/made-to-stick-hold-the-interview.html
I would create a not necessarily good application and embed some bugs. I would come up with some simple functionality to be added to the program.
Does the applicant find some bugs?
How does the applicant's code integrate into the existing code?
Does the applicant get stuck on something that doesn't really matter?
Does the applicant adapt to the coding standard of the existing code?
After this exercise, discuss the code with the applicant. This may be more valuable than the actual code.
NOTE: with regards to #bpapa answer I would make sure that problem is novel and obviously not to be used in production.
Personally I would refuse to do this when asked. An interview is one thing, and doing programming questions on paper to asses technical knowledge is fine, but actually writing some kind of application for somebody is billable and I wouldn't do it for free. Even if it only is supposed to take an hour.
I think you should focus more on what the person has done in the past, and ask technical questions that you know the answers to (since you said you have limited PHP knowledge and want a PHP developer).
I would heed Joel's advice that giving homework assignments for interviews just weeds out the best programmers (paraphrased from his book). The better programmers have a lot of options and so won't want to go through the exercise of a programming assignment. They just won't apply. That will leave you with the mid-competency people. Unfortunately, in my experience those are the ones most likely to try to look better than they are and if you aren't an expert yourself, the ones most likely to mislead you.
Here's an alternate option. Have them point you at some work they have already done. Not necessarily the code, but the site. During the interview, ask them questions about how they coded it. What data structures did they use? How were the classes or functions organized? What problems did they have to overcome?
Then as traditional programming questions in the interview that they could answer for you ont he spot. This way you can gauge their understanding and their syntax. The two don't have to be the same question.
If you are not an expert then I would suggest you be careful about trying to evaluate other developers. You should probably figure out a better way to assess the dev skills of someone else if you are not that comfortable with your own level.
I am not sure there is a good solution for you.
I'd make the coding samples very straightforward and not have it take an hour or two. Simple coding exercises that take a few minutes should be sufficient - combined with other discussions about best practices, frameworks, design questions, etc.
I like the problems at streamtech. They are pretty easy and can often be done in rather short time, but they show that the applicant is capable of structured thinking and translating this to structured code.
As for evaluation---I would use this as an opportunity to learn. Do the problem yourself first, then compare to the applicant's code. Look up any constructs that you don't know, then ask yourself which version is more obviously correct.
I think the best thing you can do is try to have a real expert sit in on the interview with you. Hire a third party if you need to. I'm not sure it's possible to be able to give a quality assessment of someone who is a more experienced developer than yourself.
The other thing to consider is that really good developers may pick up on the fact that they are more experienced than yourself, and if you indicate that you are one of the developers it may actually put them off (not trying to be offensive, I just mean in the context of you implying that you are not very experienced.)
Give them an address or such as a plain text file and ask them to create a simple script to turn it into XML. I used that once and it worked wonders.
If you want to test them on the spot, ask them to reverse a string. From an organisational standpoint, perseverance, determination and enthusiasm are just as important as being technically adept, IMHO.
Well, everyone seems to be discouraging the coding effort for an interveiw. I'll disagree with the disagreers. To answer your question--if you want an example of what to have them code--drop a simple calculator on the table in front of them and ask them to write a program to create the calculator virtually. Give them half and hour and see how far they get. Some may finish in that time.
Have you ever tried pair programming before? Two people sit down at one machine, they share keyboard and mouse, and talk about what they're doing as they go. I think this is absolutely the best approach, because it will, eventually (after everyone's panic subsides), really indicate how well you two work together.
If you're not a great programmer, this person should be able to teach you and put you at ease. If they're not that good, but you work together well, that might be more desirable than a brilliant but unpleasant person.
At the end of the session, just delete your work. No big deal.
I've never been a part of the hiring process... but in interviews I've done, I was asked once to implement a doubly linked list, and another to work out an algorithm, the classic, how many integer points within a given shape, in this case three points forming a triangle, once in O(n^2) and then again in O(n).
I don't think the way to do it is to make them program something, but to make sure they know how to figure it out. You give them a problem or ask them a question, and tell them to think out loud, and observe their thought process. This doesn't exactly show if they have clean code, but depending on the problem it gives you insight as to wether or not they know what their talking about.
Having a small, well defined task can help you take examine people on a level playing field with a relatively small investment of time on their part. You don't need something complicated to see what people can do.
In the past, I've asked people to write a small web application that exercises a few fundamental concepts. We keep the particulars of what the application is supposed to do really simple.
I would also try to avoid tasks that require a lot of supplemental knowledge (viz, don't ask them to solve a problem from your particular problem domain).
Edit:
Regarding "small, well defined tasks": What I try to shoot for is something that includes a very thorough description of some simple business logic as part of a larger programming task. For example, one of the programming assignments I've given in the past involves setting up a simple Java web application and implementing a few features. We made sure to describe thoroughly how the features were supposed to work to remove ambiguity. This was for a couple reasons:
The point is really to see if the candidate can build a simple application from scratch, not to see whether they can guess correctly about what we want.
If you define the task really well, you get to see more about how thorough someone is with the type of work that they're likely to be doing in a business situation.
We wanted something flexible enough to give to candidates at varying levels of experience.
I should note here that I think programming assignments are most effectively used to check for competency. If you give a really hard assignment, or one that isn't well-defined, odds are that you're not going to get results that tell you what you want to know (unless you're testing specifically for how the candidate handles difficult assignments or ambiguity).
I argree with bpapa about it being an interview instead of a test run, maybe instead consider asking some questions about how they would undergo certain talks to do with the programming...
I once had to sit a Visual Basic MCP exam at the end of which they didn't even bother to give me the result.
Happily though when I asked the question as to whether I would be given the result I was sitting at the Commit/Cancel screen.
So I hit cancel thanked them for wasting my time and walked out.
To answer the question:
For PHP, I think a shopping cart, address book and forum would be good projects. Those usually cover a wide spectrum of web-programming topics - sessions, registration, database, form processing and authentication.
Personally speaking:
It looks like you looking more of an architecture person than a coding guru. I wouldn't penalize the applicant because he cannot come up with the name of an obscure function or need to refer elsewhere. The key thing is that he has the initiative and know where to look (heaven knows how many times I need to look up PHP.NET). A good question for an architecture guy, IMHO, is to tell him you have a data-set, but you have three different ways of displaying them and each view has different operations. If his answer is just a gigantic SWITCH-CASE, then he may be the wrong choice.
Usually weak programmers does not understand recursion pretty well, that's from my observations as far as now, now this does not have anything to do with PHP directly and probably a recursive factorial or fibonacci series wouldn't be a big deal, but let's say to load a tree control with data from a database with some parent-child relationship might be a good sample.
Also as you're not an expert as you said, think off something you can handle confidently.
It usually depends on the language you are hiring for. For example, when I went and gave an interview for PHP, I was asked to write a blog script, using custom MVC framework, whereas when I interviewed for an opening as a JS dev, I was asked to code a certain plugin in jQuery. Its more dependent on you are hiring the guy for ultimately. You dont want to ask someone to write you a music recommendation engine and then have him work on a payments gateway processor.
Why are so many people still writing crappy versions of things in standard libraries? Not to go after PHP developers, but guys go read the PHP SPL
Peer review can help catch that kind of thing. If you have another developer looking at the code, and they continually find implementations of standard library methods, it should fail the review unless there's a good reason for reinventing the wheel.
Young, ambitious programmers like to solve every problem on their own. They don't need no stinkin' libraries. Older, lazy programmers would rather search for existing solutions to the problem at hand.
So my advice: the next time you hire a programmer, choose the old guy who falls asleep in the reception area.
Just kidding, mostly. Peer review and education is the answer.
Better search techniques. and Domain Specific Familiarity
How does a developer check for a function they dont know the name of? Or perhaps there isnt an EXACT built in function to do what they want, but something they can use to save a lot of code. You need to be able to find the right terminology for the problem at hand, and from there you know what to search for. This is best achived by reading topics specific to your problem domain. Get away from coding specific resources and spend sometime in the field which you are coding for... wether it be retail, medical, insurance, etc.
Summary: Assumption is the mother of all FUBARs
I see this a lot from colleagues who are unfamiliar with the concept of frameworks (god how they complain about "two languages in one"), to wit: old C++ guys suddenly confronted with C# diving in head first to recreate hashtables from scratch...
Clearly a big part of this phenomenon from that angle is not stepping out of old mindsets and habits. If you're in a new environment you need to learn the new rules. The only way to deal with that from the outside looking in is to provide training, whether that's pair-programming for a while or something more formal.
Lack of familiarity with your tools breeds the contempt of others.
A simple coding style document might help by reminding the devs that there are libraries available (maybe list some preferred) and that they should be familiar with them.
Sometimes, you just have to remind people.
A peer review would help.
PHP is well documented if and only if, you know exactly what you're looking for. For example, you'd open Arrays and Array functions sections to see what you can do with arrays. And guess what, there is not even mention of SPL.
You should also encourage research before actually setting out on writing code. I usually approach problems by thinking about a way to do it, then I try to find anything in the standard library or any other libraries that will help me out. I'd say that an hour of research in some cases can be worth days of coding.
If people aren't doing this, it may be a good idea to have someone ask them questions about their general approach to the problem and what library functions/classes they are thinking about using. If they're missing something obvious, suggest it to them.
Two reasons pop to mind quickly. First, the Standard PHP Library isn't WELL known, and suffers from poor documentation. The php.net website is widely considered the language's best asset, but a lot of the newer built in classes (such as the SPL, reflection API, DomDocument, etc.) are little more than a list of methods without a lot of context.
More importantly though, it looks like the full SPL never shipped by default with any version of PHP prior to the (unreleased) 5.3. This is a killer as far as adoption goes. Usually people writing PHP code don't have control over what gets complied into their PHP binary. That's handled by their web-host and/or operations team, and web hosts and/or operations teams have different goals than a developer and aren't going to install every optional extension that comes along. This also means projects like Drupal, Joomla, Wordpress, etc. can't rely on the SPL being installed everywhere, so they don't use it.
Part of the reason PHP "won out" over perl was a single install had everything you ever needed. Optional extensions have never become widely adopted until they became part of the base install.
Very hard question to answer. Obviously peer review helps, but also proper documentation. Do your projects have technical specs, where you map out the classes and intefaces to be created?
If so, someone else on the team should review the specs and point out where existing code could be used...
Agree with training and peer review, but also enforcing unit testing and code documentation should help with the NIH syndrome :)
I've been a PHP developer for many years now, with many tools under my belt; tools that I've either developed myself, or free-to-use solutions that I have learned to trust.
I looked into CodeIgniter recently, and discovered that they have many classes and helper routines to aid with development, yet saw nothing in the examples that I couldn't do just as easily with my own tools. Simple things like DB abstractions, Email helpers, etc. There was some interesting code relating to routes - mapping urls to the right controllers; but even that's not particularly difficult to code yourself if you've ever written an MVC style web app with pretty urls.
Even after looking through some of the other popular frameworks, I still see nothing that would be that much of a time-saver. Even looking at the forums, I see people struggling to get the tools to work for them. I do understand how they would be more useful for junior developers, since full system design skills take a while to understand and appreciate fully.
Yet, I'm often told that I should use an off-the-shelf framework to produce my solutions, but I still remain unconvinced. What's the real benefit to someone like myself? Am I just being elitist, or is this a common opinion?
Edit: Looking at some of the answers here, should I perhaps consider packaging up my toolset as its very own framework, writing some documentation and posting tutorials? If I'm hesitant to take on other's frameworks, would opening it up and getting more eyes on it help to improve my own skills/tools?
Frameworks have several advantages:
You don't have to write everything. In your case, this is less of a help because you have your own framework which you have accumulated over the years.
Frameworks provide standardized and tested ways of doing things. The more users there are of a given framework, the more edge cases that have been encountered and coded for. Your own code may, or may not, be battle hardened in the same way.
Others can be recruited onto a project with a standard framework and have access to the documentation, examples and experience with that framework. Your own snippets may or may not be fully documented or have examples of use... but isn't much chance that others are comfortable with them initially.
EDIT:
With regards to your idea of packaging up your own framework, the benefit of cleaning it up for public consumption can be larger than the benefit of getting others to use it.
The reason is simple: you will have to re-evaluate your assumptions about each component, how they fit together and how clear each piece is to understand. Once you publish your framework, your success will be strongly dependent on how easy it is to get up and running with.
Big wins with little effort are essential for adoption (those wins will encourage people to delve further into the framework). Ruby on Rails in an example of a framework that gives such big wins with little effort, and then has hidden layers of features that would have overwhelmed someone just getting started. (The question of the quality of RoR apps is not the point, the point is about adoption speed).
After people adopt a framework, it is about the ease of continued use. Little details like consistent parameter use patterns make all the difference here. If one class has many parameters on every method, while another has setters that are expected to be called before invoking methods, you will lose users because they can't get a "feel" for what is expected in a given case without resorting to the documents.
If both ease-of-adoption and ease-of-living-with issues are addressed properly, you only have to get lucky for people to adopt your framework. If those issues are not addressed properly, even an initial interest in the framework will wane quickly. The reason is that there are many frameworks: you will need to stand out to gain the advantages of having others using your kit (as they rightfully are as wary of your framework as you are of others).
Here's another reason not to create your own framework. Linus' Law - "Given enough eyeballs, all bugs are shallow". In other words, the more people who use a given framework, the more solid and bug-free it is likely to be.
Have you seen how many web frameworks there are for Java? Back in the day, it was fashionable for any half-decent developer/architect to write their own custom web framework. And at the end of the day, 95% of them looked like a custom implementation of Struts (the most popular Java web framework at the time). So they basically created a Struts clone that was: 1) proprietary; and 2) not as well documented and tested.
Let's face it - writing our own customer framework is fun, but what happens next? It becomes a maintenance burden to keep up with the framework yourself (or the poor soul who replaces you). And maintaining software is much, much more costly, especially when it comes to custom frameworks. Is the company in business to solve domain problems or in the business of maintaining frameworks?
I forget who said it, but I once heard a great quote - "The first rule to creating your own framework is: don't". Somebody else has probably gone through the effort of doing so and probably done the same work you would have done. Save yourself the time, effort, and testing.
There's many comments here as to the advantages of using a framework, and certainly I think in a good many cases they are perfectly correct.
HOWEVER
All frameworks come with the downside that they have a domain of problems that can be fitted into them. If your problem is well inside the scope of the domain then using a framework isn't an issue, and most of the time it's readily apparent if your problem is well outside the domain so you don't give it a thought. Issues arise when you try to force a problem into a framework that it just doesn't quite fit into or has some unusual non-standard feature - in which case you complete 90% of the code really fast then spend all the time you've saved figuring out how to bend or extend the framework so it can accomplish some obscure requirement. Because in these case your solution/extension has to plug into the framework it can often be more difficult to code than if you'd come to it independently.
In the wrong circumstances this can actually be disastrous. For example if a client asks for a project that you believe will fit into a framework solution and you quote accordingly, then after completing 90% you find the gotcha then you can be really up the creek, especially if it's some feature that the client is insistent upon (and it always is). These issues tend to arise because it is not always apparent from the word go where the gotchas might lie, particularly if you're using a framework you are less familiar with (and you have to from time to time).
This is really the same problem as arises with deploying any third party software in a project. Myself from experience I have no qualms about using frameworks or similar, but given the choice I will always go for the lightest, thinnest, wrapper I can find that will do what I need. That way I gain the advantages, whilst knowing that if issues do arise (and they are generally less likely to with a thinner wrapper) then figuring out how to work around them is likely to be simpler than learning an extensive code-base to the point where I can safely modify it.
The framework code is likely to be well-tested and relatively free of bugs. By using it you save yourself time testing/maintaining your own code to do the same thing.
And any time saved is good. Laziness pays off in programming.
One thing that you will be missing out on is all of the Validation that goes into a popular framework.
Your routines simply don't have the same exposure that the popular libraries have.
You may have a point.... however I wouldn't underestimate the power of many, as an example phpBB is as far as i'm concerned the bb solution to use. Why? Because there are many, many thousands of posts on their support boards and many people using it who are knowledgeable and can help people solve problems.
Therefore the only reason in your case to use a popular framework is the many others that use it, report bugs against it, fix it and support it. It'll be tricky to get the same coverage on your own libraries.
I would go against the grain here, and say, you should use your own custom framework, If the software you are building is the core of your business. As Joel would say, "Find the dependencies - and eliminate them". If you are just putting up a little website for your company, and you business isn't maintaining websites, then go ahead and use a framework. But when that website is your business, then you shouldn't depend on a framework from somebody else to let you get the job done.
I think the main reason is that when you use a common framework, there are a lot of people who are instantly familiar with your product.
Apart from that I think it's most important that whatever tools you use actually get the job done. If it happens to be familiar to other people, then that's a bonus.
I agree you should use your own custom framework. Not only is it easier for you to understand, but it provides the ultimate in job security!
Three reasons I can think of immediately:
A well-known framework will be familiar to other developers who may have to work on your project
A well-known framework will have resources like books, discussion boards, and other experts that can be used for finding out more information
Managers will often have a "don't reinvent the wheel" philosophy. In fact, existing solutions have probably solved the same problems that you'd discover if you create your own solution.
All of that said, there may still be a place for your own solutions. We wouldn't have so many frameworks (or scripting languages) to choose from if no one started something new.
Any experienced developer can build a framework -- the challenging part is convincing others that it's worth using. You'll need to create documentation and tutorials for it for those who plan to use or maintain it. You'll probably need to create a demo site to prove that its useful and actually works like it's supposed to.
That alone can be a considerable investment, not including bugs that could pop up in between. When its all said it done, it could be worth spending time learning another framework instead of making your own.
You mentioned CodeIgniter -- I personally feel like that's a pretty framework -- it doesn't get much more barebones than that.
What you essentially have is your own framework. So, it isn't a time-saver FOR YOU, because you have already spent the time to develop the framework. If you didn't have that to build from, it would certainly be easier and faster to use an existing framework than to roll your own.
What you need to look at is whether or not your framework is better than other options out there, and whether your familiarity with your own code outweighs having other eyes looking at it, and other people using it in enough different ways that the likelihood of any problems being found and corrected is much higher.
Also, if your framework is so much better than everyone elses', you might consider opening yours up to the community ;)
As you probably know: "time is money". So by using a popular framework with a lot of helpers, a lot of code examples on web and a big community you do more in less time.
Sometimes it if ok to use frameworks because you become more productive, but in some advanced and difficult projects it may happen so that the framework stays in your way and you have to find workarounds.
I think there is no definitive answer. You should put in balance the pros and cons and take the right decision for your project.
Usually I adopt popular frameworks very fast but not in critical parts of the projects and in time I extend their usage.
I think that if you don't see a need to use a framework then don't.
The reason I use a framework for example Django for python or Rails for Ruby or Webforms and MVC for ASP.net is because they make it easier and faster to write applications for them. In the case of Ruby and Python not using a framework for me would make me go crazy.
If you have something that works and don't see a need to use a framework I would say stick with what you feel is best. But, I would still keep up to date with frameworks.
I think they are more useful if you are starting from scratch and don't have the time to write your own. If you already have a codebase you developed over the years, they may be much less useful, but it may still be useful to take a look and see what they did.
For example, I am sure major game development shops are not using third-party tools, engines and frameworks, not because they are not sufficient, but they already have built their own since the 80's or whatever.
Plus, if you are using an off-the-shelf component, there is no way to exceed it in its particular area. If you need to be a market leader in a particular dimension, you should be building your own solution in that dimension, so you can lead. If you don't need this capability, using a third-party component that is just as good as yours may be a good solution as long as it is an easy transition. Time to train in the new tool and living with its idiosyncrasies may or may not be worth it though.
The other thing to consider is that if you can build something, you truly understand it. Otherwise, you don't. Now, you don't need to fully understand stuff to use them, so long as they "just work", but we all know how that goes... :)
Can you solve the problems you are given have with your code faster and more reliably than public frameworks?
If yes, then keep using your own.
If no, then find the framework that does a better job and run with it for that project.
It all comes down to which codebase gets the job done better(for the value of better given by the client. ;) )
Disadvantages.
Most frame works are not object orientated. (code igniter does show some promiss)
Most of the code is done via includes. trying to track down the problem is like pulling on a thread on a sweater, and having to unravel the entire garment to fully understand the creation.
Most frame works have poorly written documentation.
Most frame works try to do many many many things.
I find from my experience developing with frame works that it takes a good 3-6 months to get on top of the code base. And its only after that period of time that you will find out weather you are trying to fit a square peg into a round hole. Given that most php projects want to be finished before that period has elapsed, it will cost employers more to get any project using a big "frame work" to fruition.
Many of the php Frame works were written for php 4, and were written in a different enviroment. They have been extended greatly, but are showing their origins. The use of global constraints is particularly prevalent. I am hoping that php 6 puts most of them to death. Code igniter escapes most of this, but it is new, and has object orientated parts.
Some frame works have written code that is not needed, and causes problems.. eg: CAKE has a most excellent model view controller, but its session handling is a disaster. Unfortunately frame works are not written in a modular way. Often its an all or nothing option.
MOst programers "hack" the frame work to get it to do what they want. This leaves future programers sractching their heads. It also makes "upgrading" the frame work a impossibility.
I have yet to see a frame work that implements unit testing. (how do you know that you have not broken it).
give me a well written object any time. At least them you know the scope right off the bat.
Advantages are that it's already written and tested by multiple people therefore less likely to be bug prone.
Disadvantages are that it's not built specifically for your application and therefore will most likely perform worse.
All in all, I can't really see much reason to use one considering you already have your own...although it may be worth releasing that open source so others are able to bug check and recommend improvements.
I am completely new to programming - my interest lies in PHP & MySql for building a dynamic web application for Military Band Administration purposes. i.e. General info and social networking for members + added functionality for the management team to communicate effectively.
OK so the question - as I learn more about PHP there are terms used that I do not understand that must come from a common basis of familiarity between all languages i.e. "stack overflow" appears to be an obvious one - "using too many recursive functions may smash the stack" is another.
So is there a book (a primer perhaps) about programming in general which allows someone like me to have a better understanding of what all this means?
Bear in mind I am 57 years old (young) and am really just starting out.
Steve
Wikipedia is probably your best resource for general information on programming terminology. A large segment of their community overlaps with the programming community, so tech-related pages are normally very accurate, educational, and up to date. See their pages on stack overflows and recursion as examples.
Also, PHP.net is the best place to learn about PHP specifically, but skip the main page and go straight to the tutorial if you're just starting out.
Finally, I highly recommend the book Head First SQL for learning about databases. All of the examples in the book use MySQL. The entire Head First series is great. I hear they have a PHP book as well, but I haven't read that one.
Update: Head First PHP & MySQL is now available.
It sounds like you're missing some of the fundamentals covered in a computer science program. Not to worry, the information is readily available. You don't have to pay someone to teach it (though it's sometimes nice). Wikipedia's computer science entry isn't too bad for highlighting the major fields you're likely to encounter. Topics that are good to know:
Discrete math (Helps to understand formal logic, algorithmic complexity, probability)
Programming fundamentals (sounds like you may have a good start on these)
Data structures (Store and manipulate your data in an appropriate way for a task. For instance, why use a hashtable versus an array versus a linked list? From your list, the stack in a stackoverflow is a data structure.)
Algorithms (Manipulate your data structures in the most efficient way possible or at least know the cost. From your list, using too many recursive functions to "smash the stack" is an algorithmic choice.)
Computer Architecture (Understand what's really happening to your code after it's compiled or interpreted.)
Networks (Learn protocols, what happens to your software when it wants to talk to a machine it's not running on)
Comparative Programming Languages (PHP is just one way to skin a cat. Learn why its designers made the decisions they did and gain exposure to alternatives.)
Operating Systems (Knowing how hardware interacts with your software is good but it's probably more important to understand how it interacts with its operating system. File systems, process management, memory management, security)
Formal Languages/Theory of computation (Models of computing, grammars [used to validate and interpret code], limits of computing. Typically not used day to day as a software engineer. Then again, regular expressions finally made sense after this class.)
Software Design and Life cycle Methodologies (Be deliberate about designing, coding, testing, releasing, and maintaining your software.)
As far as books, I'd start by checking a trusted school's computer science program reading.
Stanford offers a set of classes online for free: http://see.stanford.edu/see/courses.aspx
MIT lets you download course materials for free: http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/
Check youtube for computer science related lectures.
If you want something less school-focused, a quick search on Amazon with any of the topics above will give you results with user reviews.
Obviously, taken together, this list isn't really an introduction. I'd start with a topic that sounds interesting and jump in.
Well it is not book about PHP but I think a book like "Learn to program" from the Pragmatic Bookshelf
might be useful for someone in your situation.
To get a good understanding of the inner workings of computer hardware and software in a very readable (not too technical) manner, I can recommend Code,The Hidden Language of Computer Hardware and Software by Charles Petzold.
The later chapters in particular talk about some of these more general programming concepts that are present in most programming languages. The earlier chapters focus on more the history of the computer and software, so not as relevant to your question.
However it's not a large book so the reading it all should be interesting/useful anyway.
There are better books if you are looking for an introduction to PHP/MySQL programming specifically, however if you want more general knowledge about how software and hardware works, Code is great.
I'm not sure if there's one book that'll teach you "The Fundamentals of Programming." The only way I know of learning all these things is simply practice. Get a PHP tutorial and start building things. Always keep your mind open to learning new things. When you find a better way to do something than a likely very inefficient hack you put together from incomplete knowledge, then use it and learn it and integrate it into your knowledge... after a few years of this you'll be golden.
It's been a couple years since I read it, but Programming PHP did a nice job of introducing the fundamental programming concepts along the way. It didn't do much for helping understand more advanced concepts, like MVC (which is rare in the PHP world), it things like arrays, functions, callbacks, classes, etc, where covered.
I like Corbin's comment, but I'll take the opposite approach.
Basically, with systems today, you really don't need to know all of the low level details of systems. Really, you don't.
If you find this stuff interesting, the entire internet is at your disposal -- and simply let you inner muse guide you through either necessity or simple curiousity. You can go as deep or as high as you want.
The truth is, computing today is simply SO fabulous that the project you want to embark upon is just a perfect opportunity to learn more about the arcane world of computing. The fact that folks can get as far as they can "without having a clue" is testament to how far the field has advanced. It's a good thing.
Is it a good thing to understand the process soup to nuts? Sure. Do you actually NEED that understanding to be productive and get useful results out of your time investment? No, you don't.
And, as you progress, if you actually enjoy this work (you well may not), the field goes as broad as you want.
Computing today is like "Home Depot". You can do it, we can help. There are hundreds of forums and thousands of pages of documentation, books, blogs, and discussion available for most any topic.
The key thing to focus on is simply getting your task done. Don't worry about getting it perfect, don't worry about "doing it the right way", don't "engineer" it. Just hammer bits together until you get something close to resembling what you want to get done using whatever you happen to find or intuit yourself. Because that's the easiest way to find out what you don't know, and how to not do things in your application. Try it and see.
You will be blinded by options, techniques, patterns, frameworks, etc. Not only is there "more than one way to do it", there are HUNDREDS of ways "to do it". Ignore the hundreds, and focus on the "doing it", however seems natural to you.
And don't let the yahoo's in their ivory towers poo-poo your questions, or shred your design. Unless their name is "Babbage" or they were cutting gears for the artillery computers back in WWII, we're all standing on the shoulders of giants here, and we all started somewhere. Honest criticism should always be welcome, but some folks seem to be beyond being able to offer that and instead resort to belittling.
I marvel at the applications I've seen "hacked", "butchered" and "OMG'd" together that folks get real, practical use out of -- and that's the real name of the game.
Good luck on your journey. Success in all your endeavors.
Learning is quite individual, so your mileage may vary, but I find that asking questions in public fora is very helpful. If you don't know a lot of the topic it's easy to ask the wrong questions, or somehow focus on the wrong things. Getting direct feedback from someone more experienced usually helps with that. PHP is blessed in that it has a very large and friendly community. Further, a lot of its users are amateurs or inexperienced programmers, which means that there is a culture of asking basic questions about terminology and the like. I suggest that you tap into this source.
One place to start could be at sitepoint, but there are other places
If you're more of a visual learner I would check out some video tutorials. Start with things like basic programming concepts and then move up to titles like Up and Running with PHP and Advanced PHP and MySQL. Then I'd suggest an MVC framework like codeigniter.
You can find great video tutorials on Lynda.com or Pluralsight.com and several other places.