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.