An individual new to programming usually falls into one of two classes;
Passionately obsessed with learning and willing undergo immeasurable amounts of sleep deprivation to learn this new skill, or
Approaches learning programming so unprepared that the immediate disappointment and frustration quickly consumes any desire that they had going in.
I would like to take this opportunity to present a "primer", of sorts, that I believe will allow just about anyone to turn this venture into a much more satisfying undertaking. But before we start, I'll preface this with a few qualifiers:
Language: PHP 5.x
Skill Level: Entry
Logical Reasoning Skills: Mid to High
Frustration Tolerance: Mid-level
If you can honestly assess yourself as being in possession of the three latter bullet items, you will likely find this article of great advantage to you. If not, then save yourself the frustration and abandon it altogether or continue reading for the simple sake of reading something.
PREFACE: PHP is remarkably flexible language. Due to the fact that it lacks the more strict rigors such as variable type declarations as well as also having a much cleaner syntax than languages like C or C++, it certainly allows for a pleasantly shortened learning curve.
Of course, one of the downsides to this is the fact that it also has the ability to build confidence so fast that many novice programmers quickly abandon learning such critical aspects as best practices or other major elements of a good programming paradigm.
So, all that having been said, I would like to urge that if you're new to programming, please take the time to continue your education well beyond the early confidence that accompanies instant gratification. Likewise, don't let caution be the reason that you don't experiment as the hands-on aspect is your greatest teacher. Make the mistakes. Use them to advance your knowledge. But use them as a guide to establish furthering your knowledge through more established programming practices.
PROGRAMMING 101: (Introduction) If you're reading this, chances are that you have a significant interest in the world of the unseen heroes. The mindset of a programmer is not something that is taught as much as it is an inherent mental process that is used almost constantly when evaluating real-world events or problem solving.
In a typical day-in-the-life of a programmer, he/she would see or hear about a business problem or scenario and almost instinctively begins trying to conceptualize a series of methods or actions that would solve the problem. Additionally, a sign of a really good programmer, is an individual that can see the problem and is capable of breaking it into smaller, more modular objectives. The reasoning behind this is that when attempting to address a problem as a whole, typically people view the problem and solution almost as one and the same without any further regard for the details required to achieve the solution. This is inherently the primary reason most programmers typically fail. They will pitch a solution that "sounds perfect", but fail miserably, and quite often, embarrassingly to be able to even come close to the proposed solution, if at all.
As a side note, as you move further into programming, you will take notice of a variety of programming paradigms. For instance,
Object Oriented Programming (or O.O.P. for short) would be two. Due to the advanced nature of of OOP, we'll start off centering around procedural programming. This will allow you to grasp the basics more readily without muddling the learning process with topics that would only complicate things for you rather than assist you in learning.
So, lesson #1 is more of an effort of self-teaching. Create a list of perhaps 5 reasonably simple scenarios, that require a programmatic solution. Then systematically breakdown each scenario into a series of logical blocks. Each of which supports the next. So, as an example;
Scenario: Given one apple, I would like to have it peeled, cored and sliced into 6 equal parts.
Slice apple into 6 equal parts
Now that you have an established conceptual breakdown of the tasks that need to be performed to achieve the desired solution, you can now start down the process of translating each task into a functional representation of each item. So, let's now move to that aspect of this progression.
To peel the apple, I will create a means to rotate the apple as a knife skins the peel from the apple. Therefore, I will need a peel_apple() function.
To core the apple, I will create a means of holding the apple in place while a coring device cuts out the core. Therefore, I will require a core_apple() function.
To slice the apple, I will create a means to cut the cored apple into the requested number of slices. Therefore, I will require a slice_apple(num_of_slices)
As you can see from above, we now have an established approach to how we will provide the solution that was requested. This now allows you to begin creating the outlying framework from which you will build each functional requirement. So, let's now create a code-based framework using pseudo-code to support the functional requirements.
In the above pseudo-code, you now have a readable way to visualize how you will accomplish peeling the apple. For brevity's sake, I will not define the remaining pseudo-code functions and we will assume they are defined. Now that you have the functional framework in place, you can now move on to the task of actually writing the code that would perform each task as defined.
We'll get to that coding aspect of things later. The purpose of this effort was more to provide working example of how a programmer should approach the problem/solution paradigm. Obviously, this is meant only as an example and each programmer has their own unique approaches, but the general process presented here is usually used by every programmer to some degree or another as it provides a path of lessor resistance. (
notice I refrained from saying "least")
So, as an extremely rudimentary introduction to programming, if you, as the would-be programmer, don't feel that you can analyze things using these methods, suffice it to say, that programming would cause you both frustration and disappointment all too quickly and should be avoided. On the other hand, if this makes all too perfect sense to you, then you're already well on your way to entering into a truly rewarding new skill set that, from a financial future side of things, has become the place to be as there is enormous personal and financial rewards awaiting you.
NOTE:If this article has inspired you to move yourself forward down this path, I would highly recommend acquainting yourself with such topics as installing Apache2 web server and PHP5.3 or PHP 5.4.
In my next article, we will begin to examine an entry-level introduction into the actual language of PHP5 itself. It's my honest perspective that book learning of a programming language only carries enough weight to tilt a scale, but actually getting your hands dirty with writing code is where your learning curve will take off like a V2 rocket.
"coarse" should be "course". In paragraph 3:
"Likewise" and "though" are redundant. Choose one or the other.
In paragraph 2 of "Programming 101":
...I don't think "upcoming" is the right term to use here. I would drop that bit altogether and just say, "...a sign of a good programmer..."
In paragraph 3 of that same section:
...if your target audience is someone new to development, they probably don't have a clue as to what Agile development practices are. I wouldn't introduce that term without explaining what it is--which seems outside the scope of this particular article.
I think the topic and goal you are attempting here are good, but you need to be careful. You are discussing the general topic of "programming," but you are demonstrating more of a procedural programming paradigm. You might consider mentioning that programming encompasses many different paradigms, and describe which paradigm you are introducing the reader to.
Although, I see your point about the focus of the article and the implied value therein, I would like to present that as for the requested expansion on the particular paradigm I am focusing this article around; the intention was not to pidgin-hole the context to any single paradigm, but rather to address a more generalized mindset of how a beginning programmer might need to analyze real-world scenarios. Therefore, that mindset eludes specificity in favor of the more broad spectrum of programming mentality.
Admittedly, certain presentations in my article fall into a procedural paradigm, I chose that particular direction as it's the easiest for someone new to programming to grasp versus more advanced structures like OOP.
If you truly think that my article ultimately does require that change and that it will provide more benefit, I have no problem making the requested modifications for the reader's sake.
Thank you for the editorial feedback, kaufmed!