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.

Keep your screen from falling asleep with the Screen Wake Lock API

Recently, there has been a push to change some of the names and rhetoric we as technologists use on a daily basis. This blog post explores the technical challenges, side-effects, and process of one such change: renaming default git branches

My three oldest kids have just returned from their grandparents’ house. They run into my office, each child waving a twenty dollar bill. “Look at what we got for helping Oma in the garden!” Their sweaty faces are beaming with pride. “And how will you spend your newfound wealth?” I ask, already knowing the answer. “I’m getting V-Bucks,” 11-year-old Elowen announces. Her twin sister, Linnea, nods emphatically. “It’s Robux for me,” declares 9-year-old Hallden.

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.