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.

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.

Many software engineers approach productivity metrics with cynicism and distrust; they see them as a way for managers to spy on employees and turn people into numbers. As a soft-spoken female in the male dominated high-tech industry, I have a different story to tell about software metrics.

Life is Weird Right Now. As the COVID-19 pandemic in the United States and around the world has progressed our society has been strained and our methods of interaction have been tested.

At pluralsight we encourage people to form guilds, which are self-organizing groups of people that share common interests.

Getting up in front of a group and talking about something for any period of time can be scary. But it can also be a great way to share your knowledge, to increase your knowledge, and to help others. The goal of this blog post is to give you some ideas on how to get started if you have some interest but no experience yet.

We must proactively create an environment where people from all backgrounds feel welcome and are given the trust they need to feel comfortable and the support they need to grow. This isn’t a platitude. It’s a process, a practice, and a promise. To get to a place where diversity isn’t a goal, but part of the very fabric of our organization.

The world around us is littered with calls for learning to program. You may think, "I know how to code." Learning to code may be the beginning of the journey, but I posit that even mastering a language should not be the end. It may just be time to learn a new language.

I recently had the opportunity to speak at a local developer conference, Big Mountain Data and Dev. While preparing my talk, I was struck by how important the communities I belong to have been for me. I first learned about Pluralsight while attending the local Software Craftsmanship meetup, and without the relationships that I developed there, I probably wouldn't be working here today.

When designing the architecture for an application or system of interrelated applications, it is essential to identify which quality attributes of the system are most important to the users, developers, and owners. Often this is done implicitly based on the experience and preferences of the various people participating in the project. When quality attributes are selected with intention and purpose, they help guide the design of the system. At Pluralsight, the quality attributes we focus on have evolved as the company has evolved.

As engineers, how we work is important. At Pluralsight, our engineering culture and engineering practices have been carefully created and nurtured by our founders, leaders and an engineering team who care deeply about the craft of software engineering.

Feedback is one of the best tools that we have to improve ourselves. It can help us identify our blind spots, see the impact of our actions and be more effective in our roles.

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.

Autonomous teams are becoming increasingly prevalent in our culture, with 81% of the Fortune 1000 deploying some form of a “self-directed” team model in parts of their organization. As Dan Pink writes in his book Drive, autonomy is one of the key contributors to individual motivation.

You’ve heard the phrase before, maybe even attended one, but what really is a hack day? What does a hack day look like at Pluralsight?

The software industry has always held a basic assumption that architecture is important. By association, the role of architect has always been esteemed important. But unfortunately, it isn't always clear what architecture is or what an architect's job should be.

A crumbling code base will eventually prevent you from delivering value to your customers. What are some steps you can take to mitigate this risk?

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.

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

At Pluralsight, we are very proud of our company culture. It’s truly an amazing place to work. And one of the most amazing parts about our culture is there are only two rules and three core values that help shape it...

What does it mean for a team to be responsible? What should a team be responsible for? How should teams be structured? In our careers, we've experienced pain when the answers to those questions have been ill-defined. At Pluralsight we have tried to do better, learning from the community and our own past experiences...