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.

Making HTTP calls to get resources or call APIs is a staple of software development. But if you do not properly abstract the request construction and response handling from the HTTP library that you use, it can be extremely difficult to test.

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.

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.

Coupling is an important concept in software development because it limits the ability of software to change. Temporal coupling is a kind of coupling where code is dependent on time in some way. It is particularly insidious because it is hard to detect unless you know what you are looking for.

The software industry has always held a basic assumption that architecture is important. By association, the role of architect has always been esteemed important. But unfortunately, it isn't always clear what architecture is or what an architect's job should be.

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.

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.

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

In an era where password breaches are all too common, it's easy to be concerned about what companies do with user passwords. Unfortunately, in most cases it's a black-box scenario where we can only guess at what's going on under the hood based on clues like character or length restrictions.

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