Sometimes it seems like there are software design patterns that are always good or always bad. However, that determination usually relies on the context that the software is built for.

We often discuss the technical merits of libraries/frameworks/services we are evaluating. This is an obvious discussion point. Technology needs to have technical advantages. Yet, it is also important to consider the philosophy of those who build that technology when evaluating technology to use.

Failing fast has become a common trope by now. It makes a lot of sense in some contexts. However, we need to keep in mind that failing is a means to an end. It is not the end itself.

Despite all the benefits of writing tests, we often neglect to do so. There are too many possible reasons to discuss in one blog post, but we can go over some of the more common ones.

When we talk about UX, we often refer to the UX of the products we build and use. We rarely talk about the UX of the tools used to build that software, the most important of which are programming languages.