Learning from Giants #32
Writing better error messages, End-to-end test environments in production at Uber, and Managing people.
👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.
Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.
Write better error messages (Wix UX)
"Something went wrong, please try again." error messages are product debt.
As product users, we always hate it when these messages appear. Yet as developers, we end up adding them in many instances with no afterthought.
Generic error messages are as harmful as generically-named variables but with even less context. And like variables, they often don't get as much interest as they should, and debt starts building...
"About a year ago at Wix, we abruptly realized that, too often, we were not giving users the answers to these questions. When we got this wake-up call, we felt compelled to act swiftly, and not just to address the one error message that woke us up."
The team defined good and bad error messages and then applied these principles to the 7000+ error messages they found in their product.
"What makes a good error message:"
"Say what happened and why."
"Provide reassurance."
"Be empathetic."
"Help them fix it."
"Always give a way out."
And last, remember that error messages are inherently a team effort. Neither the engineer, the UX, nor the PM can solve it independently. It's the shared context that leads to the best error experiences.
📗 Jennifer Nadler's Write better error messages" article is an excellent insight into this overlooked piece of every technical product on Earth and how the Wix UX team went about solving their massive debt. I hope it'll empower you to speak up the next time you encounter generic error messages!
Simplifying developer testing through SLATE (Uber)
Uber developers use their production runtime to run end-to-end tests. Yet they don't test on production users. Only test traffic hits their instances.
"In order to reduce the shortcomings of a shared staging environment for testing, we built a system that lets developers create on-demand, ephemeral testing environments called SLATE and deploy services in them."
Why should these environments run in production? Dependencies. Uber's service-oriented architecture means every service has a dependency graph that spans dozens, if not hundreds, of services. These make setting up and maintaining test environments extremely painful and costly.
"SUT uses production instances of dependencies by default, for guaranteeing the best fidelity while ensuring production safety. "
"SLATE is essentially an isolation created inside a production environment, where test instances of services (SUT) can be deployed."
Everything is abstracted at the request routing layer, enforcing the strictest isolation between test and production traffic. And all of this is done without touching the service business logic.
📗 Uber's Simplifying Developer Testing Through SLATE describes a fascinating alternative between full-on production testing and staging environments. While the setup isn't for all companies and without challenge, it's inspiring to see dynamic routing layers used to solve the end-to-end testing problem.
Managing people
"As a manager, everything is your fault."
"You either created the processes where this outcome happened; or you hired (or did not fire) the wrong people".
Such truths take a while to learn as a first-time manager. And if you're also a founder, it won't be your only challenge.
📗 After having lived and learned through multiple founder, CTO, and executive positions, Andreas Klinger (ProductHunt's early CTO) wrote a list of management truths and principles so that you learn from his mistakes.
A few excellent quotes:
"You manage processes; you lead people."
"Processes are not complex chains of people doing things that are burdened by horrible overheads. Processes are expectations made explicit"
"Avoid drive-by management. You most likely lack context, and most likely, you won't be the person needing to follow through."
"people x context = output."