We support teams in deciding how they work, mob programming, paired programing, individual work, or a mixture of all three.

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.

Knowledge silos impede our ability to quickly deliver value to our users.

At Pluralsight we value creating our product collaboratively. Here are the practices that we have chosen to support that principle.

I’ve never met my teammates in person. Despite this, we've used deliberate communication and a wide array of tools to build a strong distributed development team.

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.

Code reviews are generally accepted as good thing in software development. Some of the benefits include improving quality, sharing knowledge of a system, and promoting collective code ownership. But how you perform a code review matters...