Why I Learned to Code
As I get older there is one thing in this world that becomes more and more appealing to me: stability. Adventure and the unknown still beckon, but times have changed.
I have rent to pay. There are bills and responsibilities to tend to. The rock star life I once dreamt of has given way to dreams of a stable career and rock solid finances.
I decided to go back to school a couple of years ago, to finally earn my Bachelor’s degree. The problem is, most of my coursework so far had been in soft sciences. The “Psychology Factory” doesn’t offer a great job outlook.
I decided that I love hard sciences too. More than that, I love to build. Physically, mentally – however- I like to make ideas and projects.
I combined my two wants – the want for stability and the want to learn a science where I can build. After researching career fields that offer creative flexibility and a great job outlook.
Overnight, I became a programming major. It hasn’t always been easy, but it’s always been rewarding.
When I first began my coding journey, there were a few things that made my path harder than it had to be. Let me explain.
Barriers to Entry in Programming
Coding, like most things, has a business aspect to it.
Let’s talk about a business phrase that I think will help illustrate the idea I’m trying to get across. That phrase is “barrier to entry“.
“Barrier(s) to entry” is used often in the business world to describe the difficulty (or the obstacles) in being able to break into a market space or industry.
Let’s think of an example:
Imagine I want to make a new shoe company. The barrier to entry is relatively high because I would be competing against the likes of Adidas, Nike, and Converse. There are dozens of companies already successfully making shoes and their goal is to keep me out of their industry.
I may not being trying to take down Nike. Maybe I’m fine making handmade boots for a small market. Either way, Nike figures that any market share that I am able to take is market share that could belong to them. They will work to crush me.
My barriers to entry are the things and obstacles that make it difficult for my shoe company to catch that big break.
It might be things like not being familiar with how to work with rubber and other raw materials. Maybe a barrier is that I don’t have the right connections at manufacturing plants. Another might be that I don’t have shipping companies that will assist me in processing my orders, because they have exclusive deals with other shoe companies.
The shoe industry is a hard industry to get into because there are so many barriers to entry. Put another way, there are a lot of things stopping the newbies from being able to gain traction. As a result, the veterans stay on top of the industry.
Barriers to Entry in Coding
Coding is unique in that it has almost no barriers to entry.
You need a computer, an internet connection, and some dedication. That is the recipe to become a decent programmer.
I say there are “almost no” barriers to entry because there is one that I think exists. What is it?
I believe the only obstacle for new programmers is the jargon.
Jargon, one of my favorite words ever. It means words and phrases that are specific to certain fields of work and industries.
Ever watched an episode of House? All those big, latin, multi-syllable words that Hugh Laurie throws around could be considered medical jargon. They don’t make sense to me, but that’s because I’m not in the medical field. If I were in the medical field, they wouldn’t seem so gibberish.
Programming is sort of similar in this regard, that there are tons of acronyms and words and phrases that are unique to programming communities and hard for an outsider to instantly comprehend. I have personally felt frustration in spending hours on Google trying to find an easy-to-understand definition of a concept or acronym only to get the run around in definitions for jargon comprised of more jargon. It’s daunting and frustrating, and worst of all, it can discourage some who would otherwise take to programming like fish to water.
I hope that over time I can help you newbie coders jump that last hurdle, that big barrier to entry, by helping you confidently add this jargon into your vocabulary. Let’s start with some basics for now:
Basic Coding Definitions
Source Code – Sometimes simply referred to as “code”, when you think of “coding” in your head this is probably what you are picturing on the screen. Lots of typed out instructions and functions that the computer can understand but are somewhat nonsense if a human were to read it.
Programming Language – Much like a spoken language, a programming language is a language that is understood by computers. Programming languages are considered “formal” languages, meaning they have lots of strict rules that must be followed for the computer to properly understand. Examples of programming languages are Java, Ruby, Python, C#, and hundreds of others. Source code is written in a particular programming language.
An analogy that might make sense of this is to think of each programming language as a fast food restaurant. Though most fast food restaurants are somewhat similar, each has their own “flavor” and brand of what they are good at and what they’re not so good at. For an idea of a great “first language” to try, check out my appeal on Python. In this analogy, the source code is sort of like an order that you make at a restaurant. Like source code, an order is a list of instructions, and like programming languages, there are rules when you order at a restaurant (there are things you can and cannot order, you can ask for your food a certain way at one restaurant but may need to ask differently elsewhere). The source code (your food order) is comprised of pieces of the rules (menu) of the programming language (restaurant).
Program – A program is a group of source code that accomplish some sort of goal. Using the fast food analogy, the program would be your completed food order. Going off of what the programming language can offer, you put together some source code, and the program is the result.
IDE (Integrated Development Environment) – An IDE is a program that developers use to actually put together their source code and test it. Source code is just a bunch of written instructions, so technically you could type all of your source code out onto a Notepad or Word document, but an IDE is beneficial in that they are specifically built to help with the creation of code, and they allow you to test the code without needing to use a separate program. Some IDEs are built to only cater to one programming language while others are versatile and allow the programmer to create different projects depending on what language they would like to use. Eclipse, NetBeans, Intelli-J, and BlueJ are all examples of IDEs.
Using the example of a pizza place, the IDE is sort of like the brick-and-mortar store. You can order off of the menu, have your food prepared and eat your food (test your code) all inside of the restaurant. Typing code out in a Notepad or Word document is like ordering the pizza over the phone – it’s doable but you no longer have the ability to see the menu right in front of you and if your pizza gets delivered and is incorrect (your code doesn’t do what you want) you don’t have the benefit of being able to fix it and try it again right then and there.
Compiler – A compiler functions to take your source code, skim through all of it, and then attempt to run the code.
Interpreter – An interpreter goes through the source code line-by-line, executing each line as it runs.
Why such short explanations for Compiler and Interpreter?
Because this corny video does a better job of explaining these concepts than I ever will.
Syntax – Syntax refers to the way that instructions are typed out – it is the words, numbers, and symbols used.
Going back to our fast food analogy, correct syntax and incorrect syntax is like the difference between ordering a “hamburger” and ordering a “hamboorgur”. One makes sense, whereas the other doesn’t make sense, even if it is close to the correct word.
Semantics – Semantics refer to the way that the syntax is composed into statements. I am using the semantics of the English language to type this sentence.
Semantics are important because they help the programming language make sense of the source code. If you were to walk into McDonald’s and tell them “French fries lettuce large, two nuggets and”, it wouldn’t make any sense to them. Even though you used proper syntax (all the words you said are words that they understand) the way that you put the words together into a statement was nonsense.
Error- This one is hopefully pretty easy to understand. In coding, an error is when something goes wrong with your program. Something worth noting is that errors don’t happen “just because”, an error occurs due to something that you, the programmer, did incorrectly. There are three types of errors that can occur:
Syntax Error – The words, symbols, numbers, etc used in your code are not ones that make sense to the program. Sometimes called a Compile-time Error because most programs won’t compile if they find a syntax error in the code.
Runtime Error – All of the syntax in the code makes sense, but somewhere down the line the semantics simply don’t add up. The program will compile properly, but then will have an error sometime during it’s run.
Logical Error – All of the syntax and semantics make sense, but the end product isn’t what you wanted because you gave the incorrect instructions somewhere. This is like ordering a chicken sandwich and then being upset that you weren’t given a hamburger – the program did the job you told it to do, but you told it to do the wrong thing.
The list goes on and on, but I think this is a good place to start, as I’d hate for you to be overburdened with too many words and definitions early on. For the time being, study these terms and concepts, and prepare yourself – your coding journey has just begun.