19
Grow professionally as a backend developer. Interview with Javier Gomez – Backend developer at Apiumhub
We are continuing with our interview series ( previously we had interviewed Diego Ojeda – Android Lead at Apiumhub and Serhii Zabolennyi – QA Automation engineer at Apiumhub ) and today we have a Backend interview with Javier Gomez – backend developer at Apiumhub.
In this interview Javier gives advices for junior developers who are hoping to grow professionally as a backend developer and shares his programming style, his favourite books and how he deals with the unexpected as a backend developer.
What advice would you give for junior developers who are hoping to grow professionally as a backend developer
Professional life is really different from what you learn at university.
In their first years, I would recommend that they won’t have salary aspirations. The current marketplace is on a high trend, and you see guys that start with a good contract and have a really good salary in their first job. The problem with some of these contracts is that they are for some kind of work, very specific, monotonous sometimes, and with little personal development. But the attractive salary at the end of the month retains you and at the end, stops your growth.
I highly recommend that in the first years of a professional career, their aspirations would be to surround themselves with the best professionals as possible, and be beside them and learn everything from them.
The tentative idea of finding a high salary on your first contract exists, because the market is on a continuous high trend, but I recommend that they won’t think about that, for now. If you find a good place where they bet for your professional growth, even if they win less money at the end of month, I would invite them to consider this alternative. This money that they will be missing to win, they have to see it as an investment in their personal growth. And that, at the end, is an investment that will help them higher in the future, both professionally and economically.
Another recommendation is that they won’t accommodate on the first job that they find, that try different things, with the aim to decide what they really like.
At the end of all, I simply recommend that they won’t lose their growth ambition, won’t have fear of going out of their comfort zone, and that they live there as much as possible, until it forms part of their professional lives. This will give you an agility and a capacity to pivot at any moment, from language, paradigm or architecture, to provide the best possible solution that the client needs. And this is an extra value in a developer.
Living inside their comfort zone is an indicator that you aren’t doing the things well, that you aren’t growing. For this reason I suggest that live outside of it, at the beginning is hard, but as soon as they start, it will be part of their lives early, they’ll learn to manage to live with it, extracting all the possible value from the situation.
Definitely, Never Stop Growing.
It’s part of the job, you’ve to assume it. Both the product and the market to which it is intended is something in continuous evolution, you have to be conscious of that. You can’t start from the premise that the requirements can’t change, they can. Our code has to be flexible enough to evolve in a fast way and without risks.
For that, I try to base my work on clean code practices and SOLID principles. This isn’t a guarantee that a requirement change doesn’t imply that you’ve to completely redo a portion of code, but it helps you to minimize the impact of these product variations.
I would describe it as Pragmatic, but always based on good practices. Always you have to adapt to the needs of the problem, and the purism limits ourselves a lot. There are some minimum limits that aren’t negotiable, choose the proper testing techniques based on the testing pyramid, apply the clean code principles, with the aim to have the best code quality as possible. And try to put our code near the business language, basing it on the Domain Driven Design.
At the end, the purist rigor takes away flexibility, capacity for adaptation to the problems of the real world. Our job is to give solutions to real problems for our clients, the programming style is a technique that we use, and the good practices are our tools. You require knowledge to have the capacity to make decisions to know which to use where and when.
For that, I would like to think that I’ve a pragmatic programming style, and I apply the needed practices at every moment, without adding boilerplate.
Yes, I readed some books, read isn’t my passion, but I do it for my professional growth. From all of them, I found some that were really easy to follow and gave me a lot of value. I would like to highlight:
- Clean Code and Clean Architecture (Robert C. Martin): Regarding Clean Code, it lays down a foundation of elemental good practices for the daily work of any developer. It will help you to question how you do your work and if you can do it better, teaching you a lot of techniques and in which context you should apply them. Clean Architecture is an iteration from the first one, where it takes the good practices to the software architecture level. Is really similar to the Clean Code, but the iteration that it does is really interesting to go furthermore in our software quality, given that it talks not only about our code design but also all of our application.
- DDD Distilled (Vaughn Vernon): As it name says, is a distilled version of his other book, Implementing Domain Driven Design, and is a fantastic starting point for learning about DDD. It helps us to put our code close to the business, this have a lot of advantages, like using the same language as the business part of our company or client (Ubiquitous Language). It will help us to structure our repository in the same way as the product is being modeled. This book is perfect for understand what DDD is, and gives us a lot of techniques to make it possible. Having always the possibility to take a look at the original book in case of wanting to go deeper in some topics that we can see on this distilled version.
- TDD By Example (Kent Beck): Testing is a fundamental tool for the software development. TDD is one of the more known software development techniques that allows you to create features with the minimum code needed with all the possible quality through tests, which give us information about what should and shouldn’t do the software.At the beginning could seem a waste of time, or that it give us little profit compared with the effort that it requires to apply this technique. With this book we’ll see the goodness of TDD, where we will go step by step, from less to more, in an easy understandable way, with a lot of examples and being able to put it all on practise from an early step. I highly recommend give an opportunity to this book, it will change the way of thinking about the importance of testing and specially this development technique, TDD.
19