Ana, Vanessa, Anne, Pam

For a while, I thought it was time for me to start mentoring, helping others. But I always felt that I was not prepared to do it, so I kept postponing this moment as far as I could.

Back in March, Women Who Code London put together an online meeting to talk about mentoring. I was so enthusiastic about it because I would learn what I needed to become a mentor and help others. 

But as usual, things didn’t go as I expected: they didn’t have a magical formula that I could use and become a mentor, but they gave me an excellent framework to start from:

  • Know each other: make space to introduce ourselves and talk about non-work stuff in every meeting.
  • Define a goal: Make sure the mentoree knows what they want to achieve and that this goal could make them grow professionally.
  • Find ways to track their progress.
  • Timebox the sessions
  • Give feedback every session so we can see the actual progress.

This framework was great, but I was still with no mentoree and no courage to apply in that meeting to have one; I thought once again: I’m not prepared.

A week later, when I was in a meeting just for women engineers at work, I got the courage and offered to mentor. And I was relieved when I saw that nobody came forward because after all, you know, I was not prepared 😉 .

And then Vanessa pings me in slack, and everything changes: I realized I can teach and learn a lot. So we adapted the framework to our needs, and since then, we have been meeting every week.

A month later came Pam, and three months on it, Anne decided to give it a shot. 

And it has been a fantastic experience! I got lucky with these three mentorees because they all needed different kinds of help from me. So that made me realize that your experience can help others, not just your knowledge. And that each mentoree is different, and that gives these sessions such an enrichment. I have learned a lot in the past few months with these three women, and I hope they have learned something from me too. 

I’m grateful to them because they allowed me to teach them, but in reality, they teach me: you don’t realize what you can do to help others until you put yourself out there. So be brave and say you want to help, and all the rest will come naturally. After all, you are already prepared 😉 .

2019 in review

This year started as just another year: I started doing a Swift bootcamp as I had done the year before, and once again, it was an amazing experience. I learned a lot with all the beautiful Ladies that went to the bootcamp, I hope they learned something from me too 😄.

In April, I started a new job and with it came a lot of new challenges: No Storyboards 😱, functional programming, and pods all over the codebase. But I was working with a phenomenal team of wonderful people, that helped each other and pulled together to make the product a better one. I still miss you guys 😄.

For personal reasons I moved to my favourite city in September: Barcelona. New house, new and old friends, a new company with a new team. And what a team! Definitely you don’t need to go to London to find amazing developers. I have my challenges too, still no storyboards ☹️ , but no pods 💪, and loads of RxSwift… Still don’t know how to react to that 😉.

2020, is getting closer and everything seems to point out it’s going to be a very good year. May the best things about 2019 be your worst in 2020.

Happy new year!

12 weeks

Last Wednesday, was the last night of a 12-week Swift bootcamp that I gave in collaboration with TECHKNOWDay and hosted by TheCurtainLDN. And I’m already missing it!
This group of Ladies was awesome: even though they were tired and wanted to go home and chill out, they persevere and come night after night.
And we finish our app. A simple Weather app, that searches for a city and then grabs the weather for it through an API. 💪
Inspired by the BBC weather app, we follow the curriculum of Apple’s program #EveryoneCanCode. It was hard, frustrating, unbelievable, colossal and for me, it was mainly fulfilling: It’s so lovely when you see these Ladies learning and applying all the knowledge that you were trying to teach them. Nothing is more rewarding than hearing all the exclamations of joy when they put something to work! It is something that there are not enough words that can explain it. I was an apprentice too, and I know how frustrated it that can be, but it’s way better when finally you can do it.
And these Ladies can do it!

iOSCon 2017

The 2 days came and gone, so fast you couldn’t believe, it all had ended so fast!
As last year, the organisation was excellent and everything went really well…

I enjoyed all the talks that I attended and had some difficult decisions to make, the two tracks made choices impossible sometimes.
So here are my considerations:

First day

Please don’t lose the master class from Dan Cutting, The Grand Tour of iOS Architectures. A really good explanation of all the MVC, MVP, VIPER, CLEAN and FLUX or REACTIVE architectures/patterns.

Another talk not to lose is TDD in Xcode Playgrounds by Paul Ardeleanu: The power of TDD in a playground showing you how to quickly get feedback from your tests, and how can you then move the tests to your project.

Swift on the server was well represented by this workshop: Workshop: Building a server-side Swift app with the Kitura web framework by Chris Bailey and Ian Partridge.

If you are looking for a new job, please don’t skip Ace The Technical Interview by Abizer Nasir. Very good advises there.

Second day

You get to venue with mixed fillings: you are super excited for the new talks ahead, but you are also exhausted from day before…you are starting to think that your brain can’t take much more, and you sit down to listening to the keynote by Daniel Steinberg, and you definitely start to rethink your life. Why? How? What?

Another great talk was Going Universal: Building an app for Mac, iPhone, iPad and Apple TV (and staying sane) by Adrian Thomas where he explains the process of building and app not just for the iPhone, focus on how to organize your code (essentially your shared code) but not forgetting the UI and how you should maintain some core elements between the different versions of your app.

Unfortunately, there is no video for this excellent workshop by Phil Nash: Test Driving Swift To The Max – with or without the tests!. Very enlightening and using AppCode instead of Xcode.
Building better iOS apps with GraphQL, doesn’t have a video too, but was a really nice talk about how to talk to the server without a REST API. Will it be the next hype on iOS?

And that’s it, folks! Next year there will be more.
It was really nice to reencounter friends and make some new ones and learn new things.
Never stop learning!

When a good architecture helps you in your UI design iterations

I’m currently working on an internal app for Codurance, which started as a pet project while I was working with my previous client. I started the project with one simple goal: to make it work. After six or seven months of trying to put it all together in my spare time, I ended up with a skeleton of a working app. However, I wasn’t entirely satisfied with my work. Even though I had been test-driving all the code and all my ViewControllers were as light as I could imagine, I thought it wasn’t enough. So I decided to carry out a big refactoring and apply the VIPER architectural pattern.

So what’s VIPER?

VIPER stands for View, Interactor, Presenter, Entity, and Router, and it’s a version of the clean architecture applied for iOS. It’s not my intention to take a deep-dive into VIPER in this article, but if you are interested in learning more, (here)[], you have a good definition of the architecture, and here you can find a good explanation that can help you decide if you want to use it in your app or not. The section “Benefits of VIPER” in this article explain quite well why I decided to use VIPER.

Make it work

So as I explained, originally my main objective had been to make it work. And I did. With my big refactoring in place, I finished my goals for the app in no time, having the major features working. The app looked like this at that time:

This version had several problems: The way to add or delete new TimeEntries was completely obscure for a new user: you had to swipe the cell to see the buttons. I was using this pod: SWTableViewCell to achieve this. I was happy because my app was working, but I was sad because it wasn’t an app that I would like to show off. So I had a talk with our UI expert, and we decided to start iterating till we get the UI into a more satisfactory state.

First Iteration: Copy Google Calendar

Even though this app is not a calendar app, it all revolves around time entry. So we first looked at apps that had the objective of entering timed slots of work, but most of them were more like Excel sheets than apps. And because my initial idea was to have a list of TimeEntries, we looked at the Google Calendar App. The simplicity and clean design called to us, so we decided that could be a good first step to do a similar design and iterate from there. It looks better, doesn’t it? But there were still usability issues I wanted to address… I was insisting on having this swipe version because as a user, I prefer apps that have all at hand and I don’t have to go into several different views to achieve something. So I was kind of insisting on just having a one view app.

Second Iteration: Remove hidden functionality

So with this in mind, and playing a little with colors (I must confess that the colors here are my fault 😊 ), we added the functionality to the only view of our app. Giulia helped me to improve usability and the result wasn’t that hard to implement. She also decided to have 3 different views of the data since we have 3 types of user: the ones that update their hours daily, the ones that do it by week, and the ones that only do it once per month.

Third Iteration: Trying to have insertion in just one line

As you can see I’m very bad at choosing colors, but right then we were more worried about having everything that was related to a new insertion on just one line and about keeping it simple. The delete functionality stayed in the swipe, but that is an expected behavior from an iOS app, so we were ok with that.

Fourth iteration: Playing with colors

Finally, Giulia dedicated some time to me (I guess she was horrified with my colors choices 😜 ) and decide to have a look at the colors. Notice the difference? Me too…
But we were not yet happy with the insertion line. The field to search activities was too small and the stepper was too big in comparison.

Fifth Iteration: Add a picker view

The fact that now we have a PickerView gave us the space we needed to have a big text field. It all looks more harmonious and is still doing what I had in mind: just use one view to do everything in the app.

What VIPER had to do in all this

As you can see, I had to change the UI several times and some were radical changes (for example, we had a version where we tried to put the insertion line in the bottom, after the list). But because I had everything really independent and a good separation of concerns, I just needed to change my UI elements and wire them into my ViewController and there you go, everything else would work like a charm. The longest that it took me to make these changes was two days, partly because I had some problems with AutoLayout.


The decision to adopt the VIPER architecture was a good decision, and even though I don’t have a big set of new features coming up, I really appreciate the fact that I always know exactly where I have to go to find something in the app. We still have some functionality that we want to add to the app, but I think that the design is largely done. Another thing that I felt was that I didn’t want to “kill the designer” when Giulia appeared with new ideas that would make me change all of the design. It was really simple to adopt and painless. And that’s definitely a good thing to have.

Server Side Swift

In December 2015 Apple open-sourced Swift, which has been a real success. Many developers are contributing, not only via pull requests directly into the source code, but also by helping to define the shape of the language in the swift-evolution repository.
One of the things that came with Swift was server-side development. There’s a new version of Swift developed for Linux with a toolset that includes a package manager, the LLDB debugger, and the REPL. This opens a whole set of new possibilities for a lot of companies, such as IBM who are currently making a huge investment in its framework Kitura.

So why?

  • Compared to Python or Ruby – it is super fast and a type-safe language.
  • It is a language which allows developers to write expressive code.
  • As an iOS developer, you can stay in the same technology stack. If you need to develop a Web service for your iOS app to retrieve data, you can write that in the same language, using the same tooling…
  • Devs love Swift 🙂

So, what’s on the market?

There’s a lot of small frameworks that take advantage of these new possibilities, so have a look here where Edward Jiang does a great job of introducing four of the more promising frameworks already in the market. I’m divided between Vapor and Kitura:

  • The first one is growing in popularity and is starting to be the one to used in all tutorials that I’ve picked up:
    • It’s inspired by Laravel
    • Aims to be expressive and simple to use
    • Has great documentation
  • The second, Kitura, is from IBM, which reveals the extent of their belief in the advantages of this approach to application development. Alongside the core framework, IBM has also invested in:
    • A package manager, which allows developers to add their own packages
    • A sandbox environment, to allow developers to test Swift on the server-side
    • A Cloud server that is specialised for deploying Swift

Kitura is based on Express.js, so if you are already using it you will find almost no differences at project level structure and so on.

If you want to have a look of all the stack that IBM has, you can go here.

Can you convince me?

You are a backend developer and you thinking: “Nah… I’m not going to learn a new whole language…”
Well, don’t forget that Swift, first of all, is a type-safe language. And it’s a hybrid in that it supports Object-Oriented and Functional programming. A huge advantage of this is the ability to introduce yourself into functional programming, but still be “safe” in your object-oriented skills.
Yes, you would have to learn a new language… But it’s Swift!
Not convinced yet? Take a look at these 2 articles that compare server side Swift (in this case Vapor) with a lot of other well-known languages:

Please note that these tests were made before Swift 3.0 came out.


If you are a iOS developer, and you need to have a Web service for your app, you should definitely consider one of these options, since you won’t need to learn another language to deploy your Web service. If you are a backend developer, you can always learn a new, type-safe, language and then who knows? Maybe start creating your own iOS apps?

Mastering TDD

Two weeks ago I went to Paul Stringer’s course “Mastering TDD/BDD in iOS”. After the two days, I was exhausted… During the course, we looked at all the theory, completed some exercises. Paul gave us lots of links and books to read and, quite frankly, I was feeling overwhelmed.
I saw myself in front of the computer, with all those links to follow and read, and I didn’t know what to do… So I laid back on my chair and closed my eyes and thought… What do I know about TDD?

Following the rules…

Well, I know that it has laws:

  • You must write a failing test before you write any production code.
  • You must not write more of a test than is sufficient to fail, or fail to compile.
  • You must not write more production code than is sufficient to make the currently failing test pass.

I know I should follow the circle Red – Green – Refactoring:

  • Red – Create a failing test
  • Green – Write enough code to make the test pass
  • Refactor – Clean up your code and your tests (don’t forget that your tests are code too)

This works well to enforce the three laws of TDD. And as Kent Beck said:

Make it work. Make it right. Make it fast.

If you want to know all about the cycles of TDD, here is an excellent article by Uncle Bob

Going to your favorite school…

And there are schools… well not physical ones:

  • The Detroit/Chicago School or the Classicist approach
  • And the London School or the Mockist approach.

The first one uses real objects/classes and it tests the state of those objects. The second tests collaboration between objects and for that it uses mocks.
You have this article by Sandro Mancuso and this other by Jonathan Rasmusson that can help you distinguish them better.

Knowing your friends…

As an iOS developer, I tend to be more of a mockist since I drive my tests from the UI. And developing an app in Swift has some challenging aspects since we don’t have a Mocking framework… We do it all “by hand”…So yes knowing very well what kind of test double you need is a good thing. People tend to call them all mocks but as Martin Fowler said here:

Mocks aren’t stubs

But if you still have doubts about test doubles, this excellent article by Uncle Bob will definitely shed a light on it… (and I even found a version for Swift here). Magical!

Setting your priorities

Yes, that’s a really important one: use the Transformation Priority Premise to avoid big steps and to guide you into the generalization of your code. As Uncle Bob said:

[…]Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing its behavior. Transformations are simple operations that change the behavior of code.

Another good article is this one by Pedro Santos.
Don’t forget that during the refactor phase your design skills are put to test: as Sandro Mancuso said here:

TDD is not a design tool. It’s a software development workflow that prompts for code improvement in its lifecycle. […]
The great thing about TDD is that it is constantly asking us “Hey, can you make your code better? See how hard testing this class is becoming? OK, you made it work. Here’s your green bar. Now make it better.”

Having good habits

TDD must be approached like a discipline. You must have good habits to stick with it. Here is the TDD good habits manifesto. This came up for the first time in SoCraTes UK ‘16 in a form of a session facilitated by Mani Sarkar and Pedro Santos, where they challenged us to add or remove practices to their original draft that you can see here.


Well, it seems that I have a minimum knowledge about TDD. Still need to practice a lot, and apply what I have learned when coding. Here are some books that you could read:

Socrates UK


Just came back from SoCraTes UK, and it was amazing as always.
I’m looking at this blog post for 10m now, trying to explain what is SoCraTes UK and still don’t have the correct words… First of all, this is an Open Space Conference, which changes completely the ambient: people go there to share their knowledge not just to receive. And this sharing is what really matter in here…
Second I saw again some good friends that I’ve met before in other SoCraTes( You can check here at the end of the page, the other conferences).

As for the conference itself, I went to several talks about team management, feedback, empathy, and TDD… The second day was really hard, I was running from one place to another because all were amazingly interesting.
The first day I went to:

  • “Identifying signals for feedback loops” by Alastair Smith. A very interesting talk about how a project that had constant positive feedback was canned. We all try to identify where did this feedback fail. Some conclusions here

  • “How to change company structure to support Agile” – this was an interesting workshop where we started to naming all the practices related with Agile/Software Craftsmanship and then in a small group try to come up with ideas of how to convince our managers to accept then.

  • “Compare Craftsmanship and Fashion” by Alvaro Garcia. A really really interesting talk about how craftsmanship can compare with fashion… The main thing to retain is that as we ways wear underwear and just change our clothes as we go, the same happens with Software craftsmanship: our values are always there we just change the tools we use. Here are our thoughts

  • “Integration Design: 5 principles to craft better interfaces” by Giulia Mantuano. A very good talk about all the concerns we must have to give the user a better experience when he uses our products.

And that’s pretty much the first day…we had several lightning talks and after dinner a very entertaining time playing “The Professor”. There were a lot more activities and I had a really nice talk with Dominic Freeston about iOS and Swift.

The second day was a nightmare: all the talks in the market place were looking pretty much amazing and I just wanted to be able to clone myself so I could attend all of then… I really use the law of two feet this day!

  • “Smells (like team spirit) – Common team smells and how to refactor them” by Spike – As all the others, a very interesting talk about how to identify a team smell and how to deal with it in several situations…

  • “Sports and Development” by Houssam Fakih– Interesting point of view: training sports and training development skills.

  • “CQRS – Building an event system from scratch” by Emilien Pecoul– Workshop on CQRS in any language of your preference. Amazing! Here are some photos

  • “Small Small Talk talk and basic Visual Basic visual” by Daniel Irvine – The best title for a talk, and it was revealing to know that almost 20 years ago there was already a test framework.

  • “Empathy” by Antony Marcano and Ryan Alexander – Excellent workshop on how you can react in difficult situations in a team. “Good cop” and “Bad cop” examples. Superb!

  • “Refactoring Developers Habits” – by Mani Sarkar and Pedro Santos – Workshop about best practices in TDD. Here’s what we had to work on and here are some proposals.

We all came back to the main room for reflexions, retrospective and feedback. Still had time to more lightning talks. After dinner was time for me to leave…

Hope to see you all back again next year!

iOS Con

Yesterday finished iOSCon, and I just wanted to let you know how good it was. Yes, that’s right, It was really good to see so many iOS developers want to learn different things a and share their knowledge.
First of all the organization has my +1 because everything went so smooth. And for getting such a good panel of speakers. The only thing to point out is that the second day was far better than the first one, and having two tracks with impossible choices to make.

From the first day, I’ll recommend you to watch this talks:

And then the Lightning talks session special the one presented by Abizer Nasir, on how you can burnout in this job.

The second day started with Daniel Steinberg talked to us about Understanding your Toddler given us some insights of how Swift has evolved and what’s coming with Swift 3.0.
And then it was really a big struggle to choose the next one … Fortunately, you can just watch everything here. I would like to recommend you to not miss these ones:

What was really enlightening was to see that all speakers in a way were talking about the same thing: separation of concerns, clean code, clean architecture. It seems that Software Craftsmanship finally hit the iOS world. Good to know!

Code Smells – Part II

In the last post, Code Smells – Part I, I talked about the bloaters: they are code smells that can be identified as Long Methods, Large Classes, Primitive Obsessions, Long Parameter List and Data Clumps. In this one, I would like to dig into the Object-Orientation Abusers and the Change Preventers.

Object-Orientation Abusers

This type of code smell usually happens when object-oriented principles are incomplete or incorrectly applied.

Switch Statements

This case is simple to identify: we have a switch case. But you should consider it a smell too if you find a sequence of ifs. (That’s a switch case in disguise.)

Why are switch statements bad? Because when a new condition is added, you have to find every occurrence of that switch case.

So while talking to David, he asked me: and what happens if I encapsulate the switch into a method, is it acceptable then? That’s really a good question… If your switch case is only used to “take care” of one behaviour and that’s it, then it might be ok. Remember identifying a code smell doesn’t mean that you have to get always rid of it: it’s a trade off. If you find your switch statement replicated and each replication has different behaviour, then you cannot simply isolate the switch statement in a method. You need to find a proper “home” for it to be in. As a rule of thumb, you should think of polymorphism when you find yourself in this situation. There are two refactoring techniques that we can apply here:

  • Replace Type Code with Subclasses
    This technique consists of creating subclasses for each switch case and applying the respective behaviour to these subclasses.
  • Replace Type Code With Strategy
    Similar to the above one, in this case, you should make use of one of the patterns: State or Strategy.

So when to use one or the other? If the Type Code does not change the behaviour of a class you can use the Subclasses technique. Separating each behaviour into its appropriate subclass will enforce the Single Responsibility Principle and make the code more readable in general. If you need to add another case, you just add a new class to your code without having to modify any other code. So you apply the Open/Closed Principle.

You should use the Strategy approach when the Type Code affects the behaviour of your classes. If you’re changing the state of the class, fields and many other actions then you should use the State Pattern. If it only affects how you select a behaviour of the class then the Strategy Pattern is a better choice.

Hmm… It’s a little confusing, no? So let’s try with an example.

You have an enumeration EmployeeType:

And a class Employee:

It all looks ok. But what happen if you need to calculate the year bonus? You will add another method like this:

See the repetition of the switch? So let’s try first the subclass approach: Here is the superclass:

And here we have the subclasses:

With the Strategy approach we would create an interface for calculating the remuneration:

With the interface in place, we can now pass to the employee any class that conforms to that protocol and calculate the correct salary/bonus.

Temporary Field

This case occurs when we are calculating a big algorithm that needs several input variables. Creating these fields in the class has no value most of the time because they are just used for this specific calculation. And this can be dangerous too because you have to be sure you reinitialize them before you start the next computation.

Here the best refactoring technique is to use Replace Method with Method Object, which will extract the method into a separate class. Then you can split the method into several methods within the same class.

Refused Bequest

This code smell is a little tricky to detect because this happens when a subclass doesn’t use all the behaviours of its parent class. So it’s as if the subclass “refuses” some behaviours (“bequest”) of its parent class.

In this case, if it makes no sense to continue to use inheritance, the best refactoring technique is to change to Delegation: we can get rid of the inheritance by creating a field of the parent’s classes type in our subclass. This way every time you need the methods from the parent class you just delegate them to this new object.

When the inheritance is the correct thing to do, then move all unnecessary fields and methods from the subclass. Extract all methods and fields from the subclass and parent class and put them in a new class. Make this new class the SuperClass, from whom the subclass and parent class should inherit. This technique is called Extract Superclass.

Alternative Classes with Different Interfaces

Hmm, this case makes me think of “lack of communication” between members of the same team because this happens when we have two classes that do the same thing but have different names for their methods.
Start by Renaming Methods or Moving Method, so you can have both classes implementing the same interface. In some cases, only part of the behaviour is duplicated in both classes. If so, try Extract Superclass and make the original classes the subclasses.

Change Preventers

Oh boy! This kind of code smells are the ones you really want to avoid. These are the ones that when you make a change in one place, you have to go basically throughout your code-base making changes in other places too. So it’s a nightmare that all of us want to avoid!

Divergent Change

This is the case when you find yourself changing the same class for several different reasons. This means that you are violating the Single Responsibility Principle (which has to do with separation of concerns).

The refactoring technique applied here is Extract Class since you want to extract the different behaviours into different classes.

Shotgun Surgery

This means that when you make a small change in a class, you have to go and change several classes at the same time.

Even though it seems the same as the Divergent Change smell, in reality, they are opposite of each other: Divergent Change is when many changes are made to a single class. Shotgun Surgery refers to when a single change is made to multiple classes simultaneously.

Here the refactoring technique to apply is Move Method and/or Move Field. This will permit you to move the duplicated methods or fields to a common class. If that class doesn’t exist, create a new one. In the case where the original class stays almost empty, maybe you should think if this class is redundant, and if so, get rid of it by using Inline Class: move the remaining methods/fields to one of the new classes created. This all depends on whether the original class still has any responsibilities.

Parallel Inheritance Hierarchies

This case is when you find yourself creating a new subclass for class B because you add a subclass to class A.

Here you can: first, make one of the hierarchy refer to instances of another hierarchy. After this first step you can then use Move Method and Move Field to remove the hierarchy in the referred class. You can apply here the Visitor pattern too.


In the case of Object-Orientation Abusers and Change Preventers, I think that they are simpler to avoid if you know how to apply a good design to your code. And that comes with a lot of practice.

Today I’ve talked about a few refactoring techniques, but there are a lot more. You can find a good reference to all of then in

And as I said in the first part of this series, code smells can’t always be removed. Study each case and decide: remember there is always a trade off.