Leaving Redbooth

It’s difficult for me to talk about this and it was a few days ago when I had to tell my workmates about my decission, leaving Redbooth. I started with that startup from Barcelona when I haven’t finished my bachelor yet. They gave me the opportunity to work remotely and I did my best. I help firstly the iOS team when the company’s name was aready Teambox. Then I learnt a bit of Android when thought that I was able to help them and I thought why not?

It was difficult for me at first because I was used to Objective-C patterns and tools like XCode, Cocoapods, … Moreover the project was a bit messy but I did my best and then I improved the Java I had learnt at the University. I have to say that it was a great opportunity for me that I took advantage of. Since then I’ve done different mini projects/libraries in Android and I want to keep learning it (although I keep my strong opinion about the tools Google’s offering that are not as good as they shouln’t if we compare them with XCode for example)

I missed iOS, since I moved to Android the iOS team had implemented the iPad version, new components and some other interesting features. I wasn’t any more than a Junior developer in Android and I told the company about joinning again iOS as soon as they had a senior Android to replace me. Months later I ended up moving to iOS again until now.

Things I learnt from Redbooth

I’ve learnt a lot of since during these months in Redbooth that I will never forget and that have made me a better developer. Some of them has been:

• Git: I remember the first meeting we had with the lead and the team to talk about us, about our experience and how Teambox iOS Universal was organized. I didn’t know a lot about Git, if I had used it before it had been usint graphic tools and the first task that day was to learn Git. I use it almost everyday for all my projects and only form console. Once you get used to the Git commands I think that it’s easier and you can get rid of these graphic tools. We used Github, and its different features like Issues, Milestones, Releases, … We even had a bot to let you know about cowboys in the project!

• Work in a team: I had never worked before in a team. Projects I had done before were of maximum two people (Dropbox was our Git) and Trello was our collaboration tool. When you join a team you learn how important is to be coordinated with the team, and with the company’s track. When this feature has to be implemented, these bugs have to be fixed because QA team reported it, you should review that PR to see if everything is ok, … Moreover you can talk with your workmates about implementations, architectures, code structure… I enjoyed using Redbooth as a collaboration tool and learnt how powerful it can be if you use it perfectly.

• Guidelines: This point is related with the previous one. When you work alone there are some points you don’t pay attention to. Overall these related with the code style. In the same way you need a language to communicate with others and you have to use it properly when you work in a team you have a language that is the code language and some rules that tell you how to use the language. Without these rules everybody would do what he wanted. We used them for Objective-C style (forked from New York Times) and one part of the PR review was to review if the style points were respected.

• Architecture: When you work in a project that becomes bigger and where new features are coming every week you have to pay attention to your project architecture. In Redbooth we stopped to think about it some months ago when we read about VIPER and saw that we were not respecting SOLID and Clean Architecture principles. That made the code difficult to debug/test/read and understand. Our experience refactoring these components with VIPER has been very satisfactory. We refactored the biggest components and improved day by day the concept of VIPER inside the Redbooth iOS Team. I even developed a generator in Ruby https://github.com/pepicrft/viper-module-generator and I’m going to give a talk in the CodeMotion event.

• Cowboy, but sometimes: Working in a team where everything is planned, where you have an schedule of tasks that you have to follow during the week makes you loose your cowboy side. It’s not bad when the company has a certain dimension (you cannot be doing what you want because there are priorities). However you shoudln’t lost your Cowboy side because it keeps your motivation alive. I’ve sometimes received some pull of ears by my workmates for being more Cowboy than what I should.

Change of pace

It was difficult for me to take de decission, specially due to the previous points but I was very motivated with the new project and the idea behind it. The company is giving its first steps as a startup and it was a chance for me to learn about how to build a company from the scratch and work closed to the product (at least more than what I did in Redbooth). I’m going to have more flexibility now because I don’t have a fixed space of work or office. I can work at home, from a Coworking space, from a coffee, or even from the world. I’m totally conscious that this is an adventure that I cannot miss. I have a lot of hope in the project and I’m going to do my best to do it a successful project and company to help a lot of users to get in shape and keep a good health.