Oscar Funes

Published on

On switching teams, projects, technologies

I recently changed teams, which also included moving from Node.js to Java and Spring. The switch has been harder (and more interesting) than I predicted. At first, it felt rigid and verbose, especially in the JSON parsing department. Having to state every expected property, or configuring the parser to ignore additional properties, feels unnecessary. But learning has been an exciting ride, especially since I’m trying to participate more in design and opinions around architecture than on code. Among the hardest things for me has been integration testing and feeling like I nailed the correct approach when doing encapsulation and abstraction. Even though, at the same time, I feel like perhaps I’m the one overcomplicating. The reason I’m writing this is to talk about what will be some of the decisions I’ve taken with this change. And I want to explicitly NOT talk about code or technologies.

Don’t disturb the zen garden

One of the first things to cross my mind was to try and not disrupt the cadence of the team, only enhance and help. How I plan to achieve that? By being helpful and finding things to do to familiarize myself with the technology and work on things that are a bit on the end of the backlog (I don’t know how possible will that be). Also, ask questions, and participate in conversations without being too pushy on opinions without having more context into previous decisions, and design choices.

Don’t go and try to change everything

One thing I’m trying to be careful of is to learn the idioms of the project. Not try and disrupt with other practices or patterns. Might just be me, but I want to understand the inner workings of the code before adding, and much before starting to think about how to refactor. Treating it effectively as legacy code is a good starting point for me. Because, I’ll go through tests, check coverage, understand how it does something, and wonder why it does it that way instead of X o Y reason I can come up in my mind. My next step would be to suggest quick wins in regards to refactoring the code, or tests. Going back to the book, working effectively with legacy code, and finding some things to apply immediately.

Participate positively in discussions

I’m regards to emails or chat rooms, I actively ask about the context of decisions, advise on new features, and try to come up with new use cases. Worst case scenario, my question is out of scope, and I will learn about it, or it could prove to be helpful.

Help, help and help

I’ll to help as much in the project as I can be it with code reviews, stories, bugs, and anything that needs answering (and I can explain). I’ll have a few weeks only to see the code, talk with the developers and just go through documentation. I hope this will ease the beginning of the project. I hope this passing of information to me will help me to help other external people to the project.

Brook’s Law

“Adding manpower to a late software project makes it later,” — Brooks’ law While I don’t think that I can stop this from happening, I don’t want to ignore this fact and make everyone believe a timeline or earlier delivery date is achievable.

I want to make sure (without heroics) we can attain improvements (not including schedule) in other areas, like design patterns, or code reviews, and better architecture overall.


In the end, anything the team feels that I can help with I’m here. And to impact positively, as much as I can, like a positive ion resulting from a photon impact.