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.

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.

When deciding how and when to reuse code, there are many tradeoffs to consider, each with varying degrees of consistency and indirection.

At Pluralsight we value responsible, autonomous teams and we architect our systems to that end. Here are the practices that we have chosen to make that possible.

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

At Pluralsight we value continuously delivering value to production. Here are the practices that we have chosen to support that principle.

Technical debt is a widely known metaphor which helps us think about how technical issues hurt our ability to deliver business value via software systems. But knowing the concept is different from actually managing technical debt. Unfortunately, many software teams know that they have technical debt, but don't know what do to about it.

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?

An important lesson I've learned at Pluralsight is that when we let ourselves get too busy we create additional work for ourselves. This additional work is a form of non-valuable meta-work which I refer to as secondary work. It gets in the way of doing the work that actually delivers value.

One of my favorite activities as a software professional is to delete code. Over time, I've learned that this is one of the best things I can do because the ideal amount of code is no code at all.

In the face of technical complexity, we sometimes forget that the human aspect of software development can be even more challenging. Fortunately, we can gain a lot of insight into how other disciplines have overcome similar challenges. In fact, those insights have lead to several of the more revolutionary ideas in our field.

How does Pluralsight development work? How does it compare to other tech companies? Are certain processes considered ‘best’ for me and my job?