"All models are wrong; some models are useful." - George E. P. Box
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.
What does it mean to be a software engineer on a machine learning team?
There are a lot of different ways of thinking about gaining and improving at different skills. One such way is called Shu Ha Ri. This blog post explains what Shu Ha Ri is and some observations about its application in software development.
Property-based testing is a type of testing that uses randomly generated inputs to test an attribute or characteristic of the subject under test. You can contrast this with the more traditional example-based testing approach, where you provide specific test cases for your subject under test. Typically, TDD is done using example-based testing. What happens when we use property-based testing in a TDD workflow?
A hashing function is a one-way function that takes some input and returns a deterministic output. The output is often referred to as a digest, a hash code, or simply a hash.
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.
I’ve never met my teammates in person. Despite this, we've used deliberate communication and a wide array of tools to build a strong distributed development team.
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.
I recently read a blog post arguing that comments are an important part of code, and the people who claim otherwise are missing out. While I tend to fall on the opposite side of the argument, I would certainly agree that there is a time and a place where comments in code make sense. More interestingly, I realized that I haven't seen many explanations of why comments are sub-optimal, and when they are still important. So, in an effort to improve that situation, here's my take on the principles behind comments, and when those same principles are better served with different tools.
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.
In the face of technical complexity, we sometimes forget that the human aspect of software development can be even more challenging. Fortunately, we can gain a lot of insight into how other disciplines have overcome similar challenges. In fact, those insights have lead to several of the more revolutionary ideas in our field.
Autonomous teams are becoming increasingly prevalent in our culture, with 81% of the Fortune 1000 deploying some form of a “self-directed” team model in parts of their organization. As Dan Pink writes in his book Drive, autonomy is one of the key contributors to individual motivation.
You’ve heard the phrase before, maybe even attended one, but what really is a hack day? What does a hack day look like at Pluralsight?
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.
When working in a distributed system, your overall system is comprised of discrete components which I will call "bounded contexts." Sometimes these bounded contexts have the need to be eventually consistent. In this article we will cover Out of Band Healing, a pattern that can be used to reduce temporal coupling when healing your server-side caches.
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.
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.
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.
A crumbling code base will eventually prevent you from delivering value to your customers. What are some steps you can take to mitigate this risk?
One common problem that I see in test suites is confusion about what each test should cover. This confusion often leads to tests that are either too broad or too focused to accomplish the goal of their creator. When writing a test, it is important to think about what kind of test it will be and the constraints that make that type of test effective. I have 4 broad categories of tests that I keep in mind to help focus my testing.
APIs are an integral part of our distributed system here at Pluralsight. We use them to communicate between and within bounded contexts. One of our engineering team mottoes is "Be Explicit." To that end, we have a categorization system for the APIs we build and publish. This helps us know what the API is for and who should (and who shouldn't) be using it.
Pluralsight is different from most engineering organizations. We are structured differently, from what makes up a team to how we deploy code. Let's jump in and walk through a typical day in the life of a developer at Pluralsight.
You may have heard about the benefits of immutable objects, especially from the functional programming crowd. But creating and working with immutable objects in a language like C# can be tricky.
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.
Perfectionism and pragmatism are often at odds. How do you strike a balance between doing the perfect thing and doing the right thing?
When we started on our journey towards bounded contexts, we wanted to maintain the small-team, focused, feel that we had enjoyed with as a single team supporting a monolith. One strategy we adopted was to limit our dependencies between the teams and, by extension, the different bounded contexts. We did not want to introduce temporal runtime coupling between components developed by different teams because that would reduce the autonomy of these teams and limit our ability to develop the products that we wanted to develop in the ways we wanted to develop them.
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...
Null references can be a source of subtle bugs in software. Maybe is a tool that, while deceptively similar, provides much greater safety.
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.
How does Pluralsight development work? How does it compare to other tech companies? Are certain processes considered ‘best’ for me and my job?
It's hard for code to provide value unless it's accessible by users. If our code doesn't provide value, why are we writing it? The way we get code into our production environments at Pluralsight has changed over time and varies somewhat from team to team, but getting...
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...
Microservices architectures are currently highly fashionable. The question of how small a microservice can be is asked regularly. Is micro even small enough? Can we build pico-services? At Pluralsight, we have chosen to go a different direction. We are focusing on team size...
At Pluralsight, we are very proud of our company culture. It’s truly an amazing place to work. And one of the most amazing parts about our culture is there are only two rules and three core values that help shape it...