Favoring stateless functions and pushing I/O the edge of your application can make your code easier to test and reason about.

Starting out on a new project is fun and exciting. Finishing that same project can sometimes become a nightmare. Learn how to avoid pitfalls and finish projects more efficiently.

I recently gave a presentation titled "What I Learned About Software Development from Origami". Originally it was just going to be a fun way to combine two seemingly unrelated interests of mine. But I ended up getting a valuable learning out of it.

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.

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.

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.

Node.js is a runtime for javascript that requires asynchronous thinking.

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.