#118 – December 04, 2022
Back when I was managing at Uber, I latched onto a thinking tool that I drilled into the teams I worked with: reach the right outcomes by prioritizing the company first, your team second, and yourself third.
The Ultimate Guide to Outsourcing Your Auth | sponsor (sponsor)
Authentication and authorization are critical parts of any application. It's the front door to your app. But auth is also a security risk. If you are considering outsourcing your auth, check out this ebook, which includes how to evaluate an auth system, risks you might encounter and how to mitigate them, and migration implementation details.
Why most monitoring strategies fail
A team without proven observability and on-call strategies will invariably suffer from reactive disruptions; mitigating outages will be painful, like finding a needle in a haystack while blindfolded. I know because I have stabilized teams going through chaotic times.
Expensive Mistake That Often Plagues Layered Architectures
Combining service layer and business layer is a bad decision in a layered architecture. Mishandling layered architecture can be an expensive mistake.
Software engineering metrics that matter
Measuring software engineers and teams by metrics is fraught with controversy, and rightly so. There are many horror stories of individual developer productivity being measured by Lines of Code, number of commits and other activity-based metrics. This is usually ill-advised, but it doesn’t mean that metrics don’t have a place in software engineering.
Zero to a Hundred Deploys | sponsor (sponsor)
An average software team deploys between once per week and once per month. But why stop there? What if you can deliver more value to your customer more frequently? Here’s a practical guide to show you how to go from deploying once a day to a hundred times a day. Learn what measurements, development practices, communication and cultural changes are needed to get there.
Why product development requires balancing conflicting goals
This article describes the simple language I use to describe product development: opportunity, output, outcome, and impact. But more importantly it describes the tensions and unexpected implications in the model.