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.

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.

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

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.

Many teams at Pluralsight use systemd for application process management. When systemd starts a process, it needs to know if the process started successfully. The most simple way to do this is for systemd to wait for a bit after starting the process (perhaps 10 seconds) and simply check that the process is still running. Since you generally can't predict exactly how long your service will take to successfully start up, this is error prone. Furthermore, this method is slow. If you are doing synchronous restarts for a rolling deploy, this adds a lot of time.

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.

In the summer of 2014, Pluralsight suffered a significant outage when our primary database failed. After recovering from the immediate problem, we decided we should migrate to a completely different database to improve performance and availability. Though it took some time to complete, the transition was surprisingly simple thanks to a powerful pattern.

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...