Learning how to code with Scala: Hello, World!

My attempt at a “HelloWorld” tutorial with (hopefully) as few assumptions about your coding knowledge as possible.

I hope you find it useful 🙂


  • I am using Scala version 2.12.5 (for help installing Scala click here)
  • I am using sbt version 1.1.4 (for help installing sbt click here)
  • I am using Sublime to write my code (available to download from here)
  • I am using a Macbook, and therefore their OS X
  • I am using the terminal to run my code

What is SBT?

sbt stands for Simple Build Tool and it is what most people use to build their Scala projects. It provides the project with the support it needs to compile the code and make it work.

Project Structure

Below is the way I have structured a Scala project that uses sbt. Most of it is necessary for sbt to find all of the things that it needs, however the structure inside /src/main/scala and /src/test/scala is up to you 🙂 A lot of people put their Main.scala straight in the /src/main/scala directory and then organises the rest of the code in subdirectories.

image 1

What is in the project directory and why?

As you can see in the the image above, sbt needs a project directory that contains a build.properties file. The content of this file looks like this:

image 2

This tells the sbt launcher what version of sbt to use.

What is the build.sbt file and why?

sbt also needs a file called build.sbt to live inside your root directory (you can see where this is in the image 1 above). This file tells sbt how to build the project, but for this HelloWorld example we don’t need it to do that much.

image 3

The above is the minimum that you need to put in the build.sbtfile.

The name is just the name of your project, usually the name of the directory all of your code is contained within. It has to be a string (a string is a group of characters contained by a set of quotes) so here my project name is “blogPostProject”.

The scalaVersion is where you define which Scala version you want to use. Most people use the most recent stable version, you can find this information here.

What is the HelloWorld.scala file?

HelloWorld.scala is where we are writing our first bit of code!

But right now, it looks like this:

image 4

The package name I’ve used comes from the structure in image 1, each directory that comes after /src/main/scala and before the file you’re writing in is separated by a . and this forms the package. It’s worth mentioning that this is convention rather than by necessity so don’t worry about it too much, your package doesn’t have to mirror the directory structure (as long as you have src/main/scala).

What next?

Let’s get our Scala project to write out “Hello, World!” when we run it.

How do we “run it”?

So to “run” the code,  I usually open up my terminal, you may find yours on your Mac in the Utilities directory inside your Applications directory. To tell the terminal which directory to look at, I cd from where I am – ~ is the root of what is called your home directory – to where my project is saved.

cd is a command line command that tells the terminal to switch to the directory you tell it to, click here to see more command line commands.

So, in this case we are using the command cd Desktop/blogPostProject/ as I have saved my project called blogPostProject on my Desktop.

image 5

Once we are in the right place, we can use sbt to execute different tasks on our Scala project. To run our code, we type the command sbt run in the terminal and sbt should do some magic!

image 6

OK so that doesn’t look too good. This is because our HelloWorld.scala is empty and sbt doesn’t know what to run.

The above error in sbt is saying that there is No main class detected.

Let’s create one. But first…

What is data?

Data is stuff our program can process

What is a function, and how do we make one?

A function is something you can define, that can take arguments, does something, and then returns something. They are instructions for different ways to process data.

To define a function we start of by using the keyword def, this is then followed by the name you are giving the function. It’s common practise in Scala to give a function a name that begins with a lowercase letter and is in camel case format. The minimum you can do to create a function is then to write an equal sign = and then write the code you want it to execute.

A very basic function looks like this:

image 7

This is a function that takes no arguments and returns an Int (Int is the type we use when defining an Integer).

To write a function that takes arguments, we use brackets that come immediately after the function name. We give those arguments names so that we can reference them in the code, and types so the function knows what to expect.

image 8

This function takes two arguments (also known as parameters), adds them together, and returns the result.

If we look at this function quickly, it’s not immediately obvious what type of thing this function returns. So, we can add a return type to the function (also described in more detail later in this post).

image 9

And finally, the above code number1 + number2 is just one expression so we haven’t needed to use any curly braces. When we write something that has a few more stages, we need to use braces as below.

image 10

What is a return type?

A return type is defined by a colon after the initial function declaration. As you can see in image 10, the return type here is defined by : Int. It tells the developers and the compiler what type it expects to return; the result from the code inside that function.

Note:  you don’t always need to define it, but it’s fairly good practice to.

What is Unit?

Later on you will see a return type of Unit. Unit is a special kind of type used in Scala that represents only one value – ().

It is used when we can’t return something of value back from the function.

Later on, we will use the println function. println returns a Unit, as it is having a side effect in the terminal (printing a value) but we don’t have anything to return.

What is println?

println is a function that is included in Scala as default. It is a function that accepts a parameter, and tries its best to display it wherever you are running the code, in this case the terminal.

What is a class in Scala?

Classes are instructions for how to build objects, you’ll be able to use a class to create many instances that are called objects.

For example, if you have the class IceCreamMaker, you can use this to create multiple objects for the different flavours of Ice Cream.

image 11

Don’t worry too much about the syntax for now though 🙂

What is an object in Scala?

An object groups together data and functions that represent individual instances of the thing we’re modelling (e.g. an Ice Cream Maker), and gives them specific behaviour (e.g. a function to freeze the mixture).

So, if we create an object called StrawberryIceCreamMaker, and it has a function called freezeMixture then you can write  StrawberryIceCreamMaker.freezeMixure to execute the code.

image 12

So, how do we create that main class?

As we said above, an object is just one instance of a class. This allows us to use an object for the main class rather than a class.

So let’s make an object, I can write the following in HelloWorld.scala.

image 13

This above code is defining an object called HelloWorld.

What happens if we try sbt run now?

It still fails for the same reason 😩  We have defined a class, or object in this case, however we still haven’t defined a main class.

For this object to work as a main class, we can do one of two things

  1. Add a main function

image 14

For sbt to recognise this as a main class, you may add a function to the object that satisfies all of the following:

  • function must be called main
  • function must have a return type of Unit
  • function must accept one argument that has the type Array[String]

 2. Object must extend something called App

Don’t worry too much about the extends here, this probably deserves another blog post, but basically extends lets you inherit functions from the thing you’re extending. Here, HelloWorld is inheriting the main function from App. The main function it is inheriting also satisfies all of the criteria from the list above, therefore it works!

Lets run it!

So, my personal preference when creating a main class is to use the extends App option, so now I have this:

and I’m going to use the sbt run command in the terminal again.

image 17

And as you can see just above the green success word, that we have printed out the words Hello, world!


Sponsored Post Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

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

  • For more on ‘Blue Sky Scala’, I highly recommend watching this keynote from the Scala eXchange 2016 –  Scaling Intelligence: moving ideas forward by Jessica Kerr.
  • For a great talk that introduces functional programming and how to start using it, watch Push Your State To The Edge by Rhys Sharrem.
  • The most approachable guide to Scala I have come across is Essential Scala by Underscore.

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.

One year in.

I have just logged in to my mostly forgotten wordpress account and the following was sitting in the ‘drafts’ section.

This is it.

My big transition.

This week I signed up to Github, registered for access to the Instagram API, tweeted my first tweet and joined reddit.

I was full of ideas

I can honestly say my enthusiasm hasn’t waned, I just focused it on other areas of my career.

Something that has captured my attention in the last year is how fun it can be to get involved with the community – especially helping others into the scary world of technology. This year I have taken part in both Scala Exchange 2015 and Scala Days 2016 talking about what it is like to learn Scala and what to expect from the experience, hopefully encouraging and relating to others going through the same transition.

Going further with this interest was getting involved with an initiative called codebar.io, who’s “goal is to enable underrepresented groups to learn programming in a safe and collaborative environment and expand their career opportunities.” I found it incredibly rewarding and interesting to provide help and advice to people with their own projects in mind. It served as an important reminder to me of how cool technology can be as a tool for creativity when you’re inspired.

So after quickly reflecting on the past year, noticing how different it has been from my expectations, I have decided to set some goals for the following 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.

But who knows, things haven’t gone to plan as of yet – they’ve been even better.