Downtime sucks, regardless of whether it’s planned or not. As a user, when you visit a site to complete a task but you can’t because it’s down, you’re frustrated. Whether or not the site put up a cutesy banner a week earlier warning you about the downtime isn’t really relevant. Banner or not, you can’t complete your task.

Engineering @ Pluralsight is a document that outlines how we do engineering at Pluralsight — how we work. It establishes best practices that enable us to deliver the most customer value, create and maintain healthy processes, and perhaps most importantly it shapes a system where engineers and Pluralsighters feel fulfilled and happy at work. Since the first version was created in 2018, Pluralsight has gone through many changes. We recently took the opportunity to reflect on how our practices are serving us and where we could make meaningful adjustments.

I'm currently on my third engineering team at Pluralsight. While each team has had their similarities, they've also each had unique tech stacks and code bases. The first couple of months on a new team is a time of accelerated learning, especially if the tech stack is unfamiliar. When I'm new to a team I find myself wanting to contribute as much as possible, while also wanting to have the space to develop my understanding of the new and unknown. In my experience some tasks hit this balance better than others.

Life is Weird Right Now. As the COVID-19 pandemic in the United States and around the world has progressed our society has been strained and our methods of interaction have been tested.

Test-driven development (TDD) is a methodology that programmers use to produce higher quality code. The "typical" procedure of coding has always been code first, test second. TDD swaps this mindset by focusing on testing before the actual coding happens.

Fully utilizing static types, with all the safety they provide, can be a bit tricky when dealing with dynamic data — like JSON from an API call. Let's look at how to do this in TypeScript.

There are lots of different types of tests. There are lots of different types of automated tests. In this post we'll talk about unit tests, specifically a few different types of unit tests and when you might want to use each.

Making HTTP calls to get resources or call APIs is a staple of software development. But if you do not properly abstract the request construction and response handling from the HTTP library that you use, it can be extremely difficult to test.

Favoring stateless functions and pushing I/O the edge of your application can make your code easier to test and reason about.

Feedback is the information we get back from the world in response to doing something. Without feedback, there is no way to know whether we are accomplishing our goals.

In a previous post, Jon talked about living in a world without QA. If your organization has folks in dedicated QA roles, one idea is to train them to become developers. Having started my software career in QA and transitioning from QA to dev myself, I will explore some ideas about how to do that in this post.

At Pluralsight our development teams do not have dedicated QA people. We also don't have a dedicated QA team that is separate from the development team. Why do we do that? How does it work?

Property-based testing is a type of testing that uses randomly generated inputs to test an attribute or characteristic of the subject under test. You can contrast this with the more traditional example-based testing approach, where you provide specific test cases for your subject under test. Typically, TDD is done using example-based testing. What happens when we use property-based testing in a TDD workflow?

I recently read a blog post arguing that comments are an important part of code, and the people who claim otherwise are missing out. While I tend to fall on the opposite side of the argument, I would certainly agree that there is a time and a place where comments in code make sense. More interestingly, I realized that I haven't seen many explanations of why comments are sub-optimal, and when they are still important. So, in an effort to improve that situation, here's my take on the principles behind comments, and when those same principles are better served with different tools.

Pluralsight is different from most engineering organizations. We are structured differently, from what makes up a team to how we deploy code. Let's jump in and walk through a typical day in the life of a developer at Pluralsight.

One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of their creator. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. I have 4 broad categories of tests that I keep in mind to help focus my testing.

It's hard for code to provide value unless it's accessible by users. If our code doesn't provide value, why are we writing it? The way we get code into our production environments at Pluralsight has changed over time and varies somewhat from team to team, but getting...