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.

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.

If you're not careful, your Python environment can quickly become a disaster. We'll walk through the available tools to be more (code) environmentally friendly and establish some (highly opinionated) preferences for setting up Python.

Once an organization decides to introduce a new technology into its ecosystem, adoption can be tumultuous. Let's preview the introduction of the Elixir programming language at Pluralsight and note the potential hurdles. We can make an educated guess about how to address these issues head-on.

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.

The MVP solution to scaling our product experimentation.

Learning is a very personal thing. Learning a language is even more so. In this post, I discuss my approach to learning new programming languages in the hope that you will be empowered to find your own way to learn new languages.

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.

Listening to users requires both qualitative and quantitative data gathering. Let's walk through how we think about blending qual and quant and what's hindered our efforts to gather quantitative input.

You may have noticed that our blog recently got a facelift. While redesigning front end sites is fairly common, in our case, this represented a bigger change. We noticed that we weren't treating our blog with the same principles we apply to the rest of our work. And so we embarked on a journey to find a better way, which lead to our current implementation.

What sort of software architecture should you be implementing? When looking at industry trends, blogs, conference talks, and the like, it is easy to think that other companies have everything figured out. You'd be forgiven for wanting to copy the success that others are having. But there is no perfect architecture. Everything is a set of tradeoffs; there are only good and bad fits for a context.

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.

Feedback is the information we get back from the world in response to doing something. Without feedback, there is no way to know whether we are accomplishing our goals.

In a previous post, Jon talked about living in a world without QA. If your organization has folks in dedicated QA roles, one idea is to train them to become developers. Having started my software career in QA and transitioning from QA to dev myself, I will explore some ideas about how to do that in this post.

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.

Distributed systems are hard. They have a lot of moving parts with complex interactions and are inherently multi-threaded. To make them work, there is often some form of eventual consistency at play. Embracing this can make software development easier.

In order for a technology organization to deliver products in support of a company's mission, decisions about which technology to use and how to use it must be made regularly. Creating a strategy for making these decisions is a problem for many organizations.

When I joined Pluralsight, I knew going in that it was going to be a different kind of company. They were already practicing things that I'd been learning about and struggling to implement in my prior company, like TDD and continuous delivery. But I didn't realize just how different my day-to-day work would be until I found that my team was doing something called mob programming.

Code reviews are generally accepted as good thing in software development. Some of the benefits include improving quality, sharing knowledge of a system, and promoting collective code ownership. But how you perform a code review matters...

It's hard for code to provide value unless it's accessible by users. If our code doesn't provide value, why are we writing it? The way we get code into our production environments at Pluralsight has changed over time and varies somewhat from team to team, but getting...