Over the course of several months, our team has worked through a sizable migration of frontend code from one codebase to another. This is our story.

Extracting Sessions from Interaction Data in Snowflake Processing user interaction data into something useful can be challenging. On the Pluralsight Search team, we can see every interaction a learner has with our search engine, but these events are much more meaningful when considered in context. Learners don’t think about what they are trying to accomplish as isolated API calls, so if we want to understand their motivation we should look at sets of interactions bundled together into sessions.

Arguably, the most frequently asked question from an engineer is: 'When will this be done?' And yet in our engineering principles document we stipulate that 'we don’t do fixed time/fixed scope work'. No wonder, this is one of the most frequent questions that different parts of our organization are asking about: 'How can we make an agreement or sign a contract if we don’t have a fixed point in time when we can all agree that something will be ready for our clients?'

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

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.

Production issues and bugs are a common albeit frustrating part of software development. Imagine a tale of two organizations, with different approaches towards addressing this problem.

Remember when you were little and someone told you a secret? Whether it was someone they liked or a funny story they heard, you felt excited that they trusted you and that you knew the secret. Fast forward to the present day. Carli is a software engineer who has worked at the company since the very beginning. She has a secret, the knowledge of how the reporting module works.

Your team has been discussing a great new feature with some stakeholders. Everybody is really excited until… the question that every engineer dreads… So when can you have it done by?

Let us consider the value proposition of flow efficiency.

What we hope to experience while working on a cross-functional team.

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