Background
Software Engineer since 2007, my professional career has given me a great experience building applications in many different languages and domains spanning health, energy/oil/gas, media and retail. I am a quality-focused engineer with over 5 years of experience leading technical teams of 10+ including coaching and mentoring offshore teams.
I have a solid understanding of object-oriented programming and functional programming paradigms applied with extensive experience on test-driven development (TDD) and pair programming techniques. I have delivered production applications in many different languages and platforms including Go, Elixir, Ruby, Javascript/Typescript, Scala, Java, Android and iOS.
Values
I believe in transparency, servant leadership and constant — two-way — feedback. I’m constantly challenging user’s value and scope and I feel pretty excited about social impact. I also believe that people can do amazing things given the right opportunity, and I also believe that opportunities can be created.
I also enjoy speaking/attending conferences, coaching, sharing knowledge and contributing back to the software community.
Ways of working: I have led a number of programs on the path of continuous delivery, with a focus on technical capability uplift and the realisation of benefits including shorter cycle time of features released to end-users.
I consider myself an easy-going person. I tend to avoid challenging the status quo without building a rapport around the environment and I try to listen and learn how things work first.
I appreciate knowledge sharing, thoughtful code reviews and pair programming. I wouldn’t be so confident and happy about my career if I didn’t have the input from the people that I had the chance to work with.
I like to apply TDD whenever is possible and I try to keep my changes small. I also believe in discipline and code that favours the ability to refactor and good design. I understand that good design is subjective, so I tend to ask some key questions while I’m coding, such as:
- Is my code easy to maintain?
- Is my code easy to change?
- Is my code easy to read?
- Is my code expressive enough?
When doing code review, I tend to be flexible by encouraging follow-up PRs to address minor changes so that features can be unblocked as smaller PRs are being shipped. That also means a smaller scope of changes and fewer risks of breaking things.