This article will teach you GraphQL as well as how to build a small JavaScript server.

Building Your First GraphQL Server


<img alt="Black and white photograph of a surfer" height="972" src="/images/blog/finding-motivation-in-chaos/surfer.webp" width="1728">

# Finding Motivation in Chaos

> There are times in my life when I write almost more for myself than for others. It's usually about something I'm struggling with. Writing helps me process life experiences.
>
> This article was one of those times. I hope it helps you too.

## Introduction

I’ve told several of my friends recently that I write best about what I know.

Well, this is what I know: As of when I'm writing this, the last year has been pure chaos in my life, and it’s been all I can do to hold on with both hands. This isn’t anything unique to me; so many people are struggling this year. In the heart of the all of this, it’s been all I can do to focus on work.

Somewhere along the way, I stopped being able to write as much, tweet as much, or code a lot in my free time. I even have trouble finding time to play the guitar now.

When this happens — when I don’t get to express myself or create — I find myself circulating in a negative mental cycle.

“You should be writing more” becomes “You are lazy.”

“You should be coding more” becomes “You’re failing.”

“Nate, you should cut yourself some slack. Also, others have it way worse.” You’re right. I should, and they do. But this is the way the human mind works, and so it’s the mental struggle I’ve been dealing with this year.

I also think what I’ve said so far might resonate with a lot of you.

Today, I want to talk about motivation: what it is, why it might look very different from what you think, and how to get it back if you feel like you’ve lost it.

As always, get yourself a cup of some hot beverage (I’m drinking hot cocoa as I type this).

It’s cold outside, but that doesn’t mean we can’t be warm. ☕️

> “I accept chaos, I’m not sure whether it accepts me.”
>
> — Bob Dylan

## Do the Things, Be the Things

It’s been said that we shouldn’t tell others what we plan on accomplishing in the future, as the mere act of doing so gives us a dopamine rush. When people praise us for our goals, our brain feels successful and validated. Ironically, we’re now _less_ likely to complete that task. Our brain thinks we’re done.

I’d also argue that it’s just as dangerous to think about what we _should_ be accomplishing at some point in the future. I read once that most people’s unhappiness stems from the difference between how they think their lives should turn out and what actually happens.

If I staunchly believe I should own a house, be married, and have a white picket fence with 2.5 kids by the time I’m 21, I might end up being a very stressed person if I’m 22, single, searching for a job, and living in an apartment the size of a closet.

When people say they’re struggling with motivation, really what they often mean is that they think they haven’t completed anything lately that they’re proud of.

The heart of the problem is usually that they’ve tied their self-worth to their ability to complete an arbitrary task defined by either society or their own mind.

_(The thought in the sentence above is a brand new revelation for me. I realized it about myself right as I was typing it out for you. Don’t let anyone ever tell you that writing can’t be therapeutic.)_

But life isn’t just about goals. Human beings aren’t robots that check boxes.

As the cliché goes, “Life is about the journey.” What if this is true of motivation? What if being motivated isn’t about the goals you achieve? What if being motivated is persisting yourself through whatever comes your way?

_(I wrote an [article back in 2019 on this](https://www.nathanthomas.dev/blog/the-pursuit-of-personal-fulfillment) that I apparently didn’t internalize.)_

I’ve had a mounting suspicion lately that we all think about motivation in the wrong way. It’s not just about what you accomplish.

> “Life is what happens to you while you’re busy making other plans.”
>
> — John Lennon

## Accomplishments are Retroactive

If motivation isn’t about accomplishments, then what is it all about?

The best way to approach motivation is to ask yourself what the most important thing is to _you_ that you should be doing in that moment.

The stoic philosophers had an idea called “memento mori,” or “remember that you must die.” The idea was that you could die at any moment, so keep that thought in your mind to focus your attention in life onto what really matters to you.

Should you be reading that book? Working hard to make money to buy a house for your family? Writing a song? Coding an app as a side project?

The problem with defining happiness based on _completion_ of goals is that they’re so often impossible to completely define; the goalposts keep moving as life moves on.

If you told yourself that you want to be a gifted musician, you might give up in the first month if you still couldn’t absolutely shred. But if your desire is to learn to play the guitar, then you’re already fulfilling that promise the first time you play a C chord.

You’re much more likely to continue doing something if your desire stems from wanting to do the learning (or building) action, not the finishing one.

If we’re inspired by this long enough to keep creating, we often look backwards and see how much we’ve accomplished.

It’s this point that others look at with admiration.

It’s this point that so many people hang all of their hopes and dreams on.

It’s this point that causes so much unhappiness for others when their expectations do not end up matching reality.

<img alt="Foggy beach in Northern California" height="1125" src="/images/blog/finding-motivation-in-chaos/beach.webp" width="1795">

## Inaction is a Slow Death

If there is something comforting in all of this talk about motivation, it’s this — Everyone who has tried learning a new skill or habit has experienced failures. It comes with the territory. You have to be prepared to fail (especially in the beginning) when you’re learning a new skill.

This should be an encouraging thought, since it ultimately frees you to pursue what you want.

For instance, I often think of this scene from the show [Adventure Time](https://en.wikipedia.org/wiki/Adventure_Time) when talking about failure:

<img alt="Jake the Dog from Adventure Time saying, 'Dude, sucking at something is the first step towards being sort of good at something'" height="266" src="/images/blog/finding-motivation-in-chaos/jake-the-dog-advice.gif" width="474">

So many people stay in stasis because it’s safer for them to stand still and never experience failure than to be pushing for what they want and are passionate about in life. They’re scared others will judge them if they don’t succeed.

Notice a trend here?

Once again, our mind’s end goal is forcing us into unrealistic expectations of how our journey will be.

Instead of this, recognize that true success is in just _moving_ in a certain direction. This is a victory all by itself, as you can always pivot and adjust course later.

When teaching students how to code at Code Tenderloin, I sometimes see students upset that they made a small mistake. But I always remind them that it’s actually an advantage — Now that mistake is permanently burned into their mind, and they’ll likely never make it again.

A weakness has become a strength.

It’s the same way with our motivation. If we focus on the journey and not some end goal, we can be thankful in the moment for when we mess up because it’s made us even stronger.

> “The only man who never makes mistakes is the man who never does anything.”
>
> — Theodore Roosevelt

## Success is a Team Sport

There’s one more point I’d like to make about finding motivation, what it is, and how it relates into what we feel — Motivation is often found through collaboration and communion with others.

There’s a quote in the book [Debugging Through Teams](https://www.amazon.com/Debugging-Teams-Productivity-through-Collaboration/dp/1491932058) by Brian Fitzpatrick and Ben Collins-Sussman that says, “Lone craftsman are extremely rare — and even when they do exist, they don’t perform superhuman achievements in a vacuum; their world-changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort.”

Motivation is extremely easy to find (and sustain) in groups. It’s much harder to develop on your own at your desk at 11:35 pm on a random Tuesday.

When people think of how Apple started, they often think of the legend of Steve Jobs and Steve Wozniak, laboring away in a little garage in Los Altos, California.

But what people often don’t realize is that Jobs and Wozniak quickly hired a team around them who helped lay the foundation for what Apple is today. Apple never would have succeeded if it had just stayed the two of them.

If you’re struggling with motivation, perhaps it’s time to start working with those around you to produce something insanely great. Focus on what you’re passionate about and go from there.

You might be surprised what your group of believers can turn out.

> “It always seems impossible until it’s done.”
>
> — Nelson Mandela

## Embrace the Chaos, Find Motivation

Instead of fighting with how your week, month, or year is going, notice instead how you have succeeded within it. Appreciate when you’ve taken steps to work on yourself, your friends and family, and your hobbies.

Carve out some moments in the coming days to practice and build projects that you’re passionate about.

Don’t worry about what this will look like a year or two from now, since most of us can barely predict what we’ll eat for lunch today (let alone tomorrow).

Finally, think about gathering up people like you to work on ideas together. There’s strength in numbers.

If you take these steps, I promise you’ll look up one day down the road and realize that you’re somehow motivated in a way you couldn’t have previously imagined while also having a series of achievements that you’re proud of.

---

Thanks for reading.

Nathan ☕️


Change is a constant in life. The only thing that matters is that you keep working on yourself.

Finding Motivation in Chaos


<img alt="Foggy clouds lining the embankment of a forested hillside" src="/images/blog/on-loss/cloudy-hills.webp" height="880" width="1316">

# On Loss

## Every Morning I Wake Up

It's been about 4 weeks since my grandfather died.

It was due to cancer and old age, not COVID. He was 93 and lived a great life, and our family saw this event coming.

But knowing something terrible will happen doesn't make it sting any less when it finally hits.

This is probably not the way you expected an article from me to start out. This piece won't be a downer, but rather a melancholy look at the inner thoughts of someone going through loss just like many you right now.

It's not just loss from death, either. Many of you are also going through an existential crisis as COVID rages on with no definite end in sight.

This article will be my discourse with myself as I work through the thoughts I have about finding a path forward in the brave new world we live in.

Get yourself something hot to drink. ☕️

Let's talk.

> “In the confusion we stay with each other, happy to be together, speaking without uttering a single word.”
>
> \- Walt Whitman

## Into the Eye of the Storm

As I'm writing this, I _just_ got back from a long run in the winter air of Northern California.

I can feel the chill even after a hot shower. ❄️

I often run on the trails around where I live. It helps me work through my thoughts when I'm feeling frustrated. It helps me get out of my head.

It's been almost two years since COVID overran our world. We were all broadsided with a disease that would postpone marriages, instigate political turmoil, divide families/friends, and cause people we love to pass away.

Like so many others, I've done a lot of quarantining, and it's been years since I've seen some friends who live on opposite sides of the world.

On top of this, the world also started to feel... smaller.

Not "smaller" in that way where you feel close to someone on the other side of the globe, but "smaller" in the way that a box might start closing in around you.

I think many of you have experienced this as well.

We've been riding wave after wave of COVID variants. Two of my childhood friends got it last month, and it knocked them out for weeks. One of them could do nothing more than lie on a couch with a high fever for two weeks straight and proceeded to lose 10 pounds of weight in 9 days.

With these sorts of stories (or worse) everywhere, people have become cautious when it comes to getting out to make new friends and have new experiences.

It seems like we mostly communicate digitally with each other, viewing a wall of content served up on our phones in the silence of our homes.

> 'I wish it need not have happened in my time,' said Frodo.
>
> 'So do I,' said Gandalf, 'and so do all who live to see such times. But that is not for them to decide. All we have to decide is what to do with the time that is given us.'"
>
> \- J.R.R. Tolkien (The Fellowship of The Ring)

## Nobody Makes It Out Alive

Marcus Aurelius, one of the greatest emperors of Rome, kept a diary ([Meditations](https://www.amazon.com/Meditations-New-Translation-Marcus-Aurelius/dp/0812968255/ref=sr_1_1?crid=7OE9FS6HQHQ8&keywords=meditations+by+marcus+aurelius&qid=1643354809&sprefix=meditations+by+mar%2Caps%2C140&sr=8-1)) where he'd write his thoughts, points from the philosophy of [Stoicism](https://en.wikipedia.org/wiki/Stoicism), and encouragement to himself. He never meant it to be read by others (side note - you should definitely try keeping a diary to write stream-of-consciousness thoughts every day).

He once wrote, “You could leave life right now. Let that determine what you do and say and think.”

Think about the weight of that for a second.

It sounded so depressing to me when I first read it. But really, none of us make it out of life on this earth alive. If you accept that as a fact but use it to propel yourself forward towards your goals, the whole world opens up in front of you.

What are you going to do with the time you have here?

Are you going to sit and wait for life to happen to you, or are you going to go _live_?

Ryan Holiday, an author I've been enjoying reading in the pandemic, talks a lot about the concept of "Memento Mori" (or, quite literally, "Remember Death").

Death is not a horrible idea to be avoided at all costs. If you focus on the fact that you are only on this world for a set period of time, you become that much more likely to appreciate (and seek out) the experiences and people around you.

I believe there's never been a more important time to remember this than during COVID.

> "I intend to live life, not just exist."
>
> \- George Takei

## I'm Gonna Live, I'm Alright

When my grandfather was born, he was a hillbilly in rural Ohio. In later years, he would talk about running around barefoot while trapping skunks and squirrels.

At the beginning of college, he participated in the Korean War as a conscientious objector field medic (being the same reasons and religion as [Desmond Doss](https://www.youtube.com/watch?v=s2-1hz1juBI)) and saved the lives of those he came across. He spoke a few times about that as well (which was enough for our family to know he couldn't save everyone he treated).

After surviving a war in which he lost friends, he went to Michigan and decided to make something of himself. He proceeded to get his undergraduate degree and then a PhD.

He also met my grandmother. The story goes that she was working the registration desk at their university when he walked in to sign up for classes. It wasn't very long before they were dating.

Eventually, they decided to move to California where they lived a really great life.

Despite surviving horrific early life experiences, my grandfather persisted and achieved a lot in his life.

## Conclusion

I want to look back and, even if life dealt me a bad hand, be proud of the way that I played it. In order to do this, I'm going to remember that every day could be my last.

I'd encourage you to join me this year in asking to following questions:

**If today was my last day...**

- Am I working on something that's meaningful to me?
- Am I treating the people I care about with respect?
- Am I working towards my goals?
- Am I going out and living life?

If you can answer yes to these questions, I think you can look the future in the face.

Thanks for reading.

Nathan ☕️


Life is what happens when you're busy making other plans.

On Loss


<img alt="Black and white photograph of fisherman" height="912" src="/images/blog/the-pursuit-of-persistence-and-grit/fishermen.webp" width="1368">

# The Pursuit of Persistence and Grit

> This article was written right at a crucial point in my life. I had been unemployed, went through a coding bootcamp, and then got a job less than a year later at Twitter.
>
> I keep it here on my blog because I still very much resonate with its words (and I have a hunch that you might too).

## The Obstacle is the Way

Writing is, almost by definition, a solitary activity. Despite our human need for interaction with others, it’s often in the quiet moments of the day that inspiration comes to us.

That’s how I find myself this evening as I write this article for you. As I sit in front of my computer with a hot cup of tea beside me, I find myself thinking back over the last few months of my life.

Since I wrote my last article, I’ve finished the full stack web development curriculum at Lambda School, completed yet another build week with my classmates, and accepted a position as Section Leader with the school’s incoming Web 19 cohort (the 19th full-time group to go through the curriculum).

I’d be lying if I said it was easy. I’d be lying if I said it was always fun. But has it been worth it?

> “The secret of getting ahead is getting started.”
>
> — Mark Twain

## On Pressure and Diamonds

It’s been said that the secret sauce to finding success in life is to have grit. (It’s [Josh Knell](https://twitter.com/TheBigKnell). He said that.) The ability to grind it out and push through all the mundane, hard, and otherwise tough details of life that turn many others away is often what separates those who reach success from those who don’t.

If you’d have told me a year ago that I’d soon be headed towards a fairly promising career in software development, I wouldn’t have believed you. But 12 months and countless hours of studying later, here I am. It’s funny how much a person can change in a single year. In this span of time, I’ve gone from a business-minded healthcare employee to a code-dreaming, wide-eyed engineer.

<img alt="Black and white image of mountains" height="1067" src="/images/blog/the-pursuit-of-persistence-and-grit/mountains.webp" width="1600">

At Lambda School, one of the core virtues students are taught outside of writing eloquent and excellent code is the ability to persist themselves through any obstacles set in their path. This resolve, when properly seasoned with empathy, allows leaders to be formed. It allows students to walk in the door from any direction and emerge with the confidence and drive to move mountains.

Taking this pressure and turning it into pure diamonds is always up to the individual, but I’m proud to say that I’ve already seen this success story in action countless times from those who surround me here. Lambda School students are landing jobs at prestigious companies and leveraging their grit to bring them and their employers success. It’s not luck, though. You need to know that these students study night and day for these types of opportunities. In case you’re wondering, this can easily mean 7:30am until midnight every weekday including extra time on weekends for 9 months.

But hard is not the same thing as bad, and easy is not the same thing as good. Robert Frost once wrote, “Two roads diverged in a wood, and I — I took the one less traveled by, and that has made all the difference.” I think about those words sometimes while writing lines of code. The hard path is never very well traveled.

> “We choose to go to the Moon in this decade and do the other things, not because they are easy, but because they are hard.”
>
> — President John F. Kennedy

## Hold onto the Fire, Ignite the World

When I started at Lambda, I was told by an alumnus to “Keep the fire alive no matter how weakly or strongly it burns.” (You can find that quote in a [repository](https://github.com/nwthomas/programming-resources) I made of advice from Lambda School graduates.)

My fire was tested in the middle of the last build week at Lambda School. While refactoring server code, implementing application features, and writing tests using time that I honestly did not think I had, I was faced with immense pressure; I would code all day, spend time with my father who landed in the hospital with emergent and serious health issues, and somehow budget my remaining time gearing up to be a solid leader for the largest full stack web development cohort Lambda has ever seen within 72 hours of being hired.

<img alt="Black and white photograph of the Golden Gate Bridge" height="864" src="/images/blog/the-pursuit-of-persistence-and-grit/golden-gate-bridge.webp" width="1296">

It was hard. But do you know what I wanted to do each morning after those long nights? _I wanted to code_. The fire was still there.

There’s a special feeling that comes from pursuing what you love through obstacles in your path. It’s the satisfaction of living life to your full potential and realizing a skill that you might not previously have thought attainable. Lambda School has that feeling in spades, and it’s everywhere I look.

Since I’ve been a section leader, I’ve seen my classmates (who are now my colleagues while working as my 18 project managers/teacher’s assistants) bending over backwards to teach new students how to code. I see a new generation of developers with dreams and goals for their world and their families, and it’s inspiring to me.

## Conclusion

If you’re struggling right now with where you’re at in life, keep your head up; don’t focus on what you can’t control. Instead, bring a laser focus to what really matters to you; If you mess up, don’t stress out too much, but don’t take the easy path if the hard one is what will ultimately make you happy. Thomas Edison supposedly said,“I have not failed. I’ve successfully found 1,000 ways to _not_ make a lightbulb.”

I’ve realized in retrospect that the hard work of learning this content was always worth the price of admission, even when I questioned it. My path hasn’t always been easy, but has it been worth it?

Every single second.

---

Thanks for reading.

Nathan ☕️


Hard things are worth doing. Push through the feeling of wanting to stop.

The Pursuit of Persistence and Grit


<img alt="Black and white photograph of man surfing" height="964" src="/images/blog/the-pursuit-of-personal-fulfillment/man-surfing.webp" width="1450">

# The Pursuit of Personal Fulfillment

> This article was written right before I got my first job in tech.
>
> I keep it here on my blog because I still love what it says (and I have a suspicion that you might too).

## You May Say That I’m a Dreamer

A warm summer breeze is drifting through the window this evening. I’m sitting here staring at a blank electric page, and I’m struck by nostalgia.

It’s been two years (almost to the day) since I lost my job in healthcare. In those two years, I’ve seen friends I hadn’t seen since university, led a healthcare wellness program to a level that was recognized by Forbes, and spent a lot of time searching. The last eight months have been consumed by my time at Lambda School, and the most recent 3 have been as a section lead (which means I manage 160 students and 20 project managers).

As I’m drawing to the end of this role at Lambda, I’ve found myself thinking a lot about what people really want when they say they’re trying to “find their purpose.” Back when I was job hunting pre-Lambda School, I used to put a lot of thought into what I really wanted to do with the rest of my life. It was stressful. How can you find answers when you don’t even know the right questions?

I recently realized that it’s been eight months since I asked myself that. I’ve found something I love, and I’ve stopped thinking about questions like “is this what I’m meant to do?” Could it be that self-fulfillment is something viewed only in the rearview mirror of life instead of being actively pursued as a goal in-and-of-itself?

Grab your coffee, tea, or something good. ☕️

Sit down.

Let’s talk.

> “When I was 5 years old, my mother always told me that happiness was the key to life. When I went to school, they asked me what I wanted to be when I grew up. I wrote down ‘happy.’ They told me I didn’t understand the assignment, and I told them they didn’t understand life.”
>
> ― John Lennon

## It’s All About the Journey 🚗

Before I started my journey into web development and software engineering, I spent a solid six months job hunting and interviewing with lots of startups.

During that time, I started having lots of second thoughts about the direction I was headed. I started wondering the big questions in life like “What makes me happy?” and “Why do dogs love us so much when we basically trap them in our homes, regulate when they get to eat and poop, and only take them on walks a couple times a day?”

Every choice I faced was viewed through my own self-imposed lens of artificial pressure. By trying to “find my purpose,” I was actually telling myself that every choice I made was high-stakes. Everything became important. There was no room to play and be creative. There was no room to make mistakes.

I was miserable.

<img alt="Black and white photograph of waves at the beach" height="933" src="/images/blog/the-pursuit-of-personal-fulfillment/beach.webp" width="1400">

Somewhere along the way, I got it into my head that I wanted to make a personal blog. I didn’t expect anyone else to read it, but I wanted my own corner of the internet to record my thoughts.

When I couldn’t figure out how to customize Wordpress templates, I turned to the Internet to teach me a bit more about CSS and HTML. When I got stuck on animations and JavaScript, I enrolled in [The Odin Project](https://www.theodinproject.com/) out of a passing interest since it was free. When I needed additional coaching, I decided to take a free intro course from [Lambda School](https://www.bloomtech.com/). It couldn’t hurt, right?

At no point in this journey was I focused on web development or software engineering as an eventual career. I didn’t see my passions and hobbies finding their own way and taking on a life of their own. I was so focused on what I thought fulfilled me that I couldn’t see what I actually loved. It wasn’t until my family started pointing out how much I seemed to love writing code that I woke up to what was happening.

Even after that, it took a friend to pull me aside and tell me that “You could totally do this as a career, man” before I decided to step off that ledge into the unknown (credit to my friend [Joseph Cawood](https://www.linkedin.com/in/joseph-cawood-mshi/) for that conversation — He spends every day battling data in Python and R at UC Davis to make this world a better place). I enrolled in Lambda School.

> “If today were the last day of my life, would I want to do what I’m about to do today.”
>
> — Steve Jobs

## A Life Viewed in Reverse ⏮

The world needs more people who take things one day at a time and who focus on what really matters to them. There’s a quote from a Calvin and Hobbes comic where Calvin says, “If people sat outside and looked at the stars each night, I’ll bet they’d live a lot differently.”

Telling yourself that every decision you make needs to lead towards some vague pursuit of a future “purpose” sounds like a terrible way to go through life. Steve Jobs certainly seemed to think so in the quote before this section.

Forcing yourself to plan for what your unknown future self wants is an impossible journey; learning how to find personal value in what you’re doing every day is not. If you would have asked Steve if he thought his life had purpose, I’m absolutely certain he’d have responded with a “Yes.”

Before you say “This is a dumb article, Nate” and egg my house, notice that I’m not saying preparation for the future, setting goals, and planning are bad things. Those are all crucial pieces of the puzzle for anyone who wants to achieve anything great. But there is a certain element of personal reflection needed in order to focus on what both grows you as a person while also pursuing daily value and meaning.

It’s hard to find that elusive feeling of purpose when you’re always looking into the future for the answers. The thing about the future is that it never actually arrives.

<img alt="Man in waves at the ocean" height="927" src="/images/blog/the-pursuit-of-personal-fulfillment/man-in-waves.webp" width="1400">

## Turning up Gold

It’s been said that a major source of dissatisfaction in our lives is the gap between our expectations and reality. When we expect some future where we’ll finally feel complete, we start to feel an intense disconnect and bitterness with how our lives turned out if we never reach it.

Most people focus on their daily grind and see all of life’s imperfections. They see the stressors, and they long for a day when all of those things just magically disappear. This is the mindset that makes most people spend their lives wishing for a future that, quite frankly, will never arrive. As John Lennon sang, “Life is what happens to you while you’re busy making other plans.”

When you focus on your daily fulfillment, you start to sort out all of the fluff that seemed so necessary to you before, and new passions and character qualities in your life that were previously overlooked start surfacing. If this happens to you, I would highly encourage you to pursue them. You never know when one of these loose threads might tug and pull you into a life or a career that’s better than you could have dreamed.

Although I can’t anticipate the future, it’s opportunities, or it’s stressors, I do know that I’m really grateful to be where I’m at. I’m passionate about what I get to do every day, and I find my fulfillment in that.

---

Thanks for reading.

Nathan ☕️


Life is what you make it. Your reality is flexible and will give to your efforts.

The Pursuit of Personal Fulfillment


<img alt="" src="/images/blog/building-a-world-class-oncall-program/fireman.webp" title="" height="669" width="1399">

# Building a World-Class Oncall Program

> Many of the ideas here are taken from my experience (and mistakes) leading the oncall program for Twitter's web app at scale. Please feel free to disagree with this guide in certain places (which is good, as you should always question processes and try to find ways to improve them).
>
> I will tweak the ideas described here throughout my career and use it as the baseline for oncall programs at my future companies.

## Why is Everything on Fire?

If you're taking the time to read this, it probably means that you've been scorched a time or two by the fire of leading or participating in really tough incidents at work.

Perhaps your team has a good oncall program and you're looking to improve it. Perhaps your team doesn't have a dedicated oncall program yet.

Whatever the case, you're here for a reason. I'll make it worth your while.

In 2021, I was put in charge of leading the oncall program for all of [Twitter.com](https://twitter.com), the Twitter web app (a ~30 engineer rotation at the time pulled from a team of ~120). Our engineers were oncall roughly 4 times per year (2 times as primary and 2 times as secondary, something we will discuss shortly).

Our engineers faced regressions from new feature or infra launches, problems caused by internal microservices failures that challenged the partition tolerance of Twitter, natural disasters affecting our data centers, and even wild curveballs like a DDoS attack out of mainland China (which is a story for another time).

Above all, our oncall engineers had to "keep the ship pointed forward in the storm" no matter what so that the web app was available for any of the hundreds of millions of active users every day who wanted to use it.

To say this was stressful for oncall engineers is an understatement.

In the following sections, I'll try to distill insights on how to prevent burnout for oncall engineers, provide good support, educate with proper onboarding, and build a culture that makes sure your team is never caught flat footed during an incident.

Let's get to it. 🔥

## Oncall Philosophy

You might be surprised to see that this first section is more of an abstract discussion about _what_ oncall even is. But some organizations seem to muddle what oncall should be responsible for and what their tasks should be, so this is a good place to start.

As a general rule, your oncall rotation should either be domain- or team-specific. There needs to be clear boundaries between what your oncall engineers are (and are not) responsible for.

Once those rules are established, it's important to make clear that "the buck stops with oncall" when it comes to emergencies. The oncall gets to make the call about if a rollback (deploying a prior version of the code), revert (reverting a problematic pull request), forward fix (deploying with a revert/code fix instead of a rollback), or other action is necessary. The only time this should be overruled is if management or executives want to make a decision on what happens in an incident.

In other words, your primary oncall is the captain in the room in any incident (I'll explain more on the concept of primary and secondary oncalls in a bit). One of the worst feelings as oncall is being responsible for everything (such as getting pages in the middle of the night) but not _really_ being empowered to make final decisions on any of it. It creates a feeling of helplessness and resentment that will weigh on your oncall program like a stone sinking through water.

In addition to leading incidents and making decisions on them, oncall should be responsible for the following tasks:

- Leading _all_ deploys on the team for the week
- Handling pages for the week
- Analyzing health trends on metrics/logging dashboards for the service(s) they're responsible for
- Triaging new errors that are reported by the support team or error monitoring services
- Creating (and working on) tickets for new errors or oncall-related tasks
- Training new oncall engineers who are shadowing the rotation
- Writing all postmortem documents for any incidents they lead

This seems like a lot, and that's because it is. Some of these tasks can be divvied up between primary and secondary oncall roles. What are those, you might ask?

Good question. Let me explain right now.

## Primaries and Secondaries

I've previously said that "the buck stops with oncall." However, what I really meant is that the buck stops with the _primary_ oncall.

If you have a small engineering team (5-6 people), disregard everything that this section has to say (although I'll have a lot more to talk about with scope versus number of rotations soon). If this is you, your rotation is already so small that having a staggered primary/secondary oncall program would _increase_ engineer burnout.

If that's you, go ahead and skip to the next section.

Okay. If you're still here, that means you should build two rotations on your team. Each rotation will have the same engineers in it, but their shifts should be staggered (so that an engineer is primary oncall and then secondary something like half a month later).

The primary oncall should get pages first, lead incidents, be point on training new oncall, and just generally be the one in charge of oncall for the entire week.

Secondary oncall should be back up (both with pages if primary misses them as well as with covering oncall if the primary has to be out). You can also choose to divide tasks like writing postmortem documents, traiging some errors, and other lower priority tasks to the secondary oncall.

Primaries should be expected to be within 15 minutes of their computer at _all times_ in case they receive a page. Missing a page should be a big deal (and multiple instances of it should be brought up by the manager). As I've said, the buck stops with oncall. This is true of authority as well as responsibility.

Secondaries should be within 15-30 minutes of their latop (unless they let their primary know they'll be out) in case something happens and a page gets escalated to them.

You should find some service that can page the oncall engineers. [PagerDuty](https://www.pagerduty.com/) is popular at time of writing, but it can be expensive - there are other services out there like it, though. These apps should be given override ability on the engineers' phones so oncall engineers _know_ when a problem is going down and they're being paged.

No matter what you do, these pages (which can come at any time of the day or night) _will_ wear on your oncall engineers. That's why you have to be very rigorous about the way you put together a schedule for your oncall program.

## Building a Good Schedule

As I mentioned above, you should make every attempt to place your engineers into a staggered primary/secondary schedule.

Let's dig into this scheduling process a bit more.

Oncall shifts should run 24/7 for a week straight. The specifics (like start and stop days/times) can be between you and your team. If you have enough engineers distributed across the globe, you could also experiment with having some engineers cover while others are asleep.

In an _ideal_ world, your oncall rotations should be a minimum of 8 people and a maximum of around 25. The reason for this is simple - 8 engineers equals people having a primary oncall shift of once every 2 months and 25 engineers is a primary oncall shift around twice a year.

Any less than 8 engineers and you'll run a _big_ risk of burning your oncall engineers out from being oncall all the time (and believe me, feeling like the world is on your shoulders multiple times a month is not fun); any more than 25 and you run the risk of having your engineers forget _how_ to perform their oncall duties (although this can be mitigated with a strong secondary rotation where the secondary oncall engineer actually performs some duties - more on this soon).

Engineers who perform their primary oncall rotation duties should have a week or two off (at minimum) before they do their secondary oncall shift. Having someone oncall for two weeks in a row (primary and then secondary) where they're tied down to their laptop is fairly cruel. This can (rightfully) lead to anger, frustration, and even turnover if it continues despite complaints.

Add new engineers to the rotation at least several months out and give the entire team a heads up publicly when you do it. This helps mitigate problems with the schedule shifting. You don't want an enginer to find coverage for their shift only to have it shift around multiple times. When you update the schedule, tell people to review their future shifts _immediately_ and to let you know if their newly scheduled times (almost a quarter out) don't work. In this instance, the right thing to do is for you to be the one to find them coverage.

Speaking of finding coverage on your schedule, oncall engineers should be responsible at all _other_ times when they need swaps for weeks they can't work their oncall shifts. It should be a big deal if someone goes out on vacation and misses getting coverage for their shift.

The final piece of this scheduling puzzle is to do with trainings; you should make a third (and rarely-used) rotation for shadowing engineers. This component needs its own section (further below), so I'll end this one by saying that no team is complete unless people consider themselves simultaneously teachers and learners.

## More Scope or More Rotations

Before we get into a discussion of training your team, I'd like to momentarily discuss the tension with oncall schedules between being oncall for more scope and being oncall more frequently.

If you choose more scope, you'll be able to have a large roster of engineers who will be oncall less frequently. This would be on the high end of the roster size (>= 25 people) that I mentioned earlier and would equate to less oncall burnout and engineers not being tied down to their laptops 24/7 a lot of weeks every year (which can build frustration). However, the cons to this approach are that engineers may complain they're losing knowledge on how to properly perform their oncall duties given the large gap in between rotations (which is something that happened to my oncall team at Twitter).

In contrast, having a smaller rotation with much less scope will mean that your engineers get intimately familiar with the subject matter area they're responsible for and run no risk of forgetting it. They will also experience less stress from being responsible for covering a smaller domain while oncall. The main con for this approach is that your engineers will also be oncall more often; this could lead to burnout and prevent them from taking vacations or decompressing when needed from their normal (non-oncall) work.

You should avoid having _both_ large scope and frequent oncall as this is the worst of both worlds (although you may be forced into it - small startups and big corporations will have to make very different trade-offs here).

It's important to note that you will **never** reach perfection in this area. You will have people on your team who want more oncall shifts with reduced scope and people who would rather have less shifts and more scope. The key is to pick a direction and stick strongly to it.

On top of all of this, you may build up your rotation only to have some unexpected turnover that momentarily decreases the size of your rotation no matter what you did.

Perfection is not possible; instead, focus on the moving target I just described and do your best to design your rotation (more scope, more rotations, etc.) for what the _current_ needs of your company dictate.

The important part is to pick a direction with your team and stick to it (at least until it becomes obvious a change is needed).

## How to Train Your Team

I've previously mentioned that you should create a "shadow" rotation. Let's expound on that (and other training processes) right now.

I would recommend not adding an engineer to your oncall rotation unless they have met the following qualifications (roughly):

- They are a senior (or higher) engineer and have been on the team for >= 3 months
- They are a junior/mid-level engineer and have been on the team for >= 6 months

This allows these new team members to get used to the codebase, the way your architecture is set up, and the organization itself. However (and as I've mentioned all along), this will need to be shorter if your team is quite small.

Once you've deemed an engineer ready to go into the rotation, you should either meet with them in person/over video chat or have some training materials ready for them that do the following:

1. Give a breakdown of the philosophy of oncall at your company
2. Describe what primary and secondary oncall are at your company
3. Describe what the tasks are for engineers while they're oncall (and the breakdowns for primary/secondary)

The engineer should then immediately go into the shadow rotation. You should link them up with the primary engineers for the weeks they will be shadowing and make introductions (if they don't already know each other).

I would recommend you put your new oncall engineer through 2 weeks of the shadow rotation. In the first week, they should merely shadow and be a fly on the wall in all incidents, investigations, deploys, rollbacks, and anything else the primary engineer does.

In the second week of shadowing, you should flip the schedule so the shadowing engineer is "primary" from 9 AM to 5 PM their local time. They should receive all pages and otherwise function as a primary engineer, but they should have the _full_ support of the training engineer (the "real" primay engineer) in case they have questions. You will need to temporarily modify the paging schedule for this week so the shadowing engineer receives pages during 9 AM to 5 PM their local time.

Once an engineer has completed this training, you should view them as ready to go into the full rotation. Place them in the primary and secondary schedules while respecting the issues with adjusting a schedule that I mentioned previously.

## The Art of Redirecting Lightning

As you bring on new engineers, it will become more-and-more important to have a culture where oncall engineers are properly supported by their team.

In the TV show [Avatar: The Last Airbender](https://en.wikipedia.org/wiki/Avatar:_The_Last_Airbender), there is a great character named Uncle Iroh. One of the surprising skills he reveals during the show is that he can redirect lightning that is fired at him.

<img alt="Uncle Iroh from the 'Avatar: The Last Airbender' cartoon series bending lightning to his will" height="289" src="/images/blog/building-a-world-class-oncall-program/iroh-lightning.gif" width="370">

Your team should view the oncall engineers (and particularly the primary oncall for each week) as mainly responsible for redirecting lightning in times of crisis. This means that they need to find the right fix, the right people to work on it, and the right short-term mitigation techniques for an issue (which may be a rollback, quick patch, revert of code, etc.). The buck does stop with oncall, but the team needs to be ready to chip in when required.

In other words, work hard to develop a team mentality of "it's good to help oncall."

If oncall is stumped (since no one can possibly know _everything_ about this field) on a high priority issue they got a page about, it may warrant manually paging in _other_ key team members for fixing the problem (such as with a page in the middle of the night when no one else is online yet). You should advise your oncall engineers in their runbooks and oncall training that this should only be used under **extreme** circumstances (more on runbooks in just a second).

However, oncall should always be able to pull in whatever resources they need to get a job done (depending on the severity of the problem). If the ship is headed in the wrong way and it's high priority, oncall should be able to ask for (and should get) the help they need in order to right the course.

## Constructing Runbooks

Everybody forgets things, so it's **crucial** to develop great runbooks that are easy to flip through in the heat of the moment. These will be useful for both new engineers and also oncall veterans who may not have had a shift in a while.

It's also important to note here that these runbooks should never be self-hosted. You should use [Google docs](https://www.google.com/docs/about), [Notion](https://www.notion.so), or some other provider for them. The reason here is simple - the last thing you want in the middle of a very high severity incident (such as the entire company architecture being down) is for the runbooks to be down as well because you decided to run this documentation off the same servers.

In addition, these runbooks should be designed for speed. They should be written by recognizing they might be flipped through under times of extreme stress. The last thing an oncall needs during a crucial incident is to feel like they're combing the secret dusty vaults of a lost civilization while trying to decipher what previous engineers wrote down.

I would advise that your runbooks should include (at a minimum):

- How to deploy builds
- How to rollback builds
- If the team uses a GUI for the above, a guide on _manual_ processes via CLI for them
- General oncall processes (such as what we've been discussing in this article)
- A breakdown of company structure (which other teams/oncalls are responsible for what parts of the company's architecture)
- How to use your paging system (and how to perform manual pages)
- How to schedule a postmortem (assuming your team does them for [SOC II compliance](https://secureframe.com/hub/soc-2/what-is-soc-2))
- How to create a postmortem document for incidents and what to do with it

Try to keep a flattened layout structure for this documentation, and try to favor a bigger initial main table of contents over lots of pages with nested sub-categories (which is harder to search in the heat of the moment).

As time goes on, you and your oncall team will need to reevaluate these runbooks in order to add new ones, update old ones, and keep an FAQ of edge cases that occur for your oncall program.

In any case, please make sure to empower your oncall engineers to make active modifications to these runbooks when _they_ deem it necessary. Your team should view these as living documents; if you take it entirely on yourself (or a specific static group) to be the gatekeepers of periodically updating this documentation, you will almost certainly find them frequently falling out of use by oncall because the information in them is stale.

There is a lot more I could say here about runbooks, but most of it would be wasted. Anything worth talking about from this point forward will revolve around your company's specific needs, culture, and codebase. Just follow the north star of making documentation quick, informative, and easy to parse through for your oncall engineers, and your runbooks will likely be quite useful.

## Conclusion

You should take everything we just discussed in this article as a **foundation** to start your own oncall program.

Over time, you'll come up with new best practices of your own. When that happens, I hope you'll get back in touch with me so I can learn too.

As always, thanks for reading.

Nathan ☕️


With careful preparation, you can build a best-in-class software engineering oncall program with great training, runbooks, and prepared engineers.

Building a World-Class Oncall Program

This is a talk my friend and I gave at Shopify of some unique features in React Native Web that are useful for the Twitter web app.

React Native Web at Twitter


<img alt="Typescript log on a white wall background" height="700" src="/images/blog/how-to-become-a-typescript-badass/typescript-on-wall.webp" width="1050">

# Becoming a TypeScript Badass

> TypeScript fundamentally shifted the way I think about JavaScript and paved the way for me to learn other strongly-typed languages.
>
> Every hour you spend learning it will pay dividends down the road. I've even been known to say that "TypeScript is my love language."

## Why TypeScript?

If you're a member of the JavaScript community, you have likely at least heard about the new(ish) popular kid on the block - [TypeScript](https://www.typescriptlang.org/).

When I was learning JavaScript several years ago, I distinctly remember thinking, "Why would I ever need to strongly type out JavaScript? That sounds like a lot of extra work, and I already know what my JavaScript types are doing."

Don't be like past Nate.

If you invest some time up-front into learning TypeScript, you'll discover that typing out your JavaScript prevents errors in your code and saves you from being angrily strangled by your coworkers (also, it's becoming an in-demand job skill for engineers).

Let's hop into some code so you can learn for yourself why TypeScript is so awesome. By the end of this article, you'll know how to setup TypeScript, work with the basic (and some complex) types, and why you should explore this world even more.

Let's begin. 🎉

> “Hustle beats talent when talent doesn’t hustle”
>
> – Ross Simmonds

## Firing Up TypeScript

The first thing we're going to do is go ahead and install TypeScript on your machine by running this commend in your terminal:

```bash
npm install -g typescript
```

After that, the next thing you need to do is clone down a [repository](https://github.com/nwthomas/typescript-article-code) I've made for you to practice the rest of the code in this article.

After that, open up the repo in your text editor or Integrated Development Environment (IDE) of choice.

I've created a `solution` folder for you in that repo that you can peak into if you get stuck at any step of the way. Try not to look in it though, because it's a lot more fun to write out the code yourself. Do your work in the `problem` folder. I've made files there in advance that you can fill out as we go through the article.

What I want you to do first is to `cd` into the `problem/initial-setup` folder. Go ahead and open up the file inside called `initialSetup.ts`.

Next, I want you to write a `console.log` inside this file that prints out some string. It can be anything you want. Make it something fun.

Finally, in your terminal (which should still be "inside" the `problem/initial-setup` directory), run this command:

```bash
tsc initialSetup.ts
```

Notice how, after just one second, a file called initialSetup.js appears alongside your TypeScript file in the directory?

You just transpiled your first TypeScript file to JavaScript. 🎉

This is how you can do things like write server code in TypeScript and have it run in production as JavaScript.

Congrats. In ~5 minutes, you've gone from not knowing anything about TypeScript to having it installed and knowing how to transpile it into JavaScript.

I'm going to grab a snack from the fridge to celebrate. You should too. 🍪

> “Courage is the most important of all the virtues because without courage, you can't practice any other virtue consistently.”
>
> – Maya Angelou

## Learning the Basics

Now that we now how to transpile code into JavaScript, we can start digging into syntax.

First, let's go ahead and open up the file inside `problem/types` called `simpleDataTypes.ts`.

The first thing you need to know about types in TypeScript is how to type out JavaScript's 5 basic primitives (excluding `symbols`, the 6th type, which we won't be talking about in this article since they are rarely used by most developers):

1. `boolean`
2. `string`
3. `number`
4. `undefined`
5. `null`

Note that the TypeScript type `any` can be used when you want to accept any value (although this is not good practice since it defeats the whole point of using types).

Go ahead and write out the following in your `simpleDataTypes.ts` file:

```typescript
const exampleNumber: string = 100;
```

This new syntax, specifically the colon `:` and the `string` word, are ways of telling TypeScript what the variable is supposed to be. It's supposed to be a `string`.

However, there's a problem here. 😞 You probably already noticed it.

Since we assigned a `number` type (`100`) to a variable that's supposed to be of type `string`, TypeScript is unhappy. You should get an error that looks very close to this:

<img alt="VS Code screenshot of TypeScript error" height="224" src="/images/blog/how-to-become-a-typescript-badass/vscode-typescript-error.jpg" title="(Sorry for the junky screenshot)" width="1046">

This is what it looks like when TypeScript is trying to tell us that we're doing something dumb, like [tucking a caffe latte under our shirt](https://www.youtube.com/watch?v=TysjNDTWEBc).

Go ahead and change that `string` type to use `number`:

```typescript
const exampleNumber: number = 100;
```

Notice how the error clears up right away?

This is the benefit of TypeScript - Immediate, precise feedback on your types. This might not seem like such an advantage in a small file with one line of code. In fact, this might even seem like it's a little annoying to have to write.

But just imagine how nice this type checking might be in a massive codebase when dozens of people are working on the same code. 😰

What if you could ensure that other developers would have an error if they tried to accidentally assign the wrong type to a variable imported from a different area of the application? That's exactly where the power of TypeScript comes in.

Let's go ahead and try out a few more types.

Write the following lines of code in your `simpleDataTypes.ts` file:

```typescript
const exampleString: string = "Test";

const exampleBoolean: boolean = true;

const exampleNull: null = null;

const exampleUndefined: undefined = undefined;

const exampleVoid: void = null;
```

These nicely demonstrate the remaining primitive types that you might use in JavaScript.

However, the really cool next step is that we don't _always_ have to define the types of our variables. If it's a primitive value, we can actually just leave them off if we want. TypeScript will _infer_ it from the assigned value.

Here's the same code with TypeScript inferring the type from the assigned initial value:

```typescript
const exampleNumberTwo = 100;

const exampleStringTwo = "Test";

const exampleBooleanTwo = true;

const exampleNullTwo = null;

const exampleUndefinedTwo = undefined;

const exampleVoidTwo = undefined;
```

The obvious next question is, "Why would we ever use types on a variable if TypeScript can just infer them?"

I'm glad you asked.

First, sometimes you'll want to declare a variable before you assign it a value (e.g. like `let value: string;`). Adding the type when the variable is defined will explicitly set it for the future even if an initial value hasn't been added yet.

Second, stating specific types allows us to type out more complex data types (like objects and arrays). Let's go ahead and take a look at that in the next section.

Now's a great time to refill that nice beverage you've been sipping on. ☕️

> “Success is stumbling from failure to failure with no loss of enthusiasm.”
>
> \- Winston Churchill

## Objects, Arrays, and TypeScript

Now that we know how the primitive data types get typed out in TypeScript (that was a very repetitive line to write out), it's time to learn how to set up typing for some more complex scenarios (like objects and arrays).

The first thing you need to know is that TypeScript has something called an interface, and you can use it to define objects. It is, in fact, a "keyword" restricted to that purpose. If that doesn't make sense, it will in just a second.

Go ahead and open up the file called `complexDataTypes.ts` in the `types` folder for the next few examples.

For instance, suppose you have a function like this:

```typescript
function printLabel(labeledObj: { label: string }) {
  console.log(labeledObj.label);
}
```

Notice how we have a parameter (`labeledObj`) and we've defined a type on it inside the parentheses? That's how we can type out an object!

While this will run as valid TypeScript, having the type inside the parentheses looks a little messy. Let's try to clean up the typing by doing this:

```typescript
interface LabeledObjWithInterfaceKeyword {
  label: string;
}

function printLabelWithInterfaceKeyword(
  labeledObj: LabeledObjWithInterfaceKeyword
) {
  console.log(labeledObj.label);
}
```

We've just abstracted the parameter's type out into it's own "thing," the interface called `LabeledValue` defined above the function `printLabel`. We then assign that interface as the type of the parameter with the `labeledObj: LabeledValue`.

We can then easily add more key-value pairs to this object like so:

```typescript
interface LabeledObjWithInterfaceKeyword {
  label: string;
  value: number;
}

function printLabelWithInterfaceKeyword(
  labeledObj: LabeledObjWithInterfaceKeyword
) {
  console.log(labeledObj.label, labeledObj.value);
}
```

In addition to using the `interface` keyword, the second way that we can type an object is through the `type` keyword.

Here's an example of the same code above but using `type`:

```typescript
type LabeledObjWithTypeKeyword = {
  label: string;
  value: number;
};

function printLabelWithTypeKeyword(labeledObj: LabeledObjWithTypeKeyword) {
  console.log(labeledObj.label, labeledObj.value);
}
```

It's almost exactly the same because it's an [alias](<https://en.wikipedia.org/wiki/Aliasing_(computing)>) of `interface`. There are some subtle differences between `type` and `interface` (like not being able to use [merging interfaces](https://www.typescriptlang.org/docs/handbook/declaration-merging.html) with the `type` keyword), but they really aren't relevant to our discussion today and will honestly be too confusing.

Don't worry about them.

For now, choose one that you like (I'd recommend `interface` if you're on the fence) and roll with it. 👍🏻

Finally, let's briefly look through the two ways that you can define arrays in TypeScript. They're both quite straightforward, and it's again down to your preference on which one you should use:

```typescript
// First way of typing out arrays
const arrayOfNumbers1: number[] = [1, 2, 3, 4, 5];

// Second way of typing out arrays
const arrayOfNumbers2: Array<number> = [1, 2, 3, 4, 5];
```

Note that the second way is probably cleaner if you want to designate that it's something more complex like an array of objects:

```typescript
// Object type
interface ExampleObject {
  label: string;
  value: number;
}

// Array of object types
const arrayOfExampleObjects: Array<ExampleObject> = [
  { label: "label1", value: 1 },
  { label: "label2", value: 2 },
  { label: "label3", value: 3 },
];
```

As you can see, we've already reached a nice point where we've built up to some interesting type combinations. Let's take it one step further with typing out classes.

Go ahead and refill that delicious drink you made earlier.

We're going into the home stretch. ✌🏻

<img alt="White wall with ivy to the left side of it" height="667" src="/images/blog/how-to-become-a-typescript-badass/ivy-wall.webp" width="1000">

## Classes: Complex and Beautiful

The last thing we're going to do is learn the fundamentals of working with classes in TypeScript. Then, I'll leave you with a bunch of resources that you can use to continue your journey.

I want you to go ahead and go into the `classes` folder and open up the `classes.ts` file. Then, create a `class` and `interface` that look like this:

```typescript
interface Movie {
  year: number;
  name: string;
}

class Movie {
  year: number;
  name: string;

  constructor(movie: Movie) {
    this.year = movie.year;
    this.name = movie.name;
  }

  getMovieYear() {
    return this.name + " was made in " + this.year;
  }
}
```

There's a few things to notice here. First, we have two class variables called `year` and `name` inside our `Movie` class that we've defined as `number` and `string` types. Second, we have an `interface` that defines the object type that the class' constructor function is taking in, and we are then assigning values from inside that object to the class' variables.

Finally, we have a new method that uses both of these class variables to return a string.

Can you see how everything you've learned so far about TypeScript meshes nicely into the existing class syntax in JavaScript?

Go ahead and try running the command `tsc classes.ts` in this folder to transpile this file. When the `classes.js` file is created, take a look in the file to see what this class transpiles to in JavaScript. 👍🏻

We can use TypeScript's type definitions on our class variables and parameters in the constructor and methods, ensuring that we always know types they will be expecting and using.

You can find out more about classes and how they relate to TypeScript by reading up on them [here](https://www.typescriptlang.org/docs/handbook/classes.html).

> "Beautiful things don’t ask for attention."
>
> \- Unknown

## Other Resources

There's lots of interesting things in TypeScript that we haven't discussed yet in this article. It was meant to give you a quick intro, but this is where the real fun begins for you.

For instance, have you been wondering what that mysterious little `tsconfig.json` file is in the repo you've been working in for this article?

Well, you can now jump in feet-first into TypeScript's powerful and passionate community to learn about customizing that file and much more.

While there are limitless resources out there on Google, here are three interesting points to start the rest of your journey into a statically-typed future:

1. [TypeScript Docs](https://www.typescriptlang.org/) - The official documentation on TypeScript is excellent and will save your butt if you use it
2. [TS-Node](https://github.com/TypeStrong/ts-node) - This runs a development server and can auto-transpile on save for you
3. [Deno](https://deno.land/) - A new JavaScript and TypeScript runtime that's a competitor for Node.js (in other words, no transpilation needed like we've been doing in this article

## Conclusion

I hope you’ve enjoyed this article on using TypeScript. It's such powerful tool that will supercharge your development process (especially if you're working with others).

Best of luck.

Thanks for reading.

Nathan ☕️


Have you always wanted to learn how to master TypeScript? In that case, this one is for you.

Becoming a TypeScript Badass


<img alt="Neon 'Hello' sign on a black background" src="/images/blog/debounce-versus-throttle/stoplight.webp" width="1499" height="1000">

# Debounce Versus Throttle

> I wrote this article because debounce and throttle are super hard to keep straight and visualize in your head. I hope this will help you in your learning journey.

## Introduction

Back when I was trying to learn the difference between what a `debounce` function (like this one from [lodash](https://lodash.com/docs/4.17.15#debounce)) and `throttle` function were (again, here's one from [lodash](https://lodash.com/docs/4.17.15#throttle)), it turned out to be annoying to find materials that were crystal clear on _exactly_ how they functioned.

I decided to write an article to correct that for you so you don't suffer the same fate! 😌

The main source of confusion is that, at face value, the two of them seem to behave a bit the same. If you're here reading this, I'm sure you've noticed the same thing.

What we're going to do is take them one at a time and walk through some **real** code examples that will show you exactly what they do (and how they're different).

By the end, you'll be a pro.

Sound good?

Nice. If you want to follow along with live code, check out [this CodeSandbox link](https://codesandbox.io/p/sandbox/debounce-versus-throttle-sandbox-ltxep3?file=%2Fsrc%2Findex.ts&selection=%5B%7B%22endColumn%22%3A1%2C%22endLineNumber%22%3A11%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A11%7D%5D).

Let's get started.

## Debounce

At it's core, `debounce` is a process for calling a function _exactly_ once for any group of calls (the term `debounce` was [coined by John Hann](http://unscriptable.com/2009/03/20/debouncing-javascript-methods/)).

A `debounce` function is often used when a user does a _lot_ of some sort of action and we only want to act on that when they've finished; a good example of this might be when a user is entering in text into a search input. We don't want to do a search each time they type a character, so we wait until they're done typing before firing off a request for data.

Here's a nifty little diagram that might explain this concept:

<img alt="A cluster of function calls with the words 'Function is repeatedly called' over if with a 250ms wait and then a box symbolizing a funciton call that says 'When the function actually runs'" src="/images/blog/debounce-versus-throttle/debounce.webp" width="852" height="639">

For instance, let's say we have this simplified `debounce` function written in TypeScript:

```typescript
const TIMEOUT_MS = 250;

function debounce(callback: (...args: unknown[]) => unknown) {
  let timeoutId: ReturnType<typeof setTimeout> | null = null;

  return (...args: unknown[]) => {
    if (timeoutId) {
      clearTimeout(timeoutId);
    }

    timeoutId = setTimeout(() => callback(...args), TIMEOUT_MS);
  };
}
```

I know, that's a lot to digest. But we're going to walk through it together.

First off, we've defined a variable called `TIMEOUT_MS`. A `debounce` (and also `throttle`) function you'd actually use in a real app would typically allow you to set your _own_ timeout, but we're just hard-coding it here to make things easier. 👍🏻

Next, we have our very own custom `debounce` function. For its parameter, notice that it takes in a `callback` function. We don't know what this function will be, so we've defined it to take in any number of `args` of `unknown` type and returns an `unknown` type (we might want to change this for a production application, but it works for us here):

```typescript
function debounce(callback: (...args: unknown[]) => unknown) {
  // ... code goes here
}
```

This code has more to do with TypeScript than learning about our `debounce` function, so let's move on (although you can read more about TypeScript [here](https://www.nathanthomas.dev/blog/becoming-a-typescript-badass)).

This `callback` function we're taking in as a function parameter is what we're going to `debounce`! Nice, right?

Next, we have this line of code which will track a `timeoutId`:

```typescript
let timeoutId: ReturnType<typeof setTimeout> | null = null;
```

Don't get too hung up by the TypeScript types here. All this is doing is declaring a `timeoutId` variable, saying it can either by the type of the returned value of a `setTimeout` call (which returns a `number` ID for the timeout) or `null`, and then we initialize the variable to `null`.

The next thing we're going to do is return a function with the guts of our logic:

```typescript
return (...args: unknown[]) => {
  // If we've previously set a timeoutId, that means we've called
  // this function within the timeout time limit
  if (timeoutId) {
    clearTimeout(timeoutId);
  }

  // Whether or not we clear the timeoutId above, set new timeout
  timeoutId = setTimeout(() => callback(...args), TIMEOUT_MS);
};
```

The first thing it's doing is checking if `timeoutId` is truthy (e.g. not `null`, which was its initial value). If it is, that means our `debounce` has previously been called. We will go ahead and clear the `timeoutId` for reasons that will become apparent in the next few sentences.

Next, we want to call `setTimeout` and assign the return value to `timeoutId`. This `setTimeout` will call `callback` whenever it gets a chance to time out (which should happen after `250` milliseconds which we set earlier as `TIMEOUT_MS`).

_Whew_.

This was a lot.

The TLDR for the code above is that we're clearing our previously-set timeout each time we call our `debounce`-ed function. If we go long enough (`250` milliseconds) without a call to our `debounce-ed` function, we'll finally get a chance to call our `callback` function.

Let's walk through an example of it being used.

First, let's go ahead and set up our `debounce` function:

```typescript
const handleDebouncedLog = debounce(() => console.log("Hello World!"));
```

This passes in a `callback` function into `debounce` and returns an anonymous arrow function as we saw before.

From here, we can write a quick loop to run 100 times and call our `handleDebouncedLog` function each time:

```typescript
for (let i = 0; i < 100; i++) {
  handleDebouncedLog();
}
```

If we were to check the dev console, we'd see _exactly_ one log of "Hello World!" when this code was done running.

This is because we don't allow our timeout to finish when we quickly and repeatedly call our `debounce`-ed function. Each time it's called, it's clearing out the previous `timeoutId` and then setting a new one. It's only allowed to finish at the end when our `250` millisecond `TIMEOUT_MS` time runs out.

Make sense? Nice.

Let's move on to `throttle`.

## Throttle

I have good news for you! If you were able to make it through the `debounce` section with your sanity intact, you're home free.

The `throttle` function is, by comparison, really easy to grasp. This is because `throttle` merely calls a `callback` function _exactly_ once within a time span (which we'll set using our `TIMEOUT_MS` variable).

If that sounds the same as `debounce`, well... hang with me. Let's discuss it.

A `throttle` fuction is basically saying to a `callback` function it's given, "Hey. You're doing too much. Let's just dial that activity back to one function call every **X** amount of time to tone things down a little bit."

Does that make sense?

Another way of thinking about it is that using `throttle` is like a stoplight that only lets a single car through for every **X** amount of time (even if there are thousands of cars that tried to get through the intersection at the same time).

A picture is worth a thousand words, so here's another one:

<img alt="A cluster of function calls where the function is only allowed to actually run once within the timeout time" src="/images/blog/debounce-versus-throttle/throttle.webp" width="932" height="419">

And, right on schedule, here's a simplified TypeScript example of one of these bad boys:

```typescript
const TIMEOUT_MS = 10;

function throttle(callback: (...args: unknown[]) => unknown) {
  let timeoutId: ReturnType<typeof setTimeout> | null = null;

  return (...args: unknown[]) => {
    if (timeoutId) {
      return;
    }

    timeoutId = setTimeout(() => {
      callback(...args);
      timeoutId = null;
    }, TIMEOUT_MS);
  };
}
```

The first part of this function is set up exactly like before (our `TIMEOUT_MS` variable, `callback` function parameter, and `timeoutId` variable). We'll skip over those.

I've hard-coded the timeout milliseconds to be `10` this time. That's to reflect the fact that `throttle` is often used to juuuust barely take the edge off some user-initiated action (like moving a mouse or typing into an input) which we want to not run as often.

However, this is where our `throttle` differs from `debounce`. We just return early if we have a `timeoutId` set already inside the anonymous arrow function that we're creating and returning:

```typescript
return (...args: unknown[]) => {
  // This ensures we return if we've previously called the
  // function to kick off the timeout
  if (timeoutId) {
    return;
  }

  // Else, we set the timout which will eventually call our
  // callback and reset timeoutId to null
  timeoutId = setTimeout(() => {
    callback(...args);
    timeoutId = null;
  }, TIMEOUT_MS);
};
```

Wait. What? 🤨

I know. It seems a bit off. But what we're essentially doing is building a function that will set a timeout and save a `timeoutId` the first time it runs. Thereafter (until the timeout finishes `10` milliseconds later and calls the `callback`), any further attempts to call our `throttle`-ed function will merely return and not run.

This works like a charm, and it means that we are guaranteed that our `throttle`-ed function will only be called once per `TIMEOUT_MS`.

Once again, let's walk through a quick example of this code in action. First, we create our `throttle`-ed function:

```typescript
const handleThrottledLogger = throttle(() => console.log("Hello World!"));
```

Next, we're going to write a funky little loop that will call this function `20` times.

```typescript
for (let i = 0; i < 20; i++) {
  setTimeout(() => {
    handleThrottledLogger();
  }, i);
}
```

All this is doing is staggering our calls by `i` milliseconds. We're setting `20` timeouts here (each one staggered by `1` millisecond so they run one after another).

If we were to run this code and check our dev console, we'd see exactly `2` logs of `"Hello World!"`. Can you think of why?

That's right! It's our `throttle` function in action. We're only allowing one function call to get through once every `2` milliseconds.

This is exactly how a `throttle`-ed functions works. It drastically decreases the rate at which the `callback` function inside it can be called.

## Conclusion

Now that you have a great idea of the difference between `debounce` and `throttle`, you can go one step further.

What happens if you want the function call at the _end_ of your `throttle`-ed function to run instead of the _start_ (called the "trailing edge" call rather than the "leading edge" which is what this article talked you through)?

What happens if you're `debounce`-ing a function for user input on a search bar and you want the eventual function call to run with the _newest_ data from the _last_ function call (again, "trailing edge" versus "leading edge")?

These are all possible with code, and I have a sneaking supicion that you'll be able to implement them now!

In any case, I hope this article helped you grasp the differences between these two types of functions.

As always, thanks for reading my articles.

Nathan ☕️


While they might seem the same, debounce and throttle actually have different use cases. Let's learn what they are!

Debounce Versus Throttle


<img alt="A series of backpacks in different colors and stacked together" src="/images/blog/understanding-closures/backpacks.webp" width="1312" height="877">

# Understanding Closures

> Closures can feel really tough, but they're extremely useful and relatively straightforward once they "click."
>
> I hope this article helps you understand as much as it did when I wrote it.

## Starting From the Outside In

Explaining closures is a frequently-used JavaScript and TypeScript interview question, but many engineers still don’t fully understand how they work. There’s a fog that surrounds it, much like the feeling you get when you eat too much during the holidays. 🥧

When I first started learning closures, my first impulse was to close my laptop screen and go stare existentially at the local pond. But don’t worry; closures trip up a lot of people, but you’ll understand how they work and the concepts behind them by the end of this article.

I’m going to walk you through a really cool (and more importantly, simple) example. You'll get it in no time at all.

Grab your favorite coffee, apple cider, hot chocolate, or wintery beverage, and let’s get started. ☕️

> "I'll use any excuse to buy a new backpack."
>
> \- Michael Potts

## Grab Your Backpack

Closures are an interesting concept. They are truly invisible in your code, and yet they are very real. If you've written any JavaScript or TypeScript, you've almost certainly used them without even realizing it.

If nothing else, that should give you comfort; if you're already accidentally using them successfully, half the battle will just be learning the ideas behind them to fill in the gaps of how they work.

At a very base level, a closure is an invisible compartmentalization of variables that are accessible to your code at various levels (e.g. the global scope, local function scope, etc.).

Each time you write a function, a closure is created for the scope available to it. Our compiler does this automatically, so all we need to do is understand it.

For instance, let's say we have the following code:

```typescript
const globalVariable = 1;

function createClosure() {
  const localVariable = 2;

  return function () {
    return globalVariable + localVariable;
  };
}

const closure = createClosure();

console.log(closure()); // returns 3
```

This code will log the number `3` to the console. Multiple scopes have been created for your code behind the scenes; there is a global scope with the `globalVariable` in it and local scopes with the `localVariable` and `globalVariable` accessible in them.

Here's the same code with comments included to indicate which parts are global and local scopes:

```typescript
// global scope with globalVariable available
const globalVariable = 1;

function createClosure() {
  // local scope with localVariable and globalVariable available
  const localVariable = 2;

  return function () {
    // local scope with localVariable and globalVariable available
    return globalVariable + localVariable;
  };
}

const closure = createClosure();

console.log(closure()); // returns 3
```

Stop and think about what's happening here for a moment; the `createClosure` function can access both variables.

What if I told you that this ability of closures to access all variables in scope at time of the function's creation could be used later when the function is used elsewhere, even another file?

I know. Has science gone too far?

Let's find out. 🧪

> “A good traveler has no fixed plans and is not intent on arriving."
>
> \- Lao Tzu

## Counting with Closures

Here's the code we're going to be working through for the rest of the article. Go ahead and read through it. 👍🏻

Don't worry if you don't understand how it relates to closures yet. Just get an idea of what code is actually doing:

```typescript
function createCountingClosure(startingNum) {
  if (typeof startingNum !== "number") {
    return null;
  }

  let num = startingNum;

  function increment() {
    num++;
    return num;
  }

  function decrement() {
    num--;
    return num;
  }

  function getNum() {
    return num;
  }

  return [increment, decrement, getNum];
}
```

When we invoke that function, here's what we get out of it:

```typescript
const [increment, decrement, getNum] = createCountingClosure(0);
```

Furthermore, we can invoke those `increment`, `decrement`, and `getNum` functions to get the following:

```typescript
increment(); // 1
increment(); // 2
increment(); // 3
decrement(); // 2
increment(); // 3
getNum(); // 3
```

Whoa.

Don't worry. We're about to work through this code in detail to figure out exactly what's going on.

(Side note - We're doing some destructuring here. If you don't know what destructuring is, no worries. Check out MDN's [excellent article on it](https://hacks.mozilla.org/2015/05/es6-in-depth-destructuring/?ref=hackernoon.com).)

Let's look at that `createCountingClosure` function again and break down each part:

```typescript
function createCountingClosure(startingNum) {
  if (typeof startingNum !== "number") {
    return null;
  }

  let num = startingNum;

  function increment() {
    num++;
    return num;
  }

  function decrement() {
    num--;
    return num;
  }

  function getNum() {
    return num;
  }

  return [increment, decrement, getNum];
}
```

First, we're taking in an argument called `startingNum`. We are clearly expecting it to be a number (as the next line, an if statement, returns `null` if it isn't).

Next, we're assigning the value of `startingNum` to the `num` variable. This gives our counter function a starting value to work with and change later.

We then proceed to declare three functions:

1. `increment`, which increases the value of `num` and returns its value
2. `decrement`, which decreases the value of `num` and returns its value
3. `getNum`, which returns the current value of `num`
4. Finally, we return these three functions inside an array. As functions are "first class citizens" in JavaScript and TypeScript, we can pass functions around like this to be returned from our function and used elsewhere.

This is why, later on, we can invoke createCountingClosure and destructure out these three functions:

```typescript
const [increment, decrement, getNum] = createCountingClosure(0);
```

As you can see, we're also passing `0` into our function. Remember how we set it up to accept a `startingNum` argument? That value is going to be `0` in this example.

With all of that out of the way, we're now at the part of discussing the `createCountingClosure` function where we can talk about how the closures work.

> “Not all those who wander are lost.”
>
> \- J.R.R. Tolkien

## What's in the Bag?

Let's take a look at the `createCountingClosure` function again:

```typescript
function createCountingClosure(startingNum) {
  if (typeof startingNum !== "number") {
    return null;
  }

  let num = startingNum;

  function increment() {
    num++;
    return num;
  }

  function decrement() {
    num--;
    return num;
  }

  function getNum() {
    return num;
  }

  return [increment, decrement, getNum];
}
```

When we declared `increment`, `decrement`, and `getNum`, we unknowingly created little closure "backpacks" for each of them that store access to the all variables available in their scope when these functions were created.

Remember at the start of this article how we had global and local scope? Remember how the function we created had a local scope that retained access to the `globalVariable` in the global scope?

Well, the same thing is happening here. For instances, the `increment` function retains access to the `num` variable. In fact, all of these functions can still access this variable later on anywhere that we might use them (even if it's in a different file).

For example, remember how we destructured out all of these functions when we invoked `createCountingClosure`?

```typescript
const [increment, decrement, getNum] = createCountingClosure(0);
```

Here's what the `increment` function has access to (in code) at the time it's destructured out as we did above:

```typescript
let num = startingNum;

function increment() {
  num++;
  return num;
}
```

Even though we've only destructured out `increment`, it still has access to the `num` variable. It's in the function's closure backpack, along for the ride like a tiny little Yoda.

What this means is that we can access and modify our `num` variable even though we don't have it directly inside the function itself.

**Isn't that wild?** 🦁

This same thing is true for `decrement` and `getNum`, too. They both have access to `num` in the same manner through their closure from when they were created.

Let's go ahead and use our code to see how this works.

> "I would gladly live out of a backpack if it meant I could see the world."
>
> \- Unknown

## Updating Your Backpack

We're going to use our code and walk through it step by step to observe what it does. Here's a refresh of the entire thing before we get started:

```typescript
function createCountingClosure(startingNum) {
  if (typeof startingNum !== "number") {
    return null;
  }

  let num = startingNum;

  function increment() {
    num++;
    return num;
  }

  function decrement() {
    num--;
    return num;
  }

  function getNum() {
    return num;
  }

  return [increment, decrement, getNum];
}
```

In addition, we're going to invoke our `createCountingClosures` function and destructure out the functions returned in the array like we did previously:

```typescript
const [increment, decrement, getNum] = createCountingClosure(0);
```

With this setup, we're now ready to go. If you want to play around with this while we walk through the rest of this article, here's a [codepen](https://codepen.io/nwthomas/pen/maPYGK?ref=hackernoon.com) link that will allow you to interact with the code.

First off, we're going to invoke the increment function:

```typescript
increment(); // should return 1
```

As we've previously discussed, the `increment` function retains access to the num variable. When we invoke `increment`, the function will increase the value of `num` behind the scenes.

Since we passed in the value of `0` when we initially invoked `createCountingClosures` up above, we increment that value to `1`.

(If you're following along in the CodePen I provided, you'll see that pop up in the console because I've wrapped the function call in a `console.log`.)

Next, we'll invoke increment two more times like so:

```typescript
increment(); // should return 2
increment(); // should return 3
```

Notice that the value being returned each time is not starting at `1`; this is because the same variable `num` that we used above is also retained by `increment` and modified each time it is invoked. This is the incredible power of closures!

Next, we're going to call the function `decrement` to decrease the value of `num`:

```typescript
decrement(); // should return 2
```

Notice that the value is, once again, not starting at `0`. The functions `decrement` and `increment` both retain access to the same `num` variable and share the ability to modify it even though it is not contained inside either of them.

Finally, we're going to call `increment` one more time and cap it off by calling the `getNum` function (which just returns the current integer value of `num`):

```typescript
increment(); // should return 3
getNum(); // 3
```

All of these function calls have access to the `num` variable as all of them have the reference to it stored away in their little scope "backpack."

The final `getNum` call returns `3`, which is the value of `num` from all of the many changes we've made to it. Even though `num` is not contained directly inside any of the functions we've been invoking, we've modified it through the power of closures.

## Conclusion

I hope that this brief overlook of how closures work helps you grasp them.

By imagining them as little backpacks that functions can wear as they move around your application, you can build a framework in your mind for how you can access and manipulate variables contained inside of closures.

Also, now that we've stepped through how they work, you can be confident in your closure knowledge and crush your next job interview.

Thanks for reading.

Nathan ☕️


Closures can feel like a mystery until you really dig in to understand what's going on!