David Montesdeoca

I am a software developer with over 10 years of experience building products for companies spanning from small startups to scaling unicorns. For the most part of my career I have worked as a full stack developer, with special focus on the backend side, developing products with clean, maintainable and testable code. I am used to taking full ownership of features and projects in agile teams from start to finish, from the conception of the idea to the deployment to production.

I am a very curious person who likes to constantly learn new technologies and tools. For the right project I am willing to work with any programming language.

I am particularly interested in mature agile projects developed using DDD and clean architectures (e.g. hexagonal architecture a.k.a. ports and adapters). I would love to be surrounded by people who know a lot more about those topics than I do and have the opportunity to learn new things every day.

I value very positively that the company contributes with the community, with open source projects, technical blog, talks, etc.

Last year, I created my own blog where I talk about stuff that I believe may be interesting to others or that would have been helpful for me to have come across earlier.

I always try to write clean, readable, simple and maintainable code; applying design patterns and SOLID principles that I consider relevant in each case. I read as much as I can on those topics to strengthen my knowledge and I try to apply what I learn in both new and legacy code, whenever possible.

I strongly believe it is tremendously important to be consistent in everything we do as a team. Therefore, we must be committed to maintaining coding standards defining style guides, using linters, etc.

The way I see it, the purpose of DRY is not fully understood in our industry, as we usually end up with the wrong abstractions, causing more problems than solutions. And I think that is especially true for tests, where I consider WET (Write Everything Twice) is a better option, easier to understand and to modify if necessary.

The information that can be added to the description of a pull/merge request and a commit is too valuable to overlook. That's why I apply the best practices that have long been described on this post and include the references that helped me to find a certain solution.

Also I consider that doing pair programming can help to create better quality code.

Some of my references in the industry: Sandi Metz, Thoughtbot, Shopify, Martin Fowler, Janko Marohnić, Codely, Evil Martians, Kent C. Dodds, Kent Beck