So you want to learn to program? Or perhaps you’re reading this because you’re currently a non-technical product guy, or guy with the next big startup idea, and you’re curious of just what it might take to become a coder. Either way, my advice is simply this: do not attempt to spearhead these “techcrunch startups” (previously called “Web 2.0 startups”) unless you’re a coder. Most startups that get funding from professional silicon valley investors are founded by developers. The ones that aren’t are founded by high profile product guys are management from big famous tech companies like Google, etc. So if that’s not you, and you want the best shot at making a successful startup, become a coder--that, or hire us ;).
I’m going to break it down simply into some core high level concepts that should give you insight into what you’re life as a programmer might look like. I found that when learning to code the hardest part was that most books and tutorials about the subject were written by guys with knowledge too deep that they forgot what it was like to be first tackling this subject, and what questions you might have. Therefore, I’ve made it my goal to offer you the analogies necessary to start thinking like a coder.
The first thing I’m going to share is this: have you ever seen those black windows on the screens of coders, aka the “command line,” aka “the terminal,” aka “the shell,” etc?
Those are simply ways to control a remote computer via commands, rather than a graphic user interface (GUI). In short, you’re basically in side your server in a data center somewhere, doing things like installing Microsoft Word, or in the case of a web server, installing applications such as PHP, Mysql, etc. These tools are simply applications that are installed similar to applications with fancy GUIs that you see on your desktop computer. It took me a while to grasp this, but the idea is simply that these applications instead of functioning to show you pretty interfaces of a video you’re editing, or letter you’re writing, function to interpret plain text input and produce an output of more plain text. For example, if you wrote PHP code like this:
and then offered that as input to the PHP application installed on your server, the PHP application would interpret (aka “parse”) that code and return output containing the word “yes”. And typically, that output would be sent straight to the web browser.
Now we have 2 new questions: 1) when would the web browser display this result? and 2) what is this about “input” and “output”? .
1) The web browser displays this result when you go to a URL such as this: www.yoursite.com/abc-folder/php-script-name.php . Basically you’re pinging your a server connected to the domain name “yoursite.com” and requesting a file named “php-script-name.php” in the “abc-folder” directory which is located on your web server just as files are located on your hard drive. The only difference is that in this case, the script will execute the above code, and return “yes” over the internet to your web browser. Exactly how your server knows how to get this response to you is not important now. What’s important is to understand simply that if you open the script “php-script-name.php” from a web browser across the world from the server that contains this script, the script will return “yes”, provided that you provide no input.
What do you think would happen? Well, provided that you passed some input appended to the script name, specifically “?something=dog”, you would get the answer “yes” and otherwise you’d get the answer “no”. That’s just one way to provide input to a script. The reality is that within a script there is a long chain of input and output between different blocks of code. It’s the job of the code to do different things by analyzing this output and making different decisions. You could display the word “yes” in red if the viewing user is a female and in “blue” if the viewing user is a male for example. You could then make “no” green in a red based on the sex, thereby combining 2 pieces of info (whether “dog” was supplied as input and the sex of the user) to produce different output. The principle is still the same, coding is all about input and output, i.e. taking various input provided by the user (which can be many many things, and from many many places, possibly from previously stored data in the database or in cookies), and producing different output.
If you understand these 2 concepts, the next thing to do is to learn some basic HTML in this article. HTML is easy. If you care to put any time into learning how to code web applications, you’ll figure it out easily. The reason it’s so important to learn is because PHP coding is all about generating HTML. By “generating” I mean what experienced coders describe as “dynamic” without thinking.
But “dynamic” and “dynamically” are terms that at first can be quite foreign to non-coders. What they mean is potential to change. An HTML web page dynamically generated by a php script may look a certain way one day, and a different way the next. Simply imagine the date changing from day to day on a web page. HTML isn’t capable of knowing the date. However a PHP script can, and thus can dynamically adjust the HTML spit out to your web browser as output.
That’s a basic example, but where this is all going is the concept that many different aspects of a web page can dynamically change according to the php calculations made on the server. The result is generated web pages from templates that look slightly different. And I hope I’m not dropping another loaded term with “template,” but I think “template” is a good term to end on.
The idea is that the goal of using PHP in combination with HTML is to allow parts of the page (i.e. HTML snippets) to change according to PHP logic, while other HTML snippets stay unchanged. The term for the unchanged HTML snippets is “static,” i.e. unchanging. That’s the difference between dynamic and static. HTML without the aid of tools like PHP is static, unchanging, and with the help of PHP can become dynamic, changing. The logic that determines how your web pages change will be up to the product goals of your application.
Now that you have an idea of the differing responsibilities between PHP and HTML, it’s up to you to decide if you want to skip to learn some PHP and the basic logic it’s all about, or if you’d like to understand more about how web browsers interpret HTML to determine the presentation/display/design of web pages. We recommend that latter because the basics are really easy. You don’t need to master it, but it will help give you an end game to think about while you’re learning PHP, since HTML is the output your PHP code will be generating 99% of the time.