Almost exactly a year ago, I first started writing about my pivot to working full-time as a web developer (aka The Road So Far Pt I). tldr; after dancing around the edges of embracing this career (in every possible way, for my whole professional life leading up to that point), it had become clear I wanted and needed to commit. I find that reflection is the only way to take stock of progress, and a year seems like a good time to look back.
Given our understanding of what async is, how the callback pattern manages async, and some of the deficiencies of the callback pattern, let’s dive into another, newer pattern — promises.
As with callbacks, for a new developer, it can be difficult to sift through the massive amount of information available online. For the benefit of anyone else newly exposed to promises, in this post I’ve attempted to cull the resources and posts that I have found most enlightening through my own learning.
So what is a callback function?
A callback function, also known as a higher-order function, is a function that is passed to another function (let’s call this other function “otherFunction”) as a parameter, and the callback function is called (or executed) inside the otherFunction. A callback function is essentially a pattern (an established solution to a common problem), and therefore, the use of a callback function is also known as a callback pattern. (Source)
Imagine you walk into a coffee shop to get a latte. If they’re busy, perhaps you wait in line. When it’s your turn, you place your order with the cashier, and pay for the drink. The cashier writes your order — maybe even your name — on a coffee cup, and places it behind the empty (not yet fulfilled) cup of the person who ordered before you. Perhaps the shop is quite busy and there are ten cups ahead of yours. That queue of yet-unfilled coffee cups allows for the separation of the cashier (processing and queuing orders) and the barista (fulfilling orders based on the information supplied by the cashier). This queuing process results in increased efficiency and output. (The original source expands on the metaphor and is quite interesting). This is an example of asynchronous, non-blocking behavior.
Let’s talk about organizing our code. There’s never just one way to accomplish something with code. This is both great, and sort of paralyzing. How do you choose?
When self-teaching, almost all of us start at the same point. Where do I start? How do I “pick a language”? What do I focus on? I know I did.
There are two types of people, those who understand recursion and those who understand that there are two types of people in the world… (r/ProgrammerHumor)
But really. There seem to be people who can very naturally digest the concept of recursion, and those whose brains absolutely reject it. I happened to be one of the latter. In this post, we’ll go over recursion generally, and then work through a diagrammed problem example.