# Random Scala Tip #534: Adopt an Error Handling Convention for `Future`
When working with `Future` be explicit about your error handling convention, and make sure your whole team and codebase are aligned to it.
When working with `Future` be explicit about your error handling convention, and make sure your whole team and codebase are aligned to it.
These are strange times we're living in. We have unleashed an army of junior developers on our codebases while changing little else, yet we expect everything to just be okay.
Way back in December, in the spirit of the times (it seems that everyone was either solving Advent of Code or looking for a job), like an elephant in a china shop, I found myself solving a…
Before wrapping anything in `Option`, consider whether you should use a more meaningful domain-specific data type instead.
I've recently stumbled upon a post on Scala Contributors by Kit Langton describing how he managed to create the illusion of adding automatically derived (publicly visible) members to a companion of a…
Beware of leaking `Iterator` instances outside the scope you initialized it in.
Avoid using anonymous functions as class dependencies.
Welcome back to yet another episode of test purification. In the last part we explored another benefit of adding type parameters to our code, the ability to work with very lean mocks. It's been a…
This is not just clickbait, I really do mean that ANY form overloading in programming should be considered evil.
In the last part we saw how to make our code more declarative, and the tests more functional by introducing type parameters for the inner data flowing through our code. In this part we are going to…