Daniel Westheide is a senior consultant at INNOQ and has been working in various Scala projects since 2011, from large-scale distributed systems to small intranet applications. He published the e-book “The Neophyte’s Guide to Scala” and is experienced both in mentoring new Scala developers as well as working in veteran teams following a pure FP approach.
In his talk “Testing in the postapocalyptic future” at Scala Days Lausanne, Daniel will present an approach to testing called mutation testing and explain how you can use it in your Scala projects, how it compares to property-based testing, and the challenges of implementing this approach in Scala.
In advance of his talk, we spoke to Daniel about why it’s so hard to keep up with Scala, why boring solutions are elegant and why he wants to avoid using “hyped” solutions.
Share with us your favourite Scala Days story/memory
Something that really stuck with me was Jamie Dobson’s talk on postcapitalism, because it pointed out the consequences of our work. Personally, I think that non-technical talks like these are an important addition to the technical ones we all expect from a conference like Scala Days. As software engineers, we often seem to be focussed on the latest shiny technology and neglect to think about the ethical consequences of our work. Jamie did an excellent job at giving the audience some food for thought.
Watch it here:
What is your background and what does your current role involve?
I have a background in human computer interaction, however, after finishing university, I became a software developer, with a focus on the backend at that.
In my current role, I am a senior consultant meaning that most of the time I still work as a software developer, either embedded into a customer’s team or as part of our own team. I also do architecture reviews or workshops with customers. Another aspect of this role is being a mentor, which is one of the most rewarding tasks I can think of.
What is the biggest highlight of your career so far?
I can’t really think of a single highlight. Of course, there have been a few technical challenges where I am quite proud of the solution we ended up with (although, as a consultant, I am not in a position to share the details). Personal highlights are also those short moments when you realize that you have made a big positive impact on a customer or on an individual. Recently, when a project with a customer came to an end, the person I was mainly working with told me that he had never learned as much in his whole career as he had in the last three months working with me. It’s moments like this that I would count as highlights of my career.
Why did you choose Scala and what kind of problems does it solve for you?
I came to Scala from Java, back in the days when Java didn’t have lambdas yet. So originally, I chose Scala because I was looking for a statically-typed language on the JVM that allows me to express my intent rather than how to achieve it. Algebraic data types, pattern matching, higher-order functions, and local type inference allow me to put the ubiquitous language of the domain into code in a readable manner, without getting lost in boilerplate and syntax. Later, I learned to love Scala for its powerful type system, which helps me prevent certain invalid states from occurring already at compile time.
What is the most important challenge Scala developers are facing today?
One challenge I see is that Scala developers have been confronted with so many competing approaches over the last few years for structuring their programs and dealing with effects. Every year, a new approach seems to be run through the roost. It’s probably difficult for many to keep up with all of that and form an opinion on each of them: Is it worthwhile pursuing this or just another fad? More importantly, most of these approaches are quite sophisticated, making it a serious entry barrier for new Scala developers.
What is one thing that could address this challenge?
It might help to have more realistic examples of Scala programs out there that take a pass on the fancy techniques. This would demonstrate the elegance of boring solutions, and it would show that you can benefit from using Scala very quickly, without having to learn all the advanced language features that the hyped approaches are based on first.
Who should attend your talk at Scala Days and why?
Everyone who is interested in improving their tests, whether you are an advanced Scala developer or a beginner, should attend the talk. Why? Because I am going to present a really promising way of evaluating the quality of your test suite that has been gaining traction over the last few years, but that is still in its infancy in the Scala community. If you want to live in the future for a while, or if you have doubts about code coverage as a quality metric for your test suite, you should attend my talk.
Whom would you like to connect with at the conference?
I am really looking forward to meeting other ScalaBridge organizers and mentors. We have been running a workshop in Berlin twice, and I would love to swap ideas on how to make ScalaBridge even better. Apart from that, I am hoping to connect to as many new faces in the Scala community as possible. I’d love to hear about their journey and the challenges they were facing.
Tell us more, something we haven’t covered with our questions but you would really like to share with the world.
The material in the “The Neophyte’s Guide to Scala” is six years old now. Over the last three years, I have been working hard on a new book, which is more than just an updated edition. Whereas “The Neophyte’s Guide to Scala” expected you to have some Scala knowledge already, this new book will be more self-contained, targeting people who are completely new to Scala. I have still not finished writing said book, but I hope to have a first release out some time later this year.