If half or more of your code is handling edge cases, can you restructure your logic such that you don't have so many edge cases?

Destroying your development environment frequently provides a forcing function to ensure that everything is automated, works and prevents manually created state from creeping into your data stores. In this post, I'll share the cost of not doing this as well as tips and code examples to set up your own development environment.

Getting the size and position of elements in React is not a great story. Each option I researched has at least one gotcha. I'll share the best options I came up with and explain pros and cons of each. First let's take a look at the basic way to get an element's size and position in React.

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

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.