Tips for Technologists is a series aimed at teaching you to engage with technology in best way possible. You can see all the Tips for Technologists articles here.

By Nick Ruffilo

The next few posts are going to cover Javascript, PHP, and a touch upon a few other scripting languages. Over the course of my career and in my personal life, I’ve had to use nearly a dozen programming languages. Some of them I barely understand and simply copy and pasted code examples from the internet, and others I know well enough to be considered an “expert.” But, the one thing in common is that, at some point, I didn’t know how to program, and at some point, I didn’t know that specific language. It is true that once you know one or two languages, it becomes much easier to learn new languages, but there are a few high level concepts that will help you put your mind around what a programming language is, how it works, and how you can learn it. Additionally, I’ll share some tips with you that have helped me pick up languages quickly and have also worked for others.

It isn’t rocket science – but it is unforgiving
Programming, especially in today’s high-level languages, is by no means rocket science. With the right tutorial, anyone can learn the basics of Javascript, PHP, Ruby on Rails, Python, or some of the other scripting languages out there. Because many people have not been exposed — or needed to know — a programming language, they often think it is difficult and foreign. Learning the basics of programming is:

• Not as difficult as learning a new language — To learn basic javascript, you need only to learn a few basic grammar rules, and maybe 10 keywords. The basics of nearly all programming languages are geared towards English speakers, so you’ll know most of it.
• As easy as telling a 3-year-old how to make a peanut butter and jelly sandwich — In programming, you don’t want the computer making assumptions. In fact, it can’t make assumptions. Because of this, you need to be explicit in what you do. You can’t just say: “Put peanut butter and jelly on a piece of bread.” You have to write out the instructions. Get bread, open bag, remove 2 slices of bread from bag, close bag, place bread on plate, get peanut butter, open peanut butter, use knife to spread peanut butter on bread, close peanut butter, put knife in the sink, get jelly, open jelly, use knife to spread jelly on 2nd piece of bread, put knife in sink, close jelly, place the peanut butter side of bread slice 1 on jelly side of bread slice 2. I’ve found this is the hardest part for people to grasp — the need to explain everything. In the words of a silly internet meme “Ain’t nobody got time for that.”
• Strict but rewarding — All languages have their grammar. In most cases, if you do not 100% follow the structure, things will simply not work (or provide unexpected results). The grammar is not difficult, but it must be followed. For me, one of the most gratifying things is to watch something you made run. Especially when it saves you tons of time, or does something beautiful.

Give yourself a goal
Whenever I am starting to learn a new language, I program the simple game of Pong using it. That has been my goal. It is a beautifully simple game that can be logically programmed in about 20 lines of pseudocode (see below). Because of it’s simple nature, the challenge is never “how do I program Pong?” but “what is the grammar of this new language, and how can I use it to program Pong?” Pick something relevant to you and your interests. Also, chances are someone else has done something similar, and if you need, you can search and use their code as an example.

Pseudocode
Pseudocode is a concept in programming where you logically walk through a problem ignoring the grammar and specifics of a language. Pseudocode has no specific grammar and really is a set of logical statements. The “how to make a PB&J” example I laid out above is pseudocode. Every programming language has a special character(s) that allow you to write commands that are ignored by the computer — these are called comments. Comments make it so that you can leave notes for yourself and others to help understand the code. It is a good practice to write out your code in pseudocode using comments before writing any code. This ensures you can go back and read your code many years later when you’ve forgotten what and why you did things.

Steal, I mean borrow, other people’s code
Chances are, someone else has solved the problem you are facing, or written a snippet of code that will help you. It is a very common strategy to use code found on the internet in your application. Especially when learning a new language, why would you not want to use someone else’s code as a guide? For Javascript/jQuery, many people make their code compartmentalized and provide it free under MIT or other GPL licenses. Also, don’t forget to give back. There will come a time when you need a bit of code that isn’t out there (or not easy to find). If you write it, and can share it, you should.

Get a book
There are tons of different programming manuals in varied forms. For learning a new language, I love the For Dummies books mainly because I was not formally trained in programming/computer science, so it is good to have the basics reinforced. I also find their style of writing and grouping of examples logical. Others may find value in different books, but the key is to have something you can flip through and easily reference while you’re learning. I’ve also found that you need to buy the book yourself. That psychological commitment of resources will increase your desire and chance of actually learning the programming language.

Take a look at the documentation
PHP has some of the best documentation directly on their website php.net. Javascript has great documentation, but it is scattered throughout the internet. Take the time to search and find a few good resources. Bookmark them and know how to get to them easily. Being able to quickly look up the order of parameters can save you tons of time and headaches (trust me).

Object Oriented and Functional Languages
A few years ago (actually, quite a few) there word “Object Oriented” was a buzzword. Like most buzzwords, it got a hype and business people latched on to it without fully understanding what it means. Programming languages today are either functional, object oriented, or a hybrid of the two. Functional programming languages only allow you to program functions. A function is a defined name that takes in a parameter (or parameters), does something to those values, then returns another value.  Object Oriented programming languages contain functions, but require that everything be wrapped in an object. An object is a construct that can be duplicated. This allows you to create highly reusable code that is easy to read. Most of todays languages are a hybrid of both, meaning that they support and allow you to use objects but do not require it.

A function (in pseudocode):

function multiply(A, B) {
return A*B;
}

A function in an object (in pseudocode):

class Math {
function multiply(A,B) {
return A*B;
}
}

Looks similar, no? It is. The difference is, that I can create multiple Math objects in my code. For a simple function like this, that has little value, but, if I were to keep a running total or need to have changes to the values based off different parameters, it can quickly gain value. I will write more on using Objects well in the future, this is just to explain that they exist.

Interpreted and Compiled Languages.
Todays languages are either compiled or interpreted. A compiled language goes through a special process where the code you wrote gets converted into a more efficient form and packaged into an executable file (.exe on windows, for example). An interpreted language does not go through this compile process and is read and interpreted at the time the code is run. While interpreted languages are fast, there is a significant performance gain for compiled languages. Nearly all scripting languages are interpreted (NOTE: some interpreters will actually compile a script after it is first run but getting into these nuances is way beyond the scope of this. I just wanted to note it.). Unless your application has performance issues or will need to be extremely performance tuned, interpreted VS compiled should not play a decision factor.