Living By The Code

Projects | Links: GoodReads Website

Living By The Code

Living by the code is a book I took part of, which is for anybody who is struggling to make their mark in the competitive tech industry. The content provides advice from different IT professionals in order to help you out to make your best career move.

“Be open and try new things.”

Personal Thoughts

I was invited by the author to take part of this great project. I had no doubts cause I have always wanted to write a book and that would be the closest chance I would have at the time of this writing. Totally grateful.

I had the honor to be interviewed by Enrique López Mañas to share and expose lessons learned, mistakes and career advice during my trayectory in the IT area during the last 15 years.

A very fulfilling experience and totally recommended to every single person who bumps into this opportunity.

Project Description

Living by the Code: Reflect, Refactor & Refresh: Top Developers, Leaders & Innovators in Tech Share the Career Advice They Wish They’d Had When They Started.

Reflect, refactor & refresh! Top developers, leaders & innovators in tech share the career advice they wish they’d had when they started. It’s like chatting over coffee with your favorite people in tech — but better!

fernando-cejas

Project Duration

  • 3 months. Starting in January 2019 and ending in April 2019.

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 at SoundCloud, 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 the 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 feature 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. I’ve also done open-source writing. It’s something I’ve been doing in addition to my daily job, while also working on engineering.

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

I try to avoid things like procrastination that we all suffer from (it’s impossible not to procrastinate at all, but at least you can minimize it).

My first tip here is to have 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 spend 5 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 and as a second tip, I use the Pomodoro Technique.

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 VEEEEERY 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.”

Some Book Reviews

“Pretty good book when you are looking advice for your career.”

“Amazing tips and hacks that I am sure I will use in the course of my career. As an entry level Software Developer, I have gained a lot of value from this book.”