Coding Terms That Are Much Broader Than You Think

The english vocabulary that surrounds coding can be just as intimidating as the code itself. Or worse, the words look and sound like words you think you understand, but in fact have much different meanings in the context of programming. Such painful misunderstandings need to be eliminated as soon as possible for beginners, so let’s get to it.


The most basic term of all. We hear this mostly in the context of your smart phone. As in, “there’s an app for that.” But really the term ‘app’ is very broad. Like so broad you could define it as “any software that causes a computer to perform useful tasks.” Yeah, that’s like freaking everything. If you wrote something that did nothing by take text from a user and then show that text on the same web page, you’ve built an app. But hell, if you built a function that adds two numbers together and it’s only on your local computer, you’ve built an app. The level of complexity, or the platform it’s on are totally irrelevant to it’s classification as an app. Why is this important? Because otherwise it’s easy to get intimidated by the entire idea of building an ‘app’. You shouldn’t be. You start with limited functionality. You’ve still built an app. Then go from there.


Now that we’re good with app, let’s look at ‘Application Programming Interface’. It usually gets used in sentences like, “Developers can build some amazing apps on top of Twitter’s API.” This gives the impression that an API is just a way for some developer to use the data of another website. While true, an ‘API’ is wayyy more broad than that. Allow me the liberty of changing something slightly. What if it stood for an Application‘s Programming Interface? Yeah, just add the apostrophe + s, and you can see that API really just means ‘the way one interacts with an app’. And remember how broad the term ‘app’ is? Thus, API is extremely broad too. It’s actually impossible for any program you write to not have an API. To illustrate, let’s see how you could change the API of a super simple function that adds two numbers together.

Option 1: addNumbers(number1, number2) → You pass the two numbers as two separate parameters

Option 2: addNumbers({num1: number1, num2: number2}) → You pass one parameter. It’s an object with two keys ‘num1′ and ‘num2′. The values of those two keys represent the numbers we want to add.

Option 3: addNumbers([num1, num2]) → You pass one array paramater that has both numbers in it.

Each one of these options represents a different API to the exact same application of ‘addNumbers’. Each API comes with advantages and disadvantages. For me, seeing API’s as this broad concept was really enlightening and helped me conceptualize what I was doing as a programmer much better. It will also just help you understand documentation better because the term gets thrown around all the time.

Pattern: This one can be confusing only because it’s a word we all know so well in English. And the two are indeed related, but it’s not immediately obvious how until you see it in context a few times. When programmers talk about ‘patterns’, what they really mean is ‘broad conceptual way you achieve a task’. Or, according to Addy Osmani, patterns are templates for how we solve problems.” For example, if your problem is “creating an object”, then here’s two patterns for doing so.

Option 1: var myObject = {};

Options 2: var myObject = new Object();

Each pattern solves the same problem, but in different ways. Each way requires certain things that the other doesn’t. This gives each method it’s own advantages and disadvantages. I won’t get into that here, but suffice to say neither is necessarily ‘right’ or ‘wrong’. They’re just different patterns.

Stay tuned for future posts on more specific terms that are also easily misunderstood.

This article was written by Hack Reactor engineer Blake West.