跳转至

25 An Interview with Fernando Cejas

Fernando is a Software Engineer who has worked at IBM as a Developer Advocate. He has also spent time working at SoundCloud as a Mobile Core Engineer and, prior to that, at Flomio and Tuenti as a Mobile Software Engineer. Fernando is a huge fan of agile methodologies, programming, and tech in general. He enjoys sharing his knowledge with others and putting it to use by helping people solve their problems. His urge to share what he knows has turned him into a prolific public speaker.

Fernando CejasFernando Cejas

Connect with Fernando

Website: fernandocejas.com GitHub: github.com/android10 Facebook: /Penano

Interview

You are one of the most senior and well-traveled people in the industry—tell us a little more about yourself.

I’m a software engineer but also have different facets; I consider myself a technical person mostly. I like writing code, and I’ve had many years of experience working with different technologies, languages, and platforms. Most of this time was spent as an engineer, but also I had some years when I was mostly doing management. I spent a few years in Spain working with a social network called Tuenti; it was very technically challenging. Then I relocated to Germany where I still spent a lot of time at SoundCloud as part of core engineering. Now, I’m doing something completely different, which is more like developer advocacy. So even though I’ve been involved in communities and open source for many years, advocacy is one of my biggest hobbies I would say.

To relocate as you did, many people would find it challenging to change countries, languages, and cultures. Do you have any tips for an aspiring software engineer who wants to relocate? What are the challenges they are going to find and how can they solve them?

The biggest challenge is at the start when you first relocate. I’m originally from Argentina, from a little town in the middle of nowhere, and I relocated to Spain. Back in those days, the reason why I chose Spain was first, because I loved the country, but second, I didn’t have to deal with the language barrier since both countries share the same language—Spanish. Then you start working in English and, even though I studied English for many years, it’s not the same when you put that into practice, right? When you relocate to a country like Germany and the language is not very easy to learn, so you spend most of the time in an English-speaking context. Once there, I would advise not to be shy.

In order to learn you have to make mistakes all the time. You ought not to be afraid of making those mistakes. Just talk, talk, talk. In my case, of course, I definitely had to learn some basics. But go for it. And, sometimes we feel like we can survive with just English because English is kind of easy to learn. But you will definitely go a step further if you learn the host language, and you will integrate into the country, which is super important when you’re living abroad. It’s important in order to open up your mind, to evolve your mindset, and to really understand what’s going on around you. Sometimes it feels like I don’t know what’s going on here, but sometimes it’s the language barrier that is holding you back. So don’t be shy. Go for it and keep in mind that there are other people who have gone through this process. Just speak words out—it doesn’t matter.

My doctor, when I first tried in German, said, “Oh, you speak like a three-year-old kid,” — but in a sweet way. Now, she has seen my evolution, even though it’s not perfect.

Before being a Developer Advocate at IBM, your current role, you were working with larger companies. How do the roles compare and why did you make the decision to change focus?

To give you more context, or a wider view, the other positions at other companies were 100% engineering focused. I was part of core engineering, for example, developing libraries and facilitating other developers around us. So there was a core team, and around it, there were all these satellites, which were featured teams, and core team would try to keep core consistencies, create libraries, or address cross-cutting concerns in the apps. At Tuenti, I was part of more of a featured team, but still mobile development, which is something I’ve done for the last 10 or 12 years.

I always liked being involved with communities. I’ve done organization for Google developers in Barcelona, for example, for something like G-Talk. I’ve also done open-source writing. It’s something I’ve been doing in addition to my day job, while also working on engineering.

Here’s the thing: At some point, I wanted to turn that—or to try to turn that—into my day-to-day life. I said, okay, so, I’ve been doing engineering 100% for a while. Maybe it’s time to change a little bit of my career path to see how it feels. Going to a conference and creating a relationship with others and being active in the community is something I really enjoy. There are pros and cons, and I’m still working out what parts I like the most.

I consider myself a team player. I like to work with people, I like to communicate, I like to create stuff. I like to, for example, chat with someone or go to the whiteboard and come up with a solution, write down the stuff do some collaborative programming. That’s something that is more likely to happen if you’re an engineer in an office—or even a remote engineer. You have a team working on a specific bunch of nationalities within the codebase, for example. But this developer advocate position is kind of more isolated.

You probably have more flexibility in your work, and the work is more research related. You’re understanding a product—you’re understanding the need and you’re trying to create relationships. But, in the end, you do this mostly by yourself. When you have to showcase something, you create a presentation. Of course, you have a team and you collect some feedback, but the creational part, working together with someone else, like doing some pair programming, doesn’t really exist. Maybe this is the way how the company is handling this position, but that’s what I’m seeing in the community overall while exchanging feedback with other developer advocates. It involves a lot of travel as well. Sometimes, it feels like you’re not at home. But sometimes you want quiet times and a routine—that is less likely to happen in this position.

If you want to write code 100% of your time, a developer-advocate position is not one you would go for. It involves all these aspects that are very time-consuming. Of course, I always said the more senior you become, the less code you write like an engineer. You do have initiatives and are still in touch with the code itself. But this position is more about organizing, preparing presentations, emails, creating relationships, talking to many people, organizing events, and more.

You’re mostly a remote worker in this position. Is remote work something you’d recommend companies implement for their employees? If they are interested, how should they get started?

This is the 2.0 way of working nowadays. I would say if you’re not going remote, you’re missing a lot of talented people out there because not everyone is likely to or has the chance to relocate somewhere else. But moving in this direction is challenging, and I’ve been doing some advising on this. One of the challenges is if you have part of your team on site and the rest is remote. When you have a very low number of remote workers who are part of a team, they can feel outside of the team. If you think of your team behavior, for example, when you talk to someone from the team, if you’re in an office, you might not start a video call. You’ll probably just gather whoever is in the office together then and go to a room and to have a discussion.

That’s what I’ve been seeing so far. It’s very important for remote workers not to feel isolated and that they feel part of the team. There are tons of tools out there, especially for communication. A company itself must be prepared for remote work and to have the tooling and organization to handle different time zones, for example. Overall, I’d say it’s easier when 100% of the company is remote to avoid these issues.

Instead of “remote,” I’d call this kind of organization “distributed.” I would definitely encourage any company to have employees distributed as you’re missing a lot of opportunities if you are not doing that. Something surprising to me is the big players who don’t allow remote work; my company does. It’s surprising because they’re supposed to have the young mentality and so forth, but they’re not in the present or the near future. It’s not like the old days when we suffered from a lack of tooling. It’s easier now.

What are some tools you use daily that you would recommend to others?

Slack, of course; it’s such a simple tool capable of PTOs, conferencing, chat or even just phone calls. That’s my main communication tool.

For development, as I’m a big fan of mobile, in this case of Android, Android Studio is my tool; there pretty much isn’t a time when I do not open it. I like the tool Visual Studio Code. I think it’s very lightweight—kind of in the middle between a powerful text editor and IDE—so it’s kind of a hybrid. It’s super fast and there’s a big community around it.

I would also have to say my terminal. I mostly picked Linux as my operating system for the last couple of years. I had been a Linux user in the past, but then, you know, you take the chance to change your machine. I’ve been using macOS, which is super good, too, and the core itself is Linux. But I like communities. I use ArchLinux, and my command line tool. I’m not the most expert Linux user, but I like doing things on the command line. I’m basically using Bash, so not a big deal. Not these fancy terminals that exist nowadays, but my own customized Bash terminal.

With whatever tool you use, how do you start your day to set yourself up for success?

I have two techniques for staying productive that I use that are lessons learned. I try to avoid things like procrastination that we all suffer from sometimes; it’s impossible not to procrastinate at all, but at least you can minimize it. The first one is a personal routine. When we are talking about actual methodologies, I use a Trello board. This is a personal board. Every day, by the end of my day, I just take five to 10 minutes to plan out my next day. Sometimes, of course, there are things that come up out of nowhere, but most of the time you have this structure and, after your coffee, you know what you will be working on. For productivity itself, I use the Pomodoro Technique—these windows of time of 15 minutes, then you stop five minutes. Then you have another 15 minutes, and so forth until the fourth time when you have a bigger rest. That’s something that helps to really focus me and minimize the amount of procrastination. Those are my two main tools.

In addition to tools, are there any resources, like books or podcasts, that you’d recommend that have had an impact on your life?

I do listen to podcasts, but I’m more a fan of books. I have a visual memory, so I memorize more when I read rather than what I hear. That’s why I struggle more with language learning. I prefer going over books first—understand and create a relationship and then keep it in my mind. So for books, more technically, I’d first say Refactoring: Improving the Design of Existing Code by Martin Fowler. That book was a game changer for me; it’s when I understood how important testing is. It was about changing all this internal structure and extraction with all these patterns for refactoring and making your code better. The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt is another classic.

When I was a teenager, a game changer for me was El Principito—The Little Prince. It’s one of those books that doesn’t have one read—“Oh, this is about love and this is about that.” You could relate that metaphorically. In this case, it focused on the human relationship with someone you liked or loved so much, and someone who is an important part of your life.

You’ve been influential in the community with the blog posts you have written, especially in the Android ecosystem and your post on clean architecture. What’s the origin of the clean architecture post, specifically?

I remember the days of facing some challenges with other colleagues working on a social network we were starting to scale. We found that the architectures out there were good practice but would not really fit within our needs. We needed a new way of architecting mobile applications, in this case, Android, that would definitely fulfill what we were needing back then.

We had a lot of discussions on the board and basically grabbed other good practices and experiences from other areas, in this case, backing. At some point, I was interested in what Robert Martin, Uncle Bob, was saying about clean architecture, and I saw it as a very simple way of separating concerns. That would give us a code base that would make our lives easier in terms of firsts—problem-solving, scalability, modernization and testability—and that would mean that this architecture would be independent of frameworks. At the time, we were attached to frameworks. We didn’t have enough tooling to test and refactoring was a nightmare. At some point, we said okay, we need to rethink this. To be honest, that took time. I tried to evolve what we did in the company, and I spent some time at home thinking and trying to come up with something simple, as well.

I learned a lot in the process. It evolved super fast and people were coming up with new ideas and things. In the first version, failing in many different ways, I learned a lot. I think that’s the most important part, here: seeing the learning process and how people have been modifying that code and adapting it to different areas. It turned out it worked. It was about bringing already-proven things from other technologies to mobile legacies.

You’re a very seasoned speaker, traveling the world, sharing insights like this. How can a new developer unfamiliar with public speaking get started?

I think this is a recurring topic nowadays because of the content consumption and content generation. There is so much information out there, and many people are jumping on board saying that you should talk at conferences or write articles. In my opinion, you should only talk if you really like it, and if you have something to say. Some people just ask me, “How can I start?” And my answer is always: “Do you really like it? Or is the environment is pushing you towards this direction?” One of the things I have in mind is I get it out whenever I have something to say. I think, for me, it’s mostly about giving back to the community.

But if you really want to try it, I’d say start simple and work towards complexity. So if you haven’t tried it, but you want to know whether you would like it or not, you can start by starting with your company in front of a tiny meetup. For example, in my company, I implemented something that is called a five-minute talk. Once a week, we prepare a concept or something new to learn that would take five minutes to explain. So we spend half an hour and there are four speakers, let’s say. It’s a cool starting point for speaking and sharing ideas, and then you will realize whether you like it or not. Maybe then you could go after showcasing something to your colleagues—then going bigger and bigger if you really like it. If you don’t like speaking, you can apply your ideas to some papers, blogs or articles.

There is so much out there when we talk about content generation. Again, with public speaking, start from the little stuff five-minute talks maybe, or just maybe one day take the lead in a big meeting—a meeting with five to eight people maximum. As developers and engineers, we have a reputation for being introverted, and many people struggle with speaking in public, with communication, and so forth.

I used to be shyer, myself. But you can also go to conferences and start socializing, trying to make yourself a little bit more extroverted by sharing what you know.

What is something that you didn’t know when you started as a software developer that you wish someone had told you that you had to learn the hard way instead?

I wish someone would have pushed me and convinced me, when I began my career, that testing your code is important. I’m pretty sure we all started writing code without tests, and I would say, “Yeah, this is not worth it. Why should I spend time on this?” But there are so many benefits, and, of course, asserting that your code behaves as expected is something that we should always keep in mind. Writing tests for me should be something that is part of our engineering process. It should be implicit when we are writing code. We shouldn’t talk about testing and talk about writing code. They should be together. You want to make sure that the code you’re writing is behaving as expected and that would help out with refactoring. Nowadays, you know that refactoring is about changing the internal structure of your code and not the behavior. That means you still want the same behavior, which is internally asserted by the test battery that you have.

I wish I would have known that before because I would have avoided many issues. I would have avoided wasting my time on so many occasions.

“For any tool, we, as professionals, need to be open, to collect feedback, and to try out new things.”

What are your thoughts on test-driven development?

TDD is one of the more useful things I’ve found in the last few years. I’m not an expert, and, most of the time I don’t do it. But it’s nice for super complex development. Sometimes it could be a little bit more challenging, but it’s one more tool in your toolbox. But if you’re strict with the way you write code, it’s also possible without TDD. Sometimes people don’t feel comfortable by just following this red/green/refactor, like writing your code, make it fail, refactor it, and make the test to pass. So use it if you feel comfortable with it. It can depend on my mood! It can also depend on the programming language or platform.

For any tool, we, as professionals, need to be open, to collect feedback, and to try out new things.

Fernando’s Recommendations