Useful resources when learning Scala.

Here is my collection of resources I have found useful when learning Scala and Functional Programming!


Essential Scala by Underscore

My go-to recommendation for anyone starting to learn Scala. This book assumes some knowledge in programming but nothing with Scala. It takes you from the basic syntax, through common patterns, and hopes you take away key skills that will help you along your journey.

Functional Programming in Scala by Paul Chiusano and Rúnar Bjarnaso

I usually suggest this book when a developer has spent some time programming with Scala but wants to explore more Functional Programming concepts. It’s a great book to pick up, tackle one or two of the exercises, and then put down again for some time. I have been working my way through this book for around 3 years now and still not half way through, although every time I do pick it up, I enjoy my time and the challenge it provides.

Scala with Cats by Underscore

This recent addition to my list of resources has been a great help whilst making my transition from Scalaz to Cats. I recently attended the training course for this book (which I can also recommend), and together they have helped me code elegant solutions to encountered problems with Cats.


Functional Programming Principles in Scala by Martin Odersky

After spending around 6 months learning Scala basics, I used this course to continue my learning with Scala and Functional Programming. It helped me understand key concepts in FP that I use today and I enjoyed some of the exercises a lot. I wrote a more detailed review of this course here.


Scala excercises

This was recommended to me by a fellow colleague learning Scala and FP, this is an “Open Source project for learning different technologies based in the Scala Programming Language”. It provides an immersive experience to learn, especially useful if you are short on time, squeezing in some learning where you can.

Kata’s in Scala

“A programming kata is an exercise which helps a programmer hone his skills through practice and repetition.” The best thing I did for my independent learning was to tackle a kata alone every week or so, applying concepts I had recently learnt. It’s useful to see other people’s solutions to the same problem after you have finished, and possibly learn from what they may have done differently.


Demystifying Scala by Kelley Robinson

The first video you should watch when being introduced to Scala. A great talk to ease you in to Scala’s syntax, features, strengths and weaknesses. It provides an honest insight on why people choose Scala, the community, and the choice between Object Orientated Programming and Functional Programming.

A purely functional approach to building large applications by Noel Markham

I found Noel Markham’s talk to be a great introduction to Functional Programming where he builds an application whilst thoroughly explaining what he is doing and why.

Scalaz; or how I learned to stop worrying and love monads by Noel Markham

This talk was recommended to me during my job interview at ITV in order to get me up to speed with functional programming helper libraries. Excellent introduction to Validation and Typeclasses, aimed at people who might find libraries like Scalaz daunting. Noel also offers tips on how to introduce these libraries to any resistant team members.

Easy and Efficient Data Validation with Cats by Daniela Sfregola

Another excellent, beginner-friendly introduction to Validation, but this talk is more thorough, in-depth and uses the Cats library. This was especially useful for me when making the switch from Scalaz to Cats.

A Pragmatic Introduction to Category Theory by Daniela Sfregola

A very approachable and beginner-friendly introduction to Category Theory. It helped me gain a better understanding of a lot of concepts I use with Functional Programming.

Composing Programs

A keynote from the Scala Exchange 2017,  Rúnar Bjarnason talks about how to use components to create software, and why Functional Programming is the answer.

Extended Viewing

Keynote: Scaling Intelligence: moving ideas forward by Jessica Kerr

A very inspiring talk about how we can make the Scala community a better place.

Daniel Spiewak by The making of an IO

A thorough introduction on what the IO Monad is and why we should be using it.

Exploring Decision Trees with Matryoshka by Zainab Ali

A super interesting talk about making decisions on data, Zainab uses the scenario of the Titanic sinking to demonstrate.

Scala Conference Round Up 2017.

I’ve been lucky enough to attend several conferences this year and wanted to share a round up of my favourite talks.

Typelevel Summit NYC

Easy and Efficient Data Validation with Cats – Daniela Sfregola

Northeast Scala Symposium NYC

Arrested Developers: What the Scala Compiler & Lucille Bluth Have In Common – Fiona Condon


Building a Company on Scala – Dag Liodden


Type classes in Scala – Łukasz Indykiewicz

The Value of Impossible – Viktor Klang

Scala World

Exploring Decision Trees with Matryoshka – Zainab Ali

Scala exchange

Moving Away from Hope-Driven Development – Andrew Gustafson

Keynote: Composing Programs – Rúnar Bjarnason

Away With the Types! – Dave Gurnell

I’m looking forward to see what 2018 brings!

Adopting Scala: The Next Steps.

Why is it important to share our personal learning experiences?

One of my passions within the tech community is to break down the barrier to technology and open up the space for people who don’t just “get it”. I was lucky enough to stumble into the technology industry and stubborn enough to stay, but I hold my hands up and say this does not come naturally to me. The longer I have stuck around the more I have realised that most scary sounding jargon is unnecessary, most tutorials start with problems too daunting, and ‘blue sky’ Scala still has a barrier of intimidation for many people.

How did I continue with Scala and Functional Programming?

If you’re striving towards ‘pure’ code, we want to start small and push the state to the edge (this is a great talk for reference by Rhys Sharrem). I think it’s important to prioritise a few principles of functional programming and focus your attention on understanding these first before moving on to more complex ideas. The last thing we want to do is intimidate people moving towards functional programming and scare them away for good. I focused on the following three principles:


Immutability means “unable to be changed” and this is favoured in functional programming. One of the benefits of immutability is that it makes the code simpler to reason about and reduces side-effects in your application.

Throwing Exceptions

Throwing exceptions within your codebase is generally avoided in functional programming as this also contributes towards side-effects. It means you can’t predict what your function will return or how to deal with that simply. This was the first thing that I worked on reducing when getting serious about functional code as it is provided me with small slices of the codebase I could analyse and improve.

Function Signatures

A commonality I have noticed when seeking advice from mentors, is that they all write their function signatures first. The benefits they see is that you end up writing a lot of your code, and decide the direction of your solution, without even trying too hard to solve the crux of the problem. It helps break down the problem in to bitesize chunks whilst forcing you to answer the important questions first. What do I need to pass in to this function? What do I need to return from this function? How do I want to handle success and failure? How does this function fit into the wider codebase?

How to apply these principles?


The first problem I solved with these principles in mind was returning failures without losing messages. If several things fail in a function, we wanted to be able to retain all of the errors so the user can analyse a complete list. The function I was working on was currently throwing exceptions at failure. We all agreed that returning one message and exiting the function, rather than a continuing and compiling a list of messages, meant we were losing vital information.  This is where one of my mentors first introduced me to Validated, and the first time I had used a helper library like Cats. We both talked through what we wanted the function to do and how we wanted to handle failure, this helped us compose the function signature. This gave us clear direction for how the function would look. Through this example I learnt about why throwing exceptions wasn’t ideal, the benefits of writing the function signature before jumping straight into the code, and ensured immutability is maintained.

However, you don’t have to tackle these too. Use your current work and roadmap to decide what will be approached organically. Extra context around the problem will help everyone understand why a solution may or may not be suitable. It’s also helpful to get it wrong, allow people to explore a flawed solution as this is the best way to understand and remember why it doesn’t work.

How am I learning?

Pair Programming

Since joining my current job nearly one year ago, pair programming has been my default way of developing software. It’s always seemed a controversial topic when I’ve talked about this in the past. From what I’ve experienced, the more your team does it, the better it works. Our team has become very good at it, and in return, we are all happy developers; sharing knowledge, ideas and feedback.

When I started, I hadn’t used a library for functional programming and I still threw an exception or two where I couldn’t think of an appropriate way to bubble up the information I needed. Having someone there to guide me through the bombardment of information and new concepts was exactly what I needed to get started.

However, I noticed a couple of months down the line that I needed space to explore and make mistakes that pair programming just doesn’t create the right environment for. It’s important that people are allowed to recognise what’s best for their learning and exercise that.


The best thing I ever did for my independent learning and confidence was to do kata exercises at home. I started with this list of exercises and began working from the top to write the best solution I could. Then I looked up other peoples solutions, took note of concepts I liked most, and tried to apply it to the next kata on the list.

Throw yourself in: Katas, Red book, Coursera.

I started the Functional Programming Principles in Scala Coursera course about 6 months into learning Scala and felt it was too advanced for me at that time. Approaching it a year later when I had more confidence, I found that one of the first exercises was nearly enough to frighten me off once again. However, this time I persisted and I realised that this barrier to the course wasn’t reflective to the remainder and I hope this will convince anyone else that may have been scared off to try again. I wrote about my experience with the course here.

I’m having the same kind of journey with Functional Programming in Scala, exercise 3 is a real challenge and I have to really motivate myself to keep plugging away with it. This time I know that just because I can’t figure out X, doesn’t mean I can’t tackle Y. I try to move on and continue to learn new things, and come back to it when I feeling more confident, ready to attack the problem in a new way.

Here are some other resources I can recommend:

Make mistakes

I touched on this when I wrote about pair programming, but it’s worth mentioning in more context. Giving and allowing yourself more space to make mistakes is so beneficial to your learning, mindset and self-confidence. I try to see it as a necessary step, however hard that may be sometimes. Learning what’s not quite right is just as important as knowing what works.

What are the challenges?

Introducing a helper library for functional programming

Before my current team, I had never used a library for functional programming and I found the learning curve was intimidating. It almost changed the language for me and it felt like I needed to learn all these new tricks in order to get it “right”. Thankfully we practised pair-programming, and my mentor was able introduce concepts one at a time. As said above, we used validation as a great place to start and I continued to pick up new features as and when I touched them in day-to-day development.

Strip a problem back until it’s at its most basic form. You will be able to understand it more generally and be able to apply it to more than just the immediate problem. Get the function signature right even with ???

Another approach we took was to strip the problem back to a very simple example, and build up to the real world example slowly; this ensured each new piece of information was digestible. We stepped away from the desk and focused on a very basic example of validation. We then made it slightly more complex and more like the real-world problem and this gave me a chance to ask plenty of questions without any underlying assumptions.

Getting feedback about your strategy that adapts to your progress

This journey into functional programming means that there is incremental progress from “Java-like” Scala to FP. That means the first few steps won’t be perfect and getting feedback on your strategy in this time-frame will be an ongoing challenge. Ideally we would all have friendly mentors or patient colleagues, but for anyone brave enough to be doing this in their spare time, this is not possible. The only thing I can encourage and push myself to do is get out into the community to help those who want to learn. Although not all of these are specific to functional programming, a few great initiatives are:

From zero to ‘Red Book’

The difference between “Hello World” and the first few chapters of Functional Programming in Scala is huge. Please don’t let that put you or others off. From experience, these courses and books don’t follow a steady diagonal line upwards, there’s a good  chance you will find the next topic suitable and you can revisit when you have more confidence with key concepts.

One step at time. Functional Programming Principles in Scala course on Coursera is a perfect example of how some resources can be scary, but that’s not the whole story. Leave that problem and continue on, but don’t forget to go back and smash it when you feel more confident.

While struggling with exercises or problems I often write something, anything, just to get it from running around in my mind. I then work on making sense of it. This stops me from becoming confused with all of the “what about…”s and I can see my solution a little more objectively. Then I tweak and replace some parts of the code until it passes a test (manual or written). Very rarely can I write a solution straight away without changing something, which I think is what I expected to happen at some point.

It doesn’t have to have a ‘click’ moment

Most importantly, there is NO PRESSURE. Everyone is different and will have prior habits or assumptions they may need to shed before a change of mindset.

More Resources

2016 Goals Update: Scala Exchange 2016.

Another update as we draw nearer to 2017 (eek!):

  1. Deliver a talk at at least one more conference. 
  2. Help organise a community event.
  3. Finish Coursera’s Functional Programming Principles in Scala (finally!).
  4. Start a home project and see it through to the end.

Scala Community

As mentioned in previous blog posts, getting involved in the Scala community has been one of the most rewarding parts of being in the ‘tech world’. Even just following some of your favourite twitter accounts can really give you a feeling of community by reading the articles and opinions shared.

Going further by visiting meet ups and conferences, like the Scala Exchange, can be quite daunting (lots of new people to meet!). However, when you realise everyone is friendly and approachable (and more notably, in the same boat), you can start to look forward to them. It provides a platform in which you can share ideas and come together to solve reoccurring problems, and socialise with people who you have a common interest with. It’s fascinating to learn what hurdles people are facing in their own workplace and learning how they overcame something you yourself are struggling with. Alternatively, you can pick up on some things they do that would be great for your team (hackday anyone?).

Scala Services in Action

I am so excited to be talking again this year at the Scala Exchange in London this December. This time last year I was nervously preparing for my first time publicly speaking and it became one of the high points of my career so far; stepping out of my comfort zone and into the Scala community. Kingsley and I will be talking about the different frameworks you can use when building Scala microservices. We will be covering all different categories from quality of documentation to user popularity so will hopefully provide a new perspective to everyone in the audience.

Talks I’m excited to see

There are so many talks I am looking forward to this year! It’s really great to see so many ‘introductory’ talks that appeal to not only beginners but also to people who want to strip it back to basics and learn more of a foundation to those topics; there’s always something you miss the first time around. Here are some I’m most excited to see:

  • Learning and Adopting Scala – Emmanuelle Poirier and Dominic Kendrick
  • Establishing Orbit with Shapeless – Dave Gurnell
  • A brief and incomplete history of programming languages – Andrea Magnorsky
  • flatMappy Bird: Functional Flappy Bird – Martin Carolan
  • How to write maintainable Scala code – Peter Hilton
  • Crafty Communications (Scala and Pesky People) – Asher Glynn

2016 Goals Update: Functional Programming Principles in Scala.

As I mentioned in ‘One Year In’, I have a set of goals I’d love to achieve this year.

  1. Deliver a talk at at least one more conference. Even though there have rarely been other times when I have been as nervous as I am before public speaking, it is one of the most fulfilling things I have done in my career so far.
  2. Help organise a community event (codebar?).
  3. Finish Coursera’s Functional Programming Principles in Scala (finally!).
  4. Start a home project and see it through to the end.

Last week, I finally finished Coursera’s Functional Programming Principles in Scala after three attempts. When I was enjoying a particular exercise, I couldn’t wait to work on it. I would use all of my spare moments to squeeze in some extra time and it was quite common for me to use my lunch hour. However, when it was an exercise that I found too hard, I really had to force myself to go back and keep chipping away. I guess learning is always a little like that.

Favourite Assignments

  • Week 1 – Getting Started + Functions & Evaluation: Recursion – I really enjoyed the first two exercises in this assignment. Although there is a caveat to this being in my favourite list; the ‘counting change’ problem was the reason I gave up the whole course the first time I enrolled. I personally think it is much too hard for the first assignment. However, the first two problems are fun and quick! It got me really excited for the rest of the course.

  • Week 2 – Higher Order Functions: Functional Sets – This one is the first ‘real’ assignment and it is a great introduction to what the course structure will be like from now on. It had a simple concept – fill in the gaps.

  • Week 4 – Types and Pattern Matching: Huffman Coding – My favourite, by far! I really enjoyed this one because I never felt demotivated. There were obviously times when it was difficult, but never so much that I wanted to quit. These ‘hard bits’ were also scattered around. It was like walking up and down some hills rather than facing a mountain. This is the sign of a perfect exercise for me, provides motivation and satisfaction to keep you going.

The Rest

  • Week 3 – Data and Abstraction: Object-Oriented Sets – Well this drops you way down in the deep end. It was far too abstract for me and I found it hard to get my head around what the exercises were asking of me. It was also a bit frustrating that they chose to call the type ‘Set’. I understand it is more reflective of a true, mathematical set but for me, I was too used to using the word ‘set’ for a type of list in this context. However, I will say it forced me to get used to passing functions around, which I guess is the point of this course.

  • Week 5 – Collections: Anagrams – This was the reason I nearly fell at the last hurdle. I did not want to go back and complete the last exercise to this. So much so, a day or so before my sessions deadline, I submitted it without it. Thankfully, I graded high enough without it, but this just shows how much I disliked it. For anyone who is wondering, it was the sentence anagram function. And I never want to go back.

Good luck to those of you who are still working through it!

5 Tips for Nervous First-time Speakers.

Last summer, someone suggested I should submit a talk for the Scala Exchange. They made great points: a lightning talk is a great way to introduce yourself to public speaking, you will have unique approaches to experiences that may help other people, and it’s a great way to get involved in the community. That did nothing to stop me freaking out about it. Would anyone gain anything from what I have to say? What if it was boring or people disagreed with me? WHAT IF PEOPLE JUST WALKED OUT?!?!?! However, looking back, I am so grateful I was kindly pushed to take the plunge and it’s been one of the most satisfying experiences of my career.

The motivation behind this post is that the deadline for submitting talks for this years Scala Exchange is Sunday, August 14th 2016. I know a few people who are ‘umm’ing and ‘ahhh’ing about submitting an abstract and this is my advice.

Tip #1      Just click the button

Sorry event organisers. 

My approach was to just do it (there’s a slogan in there somewhere). Click the enter button and worry about it if and when the talk is accepted. One scenario is, if it gets accepted, you can channel your nervous energy into making the talk great – remember one step at a time! It means your decision has been taken away from you and you can focus on getting it done. The other outcome is that it doesn’t get accepted, which means you didn’t waste your time worrying about something that never happened. Obviously, in order to click the button you will need to have given the subject a little bit of thought, but don’t worry about the details. Think of a topic that you would like to listen to someone else talk about, or even would have liked to have listened to when you were just beginning to learn. Use this motivation to fuel a paragraph or two about what you want to get across to your audience. The rest will come when you start fleshing out the presentation.

Tip #2      Make a start

Personally, I find nothing more daunting than an empty page. The potential of what it might be: good or bad. The easiest place to start is the first and last slide. Let this pleasantly distract you. Now all you have to do is fill in the middle bits. And don’t forget to add your twitter handle to the bottom of each slide!

Tip #3      Write everything down

Something that I found invaluable the first time I prepared to do a talk was the help provided to me by Underscore and Skills Matter. They helped by walking me through the process and giving me tips on how to write and structure my presentation. Just start by writing everything down, just a complete brainstorm of ideas, and soon enough you will start being able to group these into categories. Continue this way until a story develops and voilà, presentation done!

Read this post on the new speaker programme for 2016 to find out more about how Underscore can help you and how to apply.

Tip #4      Lose the script

I’ll start this one with a story.

Around two weeks before the conference, I decided to give a little practice talk to my colleagues. I had written all of my slides, knew kind of what I was doing, and more specifically had written everything I wanted to say, exactly, for the first half of the talk. This is what happened. I found myself trying to recite my ‘script’ word for word, and when I forgot a word or two, I had no idea what I was trying to say. I was trying to remember my talk rather than actually talk. Lesson learnt. And lo and behold, I hit my stride in the second half of the talk, simply because I was just talking about a subject that I knew a bit about.

Try not to put so much pressure on it, if you know the subject just simply tell everyone else about it too.

Tip #5      One deep breath

I cannot even start to describe how nervous I was the morning of my talk. Anytime I sat in one of the other talks, all I could visualise was me up on the stage and what that would be like. It was all I could talk about and I was even starting to get on my own nerves. It felt like I’d drunk too many coffees even when I wasn’t actively thinking about it. Is this starting to scare you off? Please don’t let it. When my name was called and I walked up to the podium, I stood (for what felt like slightly too long, but wasn’t) in front of the mic, and took one long, deep breath. At that moment, all my nerves went away. I promise.

Good luck with those abstracts!

3 Golden Rules for giving Code Reviews.

You’ve finished your piece of work, you sit back, let out a deep breath and your shoulders relax. You did it! It was hard, there was a time where you had to manoeuvre around a tricky problem, and there’s a small piece of code that could be better but it was the best you could come with up with. You’re looking forward to getting your teams feedback and hoping they may have a more elegant solution or have questions you can share ideas on!

But what happens if the feedback you receive makes you angry? Or upsets you? How do you deal with that? What have they said/done that’s provoked that reaction?

Or perhaps you’re the reviewer and your colleague has reacted in a way that you weren’t expecting. How do you feel? Do you feel like they’ve overreacted? Or worse, did they *deserve* it?

Rule #1    Ask questions rather than make statements

Be kind! Sounds obvious right? But it can be all too easy to get more concerned with the code and forget about the author and their intentions. How many times have you looked at a piece of code and thought “What the hell were they doing!?!?!?”. Take a step back and remember those were decisions that were made… on purpose. Try asking why the author chose a certain method over another, and not in an accusery way either. Come at it from the angle of trying to learn about the code, and from that make your suggestion in how it could be better. If your suggestion isn’t necessary, or more of a style choice you think should be favoured, or a more efficient implementation, then do just that – suggestit. No one likes smug people and it can embarrass the author as these reviews are usually public. Be humble and help.

Rule #2    Limit personal preference

As touched upon above, personal preference is your personal preference. Unless agreed upon beforehand, picking up on issues such as formatting or layout can distract from real bugs and errors in the code. I realise that the control-freak inside most of us gets frustrated at what we feel are silly design choices, but one single person alone is not in control of the code base. If two people have different views about these issues, there is no winning in an argument – so don’t waste your time.

Rule #3    Thoroughly check its purpose

Let’s use Scala as the language we’re using. So you’ve skimmed the code, there’s no Option.get, there are no var’s to be seen and all the names being used are informative and clear. Ship it!

But wait… What if the method does not solve the task at hand. Maybe it sends the wrong (but valid) message to the wrong place. Maybe it uses the wrong data to add records to a database. Even if all of the method names match their contents, unless you go back to the original task and look at the acceptance criteria, there is no way to know if this code review deserves the OK. I would suggest taking a look at the tests and see how these compare to the aim or goal of the task. Once you know that, you can ensure all of the tests test the right things. Easy peasy.