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 – suggest it. 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.

Sofia x

Continue Reading

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

Continue Reading

First Look: Scala Spray Framework

spray is an open-source toolkit for building REST, HTTP-based integration layers on top of Scala and Akka.

Being asynchronous, actor-based, fast, lightweight, modular and testable it’s a great way to connect your Scala applications to the world.

So when Kingsley and I were deciding what frameworks to cover for our talk, we were unsure whether to include Spray or not. Spray seems to be on its way out; there’s currently no roadmap to upgrade spray to Scala 2.12 (https://twitter.com/oxbow_lakes/status/796311657203068928). However, Spray is widely used and teams are still continuing to use it, even on new services they’re building. I found it very interesting to take a first look at Spray and then move onto akka-http to be able to compare the differences. As I did with my first look at Play, I wrote an identical small REST application that can be found here, where all of the below examples can be found.

– Support

I’m going to start with this because this alone is a reason not to pick Spray up right now. As with all of my ‘first looks’, I googled things a lot. This page appeared a lot. This tells me that less people are asking/answering questions since the latest documentation which is a bad sign.


– Actors

For me, I find Actors being baked in to the Spray framework more of an obstacle rather than a useful addition. It’s one of the first thing you have to write in order to set up a service and this isn’t particularly beginner-friendly; I was definitely intimated by this concept at first and believed I needed to learn all about Actors to use Spray. However, once you realise that this is just some boilerplate you need to cover to get started, you can more or less ignore Actors from there on (if you’re project isn’t using them).


– Routes

I wasted a lot of time when writing the routes. Spray uses the magnet pattern and it can be quite complex when linking routes together; more so when trying to decipher where a particular route ends up.


I needed to thoroughly read through the docs whilst writing the routes for the first time, and not everything was very clear straight away. Specifically returning Json and Futures; something simple like not needing to explicitly state that you want to return something in Json took some time to debug.

Another annoyance was a problem that occurred when forgetting to write one of those little tilda’s between routes.


Firstly, I would expect a compilation error, but we don’t get that. We don’t even get an appropriate or clear runtime error. What we do get is very strange behaviour – the routes work for everything declared after the missing tilda and the routes before it just gets ignored.

– Implicits

If you noticed in the above picture of the routes, I’ve imported some implicits as close to where we need them as possible, but that’s not all, I have also imported them just above where I have declared myRoute. This was the only way I could get the implicits to play nice and I still have no idea why. I’m sure I’ve missed a trick here somewhere but my dislike for this still stands; it shouldn’t have to be this hard.


This felt like the most clumsy of all the framworks I used for our talk, between the odd behaviour of the implicits, the routes being hard to read at a glance and the awkward way we return Futures and Json. I will say that once I had jumped the hurdles and learnt the quirks, it was very fast and simple to add more routes and re-run the service. I also didn’t quite implement all of the little ‘extras’ I added in the play service (e.g. custom json marshallers) as I was planning on coming back to them once I had everything basic in place, however I doubt I will be going back to work on this service with Spray being on the way out.

Continue Reading

First Look: Scala Play Framework

Play Framework makes it easy to build web applications with Java & Scala.

Play is based on a lightweight, stateless, web-friendly architecture.

Built on Akka, Play provides predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications.

Play was the first framework I picked up in preparation for a talk Kingsley and I gave at Scala Exchange 2016; Scala Services in Action. As it is one I have used before at a previous company, I was keen to go back and see if I still enjoyed using it a year or so later. I was left with a great first impression from using it in industry, which thankfully has held true throughout my experience at home. As part of the talk preparation, I wrote a small REST application that can be found here, where all of the below examples can be found.

+ Documentation

Play’s website was very nice to use, clear to navigate around and included plenty of sample projects to look at. This is all so very useful when looking at a framework for the first time and can’t be underestimated. Everything I needed when writing my example project was easy to find in the Scala documentation and it covered everything in a way that I understood (not as common as you’d think!).

+ Routes

I really liked Play routes. It felt like a natural separation to keep the routes in a configuration file away from the rest of the Scala code. You simply define the route and direct it to a method in the controller, no fussing with syntax or boilerplate. Once you start to accept payloads or query parameters there is a small amount of googling to find out the exact syntax and how to pass them into your method, but nothing too scary or time-consuming.


– Guice

Play comes pre-packaged with a dependency injection framework by Google called Guice. I can’t say I’m a fan of Guice, I particularly found it to be a huge barrier when using Play as a beginner. It’s quite “magic” in the way that it does a lot of things you can’t see and, everyone knows, when magic goes wrong it’s even harder to understand and fix.

Also, as Scala developers we have come to depend on the compiler, and in most cases if it compiles, we already have a decent amount of faith it will work. Guice introduces these runtime errors into your code which is a HUGE downfall. These errors are often misleading or confusing when the project becomes more complex.


Furthermore, Guice seems to make testing quite difficult to get going with. Granted, I didn’t spend that much time battling with it, I’d already lost my temper with Guice a long time ago so my patience was wearing thin. I just found the effort in understanding what I had to do and what was going on completely unnecessary. Even though I would use Play in the future, I would not use it with Guice.

+ User Interface

Play comes with a user interface without any extra effort required. At first it may not seem like a big deal, especially if you are planning to return json objects. However, the UI helped me quite a bit when I was testing endpoints or getting runtime errors cough *Guice* cough. As shown below, if you get the endpoint wrong, it shows you all the endpoints that are available to you (thumbs up from a lazy developer).


+ Json formatters

On Play’s website it claims they aim to make Json a first class citizen. So, the good news is Play was the only framework where I successfully manipulated the json I was sending or receiving in one sitting. I was able to negate the need for certain unnecessary fields in the json to maximise usability. For example, I nested my case classes, even for those values that only needed one field like this:


This meant by using the default Play json formatters, I would need to be writing json with extra “value” fields like below. sad face.


Another example would be that you would ideally want to model your data with one case class, for example a pet:


This means this case class will model what your json will look like in the request and the response. However, it may be misleading or confusing to ask for an ID (also shown in the above json) when someone is ‘registering’ a pet, yet our service needs to respond with an ID when the user ‘GETs’ a Pet so they can use it later to update or delete.

Thankfully, Play json custom formatters (and Options) gives you a huge amount of flexibility.

Here is my custom formatter for the above examples:


– Compilation: When and How long

Play, by default, has “just in time” compilation. I realise this doesn’t sound like a huge problem, and I would agree, but it did get a bit annoying when doing what should be very quick manual tests on the endpoints. Not only do you have to send the request and wait, you have a to wait quite a while – Play does seem to be very slow 🙁 This also means that you don’t get your compilation errors until after you’ve sent a request for the first time:


which is almost as bad as runtime.

+ Cycle time

I realise that speed and usability are factors that are largely subjective and are not a clear reflection of the framework alone. However, I can claim that compared to the other frameworks I’ve had a ‘first look’ at, this tops my list in this category. The documentation is extensive and clear to navigate around, there are many templates available and every question I asked Google was answered dozens of times.

As for going from zero to service; along with the routes I have shown above, all you need is to add this to your build.sbt:

playbuildsbtand add your method straight to a class that extends Controller:


That’s it. No nasty boilerplate and nothing that isn’t directly focused on the service you want to build.


Play came out top favourite in a poll we ran during our talk in the Scala Exchange! I think this is mostly down to the excellent support and documentation you get if you choose Play, you never feel like you’re the only one who’s approached a particular problem. I saw the biggest downfall was the way it introduces runtime errors to a language that loves to depend on the compiler – I would definitely get rid of Guice.


  • I found a book by Underscore incredibly useful that can be found here. Great for beginners!
  • Activator is an excellent tool for developers to get started with SO MANY tutorials.
  • This blog by Krzystof Pado is great at looking at all of the dependency injection techniques you can use with Play – excellent read if you are looking for an alternative to Guice.

Sofia x

Continue Reading

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

Sofia x


Continue Reading

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!

Sofia x

Continue Reading

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!

Sofia x

Continue Reading

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.

Sofia x

Continue Reading